В начале всегда тяжело разобраться в большом и старом проекте. Architecture assessment — это одна из активностей архитектора. Обычно приходится работать с большими, старыми проектами, а результаты надо предоставить за неделю.

Как оценить проект размером 100к и более строк кода за неделю при этом предоставить действительно полезные для клиента результаты.

Большинство архитекторов и тех лидов сталкивались с подобными оценками проекта. Это может выглядеть как полуформальный процесс или как отдельный сервис как это сделано в нашей компании, так или иначе большинство из вас имели дело с этим.

Оригинал на английском языке для ваших не русскоговорящих друзей лежит здесь: Architecture Assessment in a week.

Подход в нашей компании

Я расскажу вам как это работает в нашей компании и как я поступаю в подобных ситуациях, но вы можете с легкостью менять данный поход согласно потребностям вашего проекта и компании.

Есть две разновидности architecture assessment.

Внутренний – мы обычно делаем его для проектов внутри компании. Любой проект может запросить оценку архитектуры по нескольким причинам:

1. Команда думает, что их проект идеален и это подозрительно. У нас были такие случаи и зачастую в таких проектах все далеко не идеально.
2. Команда хочет проверить свой проект и свои решения.
3. Команда знает, что все плохо. Они могут даже перечислить основные проблемы и причины, но хотят получить полный список проблем и рекомендаций по улучшению проекта.

Внешний – это более формальный процесс, чем внутренняя оценка. Клиент приходит всегда только в одном случае, когда все плохо – очень плохо. Обычно клиент понимает, что есть глобальные проблемы, но не может верно определить причины и разбить на составляющие.

Оценка архитектуры для внешнего клиента более сложный случай. Процесс должен быть более формальный. Проекты всегда большие и старые. В них много проблем, багов и кривого кода. Отчет о проведенной работе должен быть готов в течении нескольких недель максимум, где должны быть основные проблемы и рекомендации по улучшению. Поэтому, если мы разберемся с внешней оценкой проекта, то внутренний это будет пару пустяков. Рассмотрим самый сложный случай.

Оценка архитектуры энтерпрайз проекта

Типичный проект для оценки – это большой, старый, энтерпрайз проект с большим количеством проблем. Клиент приходит к нам и просит починить его проект. Это как с айсбергом, клиент видит только верхушку своих проблем и не догадывается о том, что под водой (в глубине кода).

Проблемы, на которые клиент может пожаловаться и может знать о них:

• Проблемы с производительностью
• Проблемы с удобством использования приложения (Usability)
• Продолжительный деплоймент
• Отсутствие unit и других тестов

Проблемы, о которых клиент скорее всего не догадывается, но они могут присутствовать в проекте:

• Проблемы с безопасностью
• Проблемы проектирования
• Неверная архитектура
• Алгоритмические ошибки
• Неподходящие технологии
• Технический долг
• Неправильный процесс разработки

Формальный процесс оценки архитектуры

Это формальный процесс, которого мы придерживаемся в компании, но вы можете его подстроить под себя в зависимости от вашей компании и проекта.

Запрос от клиента

Клиент просит оценить архитектуру текущего проекта. Ответственный человек с нашей стороны собирает базовую информацию о проекте и подбирает необходимых экспертов. В зависимости от проекта, это могут быть разные эксперты.

Solution Architect – главный человек ответственный за оценку и координацию (и зачастую единственный).
Stack specific experts – .Net, Java, Python, и другие технические специалисты в зависимости от проекта и технологий
Cloud experts – это могут быть Azure, GCP или AWS cloud архитекторы.
Infrastructure – DevOps, System administrator, и т.д.
Другие эксперты – такие как big data, machine learning, performance engineer, security expert, QA lead.

Сбор информации о проекте

Вам следует собрать как можно больше информации про проект. Вы можете использовать различные техники в зависимости от ситуации:

• Опросники и другие способы общения через почту. Самый неэффективный способ.
• Онлайн встречи.
• Специальные инструменты для обмена информацией такие как: Google doc, Confluence, репозитории и т.д.
• «Живые» встречи на месте. Самый эффективный и самый дорогой способ.

Что же надо получить от клиента?

Базовая информация. О чем проект. Его цель и ценность. Основные цели и планы на будущее. Бизнес цели и стратегии. Основные проблемы и желаемый результат.

Информация о проекте. Технологический стек, фреймворки, языки программирования. On-premise или облачный деплоймент. Если проект в облаке, какие сервиса используются. Какие архитектурные и дизайн паттерны применялись.

Не функциональные требования. Все требования, связанные с производительностью, доступностью, удобством использования системы. Требования безопасности и т.д.

Базовые юскейсы и потоки данных.

Доступ к исходному коду. Самая главная часть! Вам обязательно следует получить доступ к репозиториям и документации как собрать проект.

Доступ к инфраструктуре. Было бы неплохо получить доступ к stage или production инфраструктуре, чтобы поработать с «живой» системой. Это большая удача если у клиента есть инструменты по мониторингу инфраструктуры и производительности. Про эти инструменты мы поговорим в следующей секции.

Документация. Если у клиента есть документация это хорошее начало. Она может быть устаревшая, но это все равно хорошее начало. Никогда не верьте документации – проверяйте ее с клиентом, на реальной инфраструктуре и в исходном коде.

Процесс оценки архитектуры

Как же все-таки обработать такое большое количество информации за такие короткие сроки? Прежде всего распараллельте работу.

