Îndemnat (😉) de o oarecare teamă de AI, am decis să mă întorc la câteva elemente de bază și să recitesc The Programmer’s Brain de Felienne Hermans. Munca lui Felienne Hermans mi-a atras atenția când a ținut o conferință principală la o conferință Posit în urmă cu ani. Cartea a fost un punct culminant al săptămânii mele: extrem de interesantă și ușor de urmărit. Iată câteva note, datorită semnelor de carte minuscule pe care le-am adăugat în timp ce citeam.
Personajele principale
Personajele principale din carte sunt
- memoria de lungă durată (cunoașterea);
- memoria pe termen scurt (informații chiar acum);
- memoria de lucru (puterea de procesare).
Totul le este adus înapoi.
A depune un efort dă roade
Sunt fascinat de faptul că un profesor pe nume Ballard a aflat că „atunci când încerci să-ți amintești în mod activ informații fără studiu suplimentar, îți vei aminti mai mult din ceea ce ai învățat”.
De asemenea, vă puteți întări amintirile gândind activ, elaborând în jurul a ceva.
Sarcini cognitive
Felienne Hermans rezumă diferitele tipuri de încărcătură cognitivă:
Sarcină intrinsecă: cât de complexă este problema în sine. Încărcare străină: ce distrageri exterioare adaugă problemei. Încărcare germană: sarcină cognitivă creată de a-ți stoca gândurile în memoria pe termen lung.
În ceea ce privește încărcarea străină, un exemplu dat este o problemă de matematică prost formulată.
Refactorizarea cognitivă
Mi-am amintit această idee din prima mea lectură: poți refactoriza codul pentru a-l înțelege mai bine, un refactor pe care îl faci doar pentru tine.
Un exemplu dat este înlocuirea constructelor de limbaj necunoscute, cum ar fi funcțiile anonime. M-a făcut să mă gândesc la complicarea excesivă a unui PR atât schimbând ceva esențial, cât și înlocuind buclele for cu reduce, care nu erau familiare pentru colaboratorul meu. Ar fi trebuit să împart cele două modificări în două PR.
Un citat înrudit din carte:
„„cizibil” este într-adevăr în ochii privitorului”
Ajută-ți memoria de lucru
Când a menționat strategii pentru a vă ajuta memoria de lucru, cum ar fi crearea de tabele de stare sau diagrame, autorul a menționat PythonTutor de Philip Guo, care vizualizează execuția unui program. Mi-a amintit de pachetul boomer R de la colegul meu cynkra Antoine Fabri, care vă permite să inspectați pașii intermediari ai unui apel.
subset(head(penguins, 2), bill_len > 47) |> boomer::boom()
#> 💣 subset(head(penguins, 2), bill_len > 47)
#> · 💣 💥 head(penguins, 2)
#> · species island bill_len bill_dep flipper_len body_mass sex year
#> · 1 Adelie Torgersen 39.1 18.7 181 3750 male 2007
#> · 2 Adelie Torgersen 39.5 17.4 186 3800 female 2007
#> ·
#> · 💣 💥 bill_len > 47
#> · (1) FALSE FALSE
#> ·
#> 💥 subset(head(penguins, 2), bill_len > 47)
#> (1) species island bill_len bill_dep flipper_len body_mass sex year
#> <0 rows> (or 0-length row.names)
#>
#> (1) species island bill_len bill_dep flipper_len body_mass sex year
#> <0 rows> (or 0-length row.names)
Asocierea acestuia cu un alt pachet constructiv al lui Antoine ar putea ajuta să reprezinte mai bine codul.
Rolurile variabilelor
Cartea are o listă (de Jorma Sajaniemi) cu cele unsprezece roluri pe care le poate avea o variabilă, de exemplu „valoare fixă” sau „pas cu pas” (i într-o buclă for). Interesant vocabular! Cartea conține chiar și o diagramă de flux pentru a ne ajuta să stabilim rolul pe care îl joacă o variabilă.
Paralele cu limbajele naturale
Autorul explică o tehnică de înțelegere a codului, încercuind toate variabilele, legăndu-le etc. Îmi amintește cum aș gestiona textul latin pe care a trebuit să îl traduc în liceu. Aveam un cod de culoare și formă, arăta foarte frumos și a funcționat bine.
Vorbind despre limbi, cartea face unele paralele între computer și limbajele naturale. În special, explică modul în care strategiile de înțelegere a textului (cum ar fi interogarea sau rezumatul) se aplică citirii codului.
Păstrarea notelor
Voi încerca să fac mai bine notițele pe o foaie de hârtie când lucrez. O fac deja în unele cazuri, de exemplu când examinez pachetele pentru rOpenSci. Dar cartea insistă într-adevăr cum vă poate susține memoria sau vă poate relua munca după o întrerupere.
Pe lângă aceste note de aruncat, este important să documentați/comentați codul pentru a preveni viitorii contribuitori să cadă în unele capcane și pentru a facilita integrarea noilor colaboratori. Exemplu recent.
Alte limbaje de programare
IDE-uri:
„Transferul între două limbaje de programare este mai probabil dacă programați două limbi diferite în același IDE, ceea ce este un argument puternic pentru utilizarea unui IDE pentru mai multe limbi.”
Alegerea limbii:
„Dacă ți-ai propus să înveți o nouă limbă pentru a-ți extinde modul de gândire, este important să alegi o limbă care să fie fundamental diferită de cele pe care le-ai stăpânit deja.”
Cartea explică, de asemenea, cum unele cunoștințe pe care le ai într-o limbă înseamnă că ar putea fi necesar să „dezînvățați” unele sintaxe. A amintit de faux amis (prieteni falși) pentru cei care învață limba engleză vorbitori de limbă franceză, cum ar fi „de fapt”, asta nu înseamnă în prezent (în prezent).
Numele sunt importante…
Și cartea explică de ce, oferă sfaturi utile. Există un întreg capitol pe această temă.
Mi-a plăcut una dintre convențiile lui Butler: „Identificatorii ar trebui să fie formați din cuvinte și să folosească abrevieri numai atunci când sunt folosite mai frecvent decât cuvintele complete”. Recent, m-am încăpățânat să nu folosesc „pieptene” pentru „combinație” în igraph. Mi-a plăcut și alte convenții din aceeași listă: „Identificatorul nu trebuie să combine caractere mari și mici în moduri nestandard”, cu exemplul Page_counter. S-ar putea să citesc în mod selectiv regulile care îmi plac. 😇
Capitolul transmite perspectiva lui Allamanis conform căreia numele ar trebui să fie consecvente într-o bază de cod, deoarece asta ajută la fragmentarea (când analizați codul în biți semnificativi).
Autorul subliniază că ar trebui să evaluați calitatea numelor după codare, nu în timpul codului, deoarece ar putea fi prea multă sarcină cognitivă. M-a făcut să mă gândesc la comiterile Git: le puteți îmbunătăți după codare, atunci când codificați, este posibil să nu puteți crea un istoric Git perfect.
O altă informație care mi s-a părut interesantă este că, atunci când îmbunătățiți numele în baza de cod, locurile în care găsiți nume proaste ar putea fi locurile cu erori ascunse din diverse motive (cum ar fi corelația dintre nume rele și greșelile unui programator începător sau a unui programator confuz de complexitatea problemei în cauză).
Automatizare
Unele lucruri pe care le știi atât de bine încât le poți face fără să te gândești prea mult, ceea ce te face mai eficient. Un argument pentru învățare și practică deliberată.
Citind despre cod
Uneori, dacă scrii un cod foarte complex, nu înveți prea multe, „creierul tău a fost atât de angajat încât nu a putut stoca soluțiile”.
Blestemul expertizei
Mi-a plăcut să citesc din nou despre „blestemul expertizei”, care este deosebit de relevant atunci când predau:
„Odată ce ai stăpânit suficient o abilitate, vei uita inevitabil cât de greu a fost să înveți acea abilitate sau cunoștință.”
Concluzie
Aș recomanda cu căldură să citești Creierul programatorului de Felienne Hermans! Poate chiar de mai multe ori, așa cum am făcut-o, deoarece în mod clar nu am încredințat totul memoriei pe termen lung. 😁
Epilogul menționează câteva lecturi suplimentare, inclusiv A Philosophy of Software Design de John Ousterhout, care a rezolvat un mister pentru mine: că aici auzisem de acea carte!
