Komence ĉiam malfacilas kompreni grandan kaj malnovan projekton. Arkitekturo estas unu el la agadoj de taksado de arkitekto. Kutime vi devas labori kun grandaj, malnovaj projektoj, kaj la rezultoj devas esti liveritaj en semajno.
Kiel taksi projekton de 100k aŭ pli da linioj de kodo en semajno dum ankoraŭ provizante rezultojn kiuj estas vere utilaj al la kliento.
Plej multaj arkitektoj kaj teknikaj gvidantoj renkontis similajn projekttaksojn. Ĉi tio povas aspekti kiel duonformala procezo aŭ kiel aparta servo kiel estas farita en nia kompanio, unumaniere aŭ alie la plej multaj el vi traktis ĉi tion.
La originalo en la angla por viaj ne-ruslingvaj amikoj estas ĉi tie: .
Aliro de nia kompanio
Mi rakontos al vi kiel ĝi funkcias en nia kompanio kaj kiel mi agas en similaj situacioj, sed vi povas facile ŝanĝi ĉi tiun aliron laŭ la bezonoj de via projekto kaj kompanio.
Estas du specoj de arkitektura taksado.
Interno – ni kutime faras ĝin por projektoj ene de la firmao. Ĉiu projekto povas peti arkitekturtakson pro pluraj kialoj:
- La teamo opinias, ke ilia projekto estas perfekta kaj ĉi tio estas suspektinda. Ni havis tiajn kazojn, kaj ofte en tiaj projektoj ĉio estas malproksime de ideala.
- La teamo volas testi sian projekton kaj siajn solvojn.
- La teamo scias, ke aferoj estas malbonaj. Ili eĉ povas listigi la ĉefajn problemojn kaj kaŭzojn, sed volas kompletan liston de problemoj kaj rekomendoj por plibonigi la projekton.
Ekstera estas pli formala procezo ol interna takso. La kliento ĉiam venas nur en unu kazo, kiam ĉio estas malbona - tre malbona. Kutime la kliento komprenas, ke ekzistas tutmondaj problemoj, sed ne povas ĝuste identigi la kaŭzojn kaj malkonstrui ilin en komponantojn.
Taksi arkitekturon por ekstera kliento estas pli kompleksa kazo. La procezo devus esti pli formala. La projektoj estas ĉiam grandaj kaj malnovaj. Ili havas multajn problemojn, cimojn kaj malrektan kodon. Raporto pri la farita laboro devus esti preta ene de kelkaj semajnoj maksimume, kiu devus inkluzivi la ĉefajn problemojn kaj rekomendojn por plibonigo. Sekve, se ni traktas la eksteran taksadon de la projekto, tiam la interna taksado estos peco de kuko. Ni konsideru la plej malfacilan kazon.
Takso pri arkitekturo de entreprena projekto
Tipa projekto por taksi estas granda, malnova, entreprena projekto kun multaj problemoj. Kliento venas al ni kaj petas nin ripari sian projekton. Estas kiel kun glacimonto, la kliento vidas nur la pinton de siaj problemoj kaj ne havas ideon, kio estas sub la akvo (en la profundo de la kodo).
Problemoj pri kiuj la kliento povas plendi kaj povas konscii:
- Elfaraj Problemoj
- Problemoj pri uzebleco
- Longtempa deplojo
- Manko de unuo kaj aliaj testoj
Problemoj, pri kiuj la kliento plej verŝajne ne konscias, sed ili povas ĉeesti en la projekto:
- Sekurecaj problemoj
- Dezajnaj problemoj
- Malĝusta arkitekturo
- Algoritmaj eraroj
- Nekonvenaj teknologioj
- Teknika ŝuldo
- Malĝusta evoluprocezo
Formala arkitektura revizioprocezo
Ĉi tio estas formala procezo, kiun ni sekvas kiel kompanio, sed vi povas personecigi ĝin depende de via kompanio kaj projekto.
Peto de kliento
La kliento petas taksi la arkitekturon de la nuna projekto. La respondeca persono ĉe nia flanko kolektas bazajn informojn pri la projekto kaj elektas la necesajn spertulojn. Depende de la projekto, ĉi tiuj povas esti malsamaj spertuloj.
Solva Arkitekto – la ĉefa respondeca pri taksado kaj kunordigo (kaj ofte la sola).
Staku specifajn spertulojn – .Net, Java, Python, kaj aliaj teknikaj specialistoj depende de la projekto kaj teknologioj
Nubo-fakuloj – ĉi tiuj povas esti Azure, GCP aŭ AWS-nubaj arkitektoj.
infrastrukturo - DevOps, Sistemadministranto, ktp.
Aliaj spertuloj - kiel grandaj datumoj, maŝinlernado, agado-inĝeniero, sekureca fakulo, QA-gvidanto.
Kolekti informojn pri la projekto
Vi devus kolekti kiel eble plej multe da informoj pri la projekto. Vi povas uzi malsamajn teknikojn depende de la situacio:
- Demandiloj kaj aliaj metodoj de komunikado per poŝto. La plej neefika maniero.
- Interretaj renkontiĝoj.
- Specialaj iloj por informinterŝanĝo kiel: Google doc, Confluence, deponejoj, ktp.
- "Vivaj" renkontiĝoj surloke. La plej efika kaj plej multekosta maniero.
Kion vi devas ricevi de la kliento?
Bazaj informoj. Pri kio temas la projekto? Ĝia celo kaj valoro. Ĉefaj celoj kaj planoj por la estonteco. Komercaj celoj kaj strategioj. Ĉefaj problemoj kaj dezirataj rezultoj.
Projektaj informoj. Teknologia stako, kadroj, programlingvoj. Surloka aŭ nuba deplojo. Se la projekto estas en la nubo, kiaj servoj estas uzataj. Kiaj arkitekturaj kaj dezajnaj ŝablonoj estis uzataj.
Ne-funkciaj postuloj. Ĉiuj postuloj rilatas al rendimento, havebleco kaj facileco de uzado de la sistemo. Sekurecaj postuloj, ktp.
Bazaj uzkazoj kaj datumfluoj.
Aliro al fontkodo. La plej grava parto! Vi certe devus akiri aliron al la deponejoj kaj dokumentaro pri kiel konstrui la projekton.
Aliro al infrastrukturo. Estus bone havi aliron al la scenejo aŭ produktada infrastrukturo por labori kun la viva sistemo. Estas granda sukceso se la kliento havas ilojn por monitori infrastrukturon kaj rendimenton. Pri ĉi tiuj iloj ni parolos en la sekva sekcio.
Dokumentado. Se la kliento havas dokumentadon, tio estas bona komenco. Ĝi eble estas malmoderna, sed ĝi ankoraŭ estas bona komenco. Neniam fidu la dokumentaron - provu ĝin kun la kliento, sur reala infrastrukturo kaj en la fontkodo.
Arkitektura Taksado-Procezo
Kiel oni povas prilabori tiom grandan kvanton da informoj en tiel mallonga tempo? Unue, paraleligu la laboron.
DevOps devus rigardi la infrastrukturon. Teknika gvido en la kodon. Efikeca inĝeniero por vidi rendimentajn metrikojn. Specialisto pri datumbazoj devus fosi pli profunde en datumstrukturojn.
Sed ĉi tio estas ideala kazo kiam vi havas multajn rimedojn. Tipe, unu ĝis tri homoj taksas projekton. Vi eĉ povas fari la takson mem, kio ofte okazas se vi havas la taŭgan scion kaj sperton en ĉiuj areoj de la projekto. En ĉi tiu kazo, vi devas aŭtomatigi ĉiujn procezojn kiel eble plej multe.
Bedaŭrinde, vi devos legi la dokumentaron permane. Kun la ĝusta kvanto de sperto, vi povas rapide kompreni la kvaliton de la dokumentaro. Kio estas vera kaj kio klare ne koincidas kun la realo. Kelkfoje vi povas vidi arkitekturon en dokumentado, kiu neniam funkcios en la reala vivo. Ĉi tio estas ellasilo por vi pensi pri kiel ĝi estis farita en realeco en la projekto.
Utilaj iloj por aŭtomatigi projektan taksadon
Koda taksado estas simpla ekzerco. Vi povas uzi statikajn kodanalizilojn, kiuj montros al vi problemojn pri dezajno, rendimento kaj sekureco. Jen kelkaj el ili:
estas bonega ilo por arkitekto. Ĝi montros al vi la grandan bildon, dependecojn inter moduloj kaj eblaj areoj por refactoring. Kiel ĉiuj bonaj iloj, ĝi kostas bonan monon, sed vi povas utiligi 30-tagan provan version.
- bona malnova ilo. Ilo por statika kodanalizo. Permesas al vi identigi malbonan kodon, cimojn kaj sekurecajn problemojn por pli ol 20 programlingvoj.
Ĉiuj nubaj provizantoj havas infrastrukturajn monitorajn ilojn. Ĉi tio permesos al vi ĝuste taksi la efikecon de via infrastrukturo laŭ kosto kaj rendimento. Por AWS ĉi tio estas . Ĝi estas facila por Azure .
Plia agado-monitorado kaj registrado helpos trovi rendimentajn problemojn ĉe ĉiuj niveloj. Komencante de datumbazo kun neefikaj demandoj, la backend kaj finante per la fasado. Eĉ se la kliento ne instalis ĉi tiujn ilojn antaŭe, vi povas integri ilin en la ekzistantan sistemon sufiĉe rapide por identigi rendimentajn problemojn.
Kiel ĉiam, bonaj iloj bone valoras ĝin. Mi povas rekomendi kelkajn pagitajn ilojn. Kompreneble vi povas uzi malfermfontecon sed ĝi prenos al vi pli da tempo. Kaj ĉi tio devus esti farita antaŭe, ne dum la arkitektura taksa procezo.
- ilo por taksi aplikaĵan efikecon
- servo de monitorado de nuba sistemo
Estas multaj iloj disponeblaj por sekureca testado. Ĉi-foje mi rekomendos al vi senpagan sisteman skanilon.
- ilo por skani TTT-aplikaĵojn por konformeco al sekurecaj normoj.
Ni kunigu ĉion en unu tuton.
Preparante raporton
Komencu vian raporton per la datumoj, kiujn vi kolektis de la kliento. Priskribu la projektcelojn, limojn, ne-funkciajn postulojn. Post ĉi tio, ĉiuj enigodatenoj devus esti menciitaj: fontkodo, dokumentado, infrastrukturo.
Sekva paŝo. Listigu iujn ajn problemojn, kiujn vi trovis permane aŭ uzante aŭtomatajn ilojn. Metu grandajn aŭtomate generitajn raportojn ĉe la fino en la sekcio pri aplikaĵoj. Devus esti mallongaj kaj koncizaj pruvoj pri la trovitaj problemoj.
Priorigu la problemojn trovitajn sur la eraro, averto, informa skalo. Vi povas elekti vian propran skalon, sed ĉi tiu estas la ĝenerale akceptita.
Kiel vera arkitekto, estas via respondeco provizi rekomendojn por korekti la trovitajn problemojn. Priskribu la plibonigojn kaj komercan valoron, kiun la kliento ricevos. Kiel montri komercan valoron de ni diskutis pli frue.
Preparu vojmapon kun malgrandaj ripetoj. Ĉiu ripeto devus enhavi tempon por kompletigi, priskribon, kvanton da rimedoj necesaj por plibonigo, teknika valoro kaj komerca valoro.
Ni kompletigas la arkitekturan taksadon kaj provizas la klienton per raporto
Neniam nur poŝtu raporton. Ĝi eble tute ne estas legata, aŭ eble ne estas legita kaj komprenata sen taŭga klarigo. Resume, viva komunikado helpas forigi miskomprenojn inter homoj. Vi devus plani renkontiĝon kun la kliento kaj paroli pri la trovitaj problemoj, koncentriĝante sur la plej signifaj. Indas altiri la atenton de la kliento pri problemoj, pri kiuj li eble eĉ ne konscias. Kiel sekurecaj aferoj kaj klarigi kiel ili povus influi la komercon. Montru vian vojmapon kun plibonigoj kaj diskutu malsamajn opciojn, kiuj pli taŭgas por la kliento. Ĉi tio povus esti tempo, rimedoj, kvanto de laboro.
Kiel resumon de via renkontiĝo, sendu vian raporton al la kliento.
En konkludo
Arkitektura taksado estas kompleksa procezo. Por efektivigi la taksadon ĝuste, vi devas havi sufiĉe da sperto kaj scio.
Eblas provizi al la kliento rezultojn utilajn por li kaj lia komerco en nur semajno. Eĉ se vi faras ĝin sola.
Surbaze de mia sperto, multaj plibonigoj estis elŝutitaj en la mezo, kaj foje neniam komenciĝis. Tiuj, kiuj elektis la oran rimedon por si kaj faris nur parton de la plibonigoj, kiuj estis plej utilaj por la komerco kun minimumaj laborkostoj, signife plibonigis la kvaliton de sia produkto. Tiuj, kiuj nenion faris, povis tute fermi la projekton post kelkaj jaroj.
Via celo estas montri al la kliento maksimumajn plibonigojn por la minimuma prezo.
Aliaj artikoloj de la sekcio vi povas legi laŭplaĉe.
Mi deziras al vi puran kodon kaj bonajn arkitekturajn decidojn.
Nia fejsbuka grupo - .
fonto: www.habr.com