Како да прочитате и поправите 100,000 линии код за една недела

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

Како да оцените проект од 100 илјади или повеќе линии код за една недела, а сепак да обезбедите резултати кои се навистина корисни за клиентот.

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

Оригиналот на англиски јазик за вашите пријатели што не зборуваат руски е тука: Проценка на архитектурата за една недела.

Пристапот на нашата компанија

Ќе ви кажам како функционира во нашата компанија и како постапувам во слични ситуации, но вие лесно можете да го промените овој пристап според потребите на вашиот проект и компанија.

Постојат два вида на оценување на архитектурата.

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

1. Тимот мисли дека нивниот проект е совршен и ова е сомнително. Сме имале такви случаи, а често во вакви проекти се е далеку од идеално.
2. Тимот сака да го тестира нивниот проект и нивните решенија.
3. Тимот знае дека работите се лоши. Можеби дури и ги наведуваат главните проблеми и причини, но сакаат комплетна листа на проблеми и препораки за подобрување на проектот.

Надворешно е повеќе формален процес отколку внатрешно оценување. Клиентот секогаш доаѓа само во еден случај, кога сè е лошо - многу лошо. Обично клиентот разбира дека има глобални проблеми, но не може правилно да ги идентификува причините и да ги разложи на компоненти.

Оценувањето на архитектурата за надворешен клиент е покомплексен случај. Процесот треба да биде поформален. Проектите се секогаш големи и стари. Имаат многу проблеми, багови и искривен код. Извештајот за сработеното треба да биде готов максимум во рок од неколку недели, кој треба да ги содржи главните проблеми и препораки за подобрување. Затоа, ако се занимаваме со екстерното оценување на проектот, тогаш интерното оценување ќе биде парче колач. Да го разгледаме најтешкиот случај.

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

Типичен проект за евалуација е голем, стар, деловен проект со многу проблеми. Доаѓа клиент кај нас и бара да го поправиме неговиот проект. Тоа е како со санта мраз, клиентот го гледа само врвот на своите проблеми и нема поим што има под водата (во длабочините на кодот).

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

• Прашања за изведба
• Проблеми со употребливоста
• Долгорочно распоредување
• Недостаток на единица и други тестови

Проблеми за кои клиентот најверојатно не е свесен, но тие може да се присутни во проектот:

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

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

Ова е формален процес што го следиме како компанија, но можете да го приспособите во зависност од вашата компанија и проект.

Барање од клиент

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

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

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

Треба да соберете што е можно повеќе информации за проектот. Можете да користите различни техники во зависност од ситуацијата:

• Прашалници и други методи на комуникација преку пошта. Најнеефикасен начин.
• Онлајн состаноци.
• Специјални алатки за размена на информации како што се: Google doc, Confluence, складишта итн.
• „Во живо“ состаноци на локацијата. Најефективен и најскап начин.

Што треба да добиете од клиентот?

Основни информации. За што се работи проектот? Неговата цел и вредност. Главни цели и планови за во иднина. Деловни цели и стратегии. Главни проблеми и посакувани резултати.

Информации за проектот. Технолошки стек, рамки, програмски јазици. Распоредување во простории или облак. Ако проектот е во облак, какви услуги се користат. Кои архитектонски и дизајнерски обрасци беа користени.

Нефункционални барања. Сите барања поврзани со перформансите, достапноста и леснотијата на користење на системот. Барања за безбедност итн.

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

Пристап до изворниот код. Најважниот дел! Дефинитивно треба да добиете пристап до складиштата и документацијата за тоа како да го изградите проектот.

Пристап до инфраструктура. Би било убаво да имате пристап до сцената или продукциската инфраструктура за да работите со системот во живо. Голем успех е доколку клиентот има алатки за следење на инфраструктурата и перформансите. Ќе зборуваме за овие алатки во следниот дел.

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

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

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

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

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

За жал, ќе мора рачно да ја прочитате документацијата. Со вистинското искуство, можете брзо да го разберете квалитетот на документацијата. Што е точно, а што јасно не се совпаѓа со реалноста. Понекогаш може да видите архитектура во документација која никогаш нема да работи во реалниот живот. Ова е поттик за да размислите како тоа беше направено во реалноста во проектот.

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

Оценувањето на кодот е едноставна вежба. Можете да користите статични анализатори на код што ќе ви ги покажат проблемите со дизајнот, перформансите и безбедноста. Еве неколку од нив:

