tgoop.com/rect_arrow/307
Last Update:
Архитектурные решения «снизу»
В позднем Agile стало модно говорить о возникающих в процессе разработки проектных решениях (Emergent Design) как об архитектуре снизу.
Часто слышу на статусах фразу «Это архитектурное решение принял разработчик».
Корректно ли это?
Архитектурное решение по определению — это значимое и обоснованное проектное решение.
Что значит значимое?
Это значит, что такое решение сложно или даже невозможно отыграть назад.
То есть решение необратимое или сложно обратимое.
Может ли разработчик принять такое решение?
Вполне. )
Что значит обоснованное?
Или иначе — чем обосновывается архитектурное решение?
Архитектурное решение обосновывается потребностями стейкхолдеров.
Это либо решение, которое всех устраивает, либо, наоборот, решение, которое всех не устраивает, но в одинаковой степени (компромисс).
Архитектор, половину рабочего дня проводящий на встречах и в обсуждениях, имеет в виду интересы стейкхолдеров.
Разработчик чаще всего имеет в виду интерес единственного стейкхолдера — себя.
Среднестатистический разработчик думает о том, как сделать проще, быстрее, красивее или, в худшем случае, «правильнее».
Архитектор думает о том, что скажут ИБ, ФСБ, поддержка, архком со своим планом импортозамещения и прочие прочие.
Резюме:
«Архитектуры снизу» не бывает, есть дизайн, возникающий в процессе разработки.
Обоснованность решений дизайна может быть ограниченной, так как стоимость отката здесь невелика.
Ежели стоимость пересмотра решения значима, это решение должно быть согласовано со всеми заинтересованными лицами, и это решение архитектора, то есть архитектурное решение.
P. S.
Мне часто возражают, дескать, наши разработчики знают всё о проекте и способны обосновать свой дизайн.
Отвечаю:
Если разработчик в теме всех стейкхолдерских хотелок, если он активный участник бесчисленных встреч и обсуждений (успевающий еще и покодить), то он и есть архитектор. )
BY Прямоугольники и стрелочки
Share with your friend now:
tgoop.com/rect_arrow/307