Luna trecută, Vicki Boykis a recomandat cartea „Codul care se potrivește în capul tău” de Mark Seemann. Am fost intrigat, mai ales de afirmația ei că „Scrieți un software bun ar trebui să fie un meșteșug lent și deliberat”.
Cartea a amintit de Programatorul pragmatic în amploarea subiectelor pe care le acoperă. Cu toate acestea, am preferat mult tonul lui.
Sustenabilitate
De-a lungul cărții, autorul arată clar că crede că trebuie să acordăm atenție codului pe care îl scrie, calității sale interne. Următoarele două propoziții au primit chiar și micul lor cadru:
„Scopul nu este să scriem cod rapid. Scopul este un software durabil.”
Aranjați Act Assert
Ce frază utilă!
Știi cum într-un test poți avea ceva de genul:
test_that("Exception Bla handled", {
withr::local_option("bla" = 1)
test_thing <- 23
x <- my_function(test_thing)
expect_equal(x, 2)
})
Primele două rânduri din test_that() sunați pregătiți ceea ce este necesar. Asta este aranja fraza.
Linia de apel my_function() face ceea ce vreau să testez. Asta este act fraza.
Linia de apel expect_equal() verifică chestia aia. Asta este afirma fraza.
Aranjați, acționați, afirmați! Cartea menționează chiar că puteți separa cele trei faze cu linii goale.
Red Green Refactor
O altă frază frumoasă! Descrie modul în care puteți lucra iterativ pe o parte a software-ului dvs.
- Roșu: scrieți un test eșuat pentru, de exemplu, o caracteristică.
- Verde: scrieți codul pentru a trece testul.
- Refactor: îmbunătățiți acel cod (dar nu faceți testul să eșueze din nou!).
Am apreciat modul în care autorul a scris că nici măcar faza roșie nu este ușoară, pentru că poți obține un test de promovare pe care credeai că va pisa. Cred că ideea este reluată în altă parte a cărții: vă puteți imagina că un test va trece sau va eșua în anumite condiții, dar mai bine să-l dovediți prin rularea testului!
Avocatul Diavolului
O tehnică prezentată în carte este Avocatul Diavolului, în care scrii cod greșit intenționat, pentru a vedea dacă testele tale îl vor detecta. Presupun că este o versiune mai puțin aleatorie (dar mai dificilă?) a testării mutațiilor, în care evaluezi cât de des suita ta de teste detectează mutanții codului tău. În R, testarea mutației este furnizată de exemplu de pachetul mutator.
Recenzii de cod care nu blochează
Există o scurtă discuție despre când să faceți recenzii de cod (regulat) pentru a nu bloca colegii de echipă. Mi-a făcut plăcere să văd asta, deoarece este important să nu fie întotdeauna un factor de limitare a ratei. Arată că sfaturile cărții sunt pragmatice.
Grupați modificări mai mici de rupere
În capitolul „Mărirea codului” care se referă la lucrul cu codul existent, autorul – printre altele – discută dacă să grupeze sau să separe modificările de ruptură într-una sau mai multe versiuni. Criteriul de decizie este cât de multă muncă creați pentru „dezvoltatorii clienți” (menținătorii dependențelor inverse).
Este, de asemenea, unul dintre numeroasele locuri din carte în care autorul ne amintește că nu există o regulă grea, că este „artă de inginerie software”.
Casa sau nu Casa
Primul capitol al cărții prezintă și critică analogii ale ingineriei software, cum ar fi compararea dezvoltării de software cu construirea unei case. Asta a reamintit de discuția „Întreținerea casei” construită de Hadley Wickham, care a comparat întreținerea ordonată cu întreținerea casei.
Teza capitolului este că toate analogiile sunt utile și imperfecte și nu ar trebui să le lăsați să limiteze sau să întunece modul în care vă vedeți munca.
Justificați excepțiile
La un moment dat, autorul scrie că analiza codului static aduce false pozitive, dar că dacă dezactivați anumite reguli, ar trebui să justificați de ce. Așa Jarl, un linter pentru codul R, te face să suprimi regulile: trebuie să explici un motiv.
Git este ușor
Îmi plac aceste trei propoziții încurajatoare:
„Git nu este cea mai ușor de utilizat tehnologia de pe planetă, dar ești un programator. Ai reușit să înveți cel puțin un limbaj de programare. În comparație cu asta, învățarea elementelor de bază ale Git este ușoară.”
Testare pe baze de date
Ca exemplu de teste lente, autorul menționează teste împotriva bazelor de date. Vreau să folosesc asta ca o scuză pentru a conecta pachetul dittodb pentru a bate joc de baze de date în teste.
Bisecție fără și cu Git
În capitolul despre Depanare, este introdusă ideea de bisectare fără Git. Autorul spune că se numește bisectie din lipsa unui cuvânt mai bun. Ideea fiind să treci de la o bucată mare de cod cu o eroare la cea mai mică bucată de cod cu aceeași eroare, presupun că un cuvânt mai bun este reprex. 😁
„A fi capabil să produci un exemplu minim de lucru este o superputere în ingineria software”.
Referitor la Git bisecție, iată reamintirea dvs. prietenoasă că o puteți încerca folosind pachetul saperlipopette R.
Timpul de box
Autorul exaltă virtuțile boxului în timp (de ex. metoda Pomodoro). Am folosit Entracte și aș recomanda să-l încerci, dacă nu ai încă o configurație similară!
Când citeam cartea, între bucăți de lectură aș croșeta câteva runde.
Performanţă
Mi-a plăcut discuția pragmatică despre performanță: nu uitați să verificați cifrele și semnificația lor.
Analiza codului comportamental
Nu am folosit niciodată analiza comportamentală a codului, ceva care folosește date Git, dar prezentarea lui mi-a amintit de comenzile Git pentru a cunoaște un proiect care are legătură (sau același?).
Navigare prin cod
Da, la mențiunea de a învăța cum să navighezi prin cod în IDE-ul tău. O abilitate atât de importantă.
Concluzie
„Cod that Fits In Your Head” este o carte ambițioasă (și destul de lungă). M-am bucurat să învăț fraze noi și să am ocazia să cunosc sau să reflectez la atâtea subiecte.
Deoarece cartea a fost publicată în 2021, AI își face apariția doar ca o scurtă notă de subsol. Singurul moment în care am crezut cu adevărat că AI va face un punct mai puțin valid a fost un punct despre unele tipuri de refactorizare care durează vechime: în pachetul igraph R, unele modificări au devenit recent fezabile într-un mod mai ușor datorită utilizării unor instrumente precum Claude.
Unele aspecte ale cărții ar putea fi puțin enervante, cum ar fi diagramele sau ilustrațiile super simple (gândiți-vă: un desen cu ciocan pentru a ilustra faptul că pentru cineva cu un ciocan, totul arată ca un cui), dar presupun că acestea își joacă rolul de a rupe paginile.
Bonus: o listă de lectură
Dacă cineva destul de nou în ingineria software mi-ar cere să mă înregistreze cărți, uitându-mă la teancul de lângă birou, aș recomanda următoarele cărți, mai specializate decât „Codul care se potrivește în capul tău”:
De asemenea, cred că există și alte modalități de a învăța, cum ar fi urmărirea discuțiilor, dar această postare este despre cărți. 😸
