Să fim sinceri, dacă mai aud o singură dată recomandarea să citesc "Clean Code", cred că închid browserul. Sunt cărți bune, nu zic nu, dar au devenit un fel de dogmă pe care mulți o repetă fără să o mai treacă prin filtrul rațiunii. După 10 ani de scris cod și arhitecturi, mi-am dat seama că cele mai mari salturi mentale nu le-am făcut citind despre cum să-mi numesc variabilele, ci din cărți care m-au învățat cum să gândesc structural.
Am selectat două titluri care nu apar de obicei în topurile clasice pentru începători, dar care mie mi-au schimbat complet modul de lucru.
1. "A Philosophy of Software Design" de John Ousterhout
Cartea asta e extrem de scurtă (are în jur de 170 de pagini), dar dărâmă multe dintre miturile promovate de unchiul Bob. Ideea de bază care m-a marcat a fost diferența dintre "deep modules" (module adânci) și "shallow modules" (module puțin adânci).
Ousterhout explică de ce modulele bune ar trebui să aibă o interfață extrem de simplă, dar să ascundă o complexitate uriașă în spate. La polul opus, clasele mici de 10 linii pe care le facem doar de dragul de a avea "metode scurte" sunt de multe ori inutile și doar împrăștie complexitatea în tot sistemul.
Cum am aplicat-o: La un proiect cu peste 80k linii de cod în TypeScript, ne chinuiam cu o structură fragmentată. Aveam sute de fișiere mici, iar ca să înțelegi o singură rută trebuia să navighezi prin zece fișiere. Am decis să facem refactoring urmând principiul "deep modules". Am comasat clasele mici, am ascuns logica internă în spatele unor API-uri interne curate și am reușit să reducem timpul de onboarding pentru noii colegi de la trei săptămâni la doar câteva zile. Codul a devenit mult mai ușor de citit fiindcă nu mai aveai zgomot vizual.
Trade-off: Designul propus de Ousterhout funcționează de minune în codebase-uri medii și mari unde complexitatea e inamicul numărul unu. Dacă lucrezi la un MVP rapid sau la un script de automatizare, aplicarea rigidă a acestor concepte o să te încetinească și o să adauge boilerplate inutil.
2. "Thinking in Systems" de Donella Meadows
Asta nu este o carte de programare. Este o carte despre sisteme în general: de la ecosisteme naturale și economie, până la modul în care funcționează o organizație. Totuși, m-a ajutat să înțeleg software-ul mai bine decât orice manual de design patterns.
Cartea te învață să vezi lumea prin prisma stocurilor, fluxurilor și a buclelor de feedback. Când scrii cod, de fapt creezi un sistem dinamic.
Cum am aplicat-o: Am avut cazul unui proiect cu peste 10.000 de utilizatori activi unde aveam probleme constante de performanță la baza de date. În loc să aruncăm cu resurse hardware în ea (soluția clasică și scumpă), am început să privesc baza de date ca pe un "stoc" cu intrări și ieșiri. Ne-am prins că problema nu era direct de la query-uri, ci de la o buclă de feedback întârziată dintr-un serviciu de background care trimitea notificări. Am ajustat acea buclă și am salvat cam 30% din costurile lunare de infrastructură, fără să scriem vreun algoritm sofisticat.
Trade-off:
Cartea e destul de abstractă și filozofică. Dacă ești în faza în care te chinui să înțelegi cum funcționează un simplu loop for sau cum să configurezi Webpack, o să ți se pară o pierdere de timp totală. Ai nevoie de puțină experiență în producție ca să poți face legătura între teorie și durerile reale din proiecte.
Voi ce cărți mai puțin cunoscute aveți pe birou care v-au schimbat modul în care abordați o problemă de cod?