Recent, echipa mea s-a apropiat de versiunea veche a produsului nostru. Acum câțiva ani, am avut un eveniment major de ucidere a codului și de distrugere a datelor, eliminând cel mai mare și mai evident cod și date neutilizate. Am făcut tot posibilul pentru refactorizare și, în cele din urmă, am decis să rescriem cele mai importante componente.

excepții

De atunci, vechiul cod a continuat să îmbătrânească. Foarte puțin software va funcționa pentru totdeauna fără dragoste și atenție - patch-urile de securitate și alte elemente esențiale creează mișcare, iar mișcarea creează schimbări, care rupe lucrurile. De atunci am făcut foarte puțin vechiul cod.

Ne-am întors

Acum am exteriorizat cea mai mare parte a vechii răutăți și am rescris la o nouă bunătate ... mai ales. Dar, ca și amintirile triste, vechiul cod nu dispare.

Așadar, ne adâncim în ceea ce numim acum „răutatea”, amintind de ororile pe care le-am putut îndepărta de mult din mintea noastră. Sunt o multime.

În ultimele zile, am văzut un cod foarte prost.

Iar Câștigătorul celui mai rău anti-model este ...

Acest model a fost aparent modul în care copiii mișto au împiedicat AirBrake să ne trimită e-mailuri pentru erori „neimportante”. Oamenii s-au obișnuit să scrie acest lucru într-un rând cum ar fi open_a_file (nume de fișier) rescue zero, despre care nici nu știam că este rubin legal (este).

Nu este acesta doar cel mai bun exemplu de utilizare a expresivității și frumuseții inerente a rubinului?

Aceasta se numește „excepții alimentare” sau „erori de înghițire” sau „eșec în tăcere”. Este rău.

Este doar greșit. Nu este niciodată corect (aproape). Este o codificare leneșă și iresponsabilă.

Mai rău, modul corect de a face față acestui lucru este doar de a scrie

Dacă creează o excepție, vom ști. Dacă există un caz de eșec comun și acceptabil, rezolvați-l evident, de exemplu

Adevăr sau consecințe

Pare amar și furios, deoarece ultimii câțiva ani din viața mea au fost frecvent întrerupți de un cod care eșuează scris de acești oameni leneși și iresponsabili. Acest lucru se întâmplă numai atunci când mă relaxez, dorm sau nu sunt interesat în alt mod de urmărirea erorilor, așa-numitul inginer neglijent creat în 2009.

Urmărirea cazurilor de eșec tăcut este dificilă. Erorile de înghițire tind să permită stării de răutate să persiste și să se abată, trăgând de-a lungul răului.

Așadar, până când ceva eșuează puternic, este adesea imposibil să se regăsească cauza principală. Am petrecut multe ore de nopți și weekenduri instrumentând codul pentru a afla o stare de eșec. Cel mai adesea, este în aval de o eroare ușor de detectat care a fost consumată.

Pur și simplu nu înțeleg cum acest model clar greșit părea să fie norma în această bază de cod veche. Pur și simplu nu înțelegeți.