În ultimii 17 ani am lucrat la peste 90 de proiecte cu multe echipe. Dar abia când am dat de Git’s blame caracteristică pe care am aflat-o despre „scrierea de mână” a fiecărui coder. Această curiozitate simplă a devenit în curând un obicei. De câte ori am văzut un cod nou, am încercat să ghicesc cine l-a scris. Apoi mi-aș verifica presupunerea cu un git blame.

(Apropo, dacă nu sunteți familiarizați cu git totuși, este o modalitate populară pentru dezvoltatori de a colabora la cod și „vina“Funcția vă arată cine a fost autorul unui anumit cod sursă de linie.)

După câțiva ani, am început să văd modele, la fel ca un expert în scrierea de mână ar putea detecta un sociopat din modul în care își desenează W-urile. Scrierea de mână a codului dezvăluie multe despre programatorul care a scris-o.

Puteți afla aproape orice din scrisul de mână al unui programator: câtă experiență au, cât de mult le pasă de lizibilitatea codului lor (și, prin extensie, cât de mult le pasă de colegii lor de echipă).

Discuții despre cod. Cod greșit țipete! Deci, codul pe care îl citiți este codul de caligrafie sau este codul de zgârietură?

O declinare rapidă: ceea ce urmează să citiți se bazează pur pe intuiția mea subiectivă. Din câte știu, nu au existat studii academice revizuite de colegi. Abilitățile mele de analiză a scrierii de mână cu coduri m-au servit bine în trecut și vă pot ajuta la fel de bine, dar – la fel ca în orice ați citit pe internet – kilometrajul dvs. poate varia.

Insight # 1: Cod umflat = luptă

De obicei, când descopăr cod care a devenit umflat și mult mai mare decât trebuie, arată un programator care se lupta să termine o sarcină care depășea abilitățile lor. Ori nu aveau cunoștințele, nici timpul pentru a termina treaba în mod corespunzător.

În viața reală, oameni care do mai puțin, tind să vorbi Mai Mult. La fel se întâmplă și în codul land: cei care nu pot face treaba elegant tind să scrie o mulțime de cod.

Din păcate, bug-urile se bucură de cod și, cu cât sunt mai multe dispoziții de cod, cu atât habitatul bug-urilor este mai mare.

„Urăsc codul și vreau cât mai puțin din acesta în produsul nostru” – Jack Diederich

Cod Calligraph VS Code Scratch Scratch

Insight # 2: Dead code = sloppiness

Ați văzut vreodată blocuri uriașe de cod comentat dedicate repo? Sau chiar mai rău: cod care nu face nimic special, dar există din motive istorice?

Interesant este că acest lucru are o corelație directă cu dezordinea biroului programatorului care a scris-o. Ați văzut vreodată comentarii sau teste învechite? Da, ai găsit un programator neglijent.

1611117550 597 Cod Calligraph VS Code Scratch Scratch

3. Cod complex = prostie sau lăcomie

Îmi place acest citat din Schumacher:

„Orice prost inteligent poate face lucrurile mai mari, mai complexe și mai violente. Este nevoie de un strop de geniu – și mult curaj pentru a merge în direcția opusă ”. – Fritz Schumacher

Dacă ați găsit un cod greu de urmărit sau de înțeles, fiți siguri că a fost scris fie de cineva care nu are nicio idee despre ceea ce fac, fie de cineva care caută securitatea locului de muncă luând „proprietatea” acelei părți a codului.

Insight # 4: Comments = un jucător de echipă (cu excepția cazului în …)

Toate limbajele la nivel înalt permit scrierea unui cod suficient de lizibil încât nu ar trebui să aveți nevoie de comentarii. Dar, uneori, complexitatea este inevitabilă din cauza lipsei de cunoștințe, timp sau cadru elegant.

Îmi place foarte mult când programatorii pun un link către referința API sau o întrebare relevantă Stack Overflow atunci când își dau seama că colegii lor (sau sinele lor viitor) vor pune la îndoială o anumită linie de cod.

Acestea fiind spuse, utilizarea excesivă a comentariilor arată o lipsă de stimă de sine (sau așa cum am menționat mai devreme, încercând să explic „codul umflat”).

Insight # 5: Nume = abilitate de comunicare

Nume variabile, nume funcții, nume parametri, nume clase. Acestea sunt nivelul de bază al comunicării către administratorii de cod.

Dacă întâlniți nume de o singură literă (cu excepția i, care este implicit în for bucle) ați găsit un programator cu lipsă de abilități de comunicare sau empatie pentru ceilalți.

Cu excepția cazului în care este un proiect temporar care nu va fi arătat nimănui sau întreținut, fiecare secundă pusă în alegerea unui nume adecvat are ca rezultat o karma bună.

Și dacă funcționalitatea unei entități se schimbă, este important să-i refactorizăm numele în consecință.

