I starten er det altid svært at forstå et stort og gammelt projekt. Arkitektur er en af arkitektvurderingsaktiviteterne. Normalt skal man arbejde med store, gamle projekter, og resultaterne skal afleveres på en uge.
Sådan evaluerer du et projekt på 100 eller flere linjer kode på en uge, mens du stadig giver resultater, der virkelig er nyttige for kunden.
De fleste arkitekter og tekniske ledere er stødt på lignende projektvurderinger. Dette kan ligne en semi-formel proces eller som en separat service, som det gøres i vores virksomhed, på en eller anden måde har de fleste af jer håndteret dette.
Originalen på engelsk til dine ikke-russisktalende venner er her: .
Vores virksomheds tilgang
Jeg vil fortælle dig, hvordan det fungerer i vores virksomhed, og hvordan jeg agerer i lignende situationer, men du kan nemt ændre denne tilgang i forhold til dit projekts og din virksomheds behov.
Der er to typer af arkitekturvurdering.
Interiør – vi plejer at gøre det til projekter i virksomheden. Ethvert projekt kan anmode om en arkitekturvurdering af flere årsager:
- Holdet synes, deres projekt er perfekt, og det er mistænkeligt. Vi har haft sådanne sager, og ofte i sådanne projekter er alt langt fra ideelt.
- Teamet ønsker at teste deres projekt og deres løsninger.
- Holdet ved, at tingene er dårlige. De kan endda nævne de vigtigste problemer og årsager, men ønsker en komplet liste over problemer og anbefalinger til forbedring af projektet.
Udvendig er en mere formel proces end en intern vurdering. Klienten kommer altid kun i et tilfælde, hvor alt er dårligt - meget dårligt. Normalt forstår klienten, at der er globale problemer, men kan ikke korrekt identificere årsagerne og opdele dem i komponenter.
Evaluering af en arkitektur for en ekstern klient er en mere kompleks sag. Processen bør være mere formel. Projekterne er altid store og gamle. De har en masse problemer, fejl og skæv kode. En rapport om det udførte arbejde bør være klar inden for højst et par uger, som bør indeholde de vigtigste problemer og anbefalinger til forbedringer. Derfor, hvis vi beskæftiger os med den eksterne vurdering af projektet, så vil den interne vurdering være et stykke kage. Lad os overveje den sværeste sag.
Vurdering af virksomhedsprojektarkitektur
Et typisk projekt at evaluere er et stort, gammelt virksomhedsprojekt med mange problemer. En kunde kommer til os og beder os om at ordne hans projekt. Det er ligesom med et isbjerg, klienten ser kun spidsen af sine problemer og aner ikke, hvad der er under vandet (i dybet af koden).
Problemer, som kunden kan klage over og kan være opmærksom på:
- Præstationsproblemer
- Usability problemer
- Langsigtet indsættelse
- Mangel på enhed og andre tests
Problemer, som bygherren højst sandsynligt ikke er klar over, men de kan være til stede i projektet:
- Sikkerhedsproblemer
- Design problemer
- Forkert arkitektur
- Algoritmiske fejl
- Uhensigtsmæssige teknologier
- Teknisk gæld
- Forkert udviklingsproces
Formel arkitekturgennemgangsproces
Dette er en formel proces, som vi følger som virksomhed, men du kan tilpasse den afhængigt af din virksomhed og projekt.
Forespørgsel fra en klient
Bygherren beder om at vurdere arkitekturen i det aktuelle projekt. Den ansvarlige på vores side indsamler grundlæggende oplysninger om projektet og udvælger de nødvendige eksperter. Afhængigt af projektet kan disse være forskellige eksperter.
Løsningsarkitekt – hovedansvarlig for vurdering og koordinering (og ofte den eneste).
Stable specifikke eksperter – .Net, Java, Python og andre tekniske specialister afhængigt af projektet og teknologierne
Cloud-eksperter – disse kan være Azure, GCP eller AWS cloud arkitekter.
Infrastruktur – DevOps, Systemadministrator mv.
Andre eksperter – såsom big data, machine learning, performance engineer, sikkerhedsekspert, QA lead.
Indsamling af information om projektet
Du bør indsamle så mange oplysninger som muligt om projektet. Du kan bruge forskellige teknikker afhængigt af situationen:
- Spørgeskemaer og andre kommunikationsmetoder via mail. Den mest ineffektive måde.
- Online møder.
- Særlige værktøjer til informationsudveksling såsom: Google doc, Confluence, repositories mv.
- "Live" møder på stedet. Den mest effektive og dyreste måde.
Hvad skal du få fra kunden?
Grundlæggende oplysninger. Hvad handler projektet om? Dens formål og værdi. Hovedmål og planer for fremtiden. Forretningsmål og strategier. Hovedproblemer og ønskede resultater.
Projektinformation. Teknologistak, rammer, programmeringssprog. On-premise eller cloud-implementering. Hvis projektet er i skyen, hvilke tjenester bruges der. Hvilke arkitektoniske og designmæssige mønstre blev brugt.
Ikke-funktionelle krav. Alle krav relateret til ydeevne, tilgængelighed og brugervenlighed af systemet. Sikkerhedskrav mv.
Grundlæggende use cases og datastrømme.
Adgang til kildekode. Den vigtigste del! Du bør helt sikkert få adgang til depoterne og dokumentationen om, hvordan du bygger projektet.
Adgang til infrastruktur. Det ville være rart at have adgang til scenen eller produktionsinfrastrukturen for at arbejde med live-systemet. Det er en stor succes, hvis kunden har værktøjer til at overvåge infrastruktur og ydeevne. Vi vil tale om disse værktøjer i næste afsnit.
Records. Hvis kunden har dokumentation er dette en god start. Det kan være forældet, men det er stadig en god start. Stol aldrig på dokumentationen - test den med klienten, på ægte infrastruktur og i kildekoden.
Arkitektur evalueringsproces
Hvordan kan man behandle så stor en mængde information på så kort tid? Først og fremmest paralleliser arbejdet.
DevOps bør se på infrastrukturen. Tech lead ind i koden. Præstationsingeniør til at se præstationsmålinger. En databasespecialist bør grave dybere ned i datastrukturer.
Men dette er et ideelt tilfælde, når du har mange ressourcer. Typisk evaluerer en til tre personer et projekt. Du kan endda selv foretage vurderingen, hvilket ofte er tilfældet, hvis du har den rette viden og erfaring inden for alle områder af projektet. I dette tilfælde skal du automatisere alle processer så meget som muligt.
Desværre bliver du nødt til at læse dokumentationen manuelt. Med den rette mængde erfaring kan du hurtigt forstå kvaliteten af dokumentationen. Hvad er sandt, og hvad er tydeligvis ikke sammenfaldende med virkeligheden. Nogle gange kan du se arkitektur i dokumentation, som aldrig vil fungere i det virkelige liv. Dette er en trigger for dig til at tænke over, hvordan det i virkeligheden blev gjort i projektet.
Nyttige værktøjer til at automatisere projektevaluering
Kodevaluering er en simpel øvelse. Du kan bruge statiske kodeanalysatorer, der viser dig design, ydeevne og sikkerhedsproblemer. Her er et par af dem:
er et fantastisk værktøj for en arkitekt. Det vil vise dig det store billede, afhængigheder mellem moduler og potentielle områder for refactoring. Som alle gode værktøjer koster det gode penge, men du kan drage fordel af en 30-dages prøveversion.
- et godt gammelt værktøj. Et værktøj til statisk kodeanalyse. Giver dig mulighed for at identificere dårlig kode, fejl og sikkerhedsproblemer for mere end 20 programmeringssprog.
Alle cloud-udbydere har værktøjer til overvågning af infrastruktur. Dette vil give dig mulighed for korrekt at evaluere effektiviteten af din infrastruktur med hensyn til omkostninger og ydeevne. For AWS er dette . Det er nemt for Azure .
Yderligere præstationsovervågning og logning hjælper med at finde præstationsproblemer på alle niveauer. Startende fra en database med ineffektive forespørgsler, backend og slutter med frontend. Selvom klienten ikke har installeret disse værktøjer tidligere, kan du integrere dem i det eksisterende system ret hurtigt for at identificere ydeevneproblemer.
Som altid er gode værktøjer det værd. Jeg kan anbefale et par betalte værktøjer. Selvfølgelig kan du bruge open source, men det vil tage dig mere tid. Og dette bør gøres på forhånd, ikke under den arkitektoniske vurderingsproces.
– et værktøj til vurdering af applikationsydelse
– skysystemovervågningstjeneste
Der er mange værktøjer tilgængelige til sikkerhedstest. Denne gang vil jeg anbefale dig et gratis systemscanningsværktøj.
– et værktøj til at scanne webapplikationer for overholdelse af sikkerhedsstandarder.
Lad os samle alt til en helhed.
Udarbejdelse af en rapport
Start din rapport med de data, du har indsamlet fra kunden. Beskriv projektets mål, begrænsninger, ikke-funktionelle krav. Herefter skal alle inputdata nævnes: kildekode, dokumentation, infrastruktur.
Næste skridt. Angiv eventuelle problemer, du har fundet manuelt eller ved hjælp af automatiserede værktøjer. Placer store automatisk genererede rapporter til sidst i applikationssektionen. Der bør være korte og koncise beviser for de fundne problemer.
Prioriter de problemer, der findes på fejl-, advarsels-, infoskalaen. Du kan vælge din egen skala, men dette er den generelt accepterede.
Som en ægte arkitekt er det dit ansvar at give anbefalinger til at rette op på de fundne problemer. Beskriv de forbedringer og forretningsværdi, som kunden vil modtage. Sådan viser du forretningsværdi fra vi diskuterede tidligere.
Udarbejd en køreplan med små iterationer. Hver iteration bør indeholde tid til færdiggørelse, beskrivelse, mængden af nødvendige ressourcer til forbedring, teknisk værdi og forretningsværdi.
Vi afslutter arkitekturvurderingen og giver bygherren en rapport
Send aldrig bare en rapport. Den læses måske slet ikke, eller den kan ikke læses og forstås uden ordentlig forklaring. Kort sagt hjælper live kommunikation med at eliminere misforståelser mellem mennesker. Du bør planlægge et møde med klienten og tale om de fundne problemer med fokus på de væsentligste. Det er værd at henlede klientens opmærksomhed på problemer, som han måske ikke engang er opmærksom på. Såsom sikkerhedsproblemer og forklar, hvordan de kan påvirke virksomheden. Vis din køreplan med forbedringer og diskuter forskellige muligheder, der er mere egnede til kunden. Dette kan være tid, ressourcer, mængden af arbejde.
Som et resumé af dit møde, send din rapport til kunden.
Afslutningsvis
Arkitekturevaluering er en kompleks proces. For at udføre vurderingen korrekt skal du have tilstrækkelig erfaring og viden.
Det er muligt at give kunden resultater, der er nyttige for ham og hans virksomhed på blot en uge. Også selvom du gør det alene.
Baseret på min erfaring blev mange forbedringer downloadet i midten, og nogle gange startede de aldrig. De, der valgte den gyldne middelvej for sig selv og kun lavede en del af de forbedringer, der var mest nyttige for virksomheden med minimale lønomkostninger, forbedrede kvaliteten af deres produkt markant. De, der ikke gjorde noget, kunne lukke projektet helt efter et par år.
Dit mål er at vise kunden maksimale forbedringer til minimumsprisen.
Andre artikler fra afsnittet du kan læse i ro og mag.
Jeg ønsker dig ren kode og gode arkitektoniske beslutninger.
Vores facebook gruppe - .
Kilde: www.habr.com