На початку завжди важко розібратися у великому та старому проекті. Architecture assessment – це одна з активностей архітектора. Зазвичай доводиться працювати з великими, старими проектами, а результати треба надати протягом тижня.
Як оцінити проект розміром 100к і більше рядків коду за тиждень, при цьому надати дійсно корисні для клієнта результати.
Більшість архітекторів та тих лідів стикалися з подібними оцінками проекту. Це може виглядати як напівформальний процес або як окремий сервіс, як це зроблено в нашій компанії, так чи інакше більшість з вас мали справу з цим.
Оригінал англійською мовою для ваших не російськомовних друзів лежить тут: .
Підхід у нашій компанії
Я розповім вам, як це працює в нашій компанії і як я поступаю в подібних ситуаціях, але ви можете з легкістю змінювати цей похід відповідно до потреб вашого проекту та компанії.
Існують два різновиди архітектурної оцінки.
Внутрішній – ми зазвичай робимо його для проектів усередині компанії. Будь-який проект може запросити оцінку архітектури з кількох причин:
- Команда думає, що їхній проект ідеальний і це підозріло. У нас були такі випадки і найчастіше в таких проектах далеко не ідеально.
- Команда хоче перевірити свій проект та свої рішення.
- Команда знає, що все погано. Вони можуть навіть перерахувати основні проблеми та причини, але хочуть отримати повний список проблем та рекомендацій щодо покращення проекту.
зовнішній – це формальний процес, ніж внутрішня оцінка. Клієнт приходить завжди тільки в одному випадку, коли все погано дуже погано. Зазвичай клієнт розуміє, що є глобальні проблеми, але може правильно визначити причини і розбити на складові.
Оцінка архітектури для зовнішнього клієнта складніший випадок. Процес має бути більш формальним. Проекти завжди великі та старі. У них багато проблем, багів та кривого коду. Звіт про проведену роботу має бути готовий протягом декількох тижнів максимум, де мають бути основні проблеми та рекомендації щодо покращення. Тому, якщо ми розберемося із зовнішньою оцінкою проекту, то внутрішній це буде кілька дрібниць. Розглянемо найскладніший випадок.
Оцінка архітектури ентерпрайз проекту
Типовий проект для оцінки - це великий, старий, ентерпрайз проект з великою кількістю проблем. Клієнт приходить до нас і просить відремонтувати його проект. Це як із айсбергом, клієнт бачить лише верхівку своїх проблем і не здогадується про те, що під водою (в глибині коду).
Проблеми, на які клієнт може поскаржитися і знати про них:
- Проблеми з продуктивністю
- Проблеми зі зручністю використання програми (Usability)
- Тривалий деплоймент
- Відсутність unit та інших тестів
Проблеми, про які клієнт швидше за все не здогадується, але вони можуть бути присутніми в проекті:
- Проблеми з безпекою
- Проблеми проектування
- Невірна архітектура
- Алгоритмічні помилки
- Невідповідні технології
- Технічний обов'язок
- Неправильний процес розробки
Формальний процес оцінки архітектури
Це формальний процес, якого ми дотримуємось у компанії, але ви можете його підлаштувати під себе залежно від вашої компанії та проекту.
Запит від клієнта
Клієнт просить оцінити архітектуру поточного проекту. Відповідальна людина з нашого боку збирає базову інформацію про проект та підбирає необхідних експертів. Залежно від проекту це можуть бути різні експерти.
Архітектор рішення – головна людина відповідальна за оцінку та координацію (і найчастіше єдина).
Stack specific experts – .Net, Java, Python та інші технічні фахівці залежно від проекту та технологій
Cloud experts – це можуть бути Azure, GCP або AWS Cloud архітектори.
Інфраструктура - DevOps, System administrator, і т.д.
Інші експерти – такі як big data, machine learning, performance engineer, security expert, QA lead.
Збір інформації про проект
Вам слід зібрати якнайбільше інформації про проект. Ви можете використовувати різні техніки в залежності від ситуації:
- Опитувальники та інші засоби спілкування через пошту. Найнеефективніший спосіб.
- Онлайн зустрічі.
- Спеціальні інструменти для обміну інформацією такі як Google doc, Confluence, репозиторії і т.д.
- "Живі" зустрічі на місці. Найефективніший і найдорожчий спосіб.
Що треба отримати від клієнта?
Базова інформація Про що проект. Його мета та цінність. Основні цілі та плани на майбутнє. Бізнес мети та стратегії. Основні проблеми та бажаний результат.
Інформація про проект. Технологічний стек, фреймворки, мови програмування. On-premise чи хмарний деплоймент. Якщо проект у хмарі, які сервіси використовуються. Які архітектурні та дизайн патерни застосовувалися.
Чи не функціональні вимоги. Усі вимоги, пов'язані з продуктивністю, доступністю, зручністю використання системи. Вимоги безпеки та ін.
Базові юскейси та потоки даних.
Доступ до вихідного коду. Найголовніша частина! Вам обов'язково слід отримати доступ до репозиторій та документації як зібрати проект.
Доступ до інфраструктури. Було б непогано отримати доступ до stage або production інфраструктури, щоб працювати з «живою» системою. Це велика удача, якщо у клієнта є інструменти моніторингу інфраструктури та продуктивності. Про ці інструменти ми поговоримо у наступній секції.
Документація. Якщо клієнт має документацію, це хороший початок. Вона може бути застаріла, але це все одно добрий початок. Ніколи не вірте документації – перевіряйте її з клієнтом, на реальній інфраструктурі та у вихідному коді.
Процес оцінки архітектури
Як же все-таки обробити таку велику кількість інформації за такі короткі терміни? Насамперед розпаралельте роботу.
DevOps слід подивитися в інфраструктуру. Тих лід у код. Перформанс інженеру подивитися метрики за продуктивністю. Фахівцю з баз даних варто глибше копнути структури даних.
Але це ідеальний випадок, коли ви маєте багато ресурсів. Зазвичай оцінку проекту проводять від однієї до трьох осіб. Ви навіть можете провести оцінку самі, що найчастіше і відбувається, якщо у вас є належні знання та досвід у всіх галузях проекту. У такому разі вам потрібно автоматизувати всі процеси, наскільки це можливо.
На жаль, прочитати документацію вам доведеться вручну. За наявності належного досвіду, ви зможете досить швидко зрозуміти якість документації. Що там правда, а що явно не збігається із дійсністю. Іноді ви можете зустріти таку архітектуру в документації, яка ніколи не працюватиме в реальному житті. Це тригер для вас задуматися, а як воно зроблено насправді в проекті.
Корисні інструменти для автоматизації оцінки проекту
Оцінка коду – це проста вправа. Ви можете використовувати статичні аналізатори коду, які покажуть проблеми дизайну, продуктивності та безпеки. Ось кілька із них:
- Це чудовий інструмент для архітектора. Він покаже вам загальну картину, залежність між модулями та потенційні області для рефакторингу. Як усі хороші інструменти, він коштує хороших грошей, в той же час ви можете скористатися пробною 30-денною версією.
- Старий добрий інструмент. Інструмент статичного аналізу коду. Дозволяє визначити поганий код, баги, проблеми з безпекою для більш ніж 20 мов програмування.
Усі хмарні провайдери мають інструменти моніторингу інфраструктури. Це дозволить вам правильно оцінити ефективність інфраструктури з точки зору вартості та продуктивності. Для AWS це . Для Azure це просто .
Додатковий моніторинг продуктивності та логування допоможе знайти проблеми з продуктивністю на всіх рівнях. Починаючи від бази даних з неефективними запитами, бекенда та закінчуючи фронтендом. Навіть якщо клієнт не встановив ці інструменти раніше, ви можете швидко інтегрувати їх в існуючу систему, щоб визначити проблеми з продуктивністю.
Як завжди, хороші інструменти добре стоять. Я можу порадити кілька платних інструментів. Звичайно, ви можете використовувати open-source але вам знадобиться більше часу для цього. І це слід зробити наперед, а не в процесі оцінки архітектури.
- Інструмент з оцінки продуктивності додатків
- Хмарний сервіс моніторингу систем
Для тестування безпеки є багато інструментів. На цей раз я порекомендую вам безкоштовний інструмент для сканування системи.
– інструмент для сканування веб-додатків на відповідність стандартам безпеки.
Збираємо все в єдине ціле.
Готуємо звіт
Почніть свій звіт із зібраних від клієнта даних. Опишіть цілі проекту, обмеження, дисфункції. Після цього слід згадати всі вихідні коди, документація, інфраструктура.
Наступний крок. Вкажіть усі проблеми, які ви знайшли вручну або за допомогою автоматизованих інструментів. Великі автозгенеровані звіти помістіть у кінець у секцію додатків. Тут мають бути короткі та ємні докази знайдених проблем.
Пріоритезуйте знайдені проблеми за шкалою error, warning, info. Ви можете вибрати свою шкалу, але ця є загальноприйнятою.
Як справжній архітектор ви повинні надати рекомендації щодо усунення знайдених проблем. Опишіть покращення та цінність для бізнесу, які отримає клієнт. Як показати цінність для бізнесу від ми обговорювали раніше.
Підготуйте roadmap з невеликими ітераціями. Кожна ітерація повинна містити час на виконання, опис, кількість ресурсів, необхідних для покращення, технічну цінність та цінність для бізнесу.
Закінчуємо оцінку архітектури та надаємо клієнту звіт
Ніколи просто не надсилайте звіт поштою. Його можуть або взагалі не прочитати чи прочитати та не зрозуміти без належного пояснення. Коротше – живе спілкування допомагає усунути непорозуміння між людьми. Вам слід призначити мітинг із клієнтом та розповісти про знайдені проблеми, поставивши акцент на найбільш значущих. Варто звернути увагу клієнта на проблеми, про які він міг навіть не підозрювати. Такі, як проблеми з безпекою і пояснити, як вони можуть вплинути на бізнес. Покажіть свою roadmap з покращеннями та обговоріть різні варіанти, що підходять для клієнта. Це може бути час, ресурси, обсяги робіт.
Як підбиття підсумків вашого мітингу надішліть клієнтові ваш звіт.
На закінчення
Оцінка архітектури – це складний процес. Щоб провести оцінку належним чином вам необхідно мати достатньо досвіду та знань.
Це реально — надати клієнту корисні для нього та його бізнесу результати лише за тиждень. Навіть якщо ви робите це самотужки.
Виходячи з мого досвіду багато покращень закачувалися на середині, а іноді так ніколи і не розпочавшись. Ті, хто вибирали для себе золоту середину і робили лише частину покращень максимально корисних для бізнесу з мінімальними трудовитратами, значно покращували якість свого продукту. Ті ж, хто нічого не робив через пару років могли взагалі закрити проект.
Ваша мета показати клієнту максимальні покращення за мінімальну ціну.
Інші статті з розділу можна почитати на дозвіллі.
Бажаю вам чистого коду та гарних архітектурних рішень.
Наша facebook група .
Джерело: habr.com