DevOpsу следует посмотреть в инфраструктуру. Тех лиду в код. Перформанс инженеру посмотреть метрики по производительности. Специалисту по базам данных стоит глубже копнуть структуры данных.

Но это идеальный случай, когда у вас много ресурсов. Обычно оценку проекта проводят от одного до трех человек. Вы даже можете провести оценку сами, что зачастую и происходит, если у вас есть надлежащие знания и опыт во всех областях проекта. В таком случае вам нужно автоматизировать все процессы, на сколько это возможно.

К сожалению, прочитать документацию вам придется вручную. При наличии должного опыта вы сможете довольно быстро понять качество документации. Что там правда, а что явно не совпадает с действительностью. Иногда вы можете встретить такую архитектуру в документации, которая никогда не будет работать в реальной жизни. Это триггер для вас задуматься, а как же оно сделано в реальности в проекте.

Полезные инструменты для автоматизации оценки проекта

Оценка кода — это простое упражнение. Вы можете использовать статические анализаторы кода, которые покажут проблемы дизайна, производительности и безопасности. Вот несколько из них:

Structure 101 – это отличный инструмент для архитектора. Он покажет вам общую картину, зависимость между модулями и потенциальные области для рефакторинга. Как все хорошие инструменты, он стоит хороших денег, в то же время вы можете воспользоваться пробной 30-ти дневной версией.

SonarQube – старый добрый инструмент. Инструмент для статического анализа кода. Позволяет определить плохой код, баги, проблемы с безопасностью для более чем 20 языков програмирования.

Все облачные провайдеры имеют инструменты для мониторинга инфраструктуры. Это позволит вам правильно оценить эффективность инфраструктуры с точки зрения стоимости и производительности. Для AWS это trusted advisor. Для Azure это просто Azure Advisor.

Дополнительный мониторинг производительности и логирования поможет найти проблемы с производительностью на всех уровнях. Начиная от базы данных с не эффективными запросами, бэкенда и заканчивая фронтендом. Даже если клиент не установил эти инструменты ранее, вы можете довольно быстро интегрировать их в существующую систему, чтобы определить проблемы с производительностью.

Как всегда хорошие инструменты хорошо стоят. Я могу порекомендовать пару платных инструментов. Конечно, вы можете использовать open-source но вам потребуется больше времени для этого. И это следует сделать заранее, а не в процессе оценки архитектуры.

New Relic – инструмент по оценки производительности приложений
Datadog – облачный сервис мониторинга сестем

Для тестирования безопасности есть множество инструментов. На этот раз я порекомендую вам бесплатный инструмент для сканирования системы.

OWASP ZAP – инструмент для сканирования веб приложений на соответствие стандартам безопасности.

Собираем все в единое целое.

Готовим отчет

Начните свой отчет с собранных от клиента данных. Опишите цели проекта, ограничения, нефункциональные требования. После этого следует упомянуть все входящие данные исходный код, документация, инфраструктура.

Следующий шаг. Укажите все проблемы, которые вы нашли вручную или с помощью автоматизированных инструментов. Большие автосгенерированные отчеты поместите в конец в секцию приложений. Здесь должны быть короткие и ёмкие доказательства найденных проблем.
Приоритезируйте найденные проблемы по шкале error, warning, info. Вы можете выбрать свою шкалу, но эта общепринятая.

Как настоящий архитектор вы обязаны предоставить рекомендации по устранению найденных проблем. Опишите улучшения и ценность для бизнеса, которые получит клиент. Как показать ценность для бизнеса от architecture refactoring мы обсуждали ранее.

Подготовьте roadmap с маленькими итерациями. Каждая итерация должна содержать время на выполнение, описание, количество ресурсов необходимых для улучшения, техническую ценность и ценность для бизнеса.

Заканчиваем оценку архитектуры и предоставляем клиенту отчет

Никогда просто не отсылайте отчет по почте. Его могут или вообще не прочитать или прочитать и не понять без должного объяснения. Короче – живое общение помогает устранить недопонимания между людьми. Вам следует назначить митинг с клиентом и рассказать о найденных проблемах поставив акцент на самых значимых. Стоит обратить внимание клиента на проблемы, о которых он мог даже не подозревать. Такие как проблемы с безопасностью и объяснить, как они могут повлиять на бизнес. Покажите свою roadmap с улучшениями и обсудите различные варианты, более подходящие для клиента. Это может быть время, ресурсы, объём работ.

Как подведение итогов вашего митинга отправьте клиенту ваш отчет.

В заключение

Оценка архитектуры — это сложный процесс. Чтобы провести оценку должным образом вам необходимо иметь достаточно опыта и знаний.

Это реально — предоставить клиенту полезные для него и его бизнеса результаты всего за неделю. Даже если вы делаете это в одиночку.

Исходя из моего опыта многие улучшения закачивались на середине, а иногда так никогда и не начавшись. Те, кто выбирали для себя золотую середину и делали лишь часть улучшений максимально полезных для бизнеса с минимальными трудозатратами, значительно улучшали качество своего продукта. Те же, кто ничего не делал через пару лет могли и вовсе закрыть проект.

Ваша цель показать клиенту максимальные улучшения за минимальную цену.

Другие статьи из раздела architecture можно почитать на досуге.

Желаю вам чистого кода и хороших архитектурных решений.

Наша facebook группа — Software Architecture and Development.