Ce estearea agila

Ce estearea agila

1. Ce nu este in regula cu softul?

2. Defectele de proiectare - mirosurile unui soft in putrefactie

2.1. Ce stimuleaza defectele softului?

2.2. Echipele agile nu permit aparitia defectelor softului

3. Programul 'Copy'

3.1. Proiectul agil al exemplului Copy

3.2. Cum stiu dezvoltatorii agili ce trebuie facut?

4. Mentinerea proiectului cat mai bun posibil

5. Concluzie

6. Bibliografie

Motto

Dupa revizuirea ciclului de dezvoltare a softului asa cum il inteleg eu, am ajuns

la concluzia ca singura documentatie soft care satisface cerintele unui proiect

ingineresc este listingul cu cod sursa.

Jack Reeves

In 1992, Jack Reeves a scris un articol remarcabil in C++ Journal, numit 'What is Software Design'. In articol, el afirma ca proiectul unui sistem soft este documentat in primul rand de codul sau sursa. Diagramele ce reprezinta codul sursa sunt ancillary la proiect si nu reprezinta proiectul insusi. Asa cum s-a dovedit ulterior, articolul lui Reeves a fost unul dintre fundamentele dezvoltarii agile.

In paginile ce urmeaza, vom vorbi adesea despre 'Proiect'. Acesta nu trebuie considerat ca o multime de diagrame UML separate de cod. Multimea de diagrame UML poate reprezenta parti ale proiectului, dar nu proiectul in ansamblul sau. Proiectul unui produs software este un concept abstract. El se refera la forma si structura generala a programului, ca si la forma si structura de detaliu a fiecarui modul, fiecarei clase si metode. El se poate reprezenta pe diverse suporturi, dar incarnarea sa finala este codul sursa. Finalmente, codul sursa este proiectul.

1. Ce nu este in regula cu softul?

Daca esti norocos, incepi un proiect cu o imagine clara asupra a ceea ce trebuie sa fie sistemul ce se realizeaza. Proiectul sistemului este o imagine vitala in mintea ta. Daca esti si mai norocos, claritatea proiectului se pastreaza la prima realizare a sa.

Pe urma, ceva nu merge cum ar trebui. Softul incepe sa miroasa ca o bucata de carne stricata. Pe masura ce se scurge timpul, lucrurile merg tot mai rau. In cod se acumuleaza defectele, facandu-l din ce in ce mai greu de intretinut. Incercarea de efectuare a unei modificari simple devine asa de greoaie, ca seful de proiect cere reproiectarea.

Astfel de reproiectari reusesc rareori. Cu toate ca proiectantii incep reproiectarea cu cele mai bune intentii, ei descopera ca incearca sa traga intr-o tinta in miscare. Sistemul vechi continua sa evolueze si sa se schimbe, iar noul proiect trebuie sa tina cont de aceasta evolutie. Inainte de producerea primei realizari a noului proiect, acesta va avea deja incluse in el o serie de defecte de proiectare.

2. Defectele de proiectare - mirosurile unui soft in putrefactie

Softul este putred cand incepe sa aiba urmatoarele tipuri de defecte

Rigiditate Rigidity) - Proiectul este dificil de modificat deoarece orice modificare produce nevoia unor alte schimbari in alte parti ale sistemului.

Fragilitate Fragility) - Modificarile efectuate produc defecte ale sistemului in locuri care nu au nici o relatie conceptuala cu locul in care s-au facut modificarile

Imobilitate Immobility) - Este dificil sa se divizeze sistemul in componente care sa se reutilizeze in alte sisteme

Viscozitate Viscosity) - Este mai dificil sa se faca lucrurile asa cum trebuie si este mai usor sa se faca lucrurile prost

Complexitate nenecesara Needless Complexity) - Proiectul contine infrastructura care nu aduce nici un beneficiu

Repetitie nenecesara Needless Repetition) - Proiectul contine structuri repetate care se pot unifica sub o singura abstractizare

Opacitate Opacity) - Este greu de citit si inteles. Nu-si exprima satisfacator intentiile sale.

