Aan het begin is het altijd moeilijk om je weg te vinden in een groot en oud project. Architecture assessment is een van de activiteiten van een architect. Meestal moet er worden gewerkt met grote, oude projecten, en de resultaten moeten binnen een week worden gepresenteerd.
Hoe beoordeel je een project van 100.000 en meer regels code binnen een week en lever je daadwerkelijk nuttige resultaten voor de klant?
De meeste architecten en tech leads zijn geconfronteerd met dergelijke projectbeoordelingen. Dit kan eruitzien als een semi-formeel proces of als een aparte dienst zoals dat in ons bedrijf is gedaan; hoe dan ook, de meesten van jullie hebben hiermee te maken gehad.
De originele Engelse tekst voor je niet-Russischsprekende vrienden is hier te vinden: .
De benadering in ons bedrijf
Ik zal je vertellen hoe dit werkt in ons bedrijf en hoe ik in dergelijke situaties handel, maar je kunt deze aanpak eenvoudig aanpassen aan de behoeften van jouw project en bedrijf.
Er zijn twee soorten architecture assessment.
Intern ā we doen dit meestal voor projecten binnen het bedrijf. Elk project kan om een architectuuroordeel vragen om verschillende redenen:
- Het team denkt dat hun project perfect is en dat is verdacht. We hebben dergelijke gevallen gehad en vaak zijn deze projecten lang niet perfect.
- Het team wil hun project en hun oplossingen verifiƫren.
- Het team weet dat het niet goed gaat. Ze kunnen zelfs de belangrijkste problemen en oorzaken opsommen, maar willen een complete lijst van problemen en aanbevelingen voor verbetering van het project.
Extern ā dit is een formeeler proces dan de interne beoordeling. Een klant komt altijd alleen in Ć©Ć©n geval, als alles slecht is ā heel slecht. Gewoonlijk begrijpt de klant dat er wereldwijde problemen zijn, maar kan hij de oorzaken niet correct identificeren en splitsen in componenten.
Architectuurbeoordeling voor een externe klant is een complexer geval. Het proces moet formeler zijn. Projecten zijn altijd groot en oud. Er zijn veel problemen, bugs en slecht geschreven code. Het rapport over het uitgevoerde werk moet binnen enkele weken klaar zijn, met de belangrijkste problemen en aanbevelingen voor verbetering. Daarom, als we de externe beoordeling van het project in orde krijgen, is de interne beoordeling een fluitje van een cent. Laten we de moeilijkste zaak bekijken.
Architectuurbeoordeling van een enterprise project
Een typisch beoordelingsproject is een groot, oud enterprise-project met veel problemen. De klant komt bij ons en vraagt ons om zijn project te repareren. Het is als met een ijsberg; de klant ziet alleen de top van zijn problemen en heeft geen idee van wat er onder water (in de diepte van de code) verborgen ligt.
Problemen waar de klant zich misschien over kan beklagen en zich bewust van is:
- Prestatief problemen
- Problemen met de gebruiksvriendelijkheid van de applicatie (Usability)
- Langdurige implementatie
- Ontbreken van unit- en andere tests
Problemen waar de klant zich waarschijnlijk niet bewust van is, maar die aanwezig kunnen zijn in het project:
- Veiligheidsproblemen
- Ontwerpproblemen
- Verkeerde architectuur
- Algoritmische fouten
- Ongeschikte technologieƫn
- Technische schuld
- Onjuiste ontwikkelingsprocessen
Formeel proces voor architectuurevaluatie
Dit is een formeel proces dat we in het bedrijf volgen, maar je kunt het aanpassen aan je bedrijf en project.
Verzoek van de 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 experts zijn.
Solution Architect ā de belangrijkste persoon verantwoordelijk voor de evaluatie en coƶrdinatie (en vaak de enige).
Stack 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, enz.
Andere experts ā zoals big data, machine learning, performance engineer, security expert, QA lead.
Informatie verzamelen over het project
Je moet zoveel mogelijk informatie over het project verzamelen. Je kunt verschillende technieken gebruiken afhankelijk van de situatie:
- Vragenlijsten en andere manieren van communiceren via e-mail. De minst effectieve manier.
- Online meetings.
- Specifieke tools voor informatie-uitwisseling zoals: Google doc, Confluence, repositories, enz.
- āLiveā vergaderingen ter plaatse. De meest effectieve en duurste manier.
Wat moeten we van de klant verkrijgen?
Basisinformatie. Waar gaat het project over? Wat is het doel en de waarde? De belangrijkste doelen en plannen voor de toekomst. De zakelijke doelen en strategieƫn. De belangrijkste problemen en het gewenste resultaat.
Projectinformatie. Technische stack, frameworks, programmeertalen. On-premise of cloud deployment. Als het project in de cloud staat, welke diensten worden dan gebruikt? Welke architectonische en designpatronen zijn toegepast.
Niet-functionele vereisten. Alle vereisten die verband houden met de prestaties, beschikbaarheid, bruikbaarheid van het systeem. Veiligheidseisen, etc.
Basis use cases en datastromen.
Toegang tot de broncode. Het belangrijkste onderdeel! U moet absoluut toegang krijgen tot de repositories en documentatie over hoe u het project kunt samenstellen.
Toegang tot de infrastructuur. Het zou goed zijn om toegang te krijgen tot de stage- of productie-infrastructuur, zodat u met het 'levende' systeem kunt werken. Het is een grote kans als de klant monitoringtools voor infrastructuur en prestaties heeft. We zullen deze tools in de volgende sectie bespreken.
Documentation. Als de klant documentatie heeft, is dat een goed begin. Het kan verouderd zijn, maar het is nog steeds een goed begin. Vertrouw nooit blindelings op documentatie - controleer deze met de klant, op de echte infrastructuur en in de broncode.
Proces voor het evalueren van architectuur
Hoe verwerk je zoveel informatie in zo'n korte tijd? Bovenal, paralleliseer het werk.
De DevOps moet naar de infrastructuur kijken. De tech lead in de code. De performance engineer moet de prestaties van de metrics bekijken. De database specialist moet dieper in de datastructuren duiken.
Maar dit is de ideale situatie, wanneer je veel middelen hebt. Meestal wordt de projectevaluatie uitgevoerd door Ć©Ć©n tot drie personen. U kunt zelfs de evaluatie zelf uitvoeren, wat vaak gebeurt als u over de juiste kennis en ervaring in alle gebieden van het project beschikt. In dat geval moet u alle processen zo veel mogelijk automatiseren.
Helaas moet u de documentatie handmatig doorlezen. Met de juiste ervaring kunt u vrij snel de kwaliteit van de documentatie begrijpen. Wat klopt er en wat komt duidelijk niet overeen met de werkelijkheid. Soms kunt u in de documentatie een architectuur tegenkomen die nooit in het echte leven zal werken. Dit is een aanwijzing voor u om na te denken over hoe het in werkelijkheid in het project is gedaan.
Nuttige tools voor het automatiseren van de projectevaluatie
Code review is a straightforward exercise. You can use static code analyzers that will highlight design, performance, and security issues. Here are a few of them:
is a great tool for architects. It will show you the overall picture, the dependencies between modules, and potential areas for refactoring. Like all good tools, it comes at a cost, but you can take advantage of a 30-day trial version.
is the old reliable tool. A static code analysis tool. It allows you to identify bad code, bugs, and security issues for more than 20 programming languages.
All cloud providers have tools for monitoring infrastructure. This will help you accurately assess infrastructure efficiency in terms of cost and performance. For AWS, this is . For Azure, it's simply .
Additional performance monitoring and logging will help identify performance issues at all levels, from databases with inefficient queries, backend, to frontend. Even if the client hasn't installed these tools before, you can quickly integrate them into the existing system to pinpoint performance issues.
As always, good tools come at a price. I can recommend a couple of paid tools. Of course, you can use open-source options, but it will take more time. And this should be done in advance, not during the architecture evaluation process.
is a tool for assessing application performance
is a cloud service for monitoring systems
There are many tools for security testing. This time, I recommend a free tool for system scanning.
is a tool for scanning web applications for compliance with security standards.
We bring everything together.
Preparing the report
Start your report with the data collected from the client. Describe the project's objectives, constraints, and non-functional requirements. After that, mention all input data: source code, documentation, infrastructure.
Volgende stap. Geef alle problemen aan die u handmatig of met behulp van geautomatiseerde tools hebt gevonden. Grote automatisch gegenereerde rapporten plaatst u aan het einde in de bijlagen. Hier moeten korte en duidelijke bewijzen van de gevonden problemen staan.
Prioriteer de gevonden problemen op een schaal van fout, waarschuwing, informatie. U kunt uw eigen schaal kiezen, maar dit is de algemeen aanvaarde.
Als echte architect bent u verplicht aanbevelingen te doen voor het verhelpen van de gevonden problemen. Beschrijf de verbeteringen en de waarde voor de business die de klant zal ontvangen. Hoe de zakelijke waarde te tonen van dat we eerder hebben besproken.
Bereid een roadmap voor met kleine iteraties. Elke iteratie moet tijd bevatten voor uitvoering, een beschrijving, het aantal middelen dat nodig is voor de verbetering, technische waarde en waarde voor de business.
We ronden de architectuurbeoordeling af en geven de klant het rapport.
Stuur nooit gewoon het rapport per e-mail. Het kan ofwel helemaal niet gelezen worden of gelezen en niet begrepen zonder de juiste uitleg. Kortom, persoonlijk contact helpt misverstanden tussen mensen te voorkomen. U moet een vergadering met de klant plannen en de gevonden problemen uitleggen, met de nadruk op de meest significante. Het is belangrijk de klant te wijzen op problemen waar hij zich misschien niet van bewust was. Zoals beveiligingsproblemen en uitleggen hoe deze de business kunnen beĆÆnvloeden. Laat uw roadmap met verbeteringen zien en bespreek de verschillende opties die het beste bij de klant passen. Dit kan gaan over tijd, middelen en werkvolume.
Als samenvatting van uw vergadering stuurt u het rapport naar de klant.
Ter conclusie
Architectuurevaluatie is een complexe procedure. Om de evaluatie correct uit te voeren, moet u over voldoende ervaring en kennis beschikken.
Het is echt mogelijk om de klant nuttige resultaten voor hem en zijn business binnen een week te bieden. Zelfs als u dit alleen doet.
Uit mijn ervaring bleek dat veel verbeteringen halverwege stopten, en soms nooit begonnen zijn. Degenen die de gulden middenweg kozen en slechts een deel van de verbeteringen doorvoerden die het meest waardevol waren voor de business met minimale tijdsinvesteringen, verbeterden de kwaliteit van hun product aanzienlijk. Degenen die niets deden, konden na een paar jaar hun project helemaal beƫindigen.
Uw doel is om de klant de maximale verbeteringen voor de laagst mogelijke prijs te tonen.
Andere artikelen uit deze sectie kun je in je vrije tijd lezen.
Ik wens je schone code en goede architectonische oplossingen.
Onze Facebook-groep is ā .
Bron: habr.com
