The terrible events in Ukraine have divided our history into ‘before’ and ‘after’ periods. The world will never be the same after the war. It’s hard to predict something in this situation but we can say for sure that IT has been affected by the war no less than other industries. And if in the good years companies could afford some indulgences, now the problems of payment, the breakdown of established ties, the decrease in the solvency of customers and other consequences are forcing them to think about optimizing development costs.
You can try to can optimize costs in different ways. For example, you may decide to fire expensive developers and recruit juniors, simply cut staff or lower salaries. But this way is rather a losing strategy. Let’s consider other ways for your business to survive.
Where do development delays come from? Yes, everything seems so easy to do as long as the project is small and simple. But as the project grows, the number of entities in it begins to grow at a frantic pace and they begin to conflict with each other, causing:
-
- Bugs. It is impossible to foresee all the options for the development of logic in advance. A significant part of the logic is revealed already on the product platform and results in bug reports.
-
- Finishing. At the stage of development and planning, it is almost impossible to foresee all the nuances of the task. As a result, you have to constantly expand the logic and provide for previously unplanned cases.
-
- Alterations. Not always identified nuances can be limited to finishing touches. Often you have to redo part of the program.
And the larger your project, the more bugs, imperfections and reworks occur. We know the projects that completely stopped developing, and were only engaged in support.
So how to achieve flexible architecture?
There is nothing new here we may add. All these hackneyed interview questions like SOLID, GRASP, clean architecture, DDD, and so on. Take a look at the marketplace project. The first thing that catches your eye is a large number of modules, such as modular architecture. Each module appears to isolate some functionality as much as possible. When it is isolated, we can always easily localize the source of problems and can always easily correct (fix bugs, complete, redo) this particular functionality without affecting other parts of the program.
The second thing you can see is that the whole program consists of duplicate modules. For example, several modules end in applications and frameworks. This is for educational purposes to demonstrate the interchangeability of each module. And to do so that at any time you can change the framework without prejudice to the rest of the application logic.
However, there are still some nuances that affect the number of bugs and, therefore, the speed of output to production. In modern development, it’s good practice to outsource as much of the code validation work as possible to the compiler rather than the testers. In particular, it is, therefore, preferable to use a class instead of a dictionary (HashMap) where possible.
Leave a Reply