Ciclul de viaţă al produselor software este generat de nevoile de business ale consumatorilor. În sprijinul acestora vin producătorii de software cu soluţii specifice, proporţionale cu nivelul lor de pregătire şi cu tehnologiile disponibile pe piaţă. Evoluţia tehnologică foarte rapidă determină formarea unei rate de depreciere a produselor, astfel că un produs software se poate devaloriza în raport cu tehnologiile folosite. Chiar dacă funcţionalitatea business este conformă cu cerinţele consumatorilor, tehnologiile pot să nu mai reflecte exigenţele cotidiene. Calitatea unui produs software nu este reflectată doar de acurateţea cu care răspunde fluxului de date stabilit de business, ci şi de alţi factori calitativi definiţi de spectrul tehnologic existent pe piaţă la momentul evaluării. Mentenanţa unui produs, integrarea de noi funcţionalităţi furnizează o gamă de parametri adiţionali care contribuie la definirea ratei calitative, factori care sunt abstracţi din perspectiva utilizatorilor finali.
Cu aproape 20 de ani în urmă, J. B. (Joe) Rainsberger, un important promotor al programării orientate pe teste (Test Driven Development), relata un episod din perioada în care lucra ca dezvoltator la IBM. În preajma unui important milestone a început să întâmpine dificultăţi considerabile în finalizarea setului de funcţionalităţi ale proiectului la care lucra. Fiecare opţiune nou creată afecta alte funcţionalităţi deja existente. Arhitectura proiectului era atât de interactivă încât era foarte dificil să dezvolţi un nou atribut fără să modifici peisajul global. Din păcate, doar testarea manuală regresivă avea capacitatea de a scoate în evidenţă erorile apărute, ceea ce era complet inoportun şi lipsit de randament în acea situaţie.
Într-un astfel de cadru, trebuiau luate măsuri radicale pentru a putea preîntîmpina depăşirea semnificativă a termenului limită de finalizare. Nu se putea aduce în discuţie un re-design complet al aplicaţiei din cauza dimensiunilor considerabile ale codului şi a termenului foarte strâns de lucru. Singură soluţie plauzibilă era crearea unui mecanism care să permită semnalarea în timp util a posibilelor erori apărute în diverse etape de dezvoltare. J.B. s-a gândit la crearea unui pachet de metode care să testeze pilonii de baza ai proiectului. Deşi în perioada respectivă testarea automată nu exista, Joe a considerat utilă folosirea unei noi paradigme de programare, pe care el o numeşte "building on green", care avea la bază un set bine definit de metode care testau zonele fragile ale aplicaţiei, astfel că în orice moment al dezvoltării să se poată lesne stabili gradul de integritate. Deşi, în aparenţă, construirea unor noi module ale aplicaţie pare a fi o risipă de timp, acesta a contribuit semnificativ la robusteţea aplicaţiei si la viteza de dezvoltare.
În procesul de dezvoltare a unei aplicaţii, interconexiunile dintre diverse componente pot mari gradul de fragilitate al unei aplicaţii, astfel că nevoia creării unei mecanism care să restabilească balanţă este necesar.
Rularea pachetului de teste la intervale regulate de timp permitea sesizarea la timp a posibilelor erori astfel că se putea interveni la timp, totodată se micşora zona de căutare a erorii, putând delimita codul creat între cele două sesiuni de rulare de teste. Astfel, J.B. a reuşit să facă fiecare pas pe o zona stabilă, evitând scrierea unei cantităţi mari de cod, care mai apoi, trebuia refăcut. "Building on green" i-a permis încadrarea în timpul de livrare stabilit. Astfel dezvoltarea asistată de teste a devenit pentru el o paradigmă necesară pentru evitarea şi eliminarea timpilor redundanţi şi a erorilor ce pot apărea în procesul de dezvoltare.
În acea perioadă, crearea unor mecanisme software care să asigure robusteţea pe durata procesului de dezvoltare era o practică prea puţin întâlnită. Chiar şi în ziua de azi există aplicaţii foarte mari şi importante, în cadrul unor firme, a căror integritate poate fi văzută doar la finalizarea unei sesiuni de testare manuală. Astfel că finalizarea unui pachet de funcţionalităţi poate genera un set de erori care să necesite timpi suplimentari de lucru.
În present, există o varietate de opinii, părerile fiind împărţite vizavi de modalităţile de asigurare a robustetii aplicaţiilor, de metodologiile de implementare, de necesitatea realizării pachetelor de teste automate. Fiecare paradigmă este însoţită de avantajele şi riscurile aferente, cert este că se întârzie ajungerea la un consens, fapt care permite apariția multor aplicaţii pe piaţă software cu un grad ridicat de fragilitate.
Aplicaţiile care au funcţionat o perioadă pot reintra în ciclul de mentenanţă când proprietarii acestora decid modificarea unor pachete de funcţionalităţi sau realizarea altora noi. Cu cât intervalul de timp între două sesiuni consecutive de întreţinere este mai mare, cu atât gradul de depreciere al calităţii tehnologice este mai pronunţat, astfel că problematica modificării sau integrării de noi funcţionalităţi devine tot mai complexă. Progresul tehnologic constant pe unitatea de timp generează un "proces de oxidare" tehnologică al aplicaţiilor existente pe piață.
Privind dintr-o perspectiva obiectivă, proiectele de tip legacy cer un efort mai consistent din partea programatorilor. La nivel subiectiv, foarte puţini dezvoltatori se arată entuziaşti la preluarea unor astfel de sarcini. Cele mai multe aplicaţii de acest fel nu sunt susţinute de teste automate, de unit teste astfel că riscul apariţiei unor erori este inerent, fapt care duce la un disconfort semnificativ.
Evoluţia rapidă tehnologică a produs, în lumea dezvoltatorilor software, o sete după nou şi o atitudine reţinută faţă de tehnologiile care au înregistrat câţiva ani de viaţă. Dezvoltatorii încearcă să evite proiectele care folosesc tehnologii mai vechi din dorinţa de a fi în pas cu moda. Pe de altă parte ciclul de viaţă al proiectelor nu permite să se ţină pasul cu acest progres datorită costurilor aferente si al utilităţii. Din punct de vedere al businessului, actualizarea tehnologică nu este un motiv suficient de puternic care să determine pe proprietari să reinvestească în modernizarea aplicaţiei atâta timp cât fluxul de date este conform cu cerinţele. Discrepanţa dintre paradigmă dezvoltatorilor şi nevoile proiectelor determină apariția unei rupturi. Întrebarea este dacă această discrepanţă este justă şi dacă există modalităţi de depăşire a inconvenientului.
În aproape două decenii de experienţă, am văzut o atitudine generalizată faţă de proiectele legacy, dominate de apatie, dezinteres, existând situaţii când dezvoltatorii au decis chiar să îşi schimbe locul de muncă din cauza proiectelor pe care lucrau.
Fiecare tehnologie a reprezentat o tentaţie pentru cei care au îmbrăţişat-o, la momentul apariţiei ei, ca la un interval de câţiva ani gradul de depreciere a popularităţii să determine masele de developeri să evite complet acele tehnologii. Acest tip de atitudine este mai accentuată în rândul developerilor cu o experienţă mai mică de zece ani.
O prima măsură care se poate adopta în contactul cu aplicaţiile de tip legacy este Test Driven Development. Această paradigmă obligă remodelarea aplicaţiei în câteva segmente importante ale ei. Am întâlnit proiecte în care organizarea obiectuală lipsea, astfel că adoptarea unei paradigme Test Driven este realmente dificilă şi necesită restructurarea proiectului.
Pregătirea şi organizarea unei aplicaţii să permită folosirea TDD-ului este un pas proactiv şi totodată un unul important înțelegerea codului. Test Driven Development este o paradigmă de programare care poate elimina cu uşurinţă monotonia, apatia din activitatea dezvoltatorului provocându-l la o participare activă în realizarea codului.
Un alt element important este asigurarea robusteții aplicaţiei. Odată cu adoptarea paradimei TDD, o prima consecinţă importantă este ancorarea codului prin teste. Evident TDD este o paradigmă de dezvoltare şi nu o sesiune de implementare de teste. Cu toate acestea, ca obiectiv secundar, testele vor asigura integritatea blocului de cod realizat.
Pe plan subiectiv, prin abordarea unei astfel de paradigme de programare, dezvoltatorul îşi va forma o nouă viziune asupra procesului de programare. Va reuşi astfel să înţeleagă necesitatea folosirii unui întreg pachet de tehnici de programare care nu este atât de evident valorificând viziunea clasică. Granularizarea diverselor segmente de cod, definirea riguroasă a ideii de bază a fiecărei clase, separarea şi sistematizarea ideilor dezvoltate în clase devin mult mai clare.
Consider că un programator poate ieşi din rutina plictisitoare de scriere de cod prin adoptarea programării TDD. Test Driven Development deschide un câmp larg imaginaţiei, astfel că programatorul poate percepe implementarea într-un mod diferit.
Un dezvoltator este nevoit să găsească alternative de adaptare la orice tip de tehnologiei şi la orice proiect. Contactul cu un număr mare de proiecte este un deschizător de drumuri, în schimb acest aspect este apanajul unei experienţe îndelungate şi a multor oportunităţi în care s-a putut dezvolta liber personalitatea programatorului. Mediul de formare al dezvoltatorilor moderni constrânge deciziile acestora la un şablon predefinit al aplicaţiilor. Provocarea majoră a acestui tip de proiecte este doar de asimilare și respectare a unui tipar, programatorul fiind astfel privat de luarea deciziilor importante, căutarea soluţiilor tehnologice, cât şi alegerea mecanismelor optime. Un programator cu o astfel de pregătire nu înţelege "de ce"-urile, nu simte tensiunea care stă la baza deciziilor importante.
În perioada în care s-a format J.B. Rainsberger existau momente în care programatorul devenea un personaj cheie. Creativitatea era foarte bine stimulată de situaţii extreme. În prezent, foarte puţini programatori au privilegiul să scrie în portofoliul lor momente cu adevărat de neuitat. Mulţi candidaţi la interviuri nu ştiu ce răspuns să dea la întrebări legate de momente şi proiecte cheie din viaţă lor. Monotonia realizării unei liste de funcţionalităţi transformă activitatea programatorului într-una de rutină, în care doar salariul reprezintă singurul stimulent activ. Cred că trebuie să formăm programatori a căror spirit de aventură să fie viu, programarea să reprezinte una din cele mai tentante profesii, așa cum era odinioară.
de Ovidiu Mățan
de Vlad But
de Maria Revnic
de Delia Mircea
