Al principi sempre és difícil entendre un projecte gran i antic. L'arquitectura és una de les activitats de l'avaluació d'un arquitecte. Normalment s'ha de treballar amb projectes grans i antics, i els resultats s'han de lliurar en una setmana.
Com avaluar un projecte de 100 o més línies de codi en una setmana alhora que ofereix resultats que són realment útils per al client.
La majoria d'arquitectes i responsables tècnics s'han trobat amb avaluacions de projectes similars. Això pot semblar un procés semi-formal o un servei independent com es fa a la nostra empresa, d'una manera o d'una altra la majoria de vosaltres ho heu tractat.
L'original en anglès per als vostres amics que no parlen rus és aquí: .
L'enfocament de la nostra empresa
T'explicaré com funciona a la nostra empresa i com actuo en situacions semblants, però pots canviar fàcilment aquest plantejament segons les necessitats del teu projecte i empresa.
Hi ha dos tipus d'avaluació de l'arquitectura.
Interior – Normalment ho fem per projectes dins de l'empresa. Qualsevol projecte pot sol·licitar una avaluació d'arquitectura per diversos motius:
- L'equip creu que el seu projecte és perfecte i això és sospitós. Hem tingut casos així, i sovint en aquests projectes tot està lluny de ser ideal.
- L'equip vol provar el seu projecte i les seves solucions.
- L'equip sap que les coses van malament. Fins i tot poden enumerar els principals problemes i causes, però volen una llista completa de problemes i recomanacions per millorar el projecte.
Externa és un procés més formal que una avaluació interna. El client sempre ve només en un cas, quan tot està malament, molt dolent. Normalment el client entén que hi ha problemes globals, però no pot identificar correctament les causes i desglossar-les en components.
Avaluar una arquitectura per a un client extern és un cas més complex. El procés hauria de ser més formal. Els projectes sempre són grans i antics. Tenen molts problemes, errors i codi tort. En un termini màxim d'unes setmanes s'haurà d'elaborar un informe sobre el treball realitzat, que inclourà els principals problemes i recomanacions de millora. Per tant, si ens ocupem de l'avaluació externa del projecte, l'avaluació interna serà fàcil. Considerem el cas més difícil.
Avaluació de l'arquitectura del projecte empresarial
Un projecte típic a avaluar és un projecte empresarial gran i antic amb molts problemes. Un client ve a nosaltres i ens demana que arreglem el seu projecte. És com amb un iceberg, el client només veu la punta dels seus problemes i no té ni idea del que hi ha sota l'aigua (en les profunditats del codi).
Problemes dels quals el client pot queixar-se i que pot tenir coneixement:
- Problemes de rendiment
- Problemes d'usabilitat
- Desplegament a llarg termini
- Manca d'unitat i altres proves
Problemes que el client probablement no coneix, però que poden estar presents en el projecte:
- Problemes de seguretat
- Problemes de disseny
- Arquitectura incorrecta
- Errors algorítmics
- Tecnologies inadequades
- Deute tècnic
- Procés de desenvolupament incorrecte
Procés formal de revisió de l'arquitectura
Aquest és un procés formal que seguim com a empresa, però que pots personalitzar-lo en funció de la teva empresa i projecte.
Petició d'un client
El client demana avaluar l'arquitectura del projecte actual. La persona responsable del nostre costat recull informació bàsica sobre el projecte i selecciona els experts necessaris. Segons el projecte, aquests poden ser diferents experts.
Arquitecte de solucions – el responsable principal de l'avaluació i la coordinació (i sovint l'únic).
Apila experts específics – .Net, Java, Python, i altres especialistes tècnics segons el projecte i les tecnologies
Experts en núvol – aquests poden ser arquitectes de núvol Azure, GCP o AWS.
Infraestructura – DevOps, administrador del sistema, etc.
Altres experts – com ara big data, aprenentatge automàtic, enginyer de rendiment, expert en seguretat, responsable de control de qualitat.
Recollida d'informació sobre el projecte
Heu de recollir la màxima informació possible sobre el projecte. Podeu utilitzar diferents tècniques segons la situació:
- Qüestionaris i altres mètodes de comunicació per correu. La manera més ineficaç.
- Reunions en línia.
- Eines especials per a l'intercanvi d'informació com ara: Google doc, Confluence, repositoris, etc.
- Reunions "en directe" al lloc. La forma més eficaç i més cara.
Què hauria d'obtenir del client?
Informació bàsica. De què tracta el projecte? La seva finalitat i valor. Principals objectius i plans de futur. Objectius i estratègies empresarials. Principals problemes i resultats desitjats.
Informació del projecte. Pila de tecnologia, frameworks, llenguatges de programació. Desplegament local o al núvol. Si el projecte està al núvol, quins serveis s'utilitzen. Quins patrons arquitectònics i de disseny es van utilitzar.
Requisits no funcionals. Tots els requisits relacionats amb el rendiment, la disponibilitat i la facilitat d'ús del sistema. Requisits de seguretat, etc.
Casos d'ús bàsics i fluxos de dades.
Accés al codi font. La part més important! Definitivament hauríeu d'accedir als repositoris i a la documentació sobre com crear el projecte.
Accés a la infraestructura. Seria bo tenir accés a l'escenari o a la infraestructura de producció per treballar amb el sistema en directe. És un gran èxit si el client disposa d'eines per supervisar la infraestructura i el rendiment. Parlarem d'aquestes eines a la següent secció.
Registres. Si el client té documentació, és un bon començament. Pot ser que estigui obsolet, però encara és un bon començament. No confieu mai en la documentació: proveu-la amb el client, a la infraestructura real i al codi font.
Procés d'avaluació de l'arquitectura
Com es pot processar una quantitat tan gran d'informació en tan poc temps? En primer lloc, paral·lelitzeu el treball.
DevOps hauria de mirar la infraestructura. Cap tècnic al codi. Enginyer de rendiment per veure les mètriques de rendiment. Un especialista en bases de dades hauria d'aprofundir en les estructures de dades.
Però aquest és un cas ideal quan tens molts recursos. Normalment, una o tres persones avaluen un projecte. Fins i tot podeu fer l'estimació vosaltres mateixos, que sovint passa si teniu els coneixements i l'experiència adequats en totes les àrees del projecte. En aquest cas, cal automatitzar tots els processos tant com sigui possible.
Malauradament, haureu de llegir la documentació manualment. Amb la quantitat adequada d'experiència, podeu comprendre ràpidament la qualitat de la documentació. El que és cert i el que clarament no coincideix amb la realitat. De vegades podeu veure una arquitectura a la documentació que mai funcionarà a la vida real. Aquest és un detonant perquè pensis com es va fer en realitat en el projecte.
Eines útils per automatitzar l'avaluació de projectes
L'avaluació del codi és un exercici senzill. Podeu utilitzar analitzadors de codi estàtic que us mostraran problemes de disseny, rendiment i seguretat. Aquests són alguns d'ells:
és una gran eina per a un arquitecte. Us mostrarà el panorama general, les dependències entre mòduls i les àrees potencials per a la refactorització. Com totes les bones eines, costa bons diners, però podeu aprofitar una versió de prova de 30 dies.
- una bona eina antiga. Una eina per a l'anàlisi de codi estàtic. Us permet identificar codis dolents, errors i problemes de seguretat per a més de 20 llenguatges de programació.
Tots els proveïdors de núvol disposen d'eines de control de la infraestructura. Això us permetrà avaluar adequadament l'eficàcia de la vostra infraestructura en termes de cost i rendiment. Per a AWS això és . És fàcil per a Azure .
El seguiment i el registre addicionals del rendiment ajudaran a trobar problemes de rendiment a tots els nivells. A partir d'una base de dades amb consultes ineficaces, el backend i acabant amb el frontend. Fins i tot si el client no ha instal·lat aquestes eines anteriorment, podeu integrar-les al sistema existent amb força rapidesa per identificar problemes de rendiment.
Com sempre, les bones eines valen la pena. Puc recomanar un parell d'eines de pagament. Per descomptat, podeu utilitzar codi obert, però us portarà més temps. I això s'ha de fer per endavant, no durant el procés d'avaluació arquitectònica.
– una eina per avaluar el rendiment de l'aplicació
- Servei de monitorització del sistema al núvol
Hi ha moltes eines disponibles per a proves de seguretat. Aquesta vegada us recomanaré una eina gratuïta d'escaneig del sistema.
– una eina per escanejar aplicacions web per complir amb els estàndards de seguretat.
Posem-ho tot en un sol tot.
Elaboració d'un informe
Comenceu el vostre informe amb les dades que heu recollit del client. Descriu els objectius del projecte, les limitacions i els requisits no funcionals. Després d'això, s'han d'esmentar totes les dades d'entrada: codi font, documentació, infraestructura.
Següent pas. Enumereu qualsevol problema que hàgiu trobat manualment o utilitzant eines automatitzades. Col·loqueu grans informes generats automàticament al final de la secció d'aplicacions. Hi hauria d'haver evidència breu i concisa dels problemes trobats.
Prioritzeu els problemes trobats a l'error, avís i escala d'informació. Podeu triar la vostra pròpia escala, però aquesta és la generalment acceptada.
Com a autèntic arquitecte, és la seva responsabilitat oferir recomanacions per corregir els problemes trobats. Descriu les millores i el valor comercial que rebrà el client. Com mostrar el valor empresarial des de hem comentat abans.
Prepara un full de ruta amb petites iteracions. Cada iteració ha de contenir temps per completar-se, descripció, quantitat de recursos necessaris per a la millora, valor tècnic i valor comercial.
Realitzem l'avaluació de l'arquitectura i proporcionem al client un informe
No només envieu un informe per correu electrònic. Potser no es llegeix en absolut, o potser no es llegeix i s'entén sense una explicació adequada. En resum, la comunicació en directe ajuda a eliminar els malentesos entre les persones. Hauríeu de programar una reunió amb el client i parlar dels problemes trobats, centrant-vos en els més significatius. Val la pena cridar l'atenció del client sobre problemes dels quals potser ni tan sols és conscient. Com ara problemes de seguretat i explicar com poden afectar el negoci. Mostra el teu full de ruta amb millores i comenta diferents opcions que siguin més adequades per al client. Això podria ser temps, recursos, quantitat de treball.
Com a resum de la vostra reunió, envieu el vostre informe al client.
en conclusió
L'avaluació de l'arquitectura és un procés complex. Per dur a terme correctament l'avaluació cal tenir prou experiència i coneixements.
És possible oferir al client resultats útils per a ell i el seu negoci en només una setmana. Encara que ho facis sol.
Segons la meva experiència, es van baixar moltes millores al mig i, de vegades, no van començar mai. Els que van triar el mitjà daurat per a ells mateixos i van fer només una part de les millores que eren més útils per al negoci amb uns costos laborals mínims van millorar significativament la qualitat del seu producte. Els que no fessin res podrien tancar el projecte del tot al cap d'un parell d'anys.
El vostre objectiu és mostrar al client les màximes millores pel preu mínim.
Altres articles de la secció podeu llegir al vostre gust.
Us desitjo un codi net i bones decisions arquitectòniques.
El nostre grup de Facebook - .
Font: www.habr.com