Rigiditatea. Rigiditatea este tendinta softului de a fi dificil de modificat, chiar si in situatii simple. Un proiect este rigid daca o singura modificare produce o cascada de modificari in modulele dependente. Cu cat sunt mai multe module in care trebuie sa se faca modificari, cu atat proiectul este mai rigid.

Multi dezvoltaori se confrunta cu aceasta situatie, in diverse variante. Lor li se cere sa faca ceea ce pare la inceput o modificare simpla. Ei analizeaza modificarea ceruta si fac o estimare rezonabila a muncii necesare. Ma tarziu insa, in timpul lucrului pentru efectuarea modificarii, se descopera ca aceasta are repercursiuni care nu au fost anticipate. Este nevoie de analiza unor mari portiuni de cod pentru a analiza efectul modificarii in ele; este nevoie de modificarea a mult mai multor module decat s-a estimat initial. In final, modificarile necesare dureaza mult mai mult decat estimarea initiala. Cand sunt intrebati de ce a fost asa de imprecisa estimarea initiala, ei repeta lamentatia traditionala a dezvoltatorilor de soft: 'A fost mult mai complicat decat am crezut'.

Fragilitatea. Fragilitatea este tendinta unui program de a 'crapa' in mai multe locuri dupa efectuarea unei singure modificari. Deseori, defectele apar in zone care nu au nici o relatie conceptuala cu zona in care s-a facut modificarea. Rezolvarea unei probleme creeaza mai multe alte probleme, iar echipa de dezvoltare incepe sa semene cu un caine care-si vaneaza coada.

Pe masura ce fragilitatea unui modul creste, sansele ca o modificare sa provoace defecte neasteptate ajung aproape de certitudine. Desi pare absurd, astfel de situatii nu sunt rare. Astfel de module sunt cele care sunt candidate constante la reparare, cele care nu lipsesc de pe lista de defecte, cele despre care dezvoltatorii stiu ca trebuie reproiectate (insa nimeni nu doreste sa se ocupe de reproiectarea lor), cele care devin mai proaste pe masura ce se inlatura defectele din ele.

Imobilitatea. Un proiect este imobil cand el contine parti care ar putea fi utile in alte sisteme, dar efortul si riscurile implicate de separarea (extragerea) acestor parti din sistemul initial sunt prea mari. Aceasta situatie nefericita se intalneste frecvent.

Viscozitatea. Viscozitatea vine in doua forme: viscozitatea softului si viscozitatea mediului.

Cand sunt confruntati cu o modificare, de obicei dezvoltatorii gasesc mai multe moduri de efectuare a acesteia. Unele dintre modalitati conserva proiectul, altele nu (adica sunt hack-uri, trucuri). Cand modalitatile care conserva structura proiectului sunt mai greu de aplicat decat trucurile, se spune ca viscozitatea proiectului este mare. Este mai usor sa faci un lucru nepotrivit si mai dificil sa faci ceea ce trebuie. Dorim sa proiectam softul astfel ca modificarile care conserva structura proiectului sa fie usor de facut.

Viscozitatea mediului apare atunci cand mediul de programare este lent si ineficient. De exemplu, daca timpii de compilare sunt foarte mari, atunci dezvoltatorii vor fi tentati sa faca doar acele tipuri de schimbari care nu produc recompilarea multor module, chiar daca respectivele schimbari nu conserva proiectul. Daca sistemul de control al codului sursa are nevoie de ore pentru a verifica cateva fisiere, atunci dezvoltatorii vor fi tentati (fortati) sa faca acele schimbari care necesita cat mai putine verificari, fara a tine cont de conservarea proiectului.

In ambele situatii, proiectul este viscos daca proiectul softului este dificil de conservat. Dorim sa cream sisteme si medii de proiect care fac simpla conservarea proiectului.

Complexitatea inutila. Un proiect contine complexitate inutila cand el contine elemente care nu sunt utile in contextul curent. Aceasta se intampla frecvent cand dezvoltatorii anticipeaza schimbarile cerintelor si includ in soft elemente care sa opereze cu aceste modificari potentiale. La prima vedere, aceasta pare un lucru pozitiv. Pregatirea proiectului pentru viitoarele modificari trebuie sa pastreze flexibilitatea codului si sa previna cosmarele ulterioare generate de astfel de modificari.

