Pure architecture. Part I - Introduction
This is a free and very brief retelling of the new book by Robert Martin (Uncle Bob) "Pure Architecture", released in 2018.
Software architecture is a bit like building architecture. The buildings also have a fractal structure: the buildings consist of compartments, the compartments consist of rooms, the room is of walls, the walls are of bricks. Programs, however, consist of modules, which consist of packages, which consist of classes, which consist of functions, etc. However, the variety of program structures is much wider than buildings, so Uncle Bob considers software architecture “more architectural” than building architecture.
In addition, the building architecture is easier to visualize in the head than the software, because we see buildings every day, and the program architecture is hidden from us inside the source code. Software architecture is like no other.
On the other hand, the software architecture must also be aware of the physical limitations, because programs run on real hardware with limited performance, memory, network bandwidth, etc.
')
What is good architecture? This is an architecture that meets the needs of users, business owners and programmers not only at the current time, but also with time .
“If you think that good architecture is expensive, then try bad.”
"The only way to go fast is to go well."
Uncle Bob has been writing code for over 50 years. He wrote a wide variety of programs: large, small, GUI, console, web, etc. And he came to the conclusion that the rules of architecture are the same everywhere! And even for 50 years they have not changed despite the huge increase in iron productivity.
Programming languages ​​have also become much better, but the basic constructs have remained the same: if, assignment, loops, etc. If you put a programmer from the middle of the last century behind a modern MacBook, then she will be fucked up first, but then she will normally write Java code in the Idea.
But for half a century a great experience has been gained, which has not yet been 50 years ago. The rules to which this book is dedicated were formulated.
Write a work program is not difficult. It is difficult to write the program correctly . This requires knowledge, experience and skills, which require a lot of time and discipline to develop.
When the program is done correctly, it is easy to maintain and make changes to it. There is a very low percentage of defects. It does not need hordes of programmers, tons of documents with requirements and clever trackers.
It sounds utopian, but Uncle Bob managed to work on such projects. But unfortunately, in most cases we have to work in conditions of terrible design.
Let's assume design and architecture are one and the same.
Architecture is not only the upper level, it is the top-level and low-level parts in general. One without the other does not exist.
The goal of the software architecture is to minimize the human resources needed to build and maintain the required system.
If the efforts are small and remain so throughout life , then the design is good. If efforts increase with each release, then the design is bad.
As an example, Uncle Bob shows a graph of a real project in which the number of employees has increased 50 times, but the number of lines of code has increased only 2.3 times (3M -> 7M). A more scary schedule is the increase in the cost of one line of code by ~ 40 times. Those. productivity dropped from 100% to almost zero. Programmers work diligently in their full force, but in fact can do nothing. And now the worst thing is that if the first release had to pay employees several hundred thousand dollars a month, then at the end this figure was $ 20 million a month!
Then Uncle Bob remembers the parable about the hare and the turtle. In it, the tortoise won the race, because the hare was too self-confident, went to bed and slept through the whole race.
The same is true with the development: the programmer behaves with the confidence that he will be able to roll out the product quickly and restore order later. However, the problem is that after the release he needs to make the next feature, otherwise he will lag behind the competitors in the market. In the end, his productivity in a few months will simply fall to zero and he will lose.
Further, he gives an example of an experiment conducted by a certain Jason Gormen, where he writes a simple program several times. And it turns out that with TDD, the first time is faster than even the third time without TDD. That is, if you write correctly, the result is faster.
The developer should be responsible for the mess he brings to the project. The quality of architecture must be taken seriously. But for this you need to know what good architecture is.
There are two values ​​- behavior and architecture.
Behavior means that the program meets the functional requirements and thereby brings money to business owners. The problem is that many programmers believe that only this is their job.
The second value is the quality at which the program remains in a maintained state. That is, it is easy to change. The complexity of the changes should be proportional to the scale of these changes, but not their form. The architecture should not make preferences for some forms in relation to others, otherwise the owners' requests will be more difficult and more difficult to implement each time.
What is more important - behavior or architecture? Managers think it's more important that the system works. But programmers should consider, on the contrary, that architecture is more important.
The Eisenhower matrix says that the important and non-urgent has a higher priority than the urgent and unimportant. And architecture is always important, in contrast to behavior, so it is of higher priority.
The programmer must fight for the architecture. A programmer is also a member of a business. Architecture is his responsibility.
To be continued...
opening speech
Software architecture is a bit like building architecture. The buildings also have a fractal structure: the buildings consist of compartments, the compartments consist of rooms, the room is of walls, the walls are of bricks. Programs, however, consist of modules, which consist of packages, which consist of classes, which consist of functions, etc. However, the variety of program structures is much wider than buildings, so Uncle Bob considers software architecture “more architectural” than building architecture.
In addition, the building architecture is easier to visualize in the head than the software, because we see buildings every day, and the program architecture is hidden from us inside the source code. Software architecture is like no other.
On the other hand, the software architecture must also be aware of the physical limitations, because programs run on real hardware with limited performance, memory, network bandwidth, etc.
')
What is good architecture? This is an architecture that meets the needs of users, business owners and programmers not only at the current time, but also with time .
“If you think that good architecture is expensive, then try bad.”
"The only way to go fast is to go well."
Foreword
Uncle Bob has been writing code for over 50 years. He wrote a wide variety of programs: large, small, GUI, console, web, etc. And he came to the conclusion that the rules of architecture are the same everywhere! And even for 50 years they have not changed despite the huge increase in iron productivity.
Programming languages ​​have also become much better, but the basic constructs have remained the same: if, assignment, loops, etc. If you put a programmer from the middle of the last century behind a modern MacBook, then she will be fucked up first, but then she will normally write Java code in the Idea.
But for half a century a great experience has been gained, which has not yet been 50 years ago. The rules to which this book is dedicated were formulated.
Introduction
Write a work program is not difficult. It is difficult to write the program correctly . This requires knowledge, experience and skills, which require a lot of time and discipline to develop.
When the program is done correctly, it is easy to maintain and make changes to it. There is a very low percentage of defects. It does not need hordes of programmers, tons of documents with requirements and clever trackers.
It sounds utopian, but Uncle Bob managed to work on such projects. But unfortunately, in most cases we have to work in conditions of terrible design.
What is design and architecture?
Let's assume design and architecture are one and the same.
Architecture is not only the upper level, it is the top-level and low-level parts in general. One without the other does not exist.
The goal of the software architecture is to minimize the human resources needed to build and maintain the required system.
If the efforts are small and remain so throughout life , then the design is good. If efforts increase with each release, then the design is bad.
As an example, Uncle Bob shows a graph of a real project in which the number of employees has increased 50 times, but the number of lines of code has increased only 2.3 times (3M -> 7M). A more scary schedule is the increase in the cost of one line of code by ~ 40 times. Those. productivity dropped from 100% to almost zero. Programmers work diligently in their full force, but in fact can do nothing. And now the worst thing is that if the first release had to pay employees several hundred thousand dollars a month, then at the end this figure was $ 20 million a month!
Then Uncle Bob remembers the parable about the hare and the turtle. In it, the tortoise won the race, because the hare was too self-confident, went to bed and slept through the whole race.
The same is true with the development: the programmer behaves with the confidence that he will be able to roll out the product quickly and restore order later. However, the problem is that after the release he needs to make the next feature, otherwise he will lag behind the competitors in the market. In the end, his productivity in a few months will simply fall to zero and he will lose.
Further, he gives an example of an experiment conducted by a certain Jason Gormen, where he writes a simple program several times. And it turns out that with TDD, the first time is faster than even the third time without TDD. That is, if you write correctly, the result is faster.
The developer should be responsible for the mess he brings to the project. The quality of architecture must be taken seriously. But for this you need to know what good architecture is.
The story of two values
There are two values ​​- behavior and architecture.
Behavior means that the program meets the functional requirements and thereby brings money to business owners. The problem is that many programmers believe that only this is their job.
The second value is the quality at which the program remains in a maintained state. That is, it is easy to change. The complexity of the changes should be proportional to the scale of these changes, but not their form. The architecture should not make preferences for some forms in relation to others, otherwise the owners' requests will be more difficult and more difficult to implement each time.
What is more important - behavior or architecture? Managers think it's more important that the system works. But programmers should consider, on the contrary, that architecture is more important.
The Eisenhower matrix says that the important and non-urgent has a higher priority than the urgent and unimportant. And architecture is always important, in contrast to behavior, so it is of higher priority.
The programmer must fight for the architecture. A programmer is also a member of a business. Architecture is his responsibility.
To be continued...
Source: https://habr.com/ru/post/443058/
All Articles