Una dintre cărțile recomandate de mine oricărui programator (mai ales celor ce au trecut de nivelul hello world) este Clean Code: o carte cu idei despre cum ar trebui scris codul și, de ce să nu recunosc, după care m-am ghidat. Mai în glumă, mai în serios, este una dintre cărțile care chiar mi-au schimbat modul în care scriu cod (în bine). Pot stabili destul de exact dacă un cod scris de mine a fost scris înainte sau după ce am citit-o, atât de mult m-a influențat.
Cu toate astea, erau mici chestii care mă râcâiau în carte. Articolul ăsta sumarizează binișor ce nu mi-a plăcut nici mie în carte: funcții scurtate ad absurdum doar pentru a întruni un standard vag: „should be shorter than that”.
Sunt atât de drastic încât să nu recomand cartea? Ei bine… greu de zis. Am citit-o acum vreo zece ani și este posibil ca timpul să-mi fi alterat amintirile despre ce am citit în carte. Cu toate astea paginile acestei cărți m-au pus să gândesc mai bine numele și funcțiilor, numele variabilelor, principii SOLID șamd. Deci cred că o voi recomanda în continuare.
În articol se recomandă A Philosophy of Software Design. O am pe listă de vreo doi ani, trebuie să găsesc timp pentru ea…
O mai recomandăm. De două ori. Mai bine citită cu exagerările ei decât scris cod după ureche.
Recomandam, recomandam. Da, e un pic dus la extrem, dar asta e si scopul – sa vezi cum ar arata niste concepte duse la extrem, sa le aplici in mod artificial ca sa le intelegi, si odata cu asta sa intelegi si limitarile lor. La scrisul codului, orice e un tradeoff. Clean code, design patterns, documentatie, toate sunt un tradeoff intre timp investit, boilerplate adaugat, mai mult cod de scris/mentinut, si asa mai departe. A sparge o functie in 20 de bucatele e util in anumite situatii. Sau e o pierdere de timp. Ducand la extrem conceptul, inveti cand merita.