N
N
Nikolai Volkotyuk2022-01-13 07:51:21
Books
Nikolai Volkotyuk, 2022-01-13 07:51:21

How to improve your skills in building the architecture of complex applications?

Work experience as a programmer for 6 years, but the lack of specialized education makes itself felt.
It's easy to start riveting a program procedurally. It's easy to start building a simple architecture. Problems begin when there is already a massive, partially working program, and it turns out that some parts do not match with each other or external sources, or even part of the architecture needs to be redone. This is unpleasant - sometimes it's easier to start writing from scratch than to delve into thousands of lines.
Of course, the described situation is already rare, measures have been taken, but still I understand that you need to improve your skills in building architecture. I understand that now I'm more of a low-level coder than an architect.
Now I'm reading "Design Patterns" from head first in order to have a good knowledge of basic programming patterns. What else do you recommend? Not too abstruse, but not for beginners either.
The programming language, I think, is not important here, since it is rather a theory

Answer the question

In order to leave comments, you need to log in

7 answer(s)
D
Dmitry Belyaev, 2022-01-13
@acces969

If, according to theory, then this book helped me at one time:
https://www.litres.ru/robert-s-martin/chistaya-arh...
Moreover, after 1 reading, I didn’t understand anything, but I began to try to implement practices from a book to everyday development. He wrote down all his blunts in a notebook.
At that moment, I was faced with the task of bringing a piece of noodles into a somehow supported state. He was the one who inspired me to read this book.
A few months later I read it again, analyzing all the blunts that I wrote down in a notebook during this time. After reading it, I began to slowly refactor places in existing projects that really interfered with life.
After another half a year I read it for the third time, again with an eye to personal experience. And here I seem to have completely entered. At least many problems with the organization of interaction between components began to be resolved. And in general, there was a fairly clear understanding of how to structure the application and where to break it into components.
Well, after 3 readings, the moment also helped: I was given to design a new, fairly large application in Rust from scratch. Moreover, the customer shouted "microservices are cool, I want, I want, I want," and the team leader told me "let's get a monolith, but so that it would be easy to cut later, otherwise we'll miss all the deadlines." This is where understanding comes in. Well, plus in Rust, architectural components fit very well into separate crates (this is such a compilation unit in Rust), and the compiler, in principle, does not allow cyclic dependencies between crates.
Well, I recently decided to refresh my memory and re-read it again. And this time there were already thoughts like "so if you do it differently, then problems will come out here and there."

A
Alexander, 2022-02-02
@Arlekcangp

1. It helps to start learning with simple design patterns. First of all, these are simple and understandable patterns such as "strategy", "command", "iterator", "template method", "intermediary", "chain of responsibilities". Having studied and understood these patterns, you will look at OOP in a new way: not as just structured code plus data in one object, but exactly as its creator intended - an object is an independent unit interacting with others through messages. Moreover, it is the first class, just like a function in functional programming. In addition, the rest are built on these patterns. For example, a factory method is a special case of a template method. So gradually the understanding of where and why to apply various patterns will come.
2. When solving any problem, think of several architecture options for solving it. Next, try to choose
the option is not based on personal preferences or previous experience (it does not matter, positive or negative), but on the basis of an analysis of which of the options is really needed here in terms of the further development of the project. Previous experience should also be taken into account, but every project is different, the requirements are different, and each situation may be different. You need to look at how system and functional requirements can change or expand (of course, for this you need to be in the context of these requirements - that is, to know them, the manner of working with the customer's project, etc.) In many cases, when you cannot choose due to lack of information, this will logically lead you to ask the customer additional questions. And through this iterative process comes an understanding of where and how to apply the patterns.
3. Pay attention to the patterns of ERP systems (for example, the book "Templates of Enterprise Applications" by Martin Fowler) Particular attention should be paid to such a pattern as dependency inversion. This template personally helped me to take a completely different look at OOP (for the second time, after I began to apply other OOP patterns) Here https://blog.byndyu.ru/2009/12/blog-post.html is very clear in my opinion it is described (C# language but everything will be the same for any OO language) In addition, this blog has a lot of design and refactoring stuff.
4. Pay attention to the book "Growing Object-Oriented Software, Guided by Tests" by Steve Freeman But the book is useful because, unlike many other books on TDD, it understands not only the methodology of testing and writing tests, but also the principle of test -> code -> refactoring. And understands on a fairly long example. From it you can learn the habit of refactoring rather than rewriting. Moreover, even if you have a different cycle on the project - for example, tests are written after the functional, the way of thinking will still change and large-scale refactoring will not cause an irresistible desire to throw it away and rewrite it from scratch.
5. On refactoring, I can recommend the book "Working with Legacy Code" by Michael Feathers. In addition, there are many articles about this in the already mentioned blog of Alexander Bindu. Roughly speaking, I would call that collection of articles "how not to rewrite and start
living " .com/2013/08/blog-post.html
7. Study materials gradually. Do not immediately try to stick the newly acquired knowledge into the first project that comes across. Discuss possible solutions with colleagues. Over time, they will also support this practice. If possible, practice pair programming. And not necessarily with a more experienced colleague. Sometimes the questions asked by a naive person make you think much more strongly than the answers received from the sages.

S
Sergey Gornostaev, 2022-01-13
@sergey-gornostaev

Read books on this topic, work on projects where more experienced colleagues build complex architectures, participate in this within your power.

V
Vitaly Belenky, 2022-01-20
@heman

It is ideal, of course, to get into a big project with experienced colleagues.
Clean architecture is a useful book.
A series of videos on request "modular monolith" helped me. ArchDays
2020 • Modular monolith instead of microservices • Denis Tsvettsikh (Epam)
Modular PHP monolith as an alternative to microservice architecture - Julia Nikolaeva,
iSpring https://herbertograca.com/2017/07/03/the-software-... It's hard to get into my head. Above, a colleague wrote about his approach: constantly try what he learned in practice and review decisions.

Z
Zaporozhchenko Oleg, 2022-01-13
@c3gdlk

Try to work in companies and on projects that take time to write texts. With tests, the code is easy to refactor and you can try different options pretty quickly, you learn quickly yourself.
But a book is much better. You have chosen a great book, try to implement patterns from it. At least in thought experiments

D
Dmitry Makarov, 2022-01-20
@MDiMaI666

Do a lot and expand the area of ​​responsibility. And you will think for yourself. The main thing you will know is not how but why to do it. Only practice.

A
Alexander Skusnov, 2022-01-13
@AlexSku

But still, if a little abstruse, then Functional Design and Architecture (Alexander Granin). Video with explanations on FreeMonad
.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question