Unii programatori susțin că numele nu sunt importante, deoarece mașinilor nu le pasă. Ei bine, cu excepția cazului în care scrieți codul literalmente în zerouri și unele, scrieți cod și pentru oameni!

Insight # 6: citire slabă = lipsă de fluență

Uneori programatorii vorbesc fluent un limbaj, dar încearcă să răsucească și să îndoiască un alt limbaj pentru a se comporta ca limba lor preferată.

1611117551 377 Cod Calligraph VS Code Scratch Scratch

JavaScript este una dintre limbile țintă slabe.

Majoritatea programatorilor de back-end au luxul de a-și alege „limba maternă”. Și mulți sunt suficient de curajoși pentru a hack împreună câteva linii de cod front-end. Dar, deoarece browserul este în mare parte JavaScript (care este un limbaj flexibil), ei încearcă să imite ceea ce le sunt familiare tiparele din „limba maternă”.

Totul este bine și până când un programator JavaScript propriu-zis vede codul și le scoate părul!

Insight # 7: Hacks = personalitate superficială sau lipsă de disciplină

Ați petrecut vreodată mult timp ordonând o bază de coduri doar pentru a fi martor al colegului dvs. turnând benzină peste tot frumosul tău cod folosindu-l ca platformă pentru remedieri rapide și murdare?

Felicitări: ai întâlnit un hacker!

1611117551 229 Cod Calligraph VS Code Scratch Scratch

Hackerii sunt minunați în a face remedieri rapide, fără să se deranjeze să înțeleagă arhitectura în mod holistic (de obicei, amestecând cu un depanator sau prin încercări și erori).

Deci, care este captura? Ei rezolvă o problemă și creează alte 10.

Consultanții au tendința de a arăta acest comportament (deoarece timpul lor este scump și nu vor trăi cu consecințele schimbărilor lor). În plus, ei pot fi plătiți pentru a remedia aceste alte 10 probleme și pentru a semăna securitatea locului de muncă, făcând 100 de noi.

Cu toate acestea, am asistat la programatori interni care fac ca și cei mai slabi consultanți să arate ca niște stele rock. Ați estimat vreodată că o problemă durează 8 ore, dar un manager de produs vă reduce estimarea la doar 1 oră? De obicei, atunci se nasc hacks.

Acestea fiind spuse, uneori aveți nevoie de livrare rapidă (cum ar fi în faza de prototipare într-un start-up pentru a valida ideea) și este acceptat să tăiați colțurile din cauza resurselor limitate. Nimănui nu îi pasă de un cod frumos care nu rezolvă nicio problemă. Dar totuși există o diferență între tăierea cu foarfeca sau tăierea cu o macetă!

Insight # 8: Inconsistency = orgoliu și fanatism

Când ești la Roma, fă cum fac romanii. – un proverb

Există atât de multe convenții de codare. Nu contează cu adevărat care dintre ele este ales. Dar, odată ce echipa dvs. alege câteva convenții, este crucial să rămână cu ele.

În cazul în care contribuitorii ignoră unele sau toate convențiile, aceștia fie fac hacking sau sunt prea mândri pentru a-și schimba stilul pentru a se potrivi cu baza codului dvs.

Cel mai rău dintre toate este atunci când își propun în schimb propriile convenții. E un fanatism pur. Și puteți fi sigur că programatorul are o minte îngustă și în alte chestiuni.

Insight # 9 Cod WET = memorie proastă

Opusul Uscat („Nu te repeta”) este Umed („Ne place să tastăm” sau „Scrie totul de două ori”).

Ei bine, erorile se reproduc printr-un proces dezordonat numit „copiere” și „lipire”.

Există surprinzător de multe tipuri de cod WET. De exemplu:

  1. O funcție sau clasă care este scrisă de două ori, numai cu diferențe minore
  2. O variabilă care deține valoarea unei alte variabile
  3. Un set de instrucțiuni repetitive care ar putea locui într-o funcție

Acest lucru este diferit de codul umflat, prin faptul că, mai degrabă decât să fie doar complex sau răsucit, codul WET se repetă literalmente.

De obicei, codul repetitiv este un semn că un programator nu poate aminti (sau mai rău, nu a văzut) celălalt cod similar. Una dintre principalele sarcini ale creierului uman este de a detecta tiparele. Când un programator nu reușește să identifice coduri similare, este un semn de lipsă de experiență sau neatenție la detalii.

Insight # 10. Soluții temporare = lipsa disciplinei

Uneori dezvoltatorii vor injecta o soluție rapidă și murdară ca o soluție temporară, sperând că într-o zi vor reuși să o refactorizeze. Acest lucru se întâmplă de obicei din cauza unui termen limită apropiat sau a lipsei de cunoștințe. Dar, după cum știm cu toții, soluțiile temporare sunt acolo pentru a rămâne.

1611117552 773 Cod Calligraph VS Code Scratch Scratch