Din pacate, efectul prevederii este deseori opus celui anticipat. Prin pregatirea prea multor planuri de contingenta, proiectul devine mazgalit cu constructii ce nu vor fi folosite niciodata. O parte dintre pregatiri se vor dovedi utile, insa majoritatea vor fi doar un balast. Efectul este ca proiectul va include greutatea acestor elemente de proiectare nefolosite. Aceasta face softul complex si greu de inteles.

Repetitia inutila. Operatiile de Copy-and-Paste pot fi foarte utile intr-un editor de texte, insa ele pot fi operatii dezastruoase de de editare de cod. Mult prea frecvent, sistemele soft sunt construite pe zeci si sute de elemente de cod care se repeta. O posibila situatie este urmatoarea:

R are nevoie sa scrie cod pentru a face sarcina S in modulul M. El parcurge celelalte module ale codului pentru a descoperi unde se mai face sarcina S. O astfel de secventa de cod este gasita in modulul M', se copiaza in modulul M si apoi face modificarile necesare.

Fara ca R sa stie, codul pentru sarcina S din modulul M' a fost scris de T, care la randul sau l-a copiat dintr-un alt modul, M', scris de L. L a fost primul care a scris cod pentru sarcina S, si el a constatat ca sarcina S este foarte asemanatoare cu S', pentru care exista deja cod scris. L a preluat prin copiere respectivul cod, l-a pus in modulul M' si apoi l-a modificat corespunzator.

Cand acelasi cod apare mereu si mereu, in forme care difera putin una fata de alta, dezvoltatorii au o abstractizare mai putin. Gasirea tuturor repetitiilor si inlocuirea lor cu o abstractizare adecvata este o operatie nici usoara, nici placuta. Daca se foloseste abstractizarea, efectul este cresterea gradului de intelegere si de intretinere a sistemului.

Cand in sistem exista cod redundant, modificarea sistemului devine ardenta. Bug-urile gasite intr-o astfel de repetitie trebuie eliminate din toate repetitiile. Mai mult, deoarece fiecare repetitie este usor diferita de celelalte, sarcina inlaturarii bug-ului nu este nici usoara, nici aceeasi.

Opacitatea. Opacitatea este tendinta unui modul de a fi greu de inteles. Codul se poate scrie intr-o maniera clara si expresiva. La fel de bine, el se poate scrie intr-o maniera opaca si lipsita de expresivitate. Codul care evolueaza in timp tinde sa devina din ce in ce mai opac, pe masura ce inainteaza in varsta. Pentru a mentine opacitatea la minim, este nevoie de o preocupare constanta pentru pastrarea claritatii si expresivitatii codului.

La crearea unui nou modul, codul pare sa fie clar pentru cel care l-a scris. Aceasta trasatura este evidenta pentru cel implicat in conceperea modulului, deoarece el il intelege in cele mai mici amanunte. Mai tarziu, cand se lucreaza la alte module, si contactul intim cu modulul in cauza se pierde, o reparcurgere a codului din modul poate sa conduca la alte concluzii, de genul 'Cum am putut scrie asa ceva?' Pentru a preveni astfel de situatii, programatorii trebuie sa se transpuna in pielea altora care au de-a face cu modului si sa faca un efort constant pentru refactorizarea codului, astfel ca acesta sa devina usor de inteles de catre altii. Este utila, in acest context, revizuirea codului de catre altii.

2.1. Ce stimuleaza defectele softului?

In mediile non-agile, proiectele se degradeaza deoarece cerintele se modifica in moduri neanticipate de proiectul initial. Adesea, modificarile trebuie efectuate repede, si de catre persoane care nu sunt familiarizate cu filosofia proiectului initial. In consecinta, cu toate ca modificarile efectuate in soft raspund cerintelor, ele violeaza cumva proiectul initial. Putin cate putin, pe masura ce se fac noi si noi modificari, violarile se acumuleaza si proiectul incepe sa aiba 'miros neplacut'.

