Când aud încă un coleg recitând dogmatic din Clean Code că o funcție trebuie să aibă maxim patru linii, mă ia puțin capul. Am fost și eu acolo în primii ani: scriam interfețe pentru orice, spărgeam logica în zeci de fișiere minuscule și credeam că fac artă, deși sistemul devenea de fapt imposibil de urmărit. În 12 ani de backend am citit zeci de cărți tehnice, dar doar trei mi-au schimbat structural modul de lucru.
A Philosophy of Software Design — John Ousterhout
Pentru mine, cartea asta a fost antidotul direct pentru exagerările din Clean Code. Ousterhout, profesor la Stanford și autorul Tcl, explică un concept simplu: complexitatea este inamicul suprem, iar divizarea excesivă nu o elimină, doar o ascunde.
Mi-a schimbat modul de a privi abstracțiile prin conceptul de deep modules — module cu interfețe simple, dar cu funcționalitate internă bogată. Înainte, făceam shallow modules: clase anemice gen UserPasswordValidationHelperService care doar apelau o altă clasă. La un proiect de plăți cu vreo 15 microservicii unde totul era fragmentat agresiv, am aplicat ideile lui Ousterhout și am comasat peste 30 de clase inutile. Rezultatul a fost că timpul de înțelegere a flow-ului pentru un dev nou a scăzut vizibil, iar debug-ul nu mai necesita deschiderea a opt tab-uri în IDE pentru un simplu save().
Working Effectively with Legacy Code — Michael Feathers
Toată lumea vrea să scrie proiecte de la zero, pe stack-ul cel mai nou. Realitatea? 90% din viața de dev înseamnă să lucrezi pe cod scris acum 5 ani de oameni care au plecat de mult din companie.
Definiția lui Feathers pentru legacy code e brutal de simplă: cod fără teste automate. Nu contează că e scris în Rust ieri sau în PHP acum un deceniu — dacă nu-l poți testa fără frică, e legacy. Cartea te învață pragmatism pur: cum găsești seams (locuri de îmbinare) unde poți injecta teste fără să rescrii jumătate de aplicație. M-a scăpat de aroganța de a spune „trebuie rescris tot”. La un CRM de asigurări pe care l-am preluat acum câțiva ani, tehnica asta ne-a permis să stabilizăm un modul critic de facturare în 3 săptămâni, fără niciun refactoring masiv cu risc de downtime.
Designing Data-Intensive Applications — Martin Kleppmann
Nu e o lectură de weekend pe plajă. Kleppmann intră la sânge în baze de date, consistență, replici și streaming. Ce m-a marcat nu a fost teoria în sine, ci accentul constant pe compromisuri (trade-offs).
Înveți că nu există o bază de date „perfectă” sau un sistem „scalabil” la modul abstract. Vrei consistență strictă? Plătești la latență și disponibilitate. Vrei viteză maximă de scriere? Te descurci cu date eventual consistente. Înainte de cartea asta, alegeam tool-uri pe bază de hype sau benchmark-uri sintetice. După ce am citit-o, am renunțat să mai împing MongoDB peste tot doar pentru că era la modă și am început să pun întrebări incomode despre volumul de date și garanțiile de rețea.
Compromisul din spatele acestor cărți
Niciuna dintre ele nu-ți oferă rețete rapide de tipul „fă X și totul va fi bine”. Ousterhout te obligă să gândești critic și să renunți la dogme învățate în facultate, iar Kleppmann cere adesea să recitești un capitol de trei ori cu un pix pe foaie. Durează luni de zile să le digeri, nu ore.
Voi ce cărți aveți pe noptieră care chiar v-au schimbat felul în care scrieți cod în producție?