Det Àr alltid svÄrt att förstÄ ett stort och gammalt projekt i början. Arkitekturbedömning Àr en av arkitektens aktiviteter. Vanligtvis mÄste man arbeta med stora, gamla projekt, och resultatet ska levereras inom en vecka.
Hur man uppskattar ett projekt pÄ 100k+ rader kod pÄ en vecka samtidigt som man ger resultat som verkligen Àr anvÀndbara för kunden.
De flesta arkitekter och dessa ledare har stött pÄ liknande projektbedömningar. Detta kan se ut som en semi-formell process eller en separat tjÀnst som det görs i vÄrt företag, pÄ ett eller annat sÀtt har de flesta av er hanterat det.
Originalet pÄ engelska för dina icke-rysktalande vÀnner finns hÀr: .
VÄrt företags tillvÀgagÄngssÀtt
Jag kommer att berÀtta hur det fungerar i vÄrt företag och hur jag agerar i sÄdana situationer, men du kan enkelt Àndra detta tillvÀgagÄngssÀtt efter ditt projekts och företags behov.
Det finns tvÄ typer av arkitekturbedömning.
Interiör â Vi brukar göra det för projekt inom företaget. Alla projekt kan begĂ€ra en arkitektonisk granskning av flera skĂ€l:
- Teamet tycker att deras projekt Àr perfekt och det Àr misstÀnkt. Vi har haft sÄdana fall och ofta i sÄdana projekt Àr allt lÄngt ifrÄn idealiskt.
- Teamet vill testa sitt projekt och sina lösningar.
- Teamet vet att det Àr dÄligt. De kan till och med lista de viktigaste problemen och orsakerna, men de vill fÄ en komplett lista med problem och rekommendationer för att förbÀttra projektet.
Extern â Det hĂ€r Ă€r en mer formell process Ă€n intern bedömning. Klienten kommer alltid bara i ett fall, nĂ€r allt Ă€r dĂ„ligt â vĂ€ldigt dĂ„ligt. Vanligtvis förstĂ„r klienten att det finns globala problem, men kan inte korrekt identifiera orsakerna och bryta ner dem i komponenter.
Att utvÀrdera en arkitektur för en extern klient Àr ett mer komplext fall. Processen bör vara mer formell. Projekt Àr alltid stora och gamla. De har mÄnga problem, buggar och dÄlig kod. En rapport om utfört arbete bör vara klar inom max nÄgra veckor, som bör innehÄlla de viktigaste problemen och rekommendationer till förbÀttringar. DÀrför, om vi tar itu med den externa bedömningen av projektet, kommer den interna att vara en bit av kakan. LÄt oss övervÀga det svÄraste fallet.
Enterprise Project Architecture Assessment
Ett typiskt projekt att utvÀrdera Àr ett stort, gammalt företagsprojekt med mÄnga problem. En kund kommer till oss och ber oss fixa hans projekt. Det Àr som ett isberg: klienten ser bara toppen av sina problem och har ingen aning om vad som finns under vattnet (djupt inne i koden).
Problem som kunden kan klaga pÄ och som kanske kÀnner till:
- Prestandaproblem
- AnvÀndbarhetsproblem
- LĂ„ngsiktig utplacering
- Brist pÄ enhet och andra tester
Problem som kunden med största sannolikhet inte kÀnner till, men de kan förekomma i projektet:
- SĂ€kerhetsproblem
- Designproblem
- Felaktig arkitektur
- Algoritmiska fel
- OlÀmplig teknik
- Teknisk skuld
- Felaktig utvecklingsprocess
Formell arkitekturutvÀrderingsprocess
Detta Àr en formell process som vi följer i vÄrt företag, men du kan anpassa den för att passa ditt företag och projekt.
BegÀran frÄn kunden
BestÀllaren ber att fÄ utvÀrdera det aktuella projektets arkitektur. En ansvarig person pÄ vÄr sida samlar in grundlÀggande information om projektet och vÀljer ut nödvÀndiga experter. Beroende pÄ projektet kan dessa vara olika experter.
Lösningsarkitekt - den huvudansvarige för utvÀrdering och samordning (och ofta den enda).
Stapla specifika experter â .Net, Java, Python och andra tekniska specialister beroende pĂ„ projekt och teknik
Molnexperter â dessa kan vara Azure, GCP eller AWS molnarkitekter.
Infrastruktur â DevOps, systemadministratör, etc.
Andra experter â som big data, maskininlĂ€rning, prestandaingenjör, sĂ€kerhetsexpert, QA-ledare.
Samla information om projektet
Du bör samla in sÄ mycket information om projektet som möjligt. Du kan anvÀnda olika tekniker beroende pÄ situationen:
- FrÄgeformulÀr och andra metoder för kommunikation via e-post. Den mest ineffektiva metoden.
- Onlinemöten.
- Specialverktyg för informationsutbyte sÄsom: Google doc, Confluence, repositories, etc.
- Livemöten pÄ plats. Det mest effektiva och dyraste sÀttet.
Vad behöver du fÄ frÄn kunden?
GrundlÀggande information. Vad handlar projektet om? Dess syfte och vÀrde. HuvudmÄl och planer för framtiden. AffÀrsmÄl och strategier. Huvudproblem och önskat resultat.
Projekt Information. Teknisk stack, ramverk, programmeringssprÄk. Implementering pÄ plats eller moln. Om projektet Àr i molnet, vilka tjÀnster anvÀnds. Vilka arkitektoniska och designmönster som anvÀndes.
Icke-funktionella krav. Alla krav relaterade till systemets prestanda, tillgÀnglighet och anvÀndbarhet. SÀkerhetskrav mm.
GrundlÀggande anvÀndningsfall och dataflöden.
TillgÄng till kÀllkod. Den viktigaste delen! Du bör definitivt fÄ tillgÄng till arkiven och dokumentation om hur du bygger projektet.
TillgÄng till infrastruktur. Det skulle vara trevligt att ha tillgÄng till scen- eller produktionsinfrastruktur för att arbeta med "live"-systemet. Det Àr en stor framgÄng om kunden har verktyg för att övervaka infrastruktur och prestanda. Vi kommer att prata om dessa verktyg i nÀsta avsnitt.
ĐĐŸĐșŃĐŒĐ”ĐœŃĐ°ŃĐžŃ. Om kunden har dokumentation Ă€r det en bra början. Det kan vara förĂ„ldrat, men det Ă€r Ă€ndĂ„ en bra början. Lita aldrig pĂ„ dokumentation â kontrollera den med klienten, pĂ„ riktig infrastruktur och i kĂ€llkoden.
Process för utvÀrdering av arkitektur
Hur kan man bearbeta en sÄ stor mÀngd information pÄ sÄ kort tid? Först av allt, parallellisera arbetet.
DevOps bör titta pÄ infrastruktur. Teknisk ledare i kod. Prestandaingenjör för att se prestandastatistik. En databasspecialist bör grÀva djupare i datastrukturerna.
Men det hÀr Àr det perfekta fallet nÀr du har mycket resurser. Vanligtvis utförs en projektutvÀrdering av en till tre personer. Du kan till och med göra bedömningen sjÀlv, vilket ofta Àr fallet om du har rÀtt kunskap och erfarenhet inom alla delar av projektet. I det hÀr fallet mÄste du automatisera alla processer sÄ mycket som möjligt.
TyvÀrr mÄste du lÀsa dokumentationen manuellt. Med rÀtt erfarenhet kommer du att kunna förstÄ kvaliteten pÄ dokumentationen ganska snabbt. Vad som Àr sant dÀr och vad som helt klart inte sammanfaller med verkligheten. Ibland kan du stöta pÄ en arkitektur i dokumentation som aldrig kommer att fungera i verkligheten. Detta Àr en trigger för dig att fundera över hur det gÄr till i verkligheten i projektet.
AnvÀndbara verktyg för att automatisera projektutvÀrdering
Kodgranskning Àr en enkel övning. Du kan anvÀnda statiska kodanalysatorer som visar dig design, prestanda och sÀkerhetsproblem. HÀr Àr nÄgra av dem:
â Det hĂ€r Ă€r ett bra verktyg för en arkitekt. Det kommer att visa dig helheten, beroenden mellan moduler och potentiella omrĂ„den för omfaktorisering. Som alla bra verktyg kostar det bra pengar, men du kan anvĂ€nda 30-dagars provversionen.
- ett gammalt bra verktyg. Ett verktyg för statisk kodanalys. LÄter dig identifiera dÄlig kod, buggar, sÀkerhetsproblem för mer Àn 20 programmeringssprÄk.
Alla molnleverantörer har verktyg för att övervaka infrastruktur. Detta kommer att tillÄta dig att korrekt utvÀrdera effektiviteten av din infrastruktur i termer av kostnad och prestanda. För AWS Àr det . För Azure Àr det enkelt .
Ytterligare prestandaövervakning och loggning hjĂ€lper dig att hitta prestandaproblem pĂ„ alla nivĂ„er. Börjar frĂ„n databasen med ineffektiva frĂ„gor, backend och slutar med frontend. Ăven om kunden inte har installerat dessa verktyg tidigare, kan du integrera dem i det befintliga systemet ganska snabbt för att identifiera prestandaproblem.
Som alltid Àr bra verktyg bra prissatta. Jag kan rekommendera ett par betalverktyg. Naturligtvis kan du anvÀnda öppen kÀllkod men det kommer att ta dig mer tid. Och detta bör göras i förvÀg, inte under arkitekturgranskningen.
â Verktyg för utvĂ€rdering av applikationsprestanda
â molntjĂ€nst för övervakningssystem
Det finns mÄnga verktyg tillgÀngliga för sÀkerhetstestning. Den hÀr gÄngen kommer jag att rekommendera dig ett gratis systemskanningsverktyg.
â ett verktyg för att skanna webbapplikationer för överensstĂ€mmelse med sĂ€kerhetsstandarder.
LÄt oss slÄ ihop allt.
Förbereder en rapport
Börja din rapport med den information du samlat in frÄn din kund. Beskriv projektets mÄl, begrÀnsningar, icke-funktionella krav. Efter det ska all indata nÀmnas: kÀllkod, dokumentation, infrastruktur.
NÀsta steg. Ange eventuella problem du hittade manuellt eller med hjÀlp av automatiserade verktyg. Placera stora automatiskt genererade rapporter i slutet i applikationssektionen. Det bör finnas korta och koncisa bevis pÄ de problem som hittats.
Prioritera de problem som hittas pÄ en skala av fel, varning, info. Du kan vÀlja din egen skala, men detta Àr den allmÀnt accepterade.
Som en sann arkitekt Àr du skyldig att ge rekommendationer för att rÀtta till de problem som hittats. Beskriv de förbÀttringar och affÀrsvÀrde som kunden kommer att fÄ. Hur man visar affÀrsvÀrde frÄn vi diskuterade tidigare.
Förbered en fÀrdplan med smÄ iterationer. Varje iteration bör innehÄlla en tidsgrÀns, beskrivning, mÀngd resurser som behövs för att förbÀttra, tekniskt vÀrde och affÀrsvÀrde.
Vi genomför arkitekturbedömningen och ger bestÀllaren en rapport
Skicka aldrig bara en rapport per post. Det kan antingen inte lÀsas alls, eller sÄ kan det lÀsas och inte förstÄs utan ordentlig förklaring. Kort sagt, livekommunikation hjÀlper till att eliminera missförstÄnd mellan mÀnniskor. Du bör schemalÀgga ett möte med kunden och prata om de problem du har hittat, med fokus pÄ de viktigaste. Det Àr vÀrt att uppmÀrksamma klienten pÄ problem som han kanske inte ens Àr medveten om. Till exempel sÀkerhetsfrÄgor och förklara hur de kan pÄverka verksamheten. Visa din fÀrdplan med förbÀttringar och diskutera olika alternativ som skulle passa bÀttre för kunden. Det kan vara tid, resurser eller arbetsvolym.
Som en sammanfattning av ditt möte, skicka din rapport till kunden.
Sammanfattningsvis
Att utvÀrdera arkitektur Àr en komplex process. För att genomföra en bedömning pÄ rÀtt sÀtt behöver du ha tillrÀcklig erfarenhet och kunskap.
Det Ă€r möjligt att ge kunden resultat som Ă€r anvĂ€ndbara för honom och hans verksamhet pĂ„ bara en vecka. Ăven om du gör det ensam.
Enligt min erfarenhet laddades mÄnga förbÀttringar ner halvvÀgs, och ibland startade de aldrig. De som valde den gyllene medelvÀgen för sig sjÀlva och gjorde bara en del av de förbÀttringar som var mest anvÀndbara för företag med minimala arbetskostnader, förbÀttrade avsevÀrt kvaliteten pÄ sin produkt. De som inte gjorde nÄgot kunde ha stÀngt projektet helt efter ett par Är.
Ditt mÄl Àr att visa kunden maximala förbÀttringar till lÀgsta kostnad.
Andra artiklar frÄn sektionen Du kan lÀsa den nÀr du vill.
Jag önskar dig ren kod och bra arkitektoniska beslut.
VĂ„r facebookgrupp - .
KĂ€lla: will.com
