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

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

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

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

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

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

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

Има две разновидности на оценката на архитектурата.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Solution Architect – главният човек, отговорен за оценката и координацията (и често единственият).
Стек специфични експерти – .Net, Java, Python и други технически специалисти в зависимост от проекта и технологиите
Облачни експерти – това могат да бъдат архитекти на облаци Azure, GCP или AWS.
Инфраструктура – DevOps, системен администратор и т.н.
Други експерти – като експерти по big data, machine learning, performance engineering, security expert, QA lead.

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

Трябва да съберете възможно най-много информация за проекта. Можете да използвате различни техники в зависимост от ситуацията:

• Анкети и други методи за комуникация по имейл. Най-малко ефективният метод.
• Онлайн срещи.
• Специализирани инструменти за обмен на информация, като: Google doc, Confluence, хранилища и т.н.
• „Живи“ срещи на място. Най-ефективният и най-скъпият метод.

Какво трябва да получим от клиента?

Основна информация. За какво е проектът. Неговата цел и ценност. Основни цели и планове за бъдещето. Бизнес цели и стратегии. Основни проблеми и желан резултат.

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

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

Основни юзкейси и потоци от данни.

Достъп до изходния код. Най-важната част! Задължително трябва да получите достъп до репозиторите и документацията как да съберете проекта.

Достъп до инфраструктурата. Щеше да е добре да получите достъп до stage или производствената инфраструктура, за да работите с „жива“ система. Това е голям късмет, ако клиентът разполага с инструменти за мониторинг на инфраструктурата и производителността. За тези инструменти ще говорим в следващия раздел.

Документация. Ако клиентът разполага с документация, това е добро начало. Може да е остаряла, но все пак е добро начало. Никога не вярвайте на документацията – проверявайте я с клиента, на реалната инфраструктура и в изходния код.

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

Как обаче да обработите толкова голямо количество информация за толкова кратко време? Първо, разпаралелете работата.

DevOps специалистът трябва да погледне в инфраструктурата. Техническият лидер в кода. Инженерът по производителност да разгледа метриките по производителността. Специалистът по бази данни трябва да се задълбочи в структурите на данните.

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

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

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

Оценката на кода е простo упражнение. Можете да използвате статични анализатори на кода, които ще покажат проблеми в дизайна, производителността и сигурността. Ето няколко от тях:

Structure 101 е отличен инструмент за архитекти. Той ще ви покажe цялостната картина, зависимостите между модулите и потенциалните области за рефакториранe. Както всички добри инструменти, той е на добра цена, но можете да използвате и 30-дневна пробна версия.

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

Всички облачни доставчици имат инструменти за мониторинг на инфраструктурата. Това ще ви помогне да оцените ефективността на инфраструктурата от гледна точка на разходите и производителността. За AWS това е trusted advisor. За Azure е просто Azure Advisor.

Допълнителният мониторинг на производителността и логовете ще помогне за откриването на проблеми с производителността на всички нива. Започвайки от базата данни с неефективни заявки, бекенда и стигайки до фронтенда. Дори ако клиентът не е инсталирал тези инструменти преди, можете доста бързо да ги интегрирате в съществуващата система за идентифициране на проблеми с производителността.

Както винаги, добрите инструменти струват пари. Мога да ви препоръчам няколко платени инструмента. Разбира се, можете да използвате инструменти с отворен код, но ще отнеме повече време. И това трябва да се направи предварително, а не в процеса на оценяване на архитектурата.

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

Има множество инструменти за тестване на сигурността. Този път ще ви препоръчам безплатен инструмент за сканиране на системата.

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

Събираме всичко в едно.

Подготвяме отчет

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

Следваща стъпка. Посочете всички проблеми, които сте открили ръчно или с помощта на автоматизирани инструменти. Големите автосгенерирани отчети поставете в края в секция приложения. Тук трябва да бъдат кратки и ясни доказателства за откритите проблеми.
Приоритизирайте откритите проблеми по скалата error, warning, info. Можете да изберете своя скала, но тази е общоприета.

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

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

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

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

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

В заключение

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

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

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

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

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

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

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

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