Спачатку заўсёды цяжка разабрацца ў вялікім і старым праекце. Architecture assessment - гэта адна з актыўнасцяў архітэктара. Звычайна даводзіцца працаваць з вялікімі, старымі праектамі, а вынікі трэба падаць за тыдзень.
Як ацаніць праект памерам 100к і больш радкоў кода за тыдзень пры гэтым падаць сапраўды карысныя для кліента вынікі.
Большасць архітэктараў і тых лідаў сутыкаліся з падобнымі ацэнкамі праекта. Гэта можа выглядаць як паўфармальны працэс ці як асобны сэрвіс як гэта зроблена ў нашай кампаніі, так ці інакш большасць з вас мелі справу з гэтым.
Арыгінал на англійскай мове для вашых не рускамоўных сяброў ляжыць тут: .
Падыход у нашай кампаніі
Я раскажу вам як гэта працуе ў нашай кампаніі і як я раблю ў падобных сітуацыях, але вы можаце з лёгкасцю мяняць дадзены паход згодна з патрэбамі вашага праекта і кампаніі.
Ёсць дзве разнавіднасці architecture assessment.
ўнутраны - Мы звычайна робім яго для праектаў ўнутры кампаніі. Любы праект можа запытаць ацэнку архітэктуры па некалькіх прычынах:
- Каманда думае, што іх праект ідэальны і гэта падазрона. У нас былі такія выпадкі і часта ў такіх праектах усё далёка не ідэальна.
- Каманда жадае праверыць свой праект і свае рашэнні.
- Каманда ведае, што ўсё дрэнна. Яны могуць нават пералічыць асноўныя праблемы і прычыны, але жадаюць атрымаць поўны спіс праблем і рэкамендацый па паляпшэнні праекту.
знешні – гэта больш фармальны працэс, чым унутраная ацэнка. Кліент прыходзіць заўсёды толькі ў адным выпадку, калі ўсё дрэнна - вельмі дрэнна. Звычайна кліент разумее, што ёсць глабальныя праблемы, але не можа дакладна вызначыць прычыны і разбіць на кампаненты.
Ацэнка архітэктуры для знешняга кліента больш складаны выпадак. Працэс павінен быць больш фармальны. Праекты заўсёды вялікія і старыя. У іх шмат праблем, багаў і крывога кода. Справаздача аб праведзенай рабоце павінна быць гатова на працягу некалькіх тыдняў максімум, дзе павінны быць асноўныя праблемы і рэкамендацыі па паляпшэнню. Таму, калі мы разбярэмся са знешняй ацэнкай праекта, то ўнутраны гэта будзе пару дробязяў. Разгледзім самы складаны выпадак.
Ацэнка архітэктуры энтэрпрайз праекта
Тыповы праект для ацэнкі - гэта вялікі, стары, энтэрпрайз праект з вялікай колькасцю праблем. Кліент прыходзіць да нас і просіць паправіць яго праект. Гэта як з айсбергам, кліент бачыць толькі верхавіну сваіх праблем і не здагадваецца аб тым, што пад вадой (у глыбіні кода).
Праблемы, на якія кліент можа пажаліцца і можа ведаць пра іх:
- Праблемы з прадукцыйнасцю
- Праблемы з выгодай выкарыстання прыкладання (Usability)
- Працяглы дэплаймент
- Адсутнасць unit і іншых тэстаў
Праблемы, аб якіх кліент хутчэй за ўсё не здагадваецца, але яны могуць прысутнічаць у праекце:
- Праблемы з бяспекай
- Праблемы праектавання
- Няверная архітэктура
- Алгарытмічныя памылкі
- Непадыходныя тэхналогіі
- Тэхнічны доўг
- Няправільны працэс распрацоўкі
Фармальны працэс ацэнкі архітэктуры
Гэта фармальны працэс, якога мы прытрымліваемся ў кампаніі, але вы можаце яго падстроіць пад сябе ў залежнасці ад вашай кампаніі і праекту.
Запыт ад кліента
Кліент просіць ацаніць архітэктуру бягучага праекту. Адказны чалавек з нашага боку збірае базавую інфармацыю аб праекце і падбірае неабходных экспертаў. У залежнасці ад праекту, гэта могуць быць розныя эксперты.
Архітэктар рашэнняў – галоўны чалавек адказны за адзнаку і каардынацыю (і часцяком адзіны).
Stack specific experts – .Net, Java, Python, і іншыя тэхнічныя спецыялісты ў залежнасці ад праекта і тэхналогій
Cloud experts - гэта могуць быць Azure, GCP або AWS cloud архітэктары.
Інфраструктура - DevOps, System administrator, і г.д.
Іншыя эксперты такія як big data, machine learning, performance engineer, security expert, QA lead.
Збор інфармацыі аб праекце
Вам трэба сабраць як мага больш інфармацыі пра праект. Вы можаце выкарыстоўваць розныя тэхнікі ў залежнасці ад сітуацыі:
- Апытальнікі і іншыя спосабы зносін праз пошту. Самы неэфектыўны спосаб.
- Анлайн сустрэчы.
- Спецыяльныя інструменты для абмену інфармацыяй такія як: Google doc, Confluence, рэпазітары і г.д.
- "Жывыя" сустрэчы на месцы. Самы эфектыўны і самы дарагі спосаб.
Што ж трэба атрымаць ад кліента?
Базавая інфармацыя. Пра што праект. Яго мэта і каштоўнасць. Асноўныя мэты і планы на будучыню. Бізнэс мэты і стратэгіі. Асноўныя праблемы і жаданы вынік.
Інфармацыя аб праекце. Тэхналагічны стэк, фрэймворкі, мовы праграмавання. On-premise або хмарны дэплоймент. Калі праект у воблаку, якія сэрвісу выкарыстоўваюцца. Якія архітэктурныя і дызайн патэрны прымяняліся.
Ня функцыянальныя патрабаванні. Усе патрабаванні, злучаныя з прадукцыйнасцю, даступнасцю, выгодай выкарыстання сістэмы. Патрабаванні бяспекі і г.д.
Базавыя юскейсы і патокі даных.
Доступ да зыходнага кода. Самая галоўная частка! Вам абавязкова варта атрымаць доступ да рэпазітароў і дакументацыі як сабраць праект.
Доступ да інфраструктуры. Было б нядрэнна атрымаць доступ да stage ці production інфраструктуры, каб папрацаваць з "жывой" сістэмай. Гэта вялікі поспех, калі ў кліента ёсць інструменты па маніторынгу інфраструктуры і прадукцыйнасці. Пра гэтыя інструменты мы пагаворым у наступнай секцыі.
Дакументацыя. Калі ў кліента ёсць дакументацыя, гэта добры пачатак. Яна можа быць састарэлая, але гэта ўсё роўна добры пачатак. Ніколі не верце дакументацыі - правярайце яе з кліентам, на рэальнай інфраструктуры і ў зыходным кодзе.
Працэс ацэнкі архітэктуры
Як жа ўсё ж апрацаваць такую вялікую колькасць інфармацыі за такія кароткія тэрміны? Першым чынам распаралельце працу.
DevOpsу трэба паглядзець у інфраструктуру. Тых ліду ў код. Перфоманс інжынеру паглядзець метрыкі па прадукцыйнасці. Спецыялісту па базах даных варта глыбей капнуць структуры даных.
Але гэта ідэальны выпадак, калі ў вас шмат рэсурсаў. Звычайна адзнаку праекту праводзяць ад аднаго да трох чалавек. Вы нават можаце правесці ацэнку самі, што часта і адбываецца, калі ў вас ёсць належныя веды і вопыт ва ўсіх абласцях праекта. У такім разе вам трэба аўтаматызаваць усе працэсы, на колькі гэта магчыма.
На жаль, прачытаць дакументацыю вам давядзецца ўручную. Пры наяўнасці належнага досведу вы зможаце даволі хутка зразумець якасць дакументацыі. Што там праўда, а што відавочна не супадае з рэчаіснасцю. Часам вы можаце сустрэць такую архітэктуру ў дакументацыі, якая ніколі не будзе працаваць у рэальным жыцці. Гэта трыгер для вас задумацца, а як жа яно зроблена ў рэальнасці ў праекце.
Карысныя прылады для аўтаматызацыі адзнакі праекту
Ацэнка кода - гэта простае практыкаванне. Вы можаце выкарыстоўваць статычныя аналізатары кода, якія пакажуць праблемы дызайну, прадукцыйнасці і бяспекі. Вось некалькі з іх:
- Гэта выдатны інструмент для архітэктара. Ён пакажа вам агульную карціну, залежнасць паміж модулямі і патэнцыйныя вобласці для рэфактарынгу. Як усе добрыя прылады, ён каштуе добрых грошай, у той жа час вы можаце скарыстацца выпрабавальнай 30-ці дзённай версіяй.
– стары добры інструмент. Інструмент для статычнага аналізу кода. Дазваляе вызначыць дрэнны код, багі, праблемы з бяспекай для больш чым 20 моў праграмавання.
Усе хмарныя правайдэры маюць прылады для маніторынгу інфраструктуры. Гэта дазволіць вам правільна ацаніць эфектыўнасць інфраструктуры з пункту гледжання кошту і прадукцыйнасці. Для AWS гэта . Для Azure гэта проста .
Дадатковы маніторынг прадукцыйнасці і лагіравання дапаможа знайсці праблемы з прадукцыйнасцю на ўсіх узроўнях. Пачынаючы ад базы дадзеных з не эфектыўнымі запытамі, бэкенда і заканчваючы франтэндам. Нават калі кліент не ўстанавіў гэтыя інструменты раней, вы можаце даволі хутка інтэграваць іх у існуючую сістэму, каб вызначыць праблемы з прадукцыйнасцю.
Як заўсёды добрыя прылады добра стаяць. Я магу парэкамендаваць пару платных інструментаў. Вядома, вы можаце выкарыстоўваць open-source але вам спатрэбіцца больш часу для гэтага. І гэта трэба зрабіць загадзя, а не ў працэсе ацэнкі архітэктуры.
- інструмент па ацэнкі прадукцыйнасці прыкладанняў
– хмарны сэрвіс маніторынгу сестем
Для тэсціравання бяспекі ёсць мноства інструментаў. На гэты раз я парэкамендую вам бясплатную прыладу для сканавання сістэмы.
- Інструмент для сканавання вэб прыкладанняў на адпаведнасць стандартам бяспекі.
Збіраны ўсё ў адзінае цэлае.
Рыхтуем справаздачу
Пачніце сваю справаздачу з сабраных ад кліента дадзеных. Апішыце мэты праекту, абмежаванні, нефункцыянальныя патрабаванні. Пасля гэтага варта згадаць усе ўваходныя дадзеныя зыходны код, дакументацыя, інфраструктура.
Наступны крок. Пакажыце ўсе праблемы, якія вы знайшлі ўручную ці з дапамогай аўтаматызаваных інструментаў. Вялікія аўтазгенераваныя справаздачы змясціце ў канец у секцыю прыкладанняў. Тут павінны быць кароткія і ёмістыя доказы знойдзеных праблем.
Прыярытэзуйце знойдзеныя праблемы па шкале error, warning, info. Вы можаце абраць сваю шкалу, але гэтая агульнапрынятая.
Як сапраўдны архітэктар вы абавязаны падаць рэкамендацыі па ўхіленні знойдзеных праблем. Апішыце паляпшэнні і каштоўнасць для бізнэсу, якія атрымае кліент. Як паказаць каштоўнасць для бізнесу ад мы абмяркоўвалі раней.
Падрыхтуйце roadmap з маленькімі ітэрацыямі. Кожная ітэрацыя павінна змяшчаць час на выкананне, апісанне, колькасць рэсурсаў неабходных для паляпшэння, тэхнічную каштоўнасць і каштоўнасць для бізнесу.
Сканчаем адзнаку архітэктуры і падаем кліенту справаздачу
Ніколі проста не дасылайце справаздачу па пошце. Яго могуць ці ўвогуле не прачытаць ці прачытаць і не зразумець без належнага тлумачэння. Карацей - жывыя зносіны дапамагаюць ліквідаваць непаразуменні паміж людзьмі. Вам варта прызначыць мітынг з кліентам і расказаць пра знойдзеныя праблемы паставіўшы акцэнт на самых значных. Варта звярнуць увагу кліента на праблемы, пра якія ён мог нават не падазраваць. Такія як праблемы з бяспекай і растлумачыць, як яны могуць паўплываць на бізнэс. Пакажыце сваю roadmap з паляпшэннямі і абмяркуйце розныя варыянты, больш прыдатныя для кліента. Гэта можа быць час, рэсурсы, аб'ём работ.
Як падвядзенне вынікаў вашага мітынгу адпраўце кліенту вашу справаздачу.
У заключэнне
Ацэнка архітэктуры - гэта складаны працэс. Каб правесці ацэнку належным чынам вам неабходна мець дастаткова вопыту і ведаў.
Гэта рэальна - даць кліенту карысныя для яго і яго бізнэсу вынікі ўсяго за тыдзень. Нават калі вы робіце гэта ў адзіночку.
Зыходзячы з майго досведу шматлікія паляпшэнні запампоўваліся на сярэдзіне, а часам так ніколі і не пачаўшыся. Тыя, хто выбіралі для сябе залатую сярэдзіну і рабілі толькі частку паляпшэнняў максімальна карысных для бізнесу з мінімальнымі працавыдаткамі, значна паляпшалі якасць свайго прадукта. Тыя ж, хто нічога не рабіў праз пару гадоў маглі і зусім закрыць праект.
Ваша мэта паказаць кліенту максімальныя паляпшэнні за мінімальную цану.
Іншыя артыкулы з раздзела можна пачытаць у вольны час.
Жадаю вам чыстага кода і добрых архітэктурных рашэнняў.
Наша facebook група - .
Крыніца: habr.com