Структура 101 е одлична алатка за архитект. Ќе ви ја покаже големата слика, зависностите помеѓу модулите и потенцијалните области за рефакторирање. Како и сите добри алатки, чини добри пари, но можете да ја искористите 30-дневната пробна верзија.

soundQube - стара добра алатка. Алатка за статичка анализа на кодови. Ви овозможува да идентификувате лош код, грешки и безбедносни проблеми за повеќе од 20 програмски јазици.

Сите даватели на облак имаат алатки за следење на инфраструктурата. Ова ќе ви овозможи правилно да ја оцените ефективноста на вашата инфраструктура во однос на трошоците и перформансите. За AWS ова е доверлив советник. Лесно е за Azure Азур советник.

Дополнително следење на перформансите и евиденција ќе помогнат да се најдат проблеми со перформансите на сите нивоа. Почнувајќи од базата на податоци со неефикасни прашања, задниот дел и завршувајќи со предниот дел. Дури и ако клиентот претходно не ги инсталирал овие алатки, можете прилично брзо да ги интегрирате во постоечкиот систем за да ги идентификувате проблемите со перформансите.

Како и секогаш, добрите алатки вредат. Можам да препорачам неколку платени алатки. Се разбира, можете да користите отворен код, но ќе ви одземе повеќе време. И ова треба да се направи однапред, а не за време на процесот на архитектонска проценка.

нов остаток – алатка за оценување на перформансите на апликацијата
Датадог – услуга за следење на системот во облак

Достапни се многу алатки за безбедносно тестирање. Овој пат ќе ви препорачам бесплатна алатка за скенирање на системот.

OWASP ZAP – алатка за скенирање на веб апликации за усогласеност со безбедносните стандарди.

Ајде да составиме сè во една целина.

Подготовка на извештај

Започнете го вашиот извештај со податоците што ги собравте од клиентот. Опишете ги целите на проектот, ограничувањата, нефункционалните барања. По ова, треба да се споменат сите влезни податоци: изворен код, документација, инфраструктура.

Следен чекор. Наведете ги сите проблеми што ги најдовте рачно или користејќи автоматски алатки. Ставете големи автоматски генерирани извештаи на крајот во делот за апликации. Треба да има кратки и прецизни докази за пронајдените проблеми.
Дајте приоритет на проблемите пронајдени на скалата за грешка, предупредување, информации. Можете да изберете своја вага, но ова е општо прифатената скала.

Како вистински архитект, ваша одговорност е да дадете препораки за да ги поправите пронајдените проблеми. Опишете ги подобрувањата и деловната вредност што ќе ги добие клиентот. Како да се покаже деловна вредност од архитектонско рефакторирање разговаравме претходно.

Подгответе патоказ со мали повторувања. Секоја повторување треба да содржи време за завршување, опис, количина на ресурси потребни за подобрување, техничка вредност и деловна вредност.

Ја комплетираме проценката на архитектурата и му даваме извештај на клиентот

Никогаш само не испраќајте извештај по пошта. Можеби воопшто не се чита или не се чита и разбира без соодветно објаснување. Накратко, комуникацијата во живо помага да се елиминираат недоразбирањата меѓу луѓето. Треба да закажете состанок со клиентот и да разговарате за пронајдените проблеми, фокусирајќи се на најзначајните. Вреди да се сврти вниманието на клиентот на проблеми за кои можеби не е ни свесен. Како безбедносни прашања и објаснете како тие би можеле да влијаат на бизнисот. Покажете го вашиот патоказ со подобрувања и разговарајте за различни опции кои се посоодветни за клиентот. Ова може да биде време, ресурси, количина на работа.

Како резиме на вашиот состанок, испратете го вашиот извештај до клиентот.

Во заклучок

Евалуацијата на архитектурата е сложен процес. За правилно спроведување на оценувањето потребно е да имате доволно искуство и знаење.

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

Врз основа на моето искуство, многу подобрувања беа преземени во средината, а понекогаш и никогаш не започнаа. Оние кои сами ја избраа златната средина и направија само дел од подобрувањата кои беа најкорисни за бизнисот со минимални трошоци за работна сила значително го подобрија квалитетот на својот производ. Оние кои не направија ништо, можеа целосно да го затворат проектот по неколку години.

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

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

Ви посакувам чист код и добри архитектонски одлуки.

Нашата Фејсбук група - Архитектура и развој на софтвер.

Извор: www.habr.com