Настоящие размышления посвящены анализу устоявшихся практик разработки программного обеспечения и поиску альтернативных решений, направленных на повышение эффективности процесса.
Сегодня я принял решение полностью переработать ключевую функциональность системы, учитывая, что существующая архитектура, формировавшаяся более трёх лет, перестала соответствовать актуальным требованиям. Многочисленные модификации привели к тому, что первоначальная структура утратила свою гибкость, а поддержка кода становится всё более затруднительной.
Вокруг активно обсуждается необходимость написания модульных тестов, однако я остаюсь скептически настроенным по отношению к этой практике. На мой взгляд, ручное тестирование функциональности в контексте всего приложения зачастую оказывается достаточным, тогда как автоматизированное тестирование отдельных модулей представляется избыточной тратой ресурсов.
Тем не менее, я прихожу к осознанию, что ключевым аспектом разработки должна оставаться корректность и чистота логики. Она обязана быть тестируемой, поддерживаемой и элегантной.
В попытке решить проблемы сопровождения кода был принят подход разделения на слои data/domain/presentation. Однако в условиях, когда разработка ведётся в рамках единой платформы, языка программирования и модуля, данное разделение зачастую приводит к неоднозначности при выборе места для размещения компонентов. Например, если сущность относится к бизнес-логике, но зависит от специфики платформы, её интерфейс размещается в domain, а реализация — в presentation. В итоге структура фактически сводится к двум слоям: интерфейсам и их реализациям, что ставит под сомнение целесообразность подобной организации.
Опираясь на практический опыт, предлагается пересмотреть догматические принципы, популяризированные, в частности, Робертом Мартином ("Дядюшкой Бобом"). Во-первых, смена платформы — крайне редкое событие, и в моей практике таких случаев не было. Во-вторых, даже код, соответствующий всем канонам "чистой архитектуры", с течением времени превращается в труднопереносимый legacy, поскольку предугадать особенности будущих платформ невозможно.
Более рациональным представляется подход, при котором архитектура проектируется исключительно под текущие требования, с учётом потенциального, но не абстрактного, масштабирования.
В качестве альтернативы предлагается следующая стратегия:
Таким образом, основной тезис заключается в том, что проектирование должно начинаться с решения конкретной задачи, а не с попытки предугадать все возможные сценарии будущего развития системы. Только после чёткого определения компонентной структуры и их взаимодействий следует переходить к реализации бизнес-логики.
This reflection is devoted to the analysis of established software development practices and the search for alternative solutions aimed at improving the efficiency of the process.
Today I decided to completely rework the key functionality of the system, considering that the existing architecture, formed over three years, no longer meets current requirements. Numerous modifications have led to the original structure losing its flexibility, and code maintenance becoming increasingly difficult.
The necessity of writing unit tests is actively discussed, however I remain skeptical about this practice. In my opinion, manual testing of functionality in the context of the entire application often proves sufficient, while automated testing of individual modules seems an excessive waste of resources.
Nevertheless, I come to realize that the key aspect of development should remain the correctness and purity of logic. It must be testable, maintainable and elegant.
In an attempt to solve code maintenance problems, the approach of separating into data/domain/presentation layers was adopted. However, when development is conducted within a single platform, programming language and module, this separation often leads to ambiguity in choosing where to place components. For example, if an entity belongs to business logic but depends on platform specifics, its interface is placed in domain while its implementation goes to presentation. Ultimately, the structure effectively reduces to two layers: interfaces and their implementations, which calls into question the advisability of such organization.
Based on practical experience, I propose to reconsider dogmatic principles popularized in particular by Robert Martin ("Uncle Bob"). Firstly, platform change is an extremely rare event, and in my practice there have been no such cases. Secondly, even code that complies with all the canons of "clean architecture" eventually turns into difficult-to-transfer legacy, since it's impossible to predict the features of future platforms.
A more rational approach is when architecture is designed exclusively for current requirements, taking into account potential but not abstract scaling.
As an alternative, the following strategy is proposed:
Thus, the main thesis is that design should begin with solving a specific problem, not with attempting to predict all possible scenarios for the system's future development. Only after clearly defining the component structure and their interactions should one proceed to implement the business logic.
Представленный подход предлагает прагматичную альтернативу догматическим принципам проектирования ПО, фокусируясь на реальных потребностях разработки, а не на абстрактных идеалах. Этот метод может быть особенно полезен в проектах с чётко определённой предметной областью и стабильной технологической платформой.
The presented approach offers a pragmatic alternative to dogmatic software design principles, focusing on real development needs rather than abstract ideals. This method may be particularly useful in projects with clearly defined domains and stable technology platforms.