Kun järjestelmään suunnitellaan merkittäviä muutoksia, on tärkeää tietää, mihin sen nykyinen arkkitehtuuri taipuu. Edessä voi olla uuden ominaisuuden tai integraation toteuttaminen, sääntelymuutos tai päätös järjestelmän modernisoinnista. Toisinaan taas järjestelmän kehittäminen on hidastunut ja kustannukset kasvaneet ilman selvää syytä. 

Arkkitehtuurikatselmointi on ulkopuolisen asiantuntijan arvio siitä, miten ohjelmisto on rakennettu ja mihin se rakenteensa puolesta riittää. Katselmointi auttaa tunnistamaan mahdolliset ongelmat ja riskit sekä tekemään perusteltuja päätöksiä järjestelmän tulevaisuudesta ennen kuin merkittäviin kehityshankkeisiin sitoudutaan. 

Laaturaportti vastaa eri kysymykseen kuin arkkitehtuurikatselmointi 

Monessa organisaatiossa on jo koodin laatutyökalut käytössä. Ne vastaavat kuitenkin eri kysymykseen kuin siihen, jonka takia katselmointi yleensä tilataan. 

Koodin laatutyökalu kertoo, onko yksittäisellä rivillä vikaa. Johto haluaa tietää, mihin kokonaisuus riittää. Tuhannesta rivikohtaisesta havainnosta on vaikea saada vastausta jälkimmäiseen. Havaintojen puuttuminen ei myöskään todista arkkitehtuuria toimivaksi. Järjestelmä voi olla mekaanisilla mittareilla puhdas ja silti rakenteeltaan sellainen, että pienikin lisäys on työläs. 

Miten arkkitehtuurikatselmointi toteutetaan? 

Meillä Reflectorilla arkkitehtuurikatselmointi aloitetaan keskustelulla. Mitä järjestelmällä tehdään nyt? Mitä sillä aiotaan tehdä ja mikä huolettaa? Tämä ratkaisee, mihin arvioinnissa keskitytään. 

Sen jälkeen ajamme koodin koneellisesti omien analyysityökalujemme läpi. Ne antavat nopeasti kokonaiskuvan ja näyttävät, mihin kannattaa perehtyä tarkemmin. Koodi käsitellään omassa ympäristössämme, eikä sitä lähetetä ulkopuolisiin palveluihin.  

Työkalujen tulokset tulkitsemme ja tarkistamme itse. Erotamme todelliset ongelmat ja arvioimme niiden vakavuuden sen mukaan, miten järjestelmää käytetään. Epäselvät kohdat tarkistamme tarvittaessa kehittäjiltä. 

Lopuksi kirjoitamme tulokset raportiksi ja käymme ne läpi kanssanne. 

Mitä arkkitehtuurikatselmoinnissa käydään läpi 

Koko ja rakenne. Paljonko on lähdekoodia, testejä, konfiguraatiota ja generoitua koodia, ja miten koodi jakautuu eri osiin? Mitkä osat riippuvat mistäkin, pitävätkö moduulien rajat ja onko osien välillä kehäriippuvuuksia? Katsomme myös, onko jokin moduuli sellainen, jonka varassa lähes kaikki muut ovat. Tästä näkee, miksi pieni muutos voi levitä moneen paikkaan. 

Kirjastot ja tietoturva. Mitä kolmannen osapuolen kirjastoja projekti käyttää, ja onko niissä tunnettuja haavoittuvuuksia? Samalla näemme, mihin teknologioihin järjestelmä nojaa. Lisäksi staattinen analyysi etsii koodista tunnettuja tietoturvavirheiden malleja. 

Muutettavuus. Arvioimme, kuinka helposti ja turvallisesti järjestelmään voidaan tehdä muutoksia. Testikoodin määrä suhteessa lähdekoodiin antaa ensimmäisen kuvan. Ilman testejä muutokset ovat riskialttiimpia ja hitaampia tehdä. Lisäksi mittaamme, missä kohdissa logiikkaa on kasautunut niin paljon, että muutokset ovat raskaita ja virheherkkiä. 

Tunnetut sudenkuopat. Etsimme virheitä ja suorituskykyongelmia, jotka toistuvat projektista toiseen. Esimerkiksi tallennus ei päädy tietokantaan, koska transaktio on määritelty väärin, tai tietokantaan tehdään satoja erillisiä kyselyitä, vaikka yksi riittäisi. 

Katselmointi kestää muutamasta päivästä pariin viikkoon järjestelmän koon mukaan. Asiakkaalta tarvitaan lukuoikeus koodiin ja hieman aikaa taustoitukseen. 

Mitä arkkitehtuurikatselmoinnista jää käteen 

Raportti vastaa kolmeen kysymykseen: 

1. Onko koodi kunnossa? Kerromme suoraan, kestääkö järjestelmä ne muutokset, joita sille on suunniteltu. 

2. Jos ei, mikä puuttuu? Muodossa, jonka voi viedä eteenpäin. Esimerkiksi: Sovelluksen kerrosten rajat eivät pidä, jolloin ylläpidettävyys on alkanut rapautua. Yksi moduuli on kasvanut kattamaan suuren osan järjestelmästä, ja lähes jokainen muutos riippuu siitä. Testejä on paljon, mutta ne eivät kata niitä kohtia, joihin tulevat muutokset osuvat. 

3. Mitä pitäisi tehdä ja missä järjestyksessä? Suositukset tärkeysjärjestyksessä sen mukaan, mikä helpottaa kehitystä eniten. 

Havainnot viittaavat tiettyyn kohtaan koodissa, ja mukana on korjausehdotus. Näin tiimi näkee, mihin arvio perustuu, ja voi tarkistaa sen itse. Lisäksi toimitamme yleiskuvan koodiin, johon voi sisältyä kokojakauma, moduulikartta tai riippuvuuskaavio. Ne helpottavat keskustelua myös järjestelmän eri sidosryhmien kanssa. 
 
Kehittäjät tietävät usein, missä ongelmat ovat, mutta niitä on vaikea osoittaa johdolle. Katselmoinnin jälkeen tiimillä ja päättäjillä on yhteinen, koodiin perustuva kuva järjestelmästä.