Strategiile de dezvoltare software au fost şi vor fi un permanent subiect de dezbateri și contradicţii, care creează totodată un mediu propice dezvoltării ideilor importante. De-a lungul anilor am avut oportunitatea de a întâlni diferite păreri şi atitudini pe marginea acestui subiect.
O luare în considerare atât a părerilor convergente, cât şi a celor divergente în ceea ce privește o anumită viziune este o condiție de bază a evoluției strategiilor de dezvoltare software.
Arhitectura unui sistem nu se poate defini în mod independent, ea depinde de un context dat, fapt care îl introduce în ecuaţie, pe acesta din urmă, ca un aspect important şi definitoriu în alegerea tiparului arhitectural. Analiza elementelor componente va aduce mai multă claritate în alegerea formei arhitecturale a soluţiei pe care o construim.
Fiecare dintre noi ne formăm şi ne dezvoltăm urmând un traseu anume, fapt care determină formarea unor viziuni diferite asupra tehnologiei. Universităţile pe care le absolvim, firmele prin care trecem, proiectele cu care intrăm în contact, studiul individual contribuie la formarea unui pachet de informaţii care ne determina să vedem lucrurile fie într-un mod, fie în altul. Pe de altă parte, rata evoluţiei tehnologice face ca fiecare dintre noi să asimilăm într-o anume măsură noutăţile apărute.
Un aspect important, într-un mediu atât de dinamic, îl constituie filtrarea informaţiei. Apariţia zecilor şi sutelor de tehnologii, pe unitatea de timp, necesită timp de asimilare, criterii de analiză, capacitate de catalogare. De cele mai multe ori, formatarea noastră profesională este rezultatul concluziilor altora. Îmbrăţişăm preferinţele tehnologice ale firmelor în care lucrăm, preluăm know-how-ul, de multe ori, în mod automat. Toate acestea formează un sistem de valori, de cunoștințe,care ne determină capacitatea de lucru. Începem să ne maturizăm în momentul în care putem să ne detaşăm de acest întreg aparat de procesare tehnologică şi să privim în mod obiectiv lucrurile.
Maturizarea viziunii arhitecturale se dobândeşte o dată cu participarea la un număr tot mai mare de proiecte şi prin interacţiunea cu echipe de lucru tot mai diverse. Varietatea proiectelor ne lărgesc cadrul de percepţie a problematicii. Fiecare proiect contribuie la formarea unei noi perspective sau la redefinirea uneia existente.
Apetitul pentru complexitate sau tendinţa spre simplitate sunt trăsături care ne caracterizează încă din anii de şcoală. Este lesne de observat că încă din primii ani de școală unii elevi preferă la matematică, rezolvări complexe şi alții se mulţumesc cu drumul cel mai scurt spre soluţia problemei. Aceste tendinţe sunt determinante pe întreg parcursul vieţii.
Soluţiile complexe aduc noi argumente, deschid un câmp de vizibilitate mai larg, atunci când sunt bine alese. Calităţile cu care înzestrăm o soluţie software pot aduce beneficii directe în scalabilitate sau în robusteţea aplicaţiei. În schimb, dacă relaţiile dintre aspectele importante nu sunt bine definite atunci complexitatea poate fi o piedică majoră. Nu de puţine ori am întâlnit aplicaţii care încercau să combine cele mai importante tehnologii ale zilei, cu cele mai recomandate arhitecturi, în schimb creau un cadru complex, fără norme bine definite, un soi de şah fără reguli clare. Procesul de dezvoltare şi mai apoi de întreţinere al unei astfel de aplicaţii poate fi extrem de dificil.
Complexitatea poate fi un atribut al haosului sau unul al evoluţiei. Arhitectura sistemului trebuie să aducă claritate, flexibilitate și să înzestreze sistemul cu forţă. Simplitatea unui sistem complex constă în faptul că un număr mare de piese pe tablă de joc, creează un peisaj limpede, intuitiv.
Sistemele software actuale trebuie să se supună unor cerinţe diferite de cele care se produceau cu 20 de ani în urmă. Mediul Agile de dezvoltare aduce cerinţe extrem de diverse sistemelor, astfel că apariţia unor piese de puzzle, greu de anticipat la startul unui proiect, devine o aproape evidenţă.
Nevoile clienţilor sunt tot mai ridicate astfel că sistemele software trebuie să anticipeze şi să integreze o arhitectură cu un nivel ridicat de flexibilitate şi de adaptabilitate la un mediu complex. Acest fapt "ridică la fileu" nevoia de creare a unor sisteme tot mai complexe şi mai inteligente. Inversia controlului (inversion of control) a devenit o cerinţă prioritară în proiectarea sistemelor, fiecare componentă trebuind să aibă capacitatea de a fi bine definită şi independentă de celelalte. Acelaşi rol important îl joacă şi designul orientat pe interfeţe (interface oriented design), etc. . Din start putem afirma că aplicaţiile care nu respectă noile standarde de abstractizare sunt un trouble maker.
O constrângere importantă este dată de termenii de livrare ai produsului. Aceştia pot exercită o presiune considerabilă în alegerea elementelor arhitecturale. O arhitectură complexă necesită timpi de dezvoltare proporţionali, în schimb o arhitectură prea simplistă poate introduce o gama largă de probleme. Astfel tendinţa de a sacrifica modulele de unit testing este aproape evidenţă, în cele mai multe situaţii. Există un impuls subconştient de a considera faptul că funcţionalitatea modulelor create este asigurată doar prin faptul că există cod scris, aspect căruia trebuie să îi acordăm multă atenţie.
Mediul Agile de dezvoltare solicită adăugarea de noi funcţionalităţi într-un ritm foarte alert, fapt care nu permite o bună planificare şi analiză a tuturor implicaţiilor, cum permite Waterfall. Astfel introducerea de erori este aproape inerentă. Odată cu adăugarea unui pachet de funcţionalităţi, numărul de erori va fi destul de greu de controlat și timpul alocat evenimentelor neprevăzute va fi consumat în mare parte de repararea de erori introduse pe durata dezvoltării.
Nevoia de a crea module fără erori solicită ancorarea fiecărei funcţionalităţi într-un sistem care să asigure integritatea comportamentului. O modalitate excelenţă de design care să permită asigurarea unui backup de acest fel este oferită de test driven design. Această modalitate de design asigura crearea unor indicatori de stare al fiecărui aspect.
Designul bazat pe testare (impropriu numit testare) imprimă soluţiei un traseu oarecum diferit de dezvoltare față de cel clasic. O minte formată pe pricipiile clasice de programare scapă detalii importante în procesul de design, punând accentul pe alte componente. Designul bazat pe testare(TDD) permite detectarea elementelor problemă încă din faza de proiectare. Chiar dacă pentru mulţi acest tip de dezvoltare pare atipic, el oferă garanţia robusteții. Astfel efortul asimilării acestui procedeu de design conduce la rezultate foarte bune în etapele următoare.
Sistemele a căror arhitectură nu se supun unor normative clare de relaţionare a componentelor şi straturilor, cât şi modulele al căror comportament nu poate fi garantat în permanentă (prin mecanisme de verificare) constituie un impediment des întâlnit. Timpii de dezvoltare sunt depăşiţi, în general, datorită acestor două categorii de probleme. Aceste neajunsuri pot fi uşor depăşite în cazul în care arhitectura sistemelor software este gândită şi realizată cu maturitate.
Proiectarea sistemelor trebuie să ocupe un loc prioritar în dezvoltarea software, altfel aplicatiile pot avea un grad ridicat de fragilitate. Criteriile de formare a arhitecţilor sunt foarte complexe. Chiar dacă multe companii promovează pe astfel de poziţii dezvoltatori cu o experienţă de mai puțin de opt ani, cred că este un interval prea scurt de formare. Procesul de definire a profilului unui arhitect durează o perioadă mai mare şi implică şi alţi factori decât pregătirea pur teoretică. Este importantă interacţiunea cu un număr mare de proiecte pentru a putea înţelege bine concluziile autorilor importanţi, cât și a rațiunii care stă la baza acestora. Maturitatea în proiectarea sistemelor survine în momentul în care un programator a asistat la dezvoltarea unui număr consistent de aplicații astfel încât să poată înțelege neajunsurile, dar să fie capabil să definească sisteme robuste. Doar o experienţă de acest fel poate garanta soliditatea sistemelor create.