Habr - Uma Chamber





When creating a new or non-standard solution, the architect / developer usually finds a compromise between what he wants and what is needed, taking into account the given constraints. And there is always the possibility of ultimately doing not what was expected or getting a far from optimal solution.



And if โ€œwe wanted the best, but it turned out as alwaysโ€ happens because of unaccounted for or changed requirements, then this at least can be explained. But sometimes there is a hole in the old woman and it becomes annoying to miss a childish mistake simply because of blurred eyes or because of the pitfalls of the real use of fashionable technology.



And in order to minimize the possibility of such errors, in many companies there is a practice of protecting an architectural solution before starting the direct development of a new large project. This can be organized as a meeting, an architectural review, or just a smoking room discussion. It all depends on the staff structure and size of the company, as well as on the set development processes.



But what to do if the company has one or two developers, or their experience is not enough for an expert assessment of the proposed solution? Or do they simply lack the time or desire to delve into other people's difficulties?



You probably already guessed that we are talking about using Habr as a platform where you can get real help from knowledgeable people.



Indeed, great feedback can be obtained through public comment. Moreover, writing an article for Habr is much easier and more convenient than preparing for defense at the architectural committee. There is no need to agree on the date and time when you can take people away from the main process. And they, in turn, do not need to immediately be included in the context in order to be able to participate in the discussion of details.



"In due time" I had the opportunity to participate in the work of the architectural committee of a large company. And the feeling after the end of each meeting was always twofold. On the one hand, it's great to get new experience and often real help. But it also happened that the usual discussion of a seemingly petty issue turned into a verbal battle, the echoes of which reached after several days.



I especially remember the experience of participating in the process of unification of the components used. It took more than a year and a half to reconcile the interface and implementation of one tiny library and required several complete rewrites of the entire implementation. As a result, a lot of wasted time for bringing the code into a usable state that would satisfy all consumers and a completely burnt out desire to do something like that again.



On this side, an article on Habrรฉ becomes just an ideal option when the company lacks the competence to organize a discussion of a complex issue. And most importantly, no matter what solution and advice you receive during the discussion of the article, no one forces you to follow them!



All Articles