Soluțiile temporare indică un inginer pragmatic căruia îi lipsește orice gust sau mândrie în munca sa. De asemenea, pot fi un semn al stimei de sine scăzute, deoarece nu vor să dezamăgească pe altcineva (șef, client etc.).

Singura dată când o soluție temporară este acceptabilă este pentru un proiect de învățare sau prototipare (dovada conceptului). Și chiar și în aceste cazuri, este mai bine să o refactorizați de îndată ce știți cum să o faceți corect.

Insight # 11: O mulțime de dependențe = neglijență pentru viitorul proiectului

Dependențele trebuie să fie actualizate. Când un proiect are prea multe dependențe, este un semn de neglijență.

Este greu de spus ce este „prea mult”, dar regula generală este: dacă proiectul poate supraviețui cu ușurință fără o dependență, este redundant.

O altă măsură este că, dacă nu există o cerință necesară pentru problema de bază pe care dependența o rezolvă, probabil că nu este necesară.

1611117552 824 Cod Calligraph VS Code Scratch Scratch

Există trei motivații pentru dependențe inutile:

Motivul nr. 1: Dezvoltatorul este prea dornic să învețe lucruri noi.

Prin importul de noi dependențe, ei au șansa de a face această învățare într-un proiect real.

Curiozitatea este bună, dar ar trebui să existe alte platforme pentru învățare, cum ar fi proiecte secundare, sarcini pe termen scurt sau hackathoni.

Nu doriți să pierdeți un dezvoltator bun, deoarece ei cred că nu pot crește la locul lor de muncă, dar nici nu doriți ca ei să trateze produsul dvs. ca pe proiectul lor de companie.

Motivul nr. 2: este realizat de un dezvoltator junior prea ambițios.

Noii veniți în orice domeniu tind să fie copleșiți de toate noile cuvinte la modă și din frustrare sau ignoranță (sau recomandarea unui „pro”) pot decide să „sară în piscină” și să învețe totul dintr-o dată. Nu-i lăsa. Alegeți-vă tehnologia.

Motivul nr. 3: Dezvoltatorul are bagaje dintr-un alt loc de muncă (sau dintr-un proiect secundar)

Vor să aibă un avantaj asupra colegilor lor, aducând ceva pe care doar ei îl știu foarte bine.

Din păcate, nu există o soluție ușoară la acest lucru, ci abilitățile ușoare: echipa trebuie să pună la îndoială alegerea fiecărei dependențe și, dacă există un proces adecvat de revizuire și îmbinare a codului, face dificilă introducerea unui cod teribil fără ca cineva să-l observe.

Uneori, codificatorul de cowboy în cauză poate face o refacere masivă, apoi poate pune echipa într-o poziție de a accepta întreaga schimbare, deoarece a fost deja realizată. Ei bine, nu! Rugați-i să împartă cererea de atragere în părți mai mici și să fie sceptici cu privire la aducerea de noi dependențe. Da, este mai mult de lucru, dar va economisi mult mai mult timp și energie pe termen lung.

Dezvoltatorilor buni le pasă de viitorul proiectului lor, deoarece și-au petrecut cea mai finită și prețioasă resursă pentru a-l crea: timpul lor!

1611117553 337 Cod Calligraph VS Code Scratch Scratch

Apropo, o mulțime de dependențe și cuvinte la modă la modă pot fi, de asemenea, un semn că dezvoltatorul construiește un CV și se pregătește deja pentru următorul lor loc de muncă.

Caligrafie de cod

Acum că am discutat despre zgârierea codului, să vorbim despre partea inversă: cod care este o plăcere absolută de citit.

Unii spun chiar „codul este poezie. ”

Codul sursă pentru jQuery sau lodash sunt exemple grozave, dar cam toate bibliotecile populare de pe Github pe care mulți colaboratori vor converge în cele din urmă asupra frumuseții. Acest lucru, prieteni, este minunat cod caligrafie.

În esență, codul excelent este:

  1. Ușor de citit, urmărit și depanat
  2. Flexibil, configurabil și extensibil
  3. Inteligent cu utilizarea resurselor
  4. Performanta ridicata

Rețineți că unele proiecte necesită o comandă diferită. De exemplu, codul sursă Linux s-ar putea să nu fie foarte ușor de citit, deoarece performanța este mai importantă pentru un sistem de operare. Sau o aplicație IoT încorporată modestă poate sacrifica configurația în favoarea optimizării resurselor.

Oricum, puteți afla mai multe despre colegii dvs. doar analizând codul lor. Codul vorbește mai tare decât cuvintele! Așadar, data viitoare când citiți un cod, încercați git blame comandați și începeți să recunoașteți scrierea de mână a codului.

Ți-a plăcut ce ai citit? Urma să fiu anunțat când scriu ceva nou.

De asemenea, poate doriți să verificați de ce programarea este cea mai bună meserie vreodată.