Короткая статья.
Уже писал об этом вскользь, но хотел бы ещё раз подробнее остановится на том, что должен понимать Software Architect при реализации любого аспекта своей работы.
Гибкие методологии не отменяют последовательность набора действий внутри итерации разработки. Ниже приведена иллюстрация к фреймворку Software/System Development Life Cycle (SDLC). SDLC подразумевает последовательность активностей от анализа до обслуживания для каждой итерации разработки. Если очень сильно упрощать: вы сначала думаете и проектируете, потом разрабатываете, потом проверяете, что получилось.
Транзит ответственности подразумевает, что любой артефакт, рождаемый в итерации разработки, является проверяемым, однозначно верифицируемым и, очевидно, полезным на каждом следующем этапе производства.
Все слышали выражение «Самые тяжелые ошибки – ошибки архитектуры»? Что это значит? Мы с этапа эксплуатации вынуждены вернутся на этап дизайна или аналитики, то есть ресурсы между этими этапами мы потратили практически в пустую и цикл начинается по новой. Может быть более безобидный пример, когда инженер тестирования возвращается к разработчику за уточнением особенностей реализации.
Основная задач, смысл, если позволите, цикла разработки – это его линейность и последовательность, возврат на предыдущие этапы всегда тратит лишние ресурсы.
Это же касается и архитектуры. Возьмём практику quality assurance, тестирование – это по определению проверка требований. Требования – это и есть архитектура. Для E2E — это бизнес требования, для контрактных, интеграционных тестов – это system и solution архитектура. Это подразумевает однозначную читаемость и верифицируемость архитектурных артефактов.
Если вы требования описали в тексте или в нотации, подразумевающий разночтения, реализация будет такой же вольной. Неизбежно произойдет возврат на предыдущие этапы и хорошо, если этот возврат произойдет с этапов тестирования.
За рамками оставим вопросы организации полного цикла разработки, в идеальной картине мира архитектор за свои артефакты сохраняет ответственность до этапа эксплуатации. Здесь, отмечу необходимость фиксации однозначных требований на этапе дизайна их использования на этапе разработки и верификации на этапе тестирования.
Как это можно сделать?
Для бэкенда, например, с использованием контрактов и спецификаций. К сожалению, с фронтендом не так все однозначно. В пирамиде тестирования UI-тесты в самом верху – они самые дорогие и самые не стабильные, то же касается и подходов при составлении архитектурных артефактов для требований к UI компонентам. Рекомендую сосредоточится на бэкенд и архитектурных артефактах для них – контрактах и спецификациях.
Тем не менее, через бэкенд возможно описывать и тестировать пользовательские сценарии на UI, для этого, например можно использовать паттерн HATEOS для API, но этот вопрос не рассматривается в данном материале.
Так же при разработке через тестирование (TDD, «Экстремальное программирование» Кент Бек), подразумевается обязательная разработка тестов на все компоненты до их реализации, фактически речь о квази или полноценных архитектурных артефактах.