Sincer, m-am săturat de listele alea de pe LinkedIn unde toți recomandă „Clean Code” ca pe o biblie absolută. Am trecut prin faza aia acum vreo opt ani și mi-am dat seama că aplicarea oarbă a acelor reguli mai mult strică decât ajută.
Uite trei cărți care chiar mi-au dat un reset mental și m-au făcut un inginer mai bun, nu doar un scriitor de sintaxă.
1. A Philosophy of Software Design – John Ousterhout
Cartea asta e un fel de anti-Clean Code și a fost o gură de aer proaspăt pentru mine. Ousterhout, care e profesor la Stanford, explică de ce ideea de a avea funcții de maximum 4-5 linii (cum zice Uncle Bob) e adesea o prostie care crește complexitatea cognitivă a întregului proiect.
El introduce conceptul de „deep modules” versus „shallow modules”. Ideea e simplă: o clasă sau o funcție bună trebuie să aibă o interfață extrem de simplă, dar să ascundă multă complexitate în spate.
Am pățit asta direct: la un proiect cu vreo 10k useri activi zilnic, aveam un coleg pasionat de clean code care spărsese logica de checkout în 15 micro-clase de câte 10 linii fiecare. Ca să înțelegi cum se salvează o comandă, trebuia să ai 15 tab-uri deschise în IDE și să sari din una în alta. După ce am citit cartea asta, am refăcut totul în două module mari și „adânci”. Timpul de onboarding pentru un dev nou pe modulul ăla a scăzut de la trei zile la două ore.
Trade-off: Dacă lucrezi într-o corporație unde lead-ul tău e fanatic după reguli stricte de linter și „clean code” clasic, s-ar putea să ai discuții grele la code review dacă aplici ideile lui Ousterhout. Dar pentru codebase-uri pe termen lung, e aur curat.
2. Thinking in Systems – Donella Meadows
Nu are nicio legătură directă cu programarea, dar este cartea care m-a ajutat cel mai mult să înțeleg arhitectura software și dinamica unei echipe. Te învață să vezi lumea prin prisma stocurilor, fluxurilor și a buclelor de feedback.
Când scrii cod, ești tentat să repari doar bug-ul din fața ta, dar o abordare sistemică te ajută să vezi de ce acel bug a apărut acolo și cum patch-ul tău s-ar putea să creeze o problemă mult mai mare în altă parte a aplicației peste trei luni.
De când am citit-o, am început să desenez diagrame de flux înainte să scriu prima linie de cod. M-a salvat de la cel puțin trei refactoring-uri majore care ne-ar fi mâncat sute de ore de muncă degeaba pe un proiect cu microservicii.
3. Peopleware: Productive Projects and Teams – Tom DeMarco & Timothy Lister
Am citit cartea asta pe la 26 de ani, când eram într-un burnout destul de urât și credeam că soluția la toate problemele de proiect e să bag mai multe ore de muncă.
Cartea asta mi-a demonstrat, cu date concrete din sute de proiecte reale, că problemele majore din software nu sunt tehnice, ci umane. Mi-a deschis ochii asupra a ceea ce înseamnă de fapt productivitatea unui programator. Nu e vorba de câte linii de cod scrii pe oră, ci de spațiul mental pe care îl ai ca să gândești curat. Am învățat să spun „nu” ședințelor inutile și să-mi protejez timpul de focus.
Voi ce cărți ați citit care v-au schimbat perspectiva, dar care nu apar de obicei în topurile clasice de pe net?