Comments 12
Если мы сначала делаем, а потом по коду пытаемся описать, что мы делаем, то документации точно не будет. Но если у нас нормальный процесс разработки, то сначала системный аналитик разрабатывает и описывать решение, потом разработка его выполняет будет нормальная документация. Не вижу никаких проблем описать монолит с точки зрения ФТ. Совершенно, не обязательно рисовать все таблицы со связями на одном листе, и вообще, первоначальной нотацией описания чего либо, является текстовая нотация.
При микросервисной архитектуре общий объем документации станет больше. Но критериями выбора архитектуры у нас могут служить такие параметры, как возможность быстрее и проще вносить изменения в систему, возможность масштабирования, работа под нагрузкой, возможность использовать разные стеки технологий.
Плюсую. Если аналитик описал ФТ и тех.решение (на пару с архитектором), и разработчики поклялась, что именно так и сделают, берёте ФТ и ТР и переписываете из формата "система должна А" в "система делает А способом Б".
А если уже все написано, заставляйте разработчиков описывать по свежей памяти (а если будут лениться и говорить "код - лучшая документация", демонстративно дрсиавайте диктофон и просите повторить для истории)
И еще уточнение: каждый должен отвечать за свою часть документации. Меня как системного аналитика интересует функциональное описание системы, технические особенности системы должен описывать системный архитектор. Какая документация нужна разработчикам - виднее разработчикам и писать ее должны они
В теме с 2002г. - инженер по внедрению ИСУП(MS Project Server, HP PPM, c Oct 8,2008 Oracle's Primavera EPPM), Бизнес-аналитик
Примитивно:
Не буду все расписывать - лень.
Проектное предложение - Предпроект - Проект
При формировании "Проектного предложения" схемы с пляшущими человечками потенциальный заказчик не понимал
В те времена использовали IBM Rational Rose(UML-Based Design Tool)
Отлично, Михаил! С успешным стартом на Хабре! C4 также представляется оптимальной по критериям "доступность/ёмкость/эффективность". На L1 команда объединена единым видением архитектуры, L2 максимально ускоряет вовлеченность нового участника на его уровне ответственности. L3 - это база. На L4 еще не доводилось спускаться, но это вопрос ближайшего будущего. Во-первых, разработчики приходят и уходят. А, во-вторых, реализацию узкого функционала a-la визуализация в kibana дешевле отдавать на аутсорсинг,-стафинг, сохраняя при этом единое смысловое поле классов и атрибутов.
На втором уровне еще не пробовали приколачивать к компонентам CMDB-ключи (ЯП, версионность, фреймворки, источник разработки, внешние-SaaS (если есть))?
Направление важное, ждем продолжения и охотно подключусь к публикации подобного опыта..
Статья выглядит как хейт монолитных решений "в общем случае": для монолитов минусы выставляются, плюсы же заметаются под ковёр. Для микросервисов та же картина, но ровно наоборот: плюсы выпячиваются, минусы заметаются под ковёр.
С таким подходом можно легко влететь в ситуацию "микросервисного монолита", когда исключается главное достоинством микросервиса - заменяемость, при этом недостатки в виде высокой связности остаются. Зато обилие связей сервисов и необходимость обслуживания связей путём внедрения всяких мониторингов и прочих вспомогательных компонентов со своими связями ведёт к повышению хрупкости системы. Ну и поддержание обозримости системы в целом - тоже та ещё задача (схема БД одного сервиса простая, ага, а вот количество неявных связей между БД разных сервисов может очень сильно порадовать глаз в случае рефакторингов схем данных).
И да, монолит (в смысле все связи - in-process) тоже может быть модульным с нормальной архитектурой.
Я с вами полностью согласен. Думаю, мы ещё обсудим это, и, возможно, я напишу статью на эту тему. Просто хотел обратить внимание на то, что у монолитной архитектуры, скорее всего, есть ещё один "неочевидный минус" - слабая документация. Системные аналитики вряд ли распишут всё на уровне L3/L4 в C4-модели, так как они не программисты. А у разработчиков, в свою очередь, на это просто не будет времени - для них главное, чтобы система работала.
Слабая документация обычно не от стиля архитектуры зависит, а от своевременного выделения административных и человеческих ресурсов зависит.
Можно к этому вопросу даже с другой стороны подойти: микросервисный стиль архитектуры поддерживать больнее без текстового описания архитектуры. Если у разработчика проект на компилируемом языке, то нестыковка интерфейса банально не может выстрелить: код просто не компилируется. А в мелкосервисах фиг поймёшь что там между сервисами ходит без детальной документации.
Исследовали ли Вы труды:
Кузнецова Побиска,
Шалыто Анатолия,
Паронджанова Владимира ?
Как автор данной статьи веду также телеграм-блог по системной архитектуре и аналитике, в котором рассказываю о сложных технологиях простыми словами, а также реальных кейсах из личного опыта. Буду рад общению https://t.me/SysArForAll
Что такое правильная документация проекта