In het begin is het altijd moeilijk om een groot en oud project te begrijpen. Architectuur is een van de activiteiten van een architectenassessment. Meestal werk je met grote, oude projecten en moet het resultaat binnen een week opgeleverd worden.
Hoe je een project van 100 of meer regels code in een week evalueert en toch resultaten oplevert die echt nuttig zijn voor de klant.
De meeste architecten en technische leiders zijn soortgelijke projectbeoordelingen tegengekomen. Dit lijkt misschien op een semi-formeel proces of op een aparte dienst, zoals dat in ons bedrijf gebeurt, de meesten van jullie hebben hier op de een of andere manier wel mee te maken gehad.
Het origineel in het Engels voor je niet-Russisch sprekende vrienden is hier: .
De aanpak van ons bedrijf
Ik zal u vertellen hoe het werkt in ons bedrijf en hoe ik in soortgelijke situaties handel, maar u kunt deze aanpak eenvoudig aanpassen aan de behoeften van uw project en bedrijf.
Er zijn twee soorten architectuurbeoordeling.
Interieur – we doen het meestal voor projecten binnen het bedrijf. Elk project kan om verschillende redenen een architectuurbeoordeling aanvragen:
- Het team denkt dat hun project perfect is en dit is verdacht. We hebben dergelijke gevallen gehad, en vaak is bij dergelijke projecten alles verre van ideaal.
- Het team wil hun project en hun oplossingen testen.
- Het team weet dat het slecht is. Ze noemen misschien zelfs de belangrijkste problemen en oorzaken, maar willen een volledige lijst met problemen en aanbevelingen om het project te verbeteren.
Extern is een formeler proces dan een interne beoordeling. De klant komt altijd maar in één geval, als alles slecht is - heel slecht. Meestal begrijpt de cliënt dat er mondiale problemen zijn, maar kan hij de oorzaken niet correct identificeren en deze in componenten opsplitsen.
Het evalueren van een architectuur voor een externe klant is een complexer geval. Het proces zou formeler moeten zijn. De projecten zijn altijd groot en oud. Ze hebben veel problemen, bugs en kromme code. Binnen maximaal enkele weken moet er een rapport over het verrichte werk klaar zijn, waarin de belangrijkste problemen en aanbevelingen voor verbetering worden vermeld. Als we dus de externe beoordeling van het project verzorgen, is de interne beoordeling een fluitje van een cent. Laten we het moeilijkste geval bekijken.
Beoordeling van de architectuur van ondernemingsprojecten
Een typisch project om te evalueren is een groot, oud ondernemingsproject met veel problemen. Een klant komt naar ons toe en vraagt ons om zijn project op te knappen. Het is net als bij een ijsberg: de cliënt ziet slechts het topje van zijn problemen en heeft geen idee wat zich onder water bevindt (in de diepten van de code).
Problemen waar de klant over kan klagen en waarvan hij mogelijk op de hoogte is:
- Prestatieproblemen
- Problemen met de bruikbaarheid
- Implementatie op lange termijn
- Gebrek aan eenheid en andere tests
Problemen waarvan de opdrachtgever zich waarschijnlijk niet bewust is, maar die wel aanwezig kunnen zijn in het project:
- Veiligheidsproblemen
- Ontwerpproblemen
- Verkeerde architectuur
- Algoritmische fouten
- Ongepaste technologieën
- Technische schulden
- Verkeerd ontwikkelingsproces
Formeel architectuurbeoordelingsproces
Dit is een formeel proces dat wij als bedrijf volgen, maar u kunt het aanpassen afhankelijk van uw bedrijf en project.
Verzoek van een klant
De klant vraagt om de architectuur van het huidige project te evalueren. De verantwoordelijke persoon aan onze kant verzamelt basisinformatie over het project en selecteert de benodigde experts. Afhankelijk van het project kunnen dit verschillende deskundigen zijn.
Solution Architect – de hoofdverantwoordelijke voor beoordeling en coördinatie (en vaak de enige).
Stapel specifieke experts – .Net, Java, Python en andere technische specialisten, afhankelijk van het project en de technologieën
Cloud-experts – dit kunnen Azure-, GCP- of AWS-cloudarchitecten zijn.
Infrastructuur – DevOps, Systeembeheerder, etc.
Andere experts – zoals big data, machine learning, performance engineer, beveiligingsexpert, QA lead.
Het verzamelen van informatie over het project
Verzamel zoveel mogelijk informatie over het project. Afhankelijk van de situatie kun je verschillende technieken gebruiken:
- Vragenlijsten en andere communicatiemiddelen via e-mail. De meest ineffectieve manier.
- Online vergaderingen.
- Speciale tools voor informatie-uitwisseling zoals: Google doc, Confluence, repositories, etc.
- “Live” vergaderingen op locatie. De meest effectieve en duurste manier.
Wat moet je van de klant krijgen?
Basis informatie. Waar gaat het project over? Het doel en de waarde ervan. Belangrijkste doelen en plannen voor de toekomst. Zakelijke doelen en strategieën. Belangrijkste problemen en gewenste resultaten.
Project informatie. Technologiestapel, raamwerken, programmeertalen. Implementatie op locatie of in de cloud. Als het project zich in de cloud bevindt, welke services worden er gebruikt? Welke architecturale en ontwerppatronen werden gebruikt.
Niet-functionele vereisten. Alle vereisten met betrekking tot systeemprestaties, beschikbaarheid en bruikbaarheid. Veiligheidseisen enz.
Basisgebruiksscenario's en gegevensstromen.
Toegang tot broncode. Het belangrijkste onderdeel! U moet zeker toegang krijgen tot de repositories en documentatie over hoe u het project kunt bouwen.
Toegang tot infrastructuur. Het zou leuk zijn om toegang te hebben tot het podium of de productie-infrastructuur om met het live-systeem te werken. Het is een groot succes als de klant tools heeft voor het monitoren van infrastructuur en performance. We zullen over deze tools praten in de volgende sectie.
Документация. Als de klant documentatie heeft, is dit een goed begin. Het is misschien verouderd, maar het is nog steeds een goed begin. Vertrouw nooit op de documentatie: test deze samen met de klant, op de echte infrastructuur en in de broncode.
Architectuurevaluatieproces
Hoe kun je in zo’n korte tijd zo’n grote hoeveelheid informatie verwerken? Allereerst moet u het werk parallelliseren.
DevOps zou naar de infrastructuur moeten kijken. Tech leidt naar de code. Prestatie-ingenieur om prestatiestatistieken te bekijken. Een databasespecialist moet dieper graven in datastructuren.
Maar dit is een ideaal geval als je over veel middelen beschikt. Meestal evalueren één tot drie mensen een project. U kunt de calculatie zelfs zelf uitvoeren, wat vaak het geval is als u op alle onderdelen van het project over de juiste kennis en ervaring beschikt. In dit geval moet u alle processen zoveel mogelijk automatiseren.
Helaas zult u de documentatie handmatig moeten lezen. Met de juiste hoeveelheid ervaring krijgt u snel inzicht in de kwaliteit van de documentatie. Wat is waar en wat komt duidelijk niet overeen met de werkelijkheid. Soms zie je architectuur in documentatie die in het echte leven nooit zal werken. Dit is voor jou een trigger om na te denken over hoe het in werkelijkheid in het project is gedaan.
Handige tools om projectevaluatie te automatiseren
Code-evaluatie is een eenvoudige oefening. U kunt statische code-analysatoren gebruiken die u ontwerp-, prestatie- en beveiligingsproblemen laten zien. Hier zijn er een paar:
is een geweldig hulpmiddel voor een architect. Het toont u het grote geheel, de afhankelijkheden tussen modules en mogelijke gebieden voor refactoring. Zoals alle goede tools kost het goed geld, maar je kunt profiteren van een proefversie van 30 dagen.
- een goed oud hulpmiddel. Een hulpmiddel voor statische codeanalyse. Hiermee kunt u slechte code, bugs en beveiligingsproblemen voor meer dan 20 programmeertalen identificeren.
Alle cloudproviders beschikken over tools voor infrastructuurmonitoring. Hierdoor kunt u de effectiviteit van uw infrastructuur op het gebied van kosten en prestaties goed beoordelen. Voor AWS is dit het geval . Het is gemakkelijk voor Azure .
Extra prestatiemonitoring en logboekregistratie helpen bij het opsporen van prestatieproblemen op alle niveaus. Beginnend met een database met ineffectieve queries, de backend en eindigend met de frontend. Zelfs als de klant deze tools nog niet eerder heeft geïnstalleerd, kunt u ze vrij snel in het bestaande systeem integreren om prestatieproblemen te identificeren.
Zoals altijd is goed gereedschap de moeite waard. Ik kan een aantal betaalde tools aanbevelen. Natuurlijk kun je open-source gebruiken, maar het kost je meer tijd. En dit moet vooraf worden gedaan, niet tijdens het bouwkundige beoordelingsproces.
– een hulpmiddel voor het beoordelen van de prestaties van applicaties
– cloudsysteembewakingsservice
Er zijn veel tools beschikbaar voor het testen van beveiliging. Deze keer zal ik u een gratis systeemscantool aanbevelen.
– een tool voor het scannen van webapplicaties op naleving van beveiligingsnormen.
Laten we alles samenvoegen tot één geheel.
Het opstellen van een rapport
Begin uw rapport met de gegevens die u van de klant heeft verzameld. Beschrijf de projectdoelen, beperkingen en niet-functionele vereisten. Hierna moeten alle invoergegevens worden vermeld: broncode, documentatie, infrastructuur.
Volgende stap. Maak een lijst van eventuele problemen die u handmatig of met behulp van geautomatiseerde hulpmiddelen heeft gevonden. Plaats grote automatisch gegenereerde rapporten aan het einde van het toepassingengedeelte. Er moet kort en bondig bewijs zijn van de gevonden problemen.
Geef prioriteit aan de gevonden problemen op de fout-, waarschuwings- en informatieschaal. Je kunt je eigen schaal kiezen, maar dit is de algemeen aanvaarde schaal.
Als echte architect is het uw verantwoordelijkheid om aanbevelingen te doen om de gevonden problemen op te lossen. Beschrijf de verbeteringen en bedrijfswaarde die de klant zal ontvangen. Hoe u bedrijfswaarde kunt aantonen we hebben het eerder besproken.
Maak een roadmap met kleine iteraties. Elke iteratie moet de benodigde tijd voor voltooiing, een beschrijving, de hoeveelheid middelen die nodig zijn voor verbetering, de technische waarde en de bedrijfswaarde bevatten.
Wij voeren het architectuurassessment uit en voorzien de opdrachtgever van een rapport
Mail nooit zomaar een rapport. Het kan zijn dat het helemaal niet wordt gelezen, of dat het zonder de juiste uitleg niet wordt gelezen en begrepen. Kortom, live communicatie helpt misverstanden tussen mensen weg te nemen. U moet een ontmoeting met de klant plannen en de gevonden problemen bespreken, waarbij u zich concentreert op de belangrijkste. Het is de moeite waard om de aandacht van de cliënt te vestigen op problemen waarvan hij zich misschien niet eens bewust is. Zoals beveiligingsproblemen en leg uit hoe deze het bedrijf kunnen beïnvloeden. Toon jouw roadmap met verbeteringen en bespreek verschillende opties die meer geschikt zijn voor de klant. Dit kunnen tijd, middelen of hoeveelheid werk zijn.
Als samenvatting van uw bijeenkomst stuurt u uw verslag naar de opdrachtgever.
Concluderend
Architectuurevaluatie is een complex proces. Om het assessment goed uit te kunnen voeren, moet u over voldoende ervaring en kennis beschikken.
Het is mogelijk om de klant binnen een week resultaten te bieden die nuttig zijn voor hem en zijn bedrijf. Zelfs als je het alleen doet.
Op basis van mijn ervaring zijn veel verbeteringen halverwege gedownload en soms nooit gestart. Degenen die voor zichzelf de gulden middenweg kozen en slechts een deel van de verbeteringen doorvoerden die het nuttigst waren voor het bedrijf met minimale arbeidskosten, verbeterden de kwaliteit van hun product aanzienlijk. Wie niets deed, kon het project na een paar jaar helemaal afsluiten.
Jouw doel is om de klant maximale verbeteringen te laten zien voor de minimumprijs.
Andere artikelen uit de sectie u kunt op uw gemak lezen.
Ik wens je schone code en goede architectonische beslissingen.
Onze facebookgroep - .
Bron: www.habr.com