Комментарии 27
Вот это труд!
Супер! Спасибо!
Большое спасибо!
Огромное спасибо!
Спасибо вам! Начала читать шаблон и осознала, что на работе достигла некоторого предела, и надо расширять горизонты)
Чем больше мы узнаем, тем меньше мы знаем. Удивительный парадокс. Чем больше я изучаю и применяю практики управления ИТ, тем больше понимаю, как еще много всего меня ждет )
Согласна) и рада, что с возрастом спокойнее принимаю это пресловутое "Я знаю, что ничего не знаю")
А вы в каком направлении развиваетесь?
Я системный аналитик, который мечтательно засматривается в сторону архитектуры, но по нуждам проекта нередко погружается в бизнес-анализ. И ваш файл затронул мои "архитекторские" струны души)
Архитектура - это целая вселенная, но, к сожалению, часто оторванная от всего остального мира. Но там очень интересно.
Впервые я это ощутила, когда архитектор очень высокого уровня всерьез предложил отключить 3/4 пользователей, чтоб они после получения доп.инструкций стали входить в систему "правильно" и красиво, а не как ходили с пяток лет и как ходят сейчас))) И ничего, что эти пользователи платят деньги, что они могут уйти к конкурентам, что предложенный сценарий нереален) Причем некоторая несуразность процесса входа не влияла на безопасность, только на представления о прекрасном .
"Давайте с понедельника сделаем как надо".
Спасибо за шаблон.
Подскажите, насколько гибко поддается версионированию данный шаблон? Так понимаю, если описываемая версия ПО претерпевает значительные изменения в архитектуре, то их нужно отражать в новом представлении. Также любое изменение в архитектуре должно быть взешенным и отражаться в своего рода журнале принятия решений, называемых ADR. Насколько шаблон приспособлен к изменениям в архитектуре, и учитывается ли в нем журнал решений?
Спасибо за вопрос
Шаблон изначально спроектирован с учетом необходимости версионирования. В начале документа предусмотрены поля для указания версии и даты - п.1 История версий, здесь можете фиксировать все изменения описания.
Учет архитектурных решений (ADR) можно фиксировать в разделе 10 Приложения: Решения и альтернативы.
И шаблон - это рекомендация, вы всегда можете добавлять необходимые разделы и исключать те, что вам не нужны.
Спасибо за шаблон!) Хотел уточнить, удалось ли вам использовать данный шаблон в рамках вайб кодинга? Если да, то, насколько он полезен?
Честно говоря, с понятием вайб кодинга сталкиваюсь впервые. Пришлось гуглить. Когда прочитала что это - поняла, что вчера занималась вайб-кодингом, когда с помощью нейросети написала парсер для статей одного сайта.
Как я поняла, вайб-кодинг применяют чтобы что-то быстро сделать «на коленке», чтобы проверить гипотезу. Думаю, что здесь смысла что-то проектировать нет, но если проект становится серьезнее, требует развития и поддержки, то здесь описание системы пригодится.
Но что-то мне подсказывает, что код созданный нейросетью, без взгляда опытного разработчика, имеет очень много рисков.
Вау, спасибо. Вот это тема, как раз искал подобные доки.
Отличная и очень полезная работа, спасибо!
Есть мысль: как насчёт переноса в Markdown + GitHub?
Упростит коллаборацию через pull requests
Позволит реализовать версионирование
Мультиязычную структуру (i18n)
и другие фичи вроде CI для проверки валидности данных\форматирования ...
Такой формат сильно повысит масштабируемость и поддержку проекта со стороны сообщества.
Спасибо большое. Очень полезный и детальный шаблон
Отличие IT от например строительства мостов или проектирования ракет в том, что требования и соответственно архитектура постоянно изменяются. Причём не только в процессе создания, но и после ввода в эксплуатацию. Поэтому любые фундаментальные виды документирования устаревают ещё в процессе написания.
Поскролил по диагонали, вполне себе, спасибо за материал! Ценно как минимум систематизацией важных аспектов. Главное, не воспринимать как догму и не зацикливаться, а использовать для вдохновения под конкретный контекст.
Для архитекторов и аналитиков: шаблон описания архитектуры приложения (34 страницы пользы)