Cu siguranta, nu trebuie sa blamam modificarea (evolutia) cerintelor drept cauza a degradarii proiectului. In calitate de dezvoltatori de soft, noi trebuie sa fim complet constienti de evolutia (naturala) a cerintelor. In loc sa blamam aceasta evolutie, trebuie sa constientizam faptul ca cerintele reprezinta cel mai volatil element al proiectului. Daca proiectele esueaza din cauza unei ploi constante de cerinte ce se modifica, greseala apartine proiectelor si modalitatilor de proiectare. Trebuie gasita o modalitate de a face proiectele rezistente la astfel de modificari.

2.2. Echipele agile nu permit aparitia defectelor softului

Echipa agila se bazeaza pe modificari. Ea investeste putin pentru a anticipa, prin urmare nu este preocupata de imbatranirea unui proiect initial. In loc de a face asta, echipa mentine proiectul curent cat mai curat si mai simplu posibil, sprijinind aceste calitati cu o multime de teste unitare si de acceptare. Astfel, proiectul este pastrat flexibil si usor de modificat. Echipa foloseste avantajul flexibilitatii pentru a imbunatati continuu proiectul, astfel ca fiecare iteratie se termina cu un sistem al carui proiect este cat mai potrivit pentru cerintele acelei iteratii.

3. Programul 'Copy'

Observarea modului in care un proiect se degradeaza ilustreaza discutia de mai sus. Sa zicem ca seful tau vine devreme intr-o dimineata de luni si-ti cere sa scrii un program care copiaza caractere de la tastatura la imprimanta. Facand cateva exercitii mentale in cap, ajungi la concluzia ca programul nu va avea mai mult de 10 linii de cod sursa, si ca proiectarea si codificarea nu vor dura mai mult de o ora. Daca ai folosi tot ce scrie la carte, adica intalnirile de grupuri inter-functionale (cross-functional group meetings), intalnirile de educare pentru calitate (quality education meetings), intalnirile zilnice de evaluare a progresului (daily group progress meetings) si cele trei crize curente din domeniu (the three current crises in the field), terminarea programului ar avea nevoie de o saptamana - daca ai face ore suplimentare. De regula, tu inmultesti estimarile cu trei.

'Trei saptamani', ii spui sefului. Acesta accepta si te lasa sa-ti faci munca.

Proiectul initial. Chiar acum ai un pic de timp, inainte de inceperea intalnirii de revizuire a procesului, asa ca decizi sa schitezi un proiect pentru program. Folosind proiectarea structurata, trasezi diagrama din figura 1.

Figura 1. Diagrama de structura a programului Copy

Aplicatia are trei module (subprograme). Modulul Copy le apeleaza pe celelalte doua. El preia cate un caracter din modulul Read Keyboard si-l transmite modulului Write Printer

Te uiti la proiect si vezi ca e bun. Zambesti satisfacut si parasesti biroul pentru a merge la intalnire. Din pacate, una dintre crizele domeniului s-a acutizat peste noapte si a trebuit sa mergi in laborator pentru a ajuta la depanarea unui bug. La masa de pranz, pe care o iei la 3 dupa masa, ajungi sa scrii codul pentru modulul Copy, iar rezultatul este dat in listingul 1.

Chiar cand faci salvarea descoperi ca esti pe punctul de a intarzia la o intalnire pe teme de calitate. Stii ca este una importanta: se vorbeste desppre magnitudinea defectelor zero. Asa ca renunti la mancare si cola si te indrepti spre sala unde se tine.

Miercuri vii iar mai devreme si se pare ca ai timp sa te ocupi de program. Iei fisierul sursa cu programul Copy si il compilezi. Din prima se compileaza fara erori! Este un fapt pozitiv, deoarece seful te cheama la o intalnire neplanificata referitoare la economisirea tonerului la imprimantele laser.

Joi, dupa patru ore de conversatie telefonica cu un tehnician din Rocky Mount, Carolina de Nord, facand depanarea la distanta a uneia dintre cele mai obscure componente ale sistemului, ajungi sa testezi programul Copy. Din prima, functioneaza! E un lucru pozitiv, mai ales ca studentul practicant tocmai a ras directorul cu sursele de pe server, asa ca ai de cautat ultimele salvari pe banda ca sa-l refaci cat de cat. Desigur, ultima salvare completa s-a facut acum trei luni, dupa care sunt facute 94 de salvari incrementale pe care trebuie sa le restaurezi dupa ce ai restaurat salvarea completa.

