Să fim sinceri: ne-am săturat toți de aceleași liste obosite care recomandă Clean Code sau Pragmatic Programmer. Sunt ok pentru primii doi ani de facultate, dar după ce treci de un număr de bug-uri date în producție, realizezi că adevăratele probleme nu sunt despre unde pui parantezele. Iată trei cărți care mi-au schimbat radical modul de a gândi ca dev și pe care le recomand oricui vrea să treacă de nivelul de scriitor de funcții.
Thinking in Systems — Donella Meadows
Am citit-o prin 2019, când lucram la un sistem cu peste 12 microservicii care se bloca aleatoriu o dată pe lună. Echipa mea trata fiecare cădere ca pe un bug izolat: puneam un retry, mai adăugam un catch, făceam un patch. Clasicul stingi focul și mergi mai departe.
Donella Meadows m-a învățat să nu mai privesc codul ca pe un șir liniar de cauze și efecte, ci ca pe un rețea de bucle de feedback. Am realizat că retry-urile noastre „deștepte” de fapt sufocau baza de date în momentele de vârf — adică noi creasem singuri o buclă de amplificare a dezastrului. Cartea asta n-are nicio linie de cod în ea. În schimb, îți oferă un ochi critic pentru dependențe ascunse, latențe și efecte secundare. Dup-ce o citești, n-o să mai poți privi o arhitectură la fel.
The Goal — Eliyahu M. Goldratt
Este o carte scrisă ca un roman de afaceri din anii '80 despre un manager de fabrică care încearcă să-și salveze uzina de la faliment. Sună plictisitor? A fost cea mai bună lecție de DevOps și Agile pe care am primit-o vreodată.
Am avut un proiect la un client mare unde build time-ul durea 45 de minute. M-am apucat entuziasmat să optimizez Dockerfile-urile și scripturile de CI, reușind să scad timpul de build la 12 minute. Economisisem vreo 70% la build time și eram extrem de mândru. Trade-off-ul? Feature-urile tot făceau câte două săptămâni până ajungeau în producție, pentru că blocajul real era la etapa de QA manual și sign-off de la product owner. Optimizasem o zonă care nu era gâtul de sticlă (bottleneck-ul) al sistemului.
The Goal te învață Teoria Constrângerilor: orice optimizare făcută în altă parte decât la gâtul de sticlă este o iluzie de productivitate. Dialogurile din carte sunt puțin leșinate uneori, dar conceptele sunt pur aur.
A Philosophy of Software Design — John Ousterhout
Singura carte tehnică din listă, dar una care desființează direct multe dintre dogma-urile din Clean Code. Ousterhout este profesor la Stanford și creatorul Tcl, deci un om care a scris cod masiv la viața lui.
Ideea lui de bază e simplă: cel mai mare inamic al software-ului este complexitatea. Spre deosebire de recomandările populare de a sparge codul în funcții de 3 linii, el explică de ce interfețele adânci (interfață simplă, funcționalitate complexă în spate) sunt mult mai bune decât modulele superficiale. M-a ajutat să scap de vina pe care o simțeam când scriam o clasă mai lungă de 100 de linii dar care își făcea treaba perfect și era extrem de ușor de folosit din exterior.
Sunt curios, la voi ce carte a făcut acel „click” mental care n-are nicio legătură cu vreun tutorial sau limbaj de programare?