Alussa on aina vaikea ymmärtää suurta ja vanhaa projektia. Arkkitehtuuri on yksi arkkitehtiarvioinnin toiminnoista. Yleensä joudut työskentelemään suurten, vanhojen projektien kanssa, ja tulokset on toimitettava viikossa.
Kuinka arvioida projektia, jossa on 100 XNUMX tai enemmän koodiriviä viikossa, ja silti tarjotaan asiakkaalle todella hyödyllisiä tuloksia.
Useimmat arkkitehdit ja tekniset johtajat ovat kohdanneet samanlaisia projektiarvioita. Tämä voi näyttää puolimuodolliselta prosessilta tai erilliseltä palvelulta, kuten yrityksessämme tehdään, tavalla tai toisella useimmat teistä ovat käsitelleet tämän.
Alkuperäinen englanninkielinen ei-venäjää puhuville ystävillesi on täällä: .
Yrityksemme lähestymistapa
Kerron sinulle, miten se toimii yrityksessämme ja miten toimin vastaavissa tilanteissa, mutta voit helposti muuttaa tätä lähestymistapaa projektisi ja yrityksesi tarpeiden mukaan.
Arkkitehtuurin arviointia on kahdenlaisia.
Sisustus – teemme sen yleensä yrityksen sisäisiin projekteihin. Mikä tahansa projekti voi pyytää arkkitehtuurin arviointia useista syistä:
- Ryhmän mielestä heidän projektinsa on täydellinen, ja tämä on epäilyttävää. Meillä on ollut tällaisia tapauksia, ja usein tällaisissa projekteissa kaikki on kaukana ihanteellisesta.
- Tiimi haluaa testata projektiaan ja niiden ratkaisuja.
- Joukkue tietää, että asiat ovat huonosti. He saattavat jopa luetella tärkeimmät ongelmat ja syyt, mutta haluavat täydellisen luettelon ongelmista ja suosituksia projektin parantamiseksi.
Ulkoinen on muodollisempi prosessi kuin sisäinen arviointi. Asiakas tulee aina vain yhdessä tapauksessa, kun kaikki on huonosti - erittäin huonosti. Yleensä asiakas ymmärtää, että on olemassa globaaleja ongelmia, mutta ei pysty tunnistamaan syitä oikein ja jakamaan niitä osiin.
Arkkitehtuurin arviointi ulkoiselle asiakkaalle on monimutkaisempi tapaus. Prosessin pitäisi olla muodollisempi. Projektit ovat aina suuria ja vanhoja. Heillä on paljon ongelmia, bugeja ja kieroa koodia. Tehdystä työstä pitäisi valmistua enintään muutaman viikon sisällä raportti, joka sisältää tärkeimmät ongelmat ja parannusehdotukset. Siksi, jos käsittelemme hankkeen ulkoista arviointia, sisäinen arviointi on pala kakkua. Tarkastellaan vaikeinta tapausta.
Yritysprojektin arkkitehtuurin arviointi
Tyypillinen arvioitava projekti on suuri, vanha yritysprojekti, jossa on paljon ongelmia. Asiakas tulee luoksemme ja pyytää meitä korjaamaan hänen projektinsa. Se on kuin jäävuoren kanssa, asiakas näkee vain ongelmiensa huipun, eikä hänellä ole aavistustakaan, mitä veden alla (koodin syvyyksissä) on.
Ongelmat, joista asiakas voi valittaa ja joista hän voi olla tietoinen:
- Suorituskykyongelmat
- Käytettävyysongelmat
- Pitkäaikainen käyttöönotto
- Yksikön ja muiden testien puute
Ongelmia, joista asiakas ei todennäköisesti ole tietoinen, mutta joita voi esiintyä projektissa:
- Turvallisuusongelmat
- Suunnitteluongelmat
- Väärä arkkitehtuuri
- Algoritmiset virheet
- Sopimattomia tekniikoita
- Tekninen velka
- Väärä kehitysprosessi
Muodollinen arkkitehtuurin tarkistusprosessi
Tämä on muodollinen prosessi, jota noudatamme yrityksenä, mutta voit muokata sitä yrityksesi ja projektisi mukaan.
Pyyntö asiakkaalta
Asiakas pyytää arvioimaan nykyisen projektin arkkitehtuuria. Puolueemme vastuuhenkilö kerää perustiedot hankkeesta ja valitsee tarvittavat asiantuntijat. Hankkeesta riippuen nämä voivat olla erilaisia asiantuntijoita.
Ratkaisuarkkitehti – pääasiallinen arvioinnista ja koordinoinnista vastaava henkilö (ja usein ainoa).
Pinoa tiettyjä asiantuntijoita – .Net, Java, Python ja muut tekniset asiantuntijat projektista ja teknologioista riippuen
Pilvien asiantuntijat – Nämä voivat olla Azure-, GCP- tai AWS-pilviarkkitehteja.
Infrastruktuuri – DevOps, järjestelmänvalvoja jne.
Muut asiantuntijat – kuten big data, koneoppiminen, suorituskykyinsinööri, tietoturvaasiantuntija, laadunvarmistusjohto.
Tietojen kerääminen projektista
Hankkeesta tulee kerätä mahdollisimman paljon tietoa. Voit käyttää erilaisia tekniikoita tilanteesta riippuen:
- Kyselylomakkeet ja muut viestintätavat postitse. Tehottomin tapa.
- Online-kokoukset.
- Erityistyökalut tiedonvaihtoon, kuten: Google doc, Confluence, arkistot jne.
- "Live" kokoukset paikan päällä. Tehokkain ja kallein tapa.
Mitä asiakkaalta pitäisi saada?
Perustiedot. Mistä hankkeessa on kyse? Sen tarkoitus ja arvo. Tärkeimmät tavoitteet ja tulevaisuuden suunnitelmat. Liiketoiminnan tavoitteet ja strategiat. Tärkeimmät ongelmat ja toivotut tulokset.
Hankkeen tiedot. Teknologiapino, puitteet, ohjelmointikielet. Paikallinen tai pilvikäyttöönotto. Jos projekti on pilvessä, mitä palveluita käytetään. Mitä arkkitehtonisia ja suunnittelumalleja käytettiin.
Ei-toiminnalliset vaatimukset. Kaikki järjestelmän suorituskykyyn, saatavuuteen ja helppokäyttöisyyteen liittyvät vaatimukset. Turvallisuusvaatimukset jne.
Peruskäyttötapaukset ja tietovirrat.
Pääsy lähdekoodiin. Tärkein osa! Sinun pitäisi ehdottomasti päästä käsiksi arkistoihin ja dokumentaatioon projektin rakentamisesta.
Pääsy infrastruktuuriin. Olisi kiva päästä lavalle tai tuotantoinfrastruktuuriin työskennellä live-järjestelmän kanssa. On suuri menestys, jos asiakkaalla on työkalut infrastruktuurin ja suorituskyvyn seurantaan. Puhumme näistä työkaluista seuraavassa osiossa.
Asiakirjat. Jos asiakkaalla on dokumentaatio, tämä on hyvä alku. Se voi olla vanhentunut, mutta se on silti hyvä alku. Älä koskaan luota dokumentaatioon - testaa sitä asiakkaan kanssa, todellisessa infrastruktuurissa ja lähdekoodissa.
Arkkitehtuurin arviointiprosessi
Miten niin paljon tietoa voidaan käsitellä niin lyhyessä ajassa? Ensinnäkin työn rinnakkain.
DevOpsin tulisi tarkastella infrastruktuuria. Tekninen johdatus koodiin. Suorituskykyinsinööri suorituskykymittareiden katseluun. Tietokantaasiantuntijan tulisi kaivaa syvemmälle tietorakenteisiin.
Mutta tämä on ihanteellinen tapaus, kun sinulla on paljon resursseja. Tyypillisesti yhdestä kolmeen henkilöä arvioi projektin. Voit jopa tehdä arvion itse, mikä usein tapahtuu, jos sinulla on asianmukaiset tiedot ja kokemus projektin kaikilta osa-alueilta. Tässä tapauksessa sinun on automatisoitava kaikki prosessit mahdollisimman paljon.
Valitettavasti joudut lukemaan asiakirjat manuaalisesti. Oikealla kokemuksella ymmärrät nopeasti dokumentaation laadun. Mikä on totta ja mikä ei selvästikään vastaa todellisuutta. Joskus dokumentaatiossa voi nähdä arkkitehtuuria, joka ei koskaan toimi oikeassa elämässä. Tämä laukaisee sinut pohtimaan, kuinka se todellisuudessa tehtiin projektissa.
Hyödyllisiä työkaluja projektin arvioinnin automatisointiin
Koodin arviointi on yksinkertainen harjoitus. Voit käyttää staattisia koodianalysaattoreita, jotka näyttävät suunnittelu-, suorituskyky- ja tietoturvaongelmat. Tässä muutamia niistä:
on loistava työkalu arkkitehdille. Se näyttää sinulle kokonaiskuvan, moduulien väliset riippuvuudet ja mahdolliset uudelleenjärjestelyalueet. Kuten kaikki hyvät työkalut, se maksaa hyvää rahaa, mutta voit hyödyntää 30 päivän kokeiluversiota.
- vanha hyvä työkalu. Staattisen koodin analyysityökalu. Voit tunnistaa yli 20 ohjelmointikielen huonon koodin, virheet ja tietoturvaongelmat.
Kaikilla pilvipalveluntarjoajilla on infrastruktuurin seurantatyökalut. Näin voit arvioida oikein infrastruktuurisi tehokkuutta kustannusten ja suorituskyvyn kannalta. AWS:lle tämä on . Se on helppoa Azurelle .
Suorituskyvyn lisäseuranta ja kirjaaminen auttavat löytämään suorituskykyongelmia kaikilla tasoilla. Alkaen tietokannasta, jossa on tehottomia kyselyjä, taustasta ja päättyen käyttöliittymään. Vaikka asiakas ei olisi asentanut näitä työkaluja aiemmin, voit integroida ne olemassa olevaan järjestelmään melko nopeasti suorituskykyongelmien tunnistamiseksi.
Kuten aina, hyvät työkalut ovat sen arvoisia. Voin suositella paria maksullista työkalua. Tietysti voit käyttää avointa lähdekoodia, mutta se vie enemmän aikaa. Ja tämä tulisi tehdä etukäteen, ei arkkitehtuurin arviointiprosessin aikana.
– työkalu sovellusten suorituskyvyn arviointiin
– pilvijärjestelmän valvontapalvelu
Tietoturvatestaukseen on saatavilla monia työkaluja. Tällä kertaa suosittelen sinulle ilmaista järjestelmän tarkistustyökalua.
– työkalu verkkosovellusten skannaamiseen turvallisuusstandardien noudattamiseksi.
Yhdistetään kaikki yhdeksi kokonaisuudeksi.
Raportin valmistelu
Aloita raporttisi asiakkaalta keräämilläsi tiedoilla. Kuvaile projektin tavoitteet, rajoitteet, ei-toiminnalliset vaatimukset. Tämän jälkeen tulee mainita kaikki syötetiedot: lähdekoodi, dokumentaatio, infrastruktuuri.
Seuraava askel. Luettele kaikki manuaalisesti tai automaattisten työkalujen avulla löytämäsi ongelmat. Sijoita suuret automaattisesti luodut raportit sovellusosion loppuun. Havaituista ongelmista pitäisi olla lyhyt ja ytimekäs todiste.
Priorisoi virheestä, varoituksesta, tietoasteikosta löydetyt ongelmat. Voit valita oman asteikon, mutta tämä on yleisesti hyväksytty.
Todellisena arkkitehtina on sinun vastuullasi antaa suosituksia havaittujen ongelmien korjaamiseksi. Kuvaile asiakkaan saamia parannuksia ja liiketoiminta-arvoa. Kuinka näyttää liiketoiminnan arvoa keskustelimme aiemmin.
Valmistele tiekartta pienillä iteraatioilla. Jokaisen iteroinnin tulee sisältää valmistumisaika, kuvaus, parantamiseen tarvittavien resurssien määrä, tekninen arvo ja liiketoiminnan arvo.
Suoritamme arkkitehtuurin arvioinnin ja toimitamme asiakkaalle raportin
Älä koskaan lähetä raporttia postitse. Sitä ei ehkä lueta ollenkaan tai sitä ei välttämättä lueta ja ymmärretä ilman asianmukaista selitystä. Lyhyesti sanottuna elävä viestintä auttaa poistamaan väärinkäsityksiä ihmisten välillä. Sinun tulee varata tapaaminen asiakkaan kanssa ja keskustella löydetyistä ongelmista keskittyen merkittävimpiin. Asiakkaan huomio kannattaa kiinnittää ongelmiin, joista hän ei ehkä ole edes tietoinen. Kuten turvallisuuskysymykset ja selitä, kuinka ne voivat vaikuttaa liiketoimintaan. Näytä etenemissuunnitelmasi parannuksilla ja keskustele eri vaihtoehdoista, jotka sopivat paremmin asiakkaalle. Tämä voi olla aikaa, resursseja, työn määrää.
Lähetä raporttisi asiakkaalle tiivistelmänä kokouksestasi.
lopuksi
Arkkitehtuurin arviointi on monimutkainen prosessi. Arvioinnin suorittaminen oikein edellyttää, että sinulla on riittävästi kokemusta ja tietoa.
Asiakkaalle on mahdollista tarjota hänelle ja hänen yritykselleen hyödyllisiä tuloksia jo viikossa. Vaikka tekisit sen yksin.
Kokemukseni perusteella monet parannukset ladattiin kesken, ja joskus niitä ei koskaan aloitettu. Ne, jotka valitsivat itselleen kultaisen keskitien ja tekivät vain osan yritykselle hyödyllisimmistä parannuksista pienin työvoimakustannuksin, paransivat merkittävästi tuotteensa laatua. Ne, jotka eivät tehneet mitään, voivat lopettaa projektin kokonaan muutaman vuoden kuluttua.
Tavoitteesi on näyttää asiakkaalle mahdollisimman paljon parannuksia minimihinnalla.
Muita artikkeleita osiosta voit lukea rauhassa.
Toivon sinulle puhdasta koodia ja hyviä arkkitehtonisia päätöksiä.
Facebook-ryhmämme - .
Lähde: will.com