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

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

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

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

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

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

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

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

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

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

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

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

Оценка на архитектурата на корпоративния проект

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

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

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

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

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

Официален процес на преглед на архитектурата

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

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

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

Архитект на решения – основното лице, отговорно за оценката и координацията (и често единственото).
Подредете конкретни експерти – .Net, Java, Python и други технически специалисти в зависимост от проекта и технологиите
Облачни експерти – това могат да бъдат облачни архитекти на Azure, GCP или AWS.
Инфраструктура – DevOps, системен администратор и др.
Други експерти – като големи данни, машинно обучение, инженер по производителност, експерт по сигурността, QA лидер.

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

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

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

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

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

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

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

Основни случаи на употреба и потоци от данни.

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

Достъп до инфраструктура. Би било хубаво да имате достъп до сцената или производствената инфраструктура, за да работите със системата на живо. Голям успех е, ако клиентът има инструменти за мониторинг на инфраструктурата и производителността. Ще говорим за тези инструменти в следващия раздел.

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

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

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

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

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

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

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

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

Структура 101 е чудесен инструмент за архитект. Ще ви покаже голямата картина, зависимостите между модулите и потенциалните области за рефакторинг. Като всички добри инструменти, той струва добри пари, но можете да се възползвате от 30-дневна пробна версия.

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

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

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

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

Нова религия – инструмент за оценка на производителността на приложението
Куче за данни – услуга за мониторинг на облачна система

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

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

Нека съберем всичко в едно цяло.

Изготвяне на доклад

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

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

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

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

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

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

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

В заключение

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

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

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

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

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

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

Нашата фейсбук група - Софтуерна архитектура и разработка.

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