I början är det alltid svårt att förstå ett stort och gammalt projekt. Arkitektur är en av aktiviteterna i en arkitektbedömning. Vanligtvis ska man jobba med stora, gamla projekt, och resultatet ska levereras på en vecka.
Hur man utvärderar ett projekt med 100 XNUMX eller fler rader kod på en vecka samtidigt som man ger resultat som verkligen är användbara för kunden.
De flesta arkitekter och tekniska chefer har stött på liknande projektbedömningar. Detta kan se ut som en semi-formell process eller som en separat tjänst som görs i vårt företag, på ett eller annat sätt har de flesta av er hanterat detta.
Originalet på engelska för dina icke-rysktalande vänner finns här: .
Vårt företags tillvägagångssätt
Jag ska berätta hur det fungerar i vårt företag och hur jag agerar i liknande situationer, men du kan enkelt ändra detta tillvägagångssätt efter behoven i ditt projekt och ditt företag.
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 arkitekturbedömning 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 vill ha en komplett lista med problem och rekommendationer för att förbättra projektet.
Extern är en mer formell process än en 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 borde vara mer formell. Projekten är alltid stora och gamla. De har många problem, buggar och sned 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 för förbättringar. Därför, om vi tar itu med den externa bedömningen av projektet, kommer den interna bedömningen att vara en bit av kakan. Låt oss överväga det svåraste fallet.
Utvärdering av företagsprojektarkitektur
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 med ett isberg, klienten ser bara toppen av sina problem och har ingen aning om vad som finns under vattnet (i djupet av 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 är medveten om, men de kan förekomma i projektet:
- Säkerhetsproblem
- Designproblem
- Fel arkitektur
- Algoritmiska fel
- Olämplig teknik
- Teknisk skuld
- Fel utvecklingsprocess
Formell arkitekturgranskningsprocess
Detta är en formell process som vi följer som företag, men du kan anpassa den beroende på ditt företag och projekt.
Begäran från en kund
Beställaren ber att få utvärdera det aktuella projektets arkitektur. Den ansvariga personen 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 – huvudansvarig för bedömning 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 som möjligt om projektet. Du kan använda olika tekniker beroende på situationen:
- Frågeformulär och andra metoder för kommunikation via post. Det mest ineffektiva sättet.
- Onlinemöten.
- Specialverktyg för informationsutbyte såsom: Google doc, Confluence, repositories, etc.
- "Live" möten på plats. Det mest effektiva och dyraste sättet.
Vad ska du få av 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. Teknikstack, 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 prestanda, tillgänglighet och användarvänlighet för systemet. Säkerhetskrav m.m.
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 scenen eller produktionsinfrastrukturen för att arbeta med livesystemet. 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 detta en bra början. Det kan vara föråldrat, men det är ändå en bra början. Lita aldrig på dokumentationen – testa 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å infrastrukturen. Tech lead in i koden. Prestandaingenjör för att se prestandastatistik. En databasspecialist bör gräva djupare i datastrukturer.
Men det här är ett idealiskt fall när du har mycket resurser. Vanligtvis utvärderar en till tre personer ett projekt. Du kan till och med göra uppskattningen 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 mängd erfarenhet kan du snabbt förstå kvaliteten på dokumentationen. Vad som är sant och vad som helt klart inte sammanfaller med verkligheten. Ibland kan du se arkitektur i dokumentation som aldrig kommer att fungera i verkligheten. Detta är en trigger för dig att fundera över hur det gjordes i verkligheten i projektet.
Användbara verktyg för att automatisera projektutvärdering
Kodutvärdering ä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:
är ett utmärkt 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 dra nytta av en 30-dagars provversion.
- ett bra gammalt verktyg. Ett verktyg för statisk kodanalys. Låter dig identifiera dålig kod, buggar och säkerhetsproblem för mer än 20 programmeringsspråk.
Alla molnleverantörer har verktyg för övervakning av infrastruktur. Detta gör att du kan utvärdera effektiviteten av din infrastruktur i termer av kostnad och prestanda. För AWS är detta . Det är enkelt för Azure .
Ytterligare prestandaövervakning och loggning hjälper till att hitta prestandaproblem på alla nivåer. Från en databas med ineffektiva frågor, backend och slutar med frontend. Även om klienten 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 väl värt det. 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 den arkitektoniska bedömningsprocessen.
– ett verktyg för att bedöma applikationsprestanda
– övervakningstjänst för molnsystem
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 sätta ihop allt till en helhet.
Förbereder en rapport
Börja din rapport med den information du samlat in från kunden. Beskriv projektets mål, begränsningar, icke-funktionella krav. Efter detta ska alla indata nämnas: källkod, dokumentation, infrastruktur.
Nästa steg. Lista 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 problemen som finns på fel-, varnings-, infoskalan. Du kan välja din egen skala, men detta är den allmänt accepterade.
Som en sann arkitekt är det ditt ansvar 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 tid att slutföra, beskrivning, mängd resurser som behövs för förbättring, tekniskt värde och affärsvärde.
Vi genomför arkitekturbedömningen och ger beställaren en rapport
Skicka aldrig bara en rapport. Den kanske inte läses alls, eller kanske inte läses och förstås utan ordentlig förklaring. Kort sagt, direktkommunikation 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 som hittats, 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 är mer lämpade för kunden. Detta kan vara tid, resurser, mängd arbete.
Som en sammanfattning av ditt möte, skicka din rapport till kunden.
Sammanfattningsvis
Arkitekturutvärdering är en komplex process. För att genomföra bedömningen 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 företag på bara en vecka. Även om du gör det ensam.
Baserat på min erfarenhet laddades många förbättringar ner i mitten, och ibland startade de aldrig. De som valde den gyllene medelvägen för sig själva och gjorde endast en del av de förbättringar som var mest användbara för verksamheten med minimala arbetskostnader förbättrade avsevärt kvaliteten på sin produkt. De som inte gjorde något kunde stänga projektet helt efter ett par år.
Ditt mål är att visa kunden maximala förbättringar till lägsta pris.
Andra artiklar från sektionen du kan läsa på din fritid.
Jag önskar dig ren kod och bra arkitektoniska beslut.
Vår facebookgrupp - .
Källa: will.com