Архитектура как код - Роман Пионтик - ArchDays 2022 (Рубрика #Architecture)
Интересное выступление про Dochub от автора инструмента на ArchDays 2022. Актуальная информация по инсструменту расположена здесь, но тут я расскажу про основные тезисы доклада:
- Основная идея была в создании инструмена для покрытия всех этапов развития компании, от стартапа до зрелой организации.
- Этот инструмент должен быть адекватным конкретному домену, встраиваться в процессы производства и анализировать архитектуру.
- Инструмент должен был поддерживать расширяемую метамодель, позволяющую анализировать данные архитектуры.
- Инструмент должен поддерживать командное развитие архитектуры и контроль глобальных стандартов.
- То, что получилось позволило сделать "живые" документы и шаблоны, которые валидируются и актуализируются
- Внутри есть комбинация инструментов вида
-- PlantUML и Mermaid - для диаграмм как код
-- Markdown - для разметки и документации
-- Swagger и AsyncAPI - для документации контрактов API
-- YAML/JSON манифесты для описания архитектурных объектов
-- SmartAnts - язык для запросов по этим описаниям
Все это позволяет накрутить поверх проверки этой архитектурной документации, которые позволяют контролировать важные для архитекторов вещи при помощи запросов на языке SmartAnts.
В общем и целом, по моим ощущениям от этого доклада получается примерно такая схема:
- Предлагается некоторая система для документирования архитектуры на базе Dochub
- В этой системе работают специальные люди, у которых шилдик "архитектора"
- Они пишут не код приложений, а код, который документирует архитектуру
- Они же пишут валидаторы этого описания архитектуры
- А SDE (software development engineers) пишут свой код в продакшен системах
- Дальше встает вопрос а кто поддерживает актуальность production code vs architecture code и в рамках какого процесса? Например, если это обязательный этап для любой фичи и его надо пройти еще до ее релиза, то тогда lead time взмывает в небеса, если это делает благословленный небом архитектор, а если это делают SDE, то неясно какое преимущество он получает от этих действий. Если это делается постфактум, то мы опять получаем лаг между реальным кодом и архитектурным описанием как бы оно не было получено: нарисовано картинками или сгенерировано из описания картинки кодом (с тем же успехом можно промптом попросить chatGPT генерировать картинки).
P.S.
В этом подходе меня смущает, что все самое интересное заметено под ковер. Условно, хотелось бы уметь связывать архитектурное описание и реальность, причем идти от второго, а не рисовать первое хоть кодом, хоть руками. В итоге, описанный процесс с Dochub мне кажется сложным, дорогим и неудобным для всех в команде разработки, кроме архитектора, который находится во вне и придумывает правила и проверки, а также рисует диаграммы кодом.
P.P.S.
Интересно сравнить рассказ Романа из Сбера про Dochub и то, что в том же 2022 ходу рассказал Кирилл Ветчинкина из Сбер Маркета про их архрепу и процесс написания ADR (я рассказывал об этом вчера). Подход Кирилла показался мне более приземленным, практичным и полезным.
P.P.S
В следующем посте напишу куда я бы хотел копать эту тему с архитектурой, чтобы сделать сделать работу над архитектурой неинвазивной и полезной для самих разработчиков.
#Architecture #Software #SoftwareArchitecture #Management #Processes
Интересное выступление про Dochub от автора инструмента на ArchDays 2022. Актуальная информация по инсструменту расположена здесь, но тут я расскажу про основные тезисы доклада:
- Основная идея была в создании инструмена для покрытия всех этапов развития компании, от стартапа до зрелой организации.
- Этот инструмент должен быть адекватным конкретному домену, встраиваться в процессы производства и анализировать архитектуру.
- Инструмент должен был поддерживать расширяемую метамодель, позволяющую анализировать данные архитектуры.
- Инструмент должен поддерживать командное развитие архитектуры и контроль глобальных стандартов.
- То, что получилось позволило сделать "живые" документы и шаблоны, которые валидируются и актуализируются
- Внутри есть комбинация инструментов вида
-- PlantUML и Mermaid - для диаграмм как код
-- Markdown - для разметки и документации
-- Swagger и AsyncAPI - для документации контрактов API
-- YAML/JSON манифесты для описания архитектурных объектов
-- SmartAnts - язык для запросов по этим описаниям
Все это позволяет накрутить поверх проверки этой архитектурной документации, которые позволяют контролировать важные для архитекторов вещи при помощи запросов на языке SmartAnts.
В общем и целом, по моим ощущениям от этого доклада получается примерно такая схема:
- Предлагается некоторая система для документирования архитектуры на базе Dochub
- В этой системе работают специальные люди, у которых шилдик "архитектора"
- Они пишут не код приложений, а код, который документирует архитектуру
- Они же пишут валидаторы этого описания архитектуры
- А SDE (software development engineers) пишут свой код в продакшен системах
- Дальше встает вопрос а кто поддерживает актуальность production code vs architecture code и в рамках какого процесса? Например, если это обязательный этап для любой фичи и его надо пройти еще до ее релиза, то тогда lead time взмывает в небеса, если это делает благословленный небом архитектор, а если это делают SDE, то неясно какое преимущество он получает от этих действий. Если это делается постфактум, то мы опять получаем лаг между реальным кодом и архитектурным описанием как бы оно не было получено: нарисовано картинками или сгенерировано из описания картинки кодом (с тем же успехом можно промптом попросить chatGPT генерировать картинки).
P.S.
В этом подходе меня смущает, что все самое интересное заметено под ковер. Условно, хотелось бы уметь связывать архитектурное описание и реальность, причем идти от второго, а не рисовать первое хоть кодом, хоть руками. В итоге, описанный процесс с Dochub мне кажется сложным, дорогим и неудобным для всех в команде разработки, кроме архитектора, который находится во вне и придумывает правила и проверки, а также рисует диаграммы кодом.
P.P.S.
Интересно сравнить рассказ Романа из Сбера про Dochub и то, что в том же 2022 ходу рассказал Кирилл Ветчинкина из Сбер Маркета про их архрепу и процесс написания ADR (я рассказывал об этом вчера). Подход Кирилла показался мне более приземленным, практичным и полезным.
P.P.S
В следующем посте напишу куда я бы хотел копать эту тему с архитектурой, чтобы сделать сделать работу над архитектурой неинвазивной и полезной для самих разработчиков.
#Architecture #Software #SoftwareArchitecture #Management #Processes