Стас требует доказательства, что хорошая архитектура помогает решить проблему превращен...
Стас требует доказательства, что хорошая архитектура помогает решить проблему превращения кода приложения в большой ком грязи. Проблема выглядит так: кодовую базу все еще можно запускать, но развивать ее становится все тяжелее. Разработчики все больше времени тратят на исправление ошибок, согласование изменений и понимание старого кода, а не на развитие функциональности. Сразу замечу: Мартин и его «Чистая архитектура» — не единственный пример хорошего архитектурного подхода. Есть еще гексагональная архитектура, луковая архитектура. Все эти подходы говорят об одном: защищайте бизнес-логику от UI, хранилищ, фреймворков и прочей инфраструктуры. Нашел исследования по этой теме. Они сводят эту проблему к конкретным цифрам: — времени — ошибкам — стоимости сопровождения 👉 В исследовании Code Red: The Business Impact of Code Quality изучили 39 реальных промышленных кодовых баз и активность в 30 737 файлах. Авторы связывали качество кода с задачами из системы учета, историей изменений и временем разработки. Выводы такие: — код низкого качества содержит примерно в 15 раз больше дефектов; — задачи в таком коде решаются на 124% дольше; — худшие случаи по времени решения становятся примерно в 9 раз длиннее. Плохая архитектура — это больше ошибок, больше времени на задачи и хуже предсказуемость разработки. При этом проблема не просто в количестве строк. Большой файл сам по себе еще не проблема. Беда начинается, когда код трудно понимать и менять: обязанности перемешаны, методы и классы разрастаются, а одно изменение требует держать в голове слишком много неявных связей. 👉 Другая статья — Technical Debt and System Architecture. В ней исследовали две большие системы: примерно по 20 000 компонентов в каждой. Авторы смотрели на связность компонентов: — кто от кого зависит — где появляется центральный клубок — насколько изменение в одном месте может потянуть изменения в других Там хорошо видно, что дефекты распределяются по системе неравномерно. В первой системе центральные компоненты составляли около 31% файлов, но давали почти 70% всей работы по дефектам. При этом периферийные и изолированные файлы составляли около 30% системы, но давали всего 1.1% работы по дефектам. Во второй системе ядро составляло около 26% файлов, но давало около 62% всей работы по дефектам. В этой же системе дефекты в 5.8% периферийных файлов. То есть проблема в том, что внутри появляется связанный центр, через который проходит слишком много изменений. Исправляешь одно место — задеваешь другое. Добавляешь новую возможность — неожиданно ломаешь старое поведение. В этой же работе есть финансовая оценка. В одной из систем строка кода в центральных компонентах стоила в сопровождении в 15 раз дороже, чем строка кода на периферии. 👉 Еще одно крупное исследование — работа Google Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment. Там изучили 1252 проекта на C++ и Java и данные по 7200 разработчикам. Авторы смотрели на архитектурную сложность через несколько признаков: — насколько изменения могут распространяться по системе — насколько части системы развязаны между собой — сколько есть циклов между файлами и других структурных проблем Вывод из исследования: чем больше связность, чем больше циклов между файлами и проблемного наследования, тем меньшая доля работы уходит на новые возможности и тем большая — на исправление ошибок. === Итого Плохая архитектура приводит к тому, что: — становится больше ошибок; — задачи делаются дольше; — больше времени уходит на исправления вместо новых возможностей; — центральные компоненты становятся дорогими в сопровождении; — изменение одного места заставляет проверять слишком много связей. Хорошая архитектура решает обратную задачу: уменьшает связность, ограничивает распространение изменений и не дает бизнес-логике утонуть в UI, базе данных и инфраструктуре. Вопрос в том, есть ли в системе границы, которые помогают ей развиваться 👉 Подписывайся на канал Желтого клуба