Одним из факторов разложения архитектуры является компромисс с ценой разработки
Categories:
Признаки разложившейся архитектуры: множество специальных обработок, совместимых обработок, сильная связанность, неподъемное бремя. Любая архитектура со временем медленно разлагается. Разложившаяся архитектура затрудняет разработку новых функций, исправление багов затрагивает всё целиком, из-за чего тестирование и QA также трудно выполнять. Я видел, как энтузиасты разработки из смежных областей писали в постах, что нужно ограничивать абстрактное поведение модели при написании кода, тогда код будет легче понимать человеку. Код, который легче понимать человеку, также легче понимать и LLM, поэтому можно быстро разрабатывать и сокращать ошибки. Я думаю, что разработчики из смежных областей, вероятно, имеют небольшой объем проектов и привыкли к конвейерной логике. Если есть ожидание масштабирования, образ мышления не должен ограничиваться конвейером, а должен использовать мышление строителя. Ожидается построить 30-этажное здание — значит нужно заложить фундамент на 10 метров; ожидается подача воды и электричества — значит нужно зарезервировать колодцы для воды и электричества. Это проектирование с четкой целью. Кроме того, есть проектирование с нечеткой целью: например, в каком-то месте дома в будущем нужно поставить электроприбор, но неясно какой — достаточно зарезервировать розетку. В программной инженерии уже есть принципы SOLID для руководства проектированием. Часто внешне кажется, что при следовании принципам SOLID для реализации той же функции приходится затрагивать больше файлов и писать больше кода. С точки зрения краткосрочного результата, разница между проектированием и его отсутствием для босса/тестировщика и пользователя почти незаметна, преимущества проектирования проявляются только в долгосрочной перспективе. Хорошая архитектура позволяет легко добавлять функции, изменять их, исправлять баги и реже вносить проблемы. Для проектирования часто требуется больше размышлений, чем для прямой разработки функции. Нужно продумывать гранулярность. Просто заклеить всю комнату панелями розеток вместо плитки — это другая абсурдная крайность. Раньше при разработке, учитывая цикл разработки, я шел на компромиссы: когда время поджимало, вообще не проектировал, просто добавлял несколько функций и готово, а о будущем поговорим потом. Теперь с помощью ИИ мы можем делать проектирование с более мелкой гранулярностью, сгенерированный код человеку понять труднее, но инженерная система поддерживается легче. После увеличения абстракций модели похуже действительно могут не справиться, лучше использовать самую лучшую модель на данный момент. Если же писать просто скрипты, разница в возможностях между моделями может быть не слишком заметной. Снизил ли ИИ порог входа для разработчиков? Я в этом сомневаюсь, ведь путь обучения новых разработчиков уже кардинально отличается от прошлого, обсуждать высоту порога, возможно, бессмысленно, потому что мы не знаем, куда этот порог переместили.