Pentru vineri n-ai planificat nimic. E bine, deoarece iti trebuie toata ziua sa incarci cu succes programul Copy in sistemul de control al codului sursa.

Evident, programul este un mare succes, fiind instalat in toate departamentele din firma. Reputatia ta de as in programare s-a confirmat inca odata si te bucuri de pretuirea celor din jur. Cu putin noroc, anul asta ai putea scrie 30 de linii de cod.

Cerintele care se modifica. Cateva luni mai tarziu, seful vine si iti spune ca unii doresc ca programul Copy sa poata citi caractere si de la cititorul de banda perforata. Incepi sa te minunezi de ce oamenii modifica cerintele tot timpul. Programul Copy n-a fost proiectat pentru cititorul de banda perforata! Iti atentionezi seful ca astfel de modificari distrug eleganta proiectului. Fara succes, seful este de neclintit. El spune ca utilizatorii doresc cu adevarat ca uneori sa citeasca caractere de la cititorul de banda perforata.

N-ai ce face, te apuci sa planifici schimbarile. Ar trebui adaugat un parametru boolean functiei Copy. Daca este true, citirea se face de la cititorul de banda perforata; daca este false, citirea se face de la tastatura, ca mai inainte. Din nefericire, sunt acum multe alte programe care folosesc programul Copy, asa ca nu este permisa modificarea interfetei (a modului de apel). Daca s-ar modifica interfata programului Copy, toti clientii acestuia (programele care-l folosesc) ar trebui modificati (secventa de apel), recompilati si retestati. Cei de la testare te-ar linsa, ca sa nu mai amintim de cei sapte indivizi de la grupul de control al configuratiilor. Iar politia procesului ar avea o zi de teren in care sa forteze toate tipurile de revizuiri de cod pentru fiecare modul client al lui Copy

Prin urmare iese din discutie modificarea interfetei. Insa cum sa facem cunoscut programului Copy ca el trebuie sa citeasca de la cititorul de banda perforata? Exista o solutie cunoscuta: folosirea unei variabile globale (unui parametru global)! Aceasta impreuna cu operatorul conditional ternar din C. Listingul 2 prezinta rezultatul.

Clientii lui Copy care doresc sa citeasca de la cititorul de banda perforata trebuie sa seteze prima data variabila globala ptFlag la true. Apoi ei pot apela Copy, care va citi de la cititorul de banda perforata. Dupa ce Copy si-a terminat executia, variabila globala ptFlag trebuie resetata la false. Daca n-ar face asta, urmatorul client nu va sti ca in contextul curent Copy va citi de la cititorul de banda perforata, si nu de la tastatura (cum se considera implicit). Pentru a reaminti programatorilor clienti acest lucru, ai adaugat un comentariu pertinent dupa declaratia indicatorului ptFlag

Ca de obicei, softul produs de tine este apreciat, chiar mai mult decat inainte, iar o multime de programatori client sunt nerabdatori sa-l foloseasca. Viata-i frumoasa.

Da-le un deget (si ei iti iau toata mana). Dupa cateva saptamani, vine seful (care ti-a ramas sef in ciuda a trei reorganizari petrecute in firma in tot atatea luni) si-ti spune ca utilizatorii ar dori ca programul Copy sa aiba uneori iesirea nu pe imprimanta, ci pe perforatorul de banda.

Clientii! Ei ruineaza intotdeauna proiectele tale! Dezvoltarea de soft ar fi mult mai usoara daca n-ar fi clienti!

Ii spui sefului ca schimbarile cerute au un efect negativ profund asupra elegantei proiectului. Il avertizezi ca daca cererile de modificare continua in acest ritm, softul va fi imposibil de intretinut inca inainte de terminarea anului. El da din cap ca un cunoscator ce este, si-ti spune ca modificarea este obligatorie.

