In general am intalnit 3 approchs:
1.) trantim cod si vedem ce iese
2.) facem o architectura atat de complicata astfel incat cand mutam proiectul de la o echipa la alta apare probleme la mentenanta sau la adaugare noi features, in acest caz arhitecti au incearcat un overengineering nedocumentat
3.) facem o arhitectura clara, o documentam eventual pe ceva gen confluence astfel incat daca proiectul se muta de la o echipa la alta sa nu existe probleme in intelegerea arhitecturii si oricine vine nou pe proiect sa poata sa fie integrat usor pe proiect cu un scurt ramp up
Avantaje si dezavantaje:
Primul approach: cod mess, nementenabil, costuri de mentenanta foarte mari la fel si costuri foarte mari de adaugare noi features.
Al doilea approach: ti-au plecat dezvoltatori initiali care au facut aceasta arhitectura overenginnering si nu au documentat-o, cei care vin dupa ei le ia foarte mult sa inteleaga arhitectura si sa devina productivi
Al treilea approach: Proiectul e usor de mutat de la o echipa la alta, cei noi se integreaza usor citind documentatia.
Concluzie:
Scopul arhitectilor este sa faca o structura organizata, documentata, dar mentenabila, astfel incat costurile cu mentenanta, adaugare noi features sa fie minime si cand cauti ceva in cod sa stii unde sa gasesti.
Aici mai e de discutat despre cei care dezvolta soft haotic si cei care dezvolta organizat.
Dacă în 2017 cineva se apucă să facă orice cu JS și ajunge la un nivel să înțeleagă cel puține bazele programării funcționale, adică avantajul compoziției și scapă de oop (sau se limitează pur la componente în cazul react) aplicațiile devin triviale de schimbat. În special dacă mai intervine și flux și programarea reactivă.
Dacă trântești orice cod în mod funcțional și te folosești de stream-uri va fi chineză pentru cei ce nu au mai lucrat funcțional, dar pentru ceilalți indiferent ce arhitectură e pur și simplu adaugă funcții noi fără să refacă ceva orice ar avea de implementat. Nu mai ai treabă cu clase și structuri de date care trebuie proiectate din start cât mai bine, grijă la moșteniri, abstracții și alte chestii complicate.
Adică un program ecommerce va avea o clasă interface extinsă în 200 de locuri cu oop. Fără un IDE și ditamai documentația nu te atingi de sistem.
În cazul compoziției vom avea multiple funcții care modifică interfața returnată de funcția de dinainte în ordinea de compoziție.
Cred că un software architect nu ar trebui să îți livreze un document cu uml diagrams într-un program gen enterprise architect. De ce? Pentru că, așa a lucrat în izolare și nu împreună cu echipa: developeri, testeri, business people.
Sunt pentru fiecare cu expertiza lor, dar nu în mod waterfall sau siloz.
Pentru a avea o arhitectură potrivită, software arhitectul și cu restul din echipă trebuie să comunice, să dea exemple și cel mai potrivit ar fi o modelare cu stickies notes, să vadă the big picture, unde este partea cea mai importantă, unde sunt împotmolirile/conexiunile, ce anume s-ar putea cumpăra sau face outsourcing.
Să descopere împreună cu echipa ce este important, ce este mai puțin important, să amâne deciziile pentru ce anume vom folosim pe partea de infrastructură.
Din discuții avute în cadrul echipei, ar trebui să rezulte niște specificații, care se pot folosii pe post de test și de aici să rezulte a living documentation care este este tot timpul în concordanță cu codul, indiferent dacă se folosește pentru integration test un produs gen cucumber sau direct unit tests.
De o singura arhitectura creata de mine sunt mandru, era un proiect pur javascript cu Angular 1, desigur dezvoltat acum ceva timp, lumea javascript a mai evoluat de atunci, ideea e ca fundatia e solida, probabil si acuma daca ma mai uit pe proiect avand in vedere ca e online, javascript, neminificat pot revedea anumite solutii pe care le-am ales atunci cu crearea de servicii angular care primeau date in format json si foloseau mai departe diverse componente create de mine sa genereze din json un request, desigur si faptul ca am ales atunci WebStorm a ajutat foarte mult la navigare prin cod cand proiectul a inceput sa creasca.
Eu sunt de acord cu ce spune Jeff Atwood in link-ul de mai sus. Adica atunci cand fac o arhitectura nu incep cu o structura complicata de foldere si deja imi fac 100 de factory-uri si interfete de care nici nu o sa am nevoie cel mai probabil. Avea si Uncle Bob un video foarte fain in care vorbea despre SRP, si acolo incepea cu premisa ca trebuie sa anticipezi ce se intampla in viitor, ce cerinte o sa apara de la client, dar arata la sfarsit ca nu se poate, clientii sunt impredictibili si cel mai bine e sa fii undeva la mijloc. Unit tests + clean code + SOLID e de ajuns pentru mine in majoritatea proiectelor.