🥇Как да прочетете и коригирате 100,000 реда код за една седмица

В началото винаги е трудно да се разбере голям проект, особено ако е стар. Оценката на архитектурата е една от дейностите на архитектите. Обикновено се налага да работим с големи, стари проекти, а резултатите трябва да бъдат предоставени за една седмица.

Как да оценим проект с 100 000 и повече реда код за една седмица и в същото време да предоставим наистина полезни резултати за клиента?

Повечето архитекти и технически лидери се сблъсквали със подобни оценки на проекти. Това може да изглежда като полуправилен процес или като отделна услуга, както е направено в нашата компания, така или иначе, повечето от вас са имали работа с това.

Оригиналът на английски език за вашите не рускоговорещи приятели се намира тук: Architecture Assessment in a week.

Подходът в нашата компания

Ще ви разкажа как това работи в нашата компания и как постъпвам в подобни ситуации, но можете лесно да промените този подход в съответствие с нуждите на вашия проект и компания.

Съществуват два вида оценка на архитектурата.

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

Отборът смята, че проектът им е перфектен и това е подозрително. Имахме такива случаи и често в такива проекти всичко не е идеално.
Отборът иска да проверят проекта и решенията си.
Отборът знае, че всичко е лошо. Те могат дори да изброят основните проблеми и причини, но искат да получат пълен списък с проблеми и предписания за подобрение на проекта.

Външна – това е по-формален процес в сравнение с вътрешната оценка. Клиентът идва само в един случай, когато всичко е лошо – много лошо. Обикновено клиентът осъзнава, че има глобални проблеми, но не може правилно да определи причините и да ги раздели на съставни части.

Оценката на архитектурата за външен клиент е по-сложен случай. Процесът трябва да бъде по-формален. Проектите винаги са големи и стари. В тях има много проблеми, бъгове и неправилно написан код. Докладът за проведената работа трябва да бъде готов в рамките на няколко седмици, максимум, където трябва да бъдат посочени основните проблеми и предложения за подобрение. Следователно, ако разберем външната оценка на проекта, то вътрешната ще бъде просто малка подробност. Нека разгледаме най-сложния случай.

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

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

Проблемите, за които клиентът може да се оплаче и които може да знае:

Проблеми с производителността
Проблеми с удобството на приложението (Usability)
Продължителен деплоймент
Липса на unit и други тестове

Проблеми, за които клиентът вероятно не подозира, но могат да присъстват в проекта:

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

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

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

Запитване от клиента

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

Solution Architect – главният човек, отговорен за оценката и координацията (и често единственият).
Stack specific experts – .Net, Java, Python и други технически специалисти в зависимост от проекта и технологиите
Cloud experts – това могат да бъдат Azure, GCP или AWS облачни архитекти.
Infrastructure – DevOps, системен администратор и т.н.
Други експерти – като 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. Можете да изберете своя скала, но това е общоприето.

Като истински архитект вие сте длъжни да предоставите препоръки за решаване на откритите проблеми. Опишете подобренията и ценността за бизнеса, които клиентът ще получи. Как да покажете стойността за бизнеса от архитектурното рефактиране ние обсъждахме по-рано.

Подгответе план с малки итерации. Всяка итерация трябва да съдържа време за изпълнение, описание, брой ресурси, необходими за подобрението, техническа стойност и стойност за бизнеса.

Завършваме оценката на архитектурата и предоставяме на клиента доклада.

Никога не изпращайте доклада по имейл без предварително обсъждане. Той може или да не бъде прочетен изобщо, или да бъде прочетен и недоразбран без адекватно обяснение. По-кратко – живата комуникация помага да се избегнат недоразумения между хората. Трябва да насрочите среща с клиента и да обсъдите откритите проблеми, акцентирайки на най-важните. Струва си да привлечете вниманието на клиента към проблемите, за които той може дори да не подозира. Както например проблеми със сигурността и да обясните как те могат да повлияят на бизнеса. Покажете своя план с подобрения и обсъдете различни варианти, които са по-подходящи за клиента. Това може да бъде време, ресурси, обем работа.

Като обобщение на вашата среща, изпратете на клиента вашия доклад.

В заключение

Оценката на архитектурата е сложен процес. За да извършите оценка правилно, трябва да имате достатъчно опит и знания.

Възможно е да предоставите на клиента полезни резултати за него и неговия бизнес само за седмица. Дори ако го правите сами.

Според моя опит много подобрения бяха спиранти по средата, а понякога дори не започнаха. Тези, които избраха златната среда и направиха само част от подобренията, максимално полезни за бизнеса с минимални усилия, значително подобряваха качеството на своя продукт. Тези, които не направиха нищо, след няколко години можеха да закрият проекта.

Вашата цел е да покажете на клиента максимални подобрения за минимални разходи.

Други статии от раздела архитектура можете да прочетете в свободното си време.

Пожелавам ви чист код и добри архитектурни решения.

Нашата facebook група — Софтверна архитектура и развитие.

Източник: habr.com