"Plasticine" architecture
I think any project manager or lead programmer at least once encountered a situation where the application code suddenly found itself completely confused, incomprehensible, and people who supported it, in response to a request to correct an error or add new functionality, were sent “to the astral” for a few days , taking with them a fair share of the budget and, returning, presented an even more confusing code with a corrected error, but an added pair of others.
And you, as the person responsible for the project, at the same time there was a mixed feeling of annoyance, dissatisfaction with the work of their programmers and expectations of unpleasant consequences that necessarily follow a failed project that went beyond any reasonable framework and was spending the budget almost uncontrollably.
Most failed projects have one pattern. They are completely devoid of structure. I call the architecture of such systems "plasticine."
')
Well-designed systems seem to me wire cubes that have clear edges, defined by the architecture and smooth lines, implemented with competent code. If you need to make a change in them, in the right place the wire frame is unwound, new parts are added, after which everything is assembled again. Such systems are tough, they are easy to understand and the structure is visible almost immediately.
But, unfortunately, there are others. I am afraid that they are the majority. These systems are like shapeless plasticine. First, a small ball of basic functionality is created. Perhaps somewhere in the depths of his hidden wire frame competent and thoughtful architecture. But then everything changes. Every new feature, every new fix and modification is made hastily, according to the principle “just to work”. Each time, making such a correction, we take a lump of clay and stick on the side to the existing system.
There may be a dozen such corrections, a hundred, or even a thousand. Pieces of plasticine are molded randomly, they are of different size and shape, there are many of them. In appearance everything continues to work, new functions are added, errors are corrected, but from the inside the system is rapidly becoming more complex and turns into a shapeless lump consisting of individual multi-colored pieces.
And so, at some point, a task appears that affects several components of the system. With a habitual movement, we sculpt another lump ... But suddenly we realize that some completely different function has ceased to work here. We fix it by sticking another piece, and we get errors in two more. And this is a chain reaction.
At best, it is followed by global, complex and very expensive refactoring, which destroys all hopes of supplying the system on time and within budget. At worst, the system is delivered “as is”, with a huge number of errors and the absolute impossibility of its expansion or modification. With rare exceptions, such a product fails in the market, the leader (in my opinion, deservedly so) is subjected to penance, after which he is sent into exile.
Why is this happening? There are many options, but three of them seem to be the most significant to me:
1. Inadequate time frames in which the project is executed.
All in a hurry, nervous. The customer is spinning like in a griddle, threatening the top management to break the contract. Not sleeping, having worked for three weeks without weekends, the project manager rushes around and shouts at the programmers to work faster. Programmers, living in the office for the last month and working on caffeine, are doing everything possible to quickly end this misfortune. There is no time to think. Design once. It is necessary to issue features. One by one.
Typically, such a project is choked in its own bugs. At the stage of acceptance testing, the customer will issue a list of one hundred thirty-five and a half errors, exactly ninety-eight of which are critical. And, oddly enough, they will indeed be critical. It will take one or two days to correct each one, taking into account the irresponsible “plasticine” structure.
I leave the results to the reader, taking into account the attitude to such projects in his own company.
2. "Floating" specification
If the initial specification of the project is not sufficiently detailed, the functions are described vaguely, and some of the functionality is not specified at all, then such a project is guaranteed to be in the risk group according to the “plasticine architecture”.
Initially, everything is designed and implemented “as it should be”. The system may have a normal structure, competent architecture and clean code. But at some point (usually closer to delivery, when shown to the customer), it turns out that some functionality does not exactly coincide with what the customer wants. And the trouble is that it was not described in such detail that it was possible to require the customer to postpone the implementation to the RFC phase after the delivery of the main project.
As a result, we find ourselves, in fact, in the previous case considered - an urgent need (the project ends, and the final payment is usually the largest) to make a large number of changes to the code in the absence of time and budget. Next - the plasticine com begins to grow, errors appear, even more errors, an avalanche of errors ... As a result, a global and protracted refactoring, or an unstable product.
3. The project is run on gravity.
This is probably the worst option. Nobody follows the programmers, actions are not coordinated, code inspections are not carried out. The project manager is limited by the fact that he checks for the presence of programmers in the workplace and, occasionally, skims the results of their “creativity”. This usually happens when you have to show a product to a customer.
Every programmer revels in freedom and "creates eternity." Half - reinvent the wheel. The other half fasten square wheels to it. They write code. Class by class, method by method. However, sometimes the code is added to the old classes or old methods by adding a couple dozen conditions to the branch. It's easier. So faster. So do not think. The boss is happy, the project is going fast. Obviously, to a certain limit. Then it's all the same plasticine ball. All with the same consequences.
As a result, the question arises: how to prevent the "plasticine" code. There are many important things that cannot be ignored:
The project must have a clearly identified developer responsible for the system architecture (moreover, not only at the start of the project, but throughout the development).
Regular code inspections are required, the participation of the manager in which is highly desirable. Even without being a technical specialist, he will have an idea of ​​how many mistakes his charges make.
All changes to the specifications should be fixed and the code should be rebuilt accordingly.
If possible, it is necessary to exclude any "patches". Yes, it is easy to destroy the “symptom” of the bug, but this is akin to treating the symptoms of the disease. It is not clear which body will be offended the next time this error appears.
But, in fact, I can only give one piece of advice. In my opinion - the most important: Thinking! To think before writing code, to think in the process of writing it and to think even after the code is written. Do not start writing code without thinking through the architecture, if you are a programmer. Ban it to your programmers if you are a manager. And the "plasticine" architecture will no longer appear in your projects.
And you, as the person responsible for the project, at the same time there was a mixed feeling of annoyance, dissatisfaction with the work of their programmers and expectations of unpleasant consequences that necessarily follow a failed project that went beyond any reasonable framework and was spending the budget almost uncontrollably.
Most failed projects have one pattern. They are completely devoid of structure. I call the architecture of such systems "plasticine."
')
Little abstraction
Well-designed systems seem to me wire cubes that have clear edges, defined by the architecture and smooth lines, implemented with competent code. If you need to make a change in them, in the right place the wire frame is unwound, new parts are added, after which everything is assembled again. Such systems are tough, they are easy to understand and the structure is visible almost immediately.
But, unfortunately, there are others. I am afraid that they are the majority. These systems are like shapeless plasticine. First, a small ball of basic functionality is created. Perhaps somewhere in the depths of his hidden wire frame competent and thoughtful architecture. But then everything changes. Every new feature, every new fix and modification is made hastily, according to the principle “just to work”. Each time, making such a correction, we take a lump of clay and stick on the side to the existing system.
There may be a dozen such corrections, a hundred, or even a thousand. Pieces of plasticine are molded randomly, they are of different size and shape, there are many of them. In appearance everything continues to work, new functions are added, errors are corrected, but from the inside the system is rapidly becoming more complex and turns into a shapeless lump consisting of individual multi-colored pieces.
And so, at some point, a task appears that affects several components of the system. With a habitual movement, we sculpt another lump ... But suddenly we realize that some completely different function has ceased to work here. We fix it by sticking another piece, and we get errors in two more. And this is a chain reaction.
At best, it is followed by global, complex and very expensive refactoring, which destroys all hopes of supplying the system on time and within budget. At worst, the system is delivered “as is”, with a huge number of errors and the absolute impossibility of its expansion or modification. With rare exceptions, such a product fails in the market, the leader (in my opinion, deservedly so) is subjected to penance, after which he is sent into exile.
A few reasons
Why is this happening? There are many options, but three of them seem to be the most significant to me:
1. Inadequate time frames in which the project is executed.
All in a hurry, nervous. The customer is spinning like in a griddle, threatening the top management to break the contract. Not sleeping, having worked for three weeks without weekends, the project manager rushes around and shouts at the programmers to work faster. Programmers, living in the office for the last month and working on caffeine, are doing everything possible to quickly end this misfortune. There is no time to think. Design once. It is necessary to issue features. One by one.
Typically, such a project is choked in its own bugs. At the stage of acceptance testing, the customer will issue a list of one hundred thirty-five and a half errors, exactly ninety-eight of which are critical. And, oddly enough, they will indeed be critical. It will take one or two days to correct each one, taking into account the irresponsible “plasticine” structure.
I leave the results to the reader, taking into account the attitude to such projects in his own company.
2. "Floating" specification
If the initial specification of the project is not sufficiently detailed, the functions are described vaguely, and some of the functionality is not specified at all, then such a project is guaranteed to be in the risk group according to the “plasticine architecture”.
Initially, everything is designed and implemented “as it should be”. The system may have a normal structure, competent architecture and clean code. But at some point (usually closer to delivery, when shown to the customer), it turns out that some functionality does not exactly coincide with what the customer wants. And the trouble is that it was not described in such detail that it was possible to require the customer to postpone the implementation to the RFC phase after the delivery of the main project.
As a result, we find ourselves, in fact, in the previous case considered - an urgent need (the project ends, and the final payment is usually the largest) to make a large number of changes to the code in the absence of time and budget. Next - the plasticine com begins to grow, errors appear, even more errors, an avalanche of errors ... As a result, a global and protracted refactoring, or an unstable product.
3. The project is run on gravity.
This is probably the worst option. Nobody follows the programmers, actions are not coordinated, code inspections are not carried out. The project manager is limited by the fact that he checks for the presence of programmers in the workplace and, occasionally, skims the results of their “creativity”. This usually happens when you have to show a product to a customer.
Every programmer revels in freedom and "creates eternity." Half - reinvent the wheel. The other half fasten square wheels to it. They write code. Class by class, method by method. However, sometimes the code is added to the old classes or old methods by adding a couple dozen conditions to the branch. It's easier. So faster. So do not think. The boss is happy, the project is going fast. Obviously, to a certain limit. Then it's all the same plasticine ball. All with the same consequences.
What to do?
As a result, the question arises: how to prevent the "plasticine" code. There are many important things that cannot be ignored:
The project must have a clearly identified developer responsible for the system architecture (moreover, not only at the start of the project, but throughout the development).
Regular code inspections are required, the participation of the manager in which is highly desirable. Even without being a technical specialist, he will have an idea of ​​how many mistakes his charges make.
All changes to the specifications should be fixed and the code should be rebuilt accordingly.
If possible, it is necessary to exclude any "patches". Yes, it is easy to destroy the “symptom” of the bug, but this is akin to treating the symptoms of the disease. It is not clear which body will be offended the next time this error appears.
But, in fact, I can only give one piece of advice. In my opinion - the most important: Thinking! To think before writing code, to think in the process of writing it and to think even after the code is written. Do not start writing code without thinking through the architecture, if you are a programmer. Ban it to your programmers if you are a manager. And the "plasticine" architecture will no longer appear in your projects.
Source: https://habr.com/ru/post/115628/
All Articles