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

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

Како проценити пројекат од 100 или више линија кода за недељу дана док и даље пружате резултате који су заиста корисни за клијента.

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

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

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

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

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

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

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

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

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

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

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

Проблеми на које се клијент може жалити и којих може бити свестан:

• Проблеми са перформансама
• Проблеми употребљивости
• Дугорочно распоређивање
• Недостатак јединичних и других тестова

Проблеми којих клијент највероватније није свестан, али могу бити присутни у пројекту:

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

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

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

Захтев од клијента

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

решење Архитекта – главна особа одговорна за процену и координацију (а често и једина).
Скупите специфичне стручњаке – .Нет, Јава, Питхон и други технички стручњаци у зависности од пројекта и технологије
Стручњаци за облак – то могу бити Азуре, ГЦП или АВС архитекте облака.
Инфраструктура – ДевОпс, администратор система итд.
Други стручњаци – као што су велики подаци, машинско учење, инжењер перформанси, стручњак за безбедност, КА лидер.

Прикупљање информација о пројекту

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

• Упитници и други начини комуникације путем поште. Најнеефикаснији начин.
• Онлине састанци.
• Специјални алати за размену информација као што су: Гоогле доц, Цонфлуенце, репозиторијуми итд.
• Састанци „уживо“ на лицу места. Најефикаснији и најскупљи начин.

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

Основне информације. О чему је пројекат? Његова сврха и вредност. Главни циљеви и планови за будућност. Пословни циљеви и стратегије. Главни проблеми и жељени резултати.

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

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

Основни случајеви коришћења и токови података.

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

Приступ инфраструктури. Било би лепо имати приступ бини или продукцијској инфраструктури за рад са живим системом. Велики је успех ако клијент има алате за праћење инфраструктуре и перформанси. О овим алатима ћемо говорити у следећем одељку.

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

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

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

ДевОпс би требало да погледа инфраструктуру. Технички водич у код. Инжењер перформанси за преглед метрика учинка. Специјалиста за базе података би требало да копа дубље у структуре података.

Али ово је идеалан случај када имате пуно ресурса. Типично, једна до три особе процењују пројекат. Можете чак и сами да извршите процену, што је често случај ако имате одговарајуће знање и искуство у свим областима пројекта. У овом случају морате аутоматизовати све процесе што је више могуће.

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

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

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

Структура 101 је одличан алат за архитекту. Показаће вам ширу слику, зависности између модула и потенцијалне области за рефакторисање. Као и сви добри алати, кошта добар новац, али можете искористити предности пробне верзије од 30 дана.

СонарКубе - добар стари алат. Алат за статичку анализу кода. Омогућава вам да идентификујете лош код, грешке и безбедносне проблеме за више од 20 програмских језика.

Сви добављачи облака имају алате за праћење инфраструктуре. Ово ће вам омогућити да правилно процените ефикасност ваше инфраструктуре у смислу трошкова и перформанси. За АВС ово је поуздани саветник. Лако је за Азуре Азуре Адвисор.

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

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

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

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

ОВАСП ЗАП – алат за скенирање веб апликација у складу са безбедносним стандардима.

Хајде да све саставимо у једну целину.

Припрема извештаја

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

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

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

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

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

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

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

У закључку

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

Клијенту је могуће обезбедити резултате корисне за њега и његово пословање за само недељу дана. Чак и ако то урадите сами.

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

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

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

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

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

Извор: ввв.хабр.цом