I starten er det altid svært at finde sig til rette i et stort og gammelt projekt. Architecture assessment er en af aktiviteterne for arkitekten. Man må ofte arbejde med store, gamle projekter, og resultaterne skal præsenteres på en uge.
Hvordan vurderer man et projekt med 100.000 linjer kode og mere på en uge, mens man stadig leverer virkelig nyttige resultater til kunden?
De fleste arkitekter og tech leads har stået over for sådanne projektspecifikationer. Det kan se ud som en halvformel proces eller som en separat service, som den vi tilbyder i vores virksomhed, men de fleste af jer har været i denne situation.
Originalen på engelsk for dine ikke-russisk talende venner ligger her: .
Tilgangen i vores virksomhed
Jeg vil fortælle dig, hvordan det fungerer i vores virksomhed, og hvordan jeg håndterer sådanne situationer, men du kan nemt tilpasse denne tilgang til dit projekts og din virksomheds behov.
Der er to slags architecture assessment.
Intern – vi laver normalt dette for projekter inden for virksomheden. Hvert projekt kan anmode om en arkitekturvurdering af flere grunde:
- Teamet tror, at deres projekt er perfekt, og det virker mistænkeligt. Vi har haft sådanne tilfælde, og ofte er alt langt fra perfekt i disse projekter.
- Teamet ønsker at tjekke deres projekt og løsninger.
- Teamet ved, at alt er dårligt. De kan endda opremse de vigtigste problemer og årsager, men ønsker at få en fuld liste over problemer og anbefalinger til forbedringer.
Ekstern – det er en mere formel proces end den interne vurdering. Kunden henvender sig altid kun under én omstændighed, når alt er dårligt – meget dårligt. Normalt forstår kunden, at der er globale problemer, men kan ikke korrekt identificere årsagerne og nedbryde dem.
Arkitekturvurdering for en ekstern kunde er en mere kompleks sag. Processen skal være mere formel. Projekterne er altid store og gamle. Der er mange problemer, bugs og dårligt kode. Rapporten om det udførte arbejde skal være klar inden for et par uger, højst, hvor de vigtigste problemer og anbefalinger til forbedringer skal præsenteres. Så hvis vi kan finde ud af den eksterne vurdering af projektet, vil den interne være en tilføjelse. Lad os se på den mest komplekse situation.
Vurdering af enterprise-arkitektur
Et typisk projekt til vurdering er et stort, gammelt enterprise-projekt med mange problemer. Kunden henvender sig til os og beder os om at reparere deres projekt. Det er som med et isbjerg; kunden ser kun toppen af deres problemer og aner ikke, hvad der gemmer sig under overfladen (i dybden af koden).
Problemer, som kunden måske klager over og er klar over:
- Ydelsesproblemer
- Problemer med brugervenligheden af applikationen (Usability)
- Langvarig deployment
- Manglende unit og andre tests
Problemer, som kunden sandsynligvis ikke er klar over, men som kan være til stede i projektet:
- Sikkerhedsproblemer
- Designproblemer
- Forkert arkitektur
- Algorithmiske fejl
- Utilstrækkelige teknologier
- Teknisk gæld
- Forkert udviklingsproces
Formel proces for vurdering af arkitektur
Dette er en formel proces, som vi følger i virksomheden, men du kan tilpasse den til dine behov afhængigt af dit firma og projekt.
Anmodning fra kunden
Kunden beder om at få vurderet arkitekturen for det aktuelle projekt. Den ansvarlige person fra vores side indsamler grundlæggende information om projektet og vælger de nødvendige eksperter. Afhængig af projektet kan det være forskellige eksperter.
Løsningsarkitekt – den primære person, der er ansvarlig for vurderingen og koordineringen (og ofte den eneste).
Stack-specifikke eksperter – .Net, Java, Python og andre tekniske specialister afhængigt af projektet og teknologierne.
Cloud-eksperter – dette kan være Azure, GCP eller AWS cloud-arkitekter.
Infrastruktur – DevOps, systemadministrator osv.
Andre eksperter – såsom big data, machine learning, performance engineer, sikkerhedsekspert, QA lead.
Indsamling af information om projektet
Du bør indsamle så meget information som muligt om projektet. Du kan bruge forskellige teknikker afhængigt af situationen:
- Spørgeskemaer og andre kommunikationsmetoder via e-mail. Den mest ineffektive metode.
- Online møder.
- Specialværktøjer til informationsudveksling, såsom: Google doc, Confluence, repositories osv.
- »Live« møder på stedet. Den mest effektive og dyre metode.
Hvad skal man så have fra kunden?
Grundlæggende information. Hvad handler projektet om? Dets mål og værdi. Hovedmål og fremtidige planer. Forretningsmål og strategier. Hovedproblemer og ønsket resultat.
Information om projektet. Teknologistak, rammer, programmeringssprog. On-premise eller cloud-deployment. Hvis projektet er i skyen, hvilke tjenester anvendes? Hvilke arkitektoniske og designmønstre er anvendt?
Ikke-funktionelle krav. Alle krav relateret til systemets ydelse, tilgængelighed, brugervenlighed. Sikkerhedskrav osv.
Basis-usecases og datastrømme.
Adgang til kildekoden. Den vigtigste del! Du skal absolut have adgang til repositoryer og dokumentation for, hvordan projektet samles.
Adgang til infrastrukturen. Det ville være godt at få adgang til stage eller produktionsinfrastrukturen for at arbejde med det 'aktive' system. Det er en stor fordel, hvis kunden har værktøjer til overvågning af infrastruktur og ydeevne. Vi vil tale om disse værktøjer i næste sektion.
Dokumentation. Hvis kunden har dokumentation, er det et godt udgangspunkt. Den kan være forældet, men det er stadig et godt udgangspunkt. Stol aldrig blindt på dokumentationen – verificer den med kunden, på den virkelige infrastruktur og i kildekoden.
Vurderingsprocessen for arkitektur
Hvordan håndterer man så mange informationer på så kort tid? Først og fremmest, del arbejdet op i parallelle spor.
DevOps bør kigge på infrastrukturen. Tech-lead til koden. Ydelsesteknikeren skal kigge på ydeevnemetrikker. Databasespecialisten bør grave dybere i datalogi.
Men det er den ideelle situation, når du har mange ressourcer. Normalt udføres projektvurderingen af en til tre personer. Du kan endda udføre vurderingen selv, hvilket ofte er tilfældet, hvis du har den nødvendige viden og erfaring inden for alle områder af projektet. I så fald skal du automatisere alle processer, hvor det er muligt.
Desværre må du læse dokumentationen manuelt. Med tilstrækkelig erfaring kan du hurtigt vurdere kvaliteten af dokumentationen. Hvad der er sandt, og hvad der åbenlyst ikke stemmer overens med virkeligheden. Nogle gange kan du finde en arkitektur i dokumentationen, der aldrig ville fungere i virkeligheden. Dette er en indikator for dig til at overveje, hvordan det faktisk er lavet i projektet.
Nyttige værktøjer til automatisering af projektvurdering
Kodevurdering er en simpel øvelse. Du kan bruge statiske kodeanalyseværktøjer, der viser design-, performance- og sikkerhedsproblemer. Her er nogle af dem:
– er et fremragende værktøj for arkitekter. Det vil give dig et overblik, afhængigheder mellem moduler og potentielle områder for refactoring. Som med alle gode værktøjer koster det penge, men du kan samtidig benytte en 30-dages prøveversion.
– den gode gamle værktøj. Et værktøj til statisk kodeanalyse. Det kan identificere dårlig kode, bugs og sikkerhedsproblemer på mere end 20 programmeringssprog.
Alle cloud-udbydere har værktøjer til overvågning af infrastrukturen. Dette vil give dig et korrekt billede af effektiviteten af infrastrukturen med hensyn til omkostninger og ydeevne. For AWS er det . For Azure er det blot .
Yderligere ydeevneovervågning og logføring kan hjælpe med at finde ydeevneproblemer på alle niveauer. Fra databasen med ineffektive forespørgsler, backend og op til frontend. Selvom kunden ikke tidligere har installeret disse værktøjer, kan du hurtigt integrere dem i det eksisterende system for at identificere ydeevneproblemer.
Som altid koster gode værktøjer penge. Jeg kan anbefale et par betalte værktøjer. Selvfølgelig kan du bruge open-source, men det vil tage længere tid. Og det bør gøres på forhånd, ikke under vurderingen af arkitekturen.
– værktøj til vurdering af applikationsydelse
– cloud-baseret overvågning af systemer
Til sikkerhedstest findes der mange værktøjer. Denne gang vil jeg anbefale et gratis værktøj til systemscanning.
– et værktøj til scanning af webapplikationer i henhold til sikkerhedsstandarder.
Samler alt i ét.
Forbereder rapport
Start din rapport med de indsamlede data fra kunden. Beskriv projektets mål, begrænsninger og ikke-funktionelle krav. Derefter bør du nævne alle indgående data: kildekode, dokumentation, infrastruktur.
Næste skridt. Angiv alle de problemer, du har fundet manuelt eller ved hjælp af automatiserede værktøjer. Store autogenererede rapporter skal placeres i slutningen i sektionen for bilag. Her skal der være korte og præcise beviser for de fundne problemer.
Prioriter de fundne problemer på en skala af fejl, advarsel, info. Du kan vælge din egen skala, men denne er almindeligt accepteret.
Som en ægte arkitekt er du forpligtet til at give anbefalinger til at løse de fundne problemer. Beskriv forbedringerne og den værdi, som kunden vil opnå. Hvordan viser man værdien for virksomheden fra vi diskuterede tidligere.
Forbered et roadmap med små iterationer. Hver iteration skal indeholde tid til udførelse, beskrivelse, antal ressourcer nødvendige for forbedring, teknisk værdi og værdi for virksomheden.
Vi afslutter vurderingen af arkitekturen og giver kunden en rapport.
Send aldrig blot rapporten pr. mail. Den kan hverken blive læst eller blive forstået uden ordentlige forklaringer. Kort sagt – levende kommunikation hjælper med at afklare misforståelser mellem mennesker. Du bør planlægge et møde med kunden og tale om de fundne problemer med fokus på de mest betydningsfulde. Det er vigtigt at gøre kunden opmærksom på problemer, han måske ikke engang er klar over. Såsom sikkerhedsproblemer, og forklar, hvordan de kan påvirke hans forretning. Vis dit roadmap med forbedringer og diskuter forskellige muligheder, der passer bedre til kunden. Dette kan være tid, ressourcer, arbejdsomfang.
Som et resume af dit møde, send kunden din rapport.
Afslutningsvis
Vurdering af arkitektur er en kompleks proces. For at gennemføre en evaluering ordentligt, skal du have tilstrækkelig erfaring og viden.
Det er muligt at give kunden nyttige resultater for ham og hans virksomhed på bare en uge. Selv hvis du gør det alene.
På baggrund af min erfaring blev mange forbedringer stoppet halvvejs, og nogle gange begyndte de slet ikke. De, der valgte en gylden middelvej og kun gjorde de mest nyttige forbedringer for virksomheden med minimale ressourcer, forbedrede kvaliteten af deres produkt betydeligt. De, der ikke gjorde noget, kunne efter et par år lukke projektet helt.
Dit skal vise kunden maksimale forbedringer til minimal pris.
Andre artikler i sektionen kan læses i ens fritid.
Jeg ønsker jer ren kode og gode arkitektur-løsninger.
Vores Facebook-gruppe — .
Kilde: habr.com
