I början Àr det alltid svÄrt att förstÄ ett stort och gammalt projekt. Architecture assessment Àr en av aktiviteternas arkitekt. Ofta mÄste man arbeta med stora, gamla projekt, och resultaten mÄste levereras inom en vecka.
Hur kan man utvÀrdera ett projekt med 100k och fler rader kod pÄ en vecka och samtidigt ge verkligt anvÀndbara resultat för kunden?
De flesta arkitekter och teknikledare har stött pÄ liknande projektutvÀrderingar. Det kan se ut som en halvformell process eller som en separat tjÀnst, som den vi erbjuder, men oavsett vad har de flesta av er varit med om detta.
Originalet pÄ engelska för dina icke-ryssprÄkiga vÀnner finns hÀr: .
VĂ„r strategi
Jag kommer att berÀtta hur det fungerar i vÄrt företag och hur jag hanterar sÄdana situationer, men du kan enkelt anpassa denna strategi efter ditt projekts och företags behov.
Det finns tvÄ typer av architecture assessments.
Intern â vi gör vanligtvis detta för projekt inom företaget. Vilket projekt som helst kan begĂ€ra en arkitekturbedömning av flera skĂ€l:
- Teamet tror att deras projekt Àr perfekt, vilket Àr misstÀnkt. Vi har haft sÄdana fall, och ofta Àr allt annat Àn perfekt i sÄdana projekt.
- Teamet vill kontrollera sitt projekt och sina lösningar.
- Teamet vet att allt Àr dÄligt. De kan till och med lista huvudproblemen och orsakerna, men de vill ha en fullstÀndig lista med problem och rekommendationer för förbÀttring av projektet.
Extern â detta Ă€r en mer formell process Ă€n intern bedömning. Kunden kommer alltid i ett enda fall, nĂ€r allt Ă€r dĂ„ligt - mycket dĂ„ligt. Vanligtvis förstĂ„r kunden att det finns globala problem, men kan inte korrekt identifiera orsakerna och bryta ner dem i bestĂ„ndsdelar.
Architecture assessment för extern kund Àr en mer komplex frÄga. Processen mÄste vara mer formell. Projekten Àr alltid stora och gamla. De innehÄller mÄnga problem, buggar och dÄlig kod. Rapporten om det utförda arbetet mÄste vara klar inom nÄgra veckor, dÀr de viktigaste problemen och rekommendationerna för förbÀttring ska ingÄ. SÄ, om vi löser den externa bedömningen av projektet, blir den interna bara en bagatell. LÄt oss övervÀga det mest komplexa fallet.
Bedömning av arkitekturen för ett enterprise-projekt
Ett typiskt projekt för utvÀrdering Àr ett stort, gammalt enterprise-projekt med mÄnga problem. Klienten kommer till oss och ber oss att fixa sitt projekt. Det Àr som med ett isberg; klienten ser bara toppen av sina problem och anar inte vad som finns under ytan (i djupet av koden).
Problem som klienten kan klaga pÄ och kÀnner till:
- Prestandaproblem
- AnvÀndbarhetsproblem
- LĂ„ngsam distribution
- Brist pÄ enhetstester och andra tester
Problem som klienten troligen inte kÀnner till, men som kan förekomma i projektet:
- SĂ€kerhetsproblem
- Designproblem
- Felaktig arkitektur
- Algoritmiska fel
- OlÀmpliga teknologier
- Teknisk skuld
- Felaktig utvecklingsprocess
Formell arkitekturbedömningsprocess
Detta Àr en formell process som vi följer i företaget, men du kan justera den efter dina behov beroende pÄ ditt företag och projekt.
BegÀran frÄn klienten
Klienten ber oss att bedöma arkitekturen av det nuvarande projektet. Den ansvariga personen frÄn vÄr sida samlar in grundlÀggande information om projektet och vÀljer nödvÀndiga experter. Beroende pÄ projektet kan det vara olika experter.
Lösningsarkitekt â huvudpersonen ansvarig för bedömning och koordinering (och ofta den enda).
Teknikspecifika experter â .Net, Java, Python och andra tekniska specialister beroende pĂ„ projektet och teknologierna.
Molnexperter â det kan vara Azure, GCP eller AWS-molnarkitekter.
Infrastruktur â DevOps, systemadministratörer, etc.
Andra experter â sĂ„som big data, maskininlĂ€rning, prestandaingenjör, sĂ€kerhetsexpert, QA-lead.
Insamling av information om projektet
Du bör samla sÄ mycket information som möjligt om projektet. Du kan anvÀnda olika tekniker beroende pÄ situationen:
- EnkÀter och andra kommunikationssÀtt via e-post. Den mest ineffektiva metoden.
- Online-möten.
- Speciella verktyg för informationsutbyte som: Google-dokument, Confluence, repository osv.
- Fysiska möten. Den mest effektiva och dyraste metoden.
Vad behöver vi fÄ frÄn klienten?
GrundlÀggande information. Vad handlar projektet om. Dess syfte och vÀrde. HuvudmÄl och framtidsplaner. AffÀrsmÄl och strategier. Huvudproblem och önskat resultat.
Information om projektet. Teknologistack, ramverk, programmeringssprÄk. On-premise eller molndistribution. Om projektet Àr i molnet, vilka tjÀnster anvÀnds. Vilka arkitektoniska och designmönster tillÀmpades.
Icke-funktionella krav. Alla krav relaterade till systemets prestanda, tillgÀnglighet, anvÀndarvÀnlighet. SÀkerhetskrav etc.
GrundlÀggande anvÀndningsfall och datavströmmar.
à tkomst till kÀllkoden. Den allra viktigaste delen! Du bör absolut fÄ tillgÄng till repository och dokumentation om hur man bygger projektet.
à tkomst till infrastrukturen. Det vore bra att fÄ tillgÄng till stage- eller produktionsinfrastrukturen för att arbeta med ett 'levande' system. Det Àr en stor fördel om kunden har verktyg för att övervaka infrastrukturen och prestanda. Vi kommer att diskutera dessa verktyg i nÀsta avsnitt.
Dokumentation. Om kunden har dokumentation Ă€r det en bra start. Den kan vara förĂ„ldrad, men det Ă€r fortfarande en bra start. Lita aldrig blint pĂ„ dokumentationen â kontrollera den med kunden, pĂ„ den verkliga infrastrukturen och i kĂ€llkoden.
Processen för att bedöma arkitekturen
Hur ska man hantera sÄ mycket information pÄ sÄ kort tid? Först och frÀmst, parallalisera arbetet.
DevOps bör titta pÄ infrastrukturen. Tech lead pÄ koden. Prestandaingenjören bör titta pÄ prestandametrik. Databasexperten bör grÀva djupare i datamodeller.
Men det Àr det ideala fallet nÀr du har mÄnga resurser. Ofta genomförs projektvÀrderingen av en till tre personer. Du kan till och med genomföra vÀrderingen sjÀlv, vilket ofta hÀnder om du har tillrÀcklig kunskap och erfarenhet inom alla omrÄden av projektet. I sÄ fall bör du automatisera alla processer sÄ mycket som möjligt.
TyvÀrr mÄste du lÀsa dokumentationen manuellt. Med rÀtt erfarenhet kan du ganska snabbt förstÄ kvaliteten pÄ dokumentationen. Vad som Àr sant och vad som uppenbarligen inte stÀmmer med verkligheten. Ibland kan du stöta pÄ en arkitektur i dokumentationen som aldrig kommer att fungera i verkligheten. Detta Àr en signal för dig att tÀnka pÄ, hur Àr det verkligen gjort i projektet.
Nyttiga verktyg för att automatisera projektvÀrderingen
Kodbedömning Àr en enkel övning. Du kan anvÀnda statiska kodanalysatorer som visar design-, prestanda- och sÀkerhetsproblem. HÀr Àr nÄgra av dem:
Àr ett utmÀrkt verktyg för arkitekten. Det ger dig en översikt över beroenden mellan moduler och potentiella omrÄden för refaktorering. Precis som alla bra verktyg kostar det en hel del, men du kan ocksÄ ta del av en 30-dagars gratisversion.
Àr en gammal trotjÀnare. Ett verktyg för statisk kodanalys. Det identifierar dÄlig kod, buggar och sÀkerhetsproblem för mer Àn 20 programmeringssprÄk.
Alla molnleverantörer har verktyg för att övervaka infrastrukturen. Detta hjÀlper dig att korrekt bedöma effektiviteten i infrastrukturen nÀr det gÀller kostnad och prestanda. För AWS Àr det . För Azure Àr det helt enkelt .
Ytterligare prestandaövervakning och loggning hjĂ€lper till att identifiera prestandaproblem pĂ„ alla nivĂ„er. FrĂ„n databaser med ineffektiva frĂ„gor, backend och fram till frontend. Ăven om en kund inte har installerat dessa verktyg tidigare kan du ganska snabbt integrera dem i det befintliga systemet för att upptĂ€cka prestandaproblem.
Som alltid kostar bra verktyg pengar. Jag kan rekommendera nÄgra betalda verktyg. SjÀlvklart kan du anvÀnda open source, men det kommer att ta mer tid. Och detta borde göras i förvÀg, inte under bedömningen av arkitekturen.
Àr ett verktyg för utvÀrdering av applikationsprestanda
Àr en molntjÀnst för systemövervakning
För sÀkerhetstestning finns det mÄnga verktyg. Denna gÄng rekommenderar jag ett gratis verktyg för systemsökning.
Àr ett verktyg för att skanna webbapplikationer för att sÀkerstÀlla efterlevnad av sÀkerhetsstandarder.
SĂ€tt allt samman.
Vi förbereder en rapport
Börja din rapport med insamlade data frÄn kunden. Beskriv projektets mÄl, begrÀnsningar och icke-funktionella krav. Efter detta bör du nÀmna all indata, inklusive kÀllkod, dokumentation och infrastruktur.
NÀsta steg. Ange alla problem som du har hittat manuellt eller med automatisk verktyg. Stora automatiskt genererade rapporter bör placeras sist i bilagorna. HÀr bör det finnas korta och koncisa bevis pÄ de upptÀckta problemen.
Prioritera de upptÀckta problemen enligt skalan error, warning, info. Du kan vÀlja din egen skala, men detta Àr en vedertagen.
Som en riktig arkitekt Àr du skyldig att ge rekommendationer för att ÄtgÀrda de upptÀckta problemen. Beskriv förbÀttringarna och det vÀrde för affÀren som kunden fÄr. Hur man visar vÀrdet för affÀren frÄn vi diskuterade tidigare.
Förbered en roadmap med smÄ iterationer. Varje iteration bör innehÄlla tid för utförande, beskrivning, antal resurser som behövs för förbÀttringar, tekniskt vÀrde och affÀrsvÀrde.
Vi avslutar arkitekturvÀrderingen och tillhandahÄller en rapport till kunden.
Skicka aldrig bara rapporten via e-post. Den kan antingen inte lĂ€sas alls eller lĂ€sas utan att förstĂ„s utan ordentlig förklaring. Kort sagt â personligt möte hjĂ€lper till att eliminera missförstĂ„nd mellan mĂ€nniskor. Du bör boka ett möte med kunden och diskutera de upptĂ€ckta problemen med fokus pĂ„ de mest betydande. Det Ă€r viktigt att uppmĂ€rksamma kunden pĂ„ problem som han kanske inte ens har misstĂ€nkt, sĂ„som sĂ€kerhetsproblem, och förklara hur de kan pĂ„verka affĂ€ren. Visa din roadmap med förbĂ€ttringar och diskutera olika alternativ som passar kunden bĂ€ttre. Det kan handla om tid, resurser, arbetsvolym.
Som en sammanfattning av ditt möte, skicka din rapport till kunden.
Avslutningsvis
ArkitekturvÀrdering Àr en komplex process. För att genomföra en vÀrdering pÄ rÀtt sÀtt mÄste du ha tillrÀcklig erfarenhet och kunskap.
Det Ă€r verkligen möjligt att ge kunden nyttiga resultat för honom och hans affĂ€rer pĂ„ bara en vecka. Ăven om du gör det sjĂ€lv.
UtifrÄn min erfarenhet har mÄnga förbÀttringar kanske aldrig startat eller avbrutits halvvÀgs. De som valde en gyllene medelvÀg och gjorde bara en del av förbÀttringarna som var mest anvÀndbara för affÀren med minimal arbetsinsats förbÀttrade betydligt kvaliteten pÄ sin produkt. De som inte gjorde nÄgot riskerade helt att stÀnga ner projektet efter ett par Är.
Ditt mÄl Àr att visa kunden maximala förbÀttringar till minsta pris.
Andra artiklar i sektionen kan lÀsas pÄ fritiden.
Jag önskar dig ren kod och bra arkitekturlösningar.
VĂ„r Facebook-grupp â .
KĂ€lla: habr.com