Modificarea proiectului este similara cu cea anterioara. Ai nevoie de o alta variabila globala si de alt operator conditional ternar. Listingul 3 prezinta rezultatul.

Esti incantat indeosebi de faptul ca ti-ai adus aminte ca trebuie sa schimbi si comentariul. Continui sa fii ingrijorat de faptul ca structura programului se deterioreaza. Orice alta modificare a dispozitivului (perifericului) de intrare sau de iesire va forta o restructurare completa a conditiei din ciclul while. Poate ca-i timpul sa-ti scuturi de praf CV-ul.

Asteapta modificarile. Sa fii pregatit pentru modificari. Te las sa hotarasti singur cat din cele de mai sus este exagerare satirica. Scopul povestii a fost sa ilustreze cat de repede se degradeaza proiectul (structura) unui program in prezenta modificarilor. Proiectul original al programului Copy a fost simplu si elegant. Dupa doar doua modificari, el a inceput sa expuna semne de rigiditate fragilitate imobilitate complexitate redundanta si opacitate. Este evident ca tendinta va continua si ca programul va deveni o gramada de cod nestructurat.

Am putea sa stam si sa criticam modificarile care strica structura programului. Ne-am putea plange ca programul a fost bine proiectat pentru specificatiile initiale, insa cerintele ulterioare au provocat degradarea proiectului. Insa astfel am ignora unul dintre cele mai proeminente adevaruri ale dezvoltarii de soft: cerintele se modifica tot timpul!

Sa ne reamintim ca cerintele se numara printre cele mai volatile elemente ale unui proiect soft. Ele sunt continuu intr-o stare de flux si acesta trebuie sa fie un fapt acceptat de noi, dezvoltatorii. Traim intr-o lume a cerintelor care se schimba, iar sarcina noastra este sa fim siguri ca softul produs de noi va supravietui acestor schimbari. Daca structura programului (proiectul) se degradeaza datorita schimbarii cerintelor, inseamna ca n-am fost agili, deci vina este a noastra!

3.1. Proiectul agil al exemplului Copy

O dezvoltare agila ar putea incepe exact cu codul din listingul 1. Cand seful a cerut modificarea programului Copy pentru ca acesta sa preia caractere si de la cititorul de banda perforata, proiectul trebuia modificat astfel ca el sa reziste unor asemenea modificari viitoare. Rezultatul ar putea fi cel ilustrat in listingul 4.

In loc sa 'carpeasca' proiectul pentru a face posibila realizarea noii cerinte, echipa agila a exploatat sansa imbunatatirii proiectului, astfel ca acesta sa ramana in viitor neafectat de alte cerinte de acest gen (alte periferice de intrare). De acum inainte, ori de cate ori seful vine cu o cerinta privitoare la alt periferic de intrare, echipa va fi apta sa o implementeze fara modificarea (degradarea) programului Copy

Echipa a respectat principiul OCP (Open-Closed Principle), care va fi discutat mai incolo. Conform acestuia, modulele trebuie astfel proiectate incat (functionalitatea lor) sa se poata extinde fara a le modifica codul sursa. Asta este exact ce a facut echipa agila. Fiecare nou periferic de intrare cerut de sef se poate proiecta fara a modifica programul (modulul) Copy

Sa observam ca echipa n-a incercat sa anticipeze cum ar trebui modificat programul la prima proiectare a acestuia. In loc de a face asta, s-a incercat sa se scrie cod cat mai simplu care sa rezolve problema. Numai atunci cand cerintele se modifica se va modifica si proiectul (structura) modulului, in ideea de a-l face rezistent la respectivul gen de modificari.

S-ar putea afirma ca echipa a facut numai jumatate din munca. Daca s-a gandit o protectie la modificarea perifericului de intrare, de ce nu s-a facut acelasi lucru si pentru perifericul de iesire? Raspunsul este ca echipa n-are idee acum despre posibila diversificare a perifericelor de iesire. Daca s-ar adauga si astfel de protectie acum, fara sa fie nevoie de ea, ar fi nevoie de munca suplimentara care nu serveste scopurilor curente. Este clar ca daca o asemenea protectie ar fi nevoie in viitor, ea va fi usor de adaugat la cerere. Prin urmare, n-avem nici un motiv s-o luam acum in considerare.

3.2. Cum stiu dezvoltatorii agili ce trebuie facut?

Dezvoltatorii agili din exemplul de mai sus au construit o clasa abstracta pentru a proteja programul Copy de modificarea perifericului de intrare. De unde au stiut ei sa faca asa ceva? Aceasta tine de una dintre aspectele fundamentale ale proiectarii orientate pe obiecte.

Proiectul initial (structura initiala) a programului Copy este inflexibila, rigida, datorita directiei dependentelor sale. Sa reconsideram figura 1, unde se remarca faptul ca modulul Copy depinde direct de modulele KeyboardReader si PrinterWriter. In aplicatie, modulul Copy este un modul de nivel mai inalt, el stabilind politica aplicatiei, in cazul nostru stiind cum se copiaza caracterele. Din nefericire, el a fost facut dependent de detaliile de nivel jos ale tastaturii si imprimantei. Ori de cate ori aceste detalii de nivel jos se modifica, este afectata politica de nivel inalt.

Odata ce lipsa de flexibilitate a iesit la iveala, dezvoltatorii agili vor sti ca dependenta modulului Copy de perifericul de intrare trebuie inversata, in asa fel incat Copy sa nu depinda pe viitor de perifericul de intrare. Apoi se foloseste sablonul STRATEGY pentru a crea inversiunea dorita.

Pe scurt, dezvoltatorii agili stiu ce au de facut deoarece:

Au detectat problema (dificultatea) prin folosirea practicilor agile;

Au diagnosticat problema prin aplicarea principiilor de proiectare; si

Au rezolvat problema prin aplicarea unui sablon de proiectare adecvat.

Comunicarea dintre aceste trei aspecte ale dezvoltarii de soft este proiectarea propriu-zisa.

4. Mentinerea proiectului cat mai bun posibil

Dezvoltatorii agili incearca sa mentina proiectul cat mai adecvat si mai curat posibil. Aceasta nu este o activitate permanenta sau hazardata.Ei nu 'curata' proiectul la fiecare cateva saptamani. In schimb, ei pastreaza softul cat mai curat, simplu si expresiv posibil, in fiecare moment. Nu spun niciodata: 'vom reveni si vom rezolva cutare problema mai tarziu'. Nu lasa niciodata degradarea sa inceapa.

Atitudinea pe care o au dezvoltatorii agili fata de soft este exact atitudinea chirurgilor fata de procedurile de sterilizare. Aceste proceduri de sterilizare fac posibila operatia chirurgicala. Fara ele, riscul de infectie este prea mare pentru a putea fi tolerat. Dezvoltatorii agili se comporta la fel fata de proiectele lor. Riscul de a permite sa inceapa cea mai usoara degradare este prea mare pentru a fi tolerat.

Proiectul (structura programului) trebuie sa ramana curat(a), si deoarece codul sursa este cea mai importanta expresie a sa, codul sursa trebuie sa ramana curat. Profesionalismul dicteaza ca noi, in calitate de dezvoltatori de soft, nu putem tolera degradarea softului.

5. Concluzie

Ce este prin urmare proiectarea agila? Proiectarea agila este un proces, nu un eveniment. Ea este aplicarea continua a principiilor, sabloanelor si practicilor cu scopul de a imbunatati structura si nivelul de intelegere (lizibilitate, readability) a softului (codului sursa). Ea este aplecarea spre pastrarea proiectului sistemului cat mai simplu, curat si expresiv este posibil la fiecare moment de evolutie a acestuia.

In capitolele urmatoare se vor investiga principiile si sabloanele de proiectare a softului. Pe masura ce le citesti, sa-ti amintesti ca un dezoltator agil nu aplica aceste principii si sabloane la un proiect mare, general. In schimb, ele se aplica de la iteratie la iteratie intr-o incercare de a pastra curat codul si proiectul pe care acesta il inglobeaza.

6. Bibliografie

Reeves, Jack. What Is Software Design? C++ Journal, Vol. 2, No. 2, 1992. URL: https://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

Vezi The Dependency Inversion Principle, ch. 11

Vezi ch 14.