ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 147
Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 47
Abonament PDF

“Legacy code” și modul în care un developer poate depăși neajunsurile existente

Romulus Bucur
Senior developer & PM @Siemens



PROGRAMARE

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.

Nevoia creării unui cod robust - "building on green"

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.

Codul moştenit (legacy code)

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.

Test Driven Development - o alternativă viabilă

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.

Concluzii

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ă.

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects