Evoluția profesională a unui dezvoltator software parcurge de obicei următoarele etape: programator junior, programator senior, lider tehnic sau de echipă, uneori arhitect și apoi manager. Această cale este paradoxală: cariera care începe prin a scrie cod se transformă în a nu mai scrie deloc cod. De altfel, cum ai putea să te ții la curent cu toate noutățile care apar în fiecare an în tehnologie?
O nouă schemă a evoluției mult mai interesantă pentru programatorii pasionați, a ieșit la suprafață în anii recenți. Acest articol își propune să evidențieze tocmai aceste noi tipuri de evoluție ilustrate de programatori care încă scriu cod și îi pot ajuta pe alții chiar la 40, 50 sau 60 de ani. Robert C. Martin. Michael Feathers. Rebecca Wirfs-Brock. De ce sunt ei diferiți? Cum pot să se țină la zi cu schimbările din tehnologie?
Când a fost inventat unit testing-ul? Test Driven Development? Folosirea abstracțiilor pentru design ușor de modificat? Principiile SOLID?
Toate par a fi noi. Cărțile despre ele au fost publicate în ultimii zece ani. Dar sunt cu adevărat noi?
Barbara Liskov a avut la QCon 2013 keynote-ul intitulat "The Power of Abstraction". În keynote, ea analizează conversațiile inițiale pe care o comunitate mică de programatori le-a avut despre design modificabil în anii "70. Tot în aceeași perioadă, ea a dat numele unuia din principiile SOLID, "Liskov Substitution Principle", printr-o remarcă scrisă pe un bulletin board. Acum 40 de ani! 40 de ani au trecut de când unul dintre principiile de bază din designul OOP a fost formulat și pe care milioane de programatori îl folosesc de atunci în fiecare zi. 40 de ani de când abstracțiile au fost introduse pentru a permite design ușor de modificat.
Dar poate și alte aspecte din tehnologie sunt revoluționare. Serviciile web sunt o idee nouă, nu? Sau arhitectura REST?
E adevărat că anumite lucruri au trebuit să se întâmple pentru ca serviciile web să apară. O nevoie de business. Standardizare. Expansiunea web-ului. Dar, dacă ne uităm atent la serviciile web, ideea de design din spatele lor este următoarea: Compunem funcționalitate complexă din componente mici care fac un lucru bine și comunică între ele prin mesaje text. Ciudat! Dar această idee a fost enunțată în anii "70 în cadrul principiilor de design UNIX:
"Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Composition: Design programs to be connected to other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do."
Dar serviciile REST? Expunerea resurselor folosind un set limitat de operații oferit de protocolul http? Cu siguranță, această idee a apărut în ultimii ani. Sugestive sunt în acest sens opiniile lui Alan Kay, unul din fondatorii Object Oriented Programming, a avut de spus despre această paradigmă:
"M-am gândit la obiecte ca fiind celule biologice și/sau calculatoare individuale într-o rețea, capabile doar să comunice prin mesaje (deci mesajele au apărut la început de tot) - ne-a luat mult timp să ne dăm seama cum putem trimite mesaje într-un limbaj de programare într-un mod destul de eficient încât să fie util."
"Fiecare obiect ar trebui să aibă un URL"
Al doilea citat este dintr-o prezentare din 1993. Serviciile REST, într-o propoziție scurtă, acum 20 de ani.
Dacă fundamentele tehnologiei nu se modifică, atunci ce anume se schimbă?
Acum douăzeci de ani, dacă un programator trebuia să implementeze o comunicare între două obiecte pe rețea, reușita acestei operații era condiționată nu numai de multă pricepere ci și de multă magie. O tehnologie (sperăm uitată) numită CORBA era modul standard de a o implementa. Programatorul trebuia să o înțeleagă, să scrie cod într-un anumit mod, să repare problemele care apăreau și multe altele. Un task de acest gen consuma foarte mult timp, în afară de cazul în care programatorul era capabil să vizualizeze octeții care erau transmiși între procese.
Azi, modul standard de a implementa acest task este de a scrie un serviciu web cu o interfață bine definită, un lucru pe care orice programator îl poate implementa în câteva ore (presupunând că funcționalitatea este simplă). Programatorul nu are idee cum se realizează comunicarea între procese (în afara cazului în care vrea să afle), doar că funcționează atunci când codul este scris într-un anumit fel.
Acum cincisprezece ani, scrierea unui mic program cerea cunoștințe despre modul în care este alocată memoria. Acest lucru genera multe zile de investigații pentru erori cu mesaj foarte de "ajutor", "memory corruption error: #FFFFFF". Azi, majoritatea programatorilor au uitat despre pointer-i și alocarea dinamică a memoriei, pentru că limbajul de programare și platforma au preluat această funcționalitate.
Schimbarile din tehnologie sunt rareori fundamentale. Cel mai des se modifică implementarea. Iar implementarea devine tot mai simplă în timp. Dar dacă implementarea se simplifică, de ce avem în continuare probleme în dezvoltarea de aplicații?
Definiția noastră pentru arhitectură este "când programarea se întâlnește cu lumea reală". Codul este pur, repetabil, de încredere. Calculatorul nu dă două răspunsuri diferite la aceeași întrebare, decât dacă este programat să o facă.
Lumea reală este diferită. Nu toată lumea folosește același format de dată, calendar sau alfabet. Ora se schimbă în funcție de fusul orar și la viteze relativiste. Server-ele se opresc. Rețelele nu mai funcționează.
Dificultatea fundamentală a programării a fost întotdeauna de a traduce cerințe ambigue în cod foarte precis, rezistent la surprizele din lumea reală. Dar, pentru mulți ani, această dificultate fundamentală a fost ascunsă sub detalii de implementare. Programatorii aveau destule probleme legate de alocarea de memorie și comunicarea pe rețea încât era dificil să se pună fața în față cu lumea reală. De aceea, mulți erau protejați de ea.
O dată ce implementarea s-a simplificat, dificultatea fundamentală a programării a devenit vizibilă. Azi vorbim mai puțin despre comunicarea între servicii și mai mult despre design modificabil, pentru că schimbarea face parte din lumea reală. Azi vorbim mai puțin despre alocarea de memorie și mai mult despre testare unitară, pentru că toată lumea face greșeli în lumea reală.
Aceasta ne aduce la concluzia:
Tehnologiile se modifică. Dar fundamentele programării nu s-au modificat în ultimii douăzeci de ani. Probabil că nu se vor modifica dramatic în următorii zece ani. Dacă vrei să fii în contact cu programarea ani buni de-acum înainte, precum Robert C. Martin, Michael Feathers sau Rebecca Wirfs-Brock, iată ce trebuie să faci:
Stăpânește fundamentele programării și abilitățile asociate, nu doar tehnologia în care lucrezi azi.
Acest lucru nu înseamnă ca poți ignora platforma pe care o folosești, ci să înțelegi că este doar o unealtă care te ajută să îți faci treaba: traducerea cerințelor ambigue în cod ușor de modificat, funcțional, precis și gata să dea piept cu lumea reală.
Am menționat în articol câteva abilități independente de tehnologie. Am compilat aici o listă care nu are cum să fie completă, dar credem că este un început bun:
Funcționalități ale limbajelor de programare:
Design software:
Programare paralelă:
Validare:
Arhitectură:
Refactoring:
Lucrul cu codul dificil de modificat:
Aceste abilități sunt independente de tehnologie. O dată ce le stăpânești, le vei putea folosi într-o tehnologie complet nouă. Aceste abilități îți vor permite să îți crești cariera, indiferent de modificările din tehnologie.
Dificultatea fundamentală a programării a fost întotdeauna de a traduce cerințe ambigue în cod foarte precis și rezistent la problemele care pot apărea în lumea reală. Răspunsul la această provocare a fost dezvoltat în ultimii 50 de ani și nu s-a modificat prea mult în timp. Singurul lucru care se modifică este implementarea, de obicei devenind mai ușoară.
Stăpânirea fundamentelor programării și a abilităților asociate sunt cel mai bun pariu pentru a crește o carieră independentă de modificările viitoare din tehnologie. Mantra "Abilitățile sunt presus de tehnologie" nu înseamnă că nu trebuie să cunoști tehnologia, doar că pe perioade mai lungi abilitățile sunt mai importante.
Dacă vrei să mergi pe această cale, nu ești singur. Comunitățile de software craftsmanship din orașul tău pot să ajute (de exemplu comunitățile Agile Works din România - http://agileworks.ro) și conferințe de craftsmanship precum I TAKE Unconference - http://itakeunconf.com sunt organizate cu acest scop. Alătură-te lor și crește-ți cariera ca software craftsman și nu ca viitor manager.