cultul Cargo este inevitabil

este necontroversat faptul că noii dezvoltatori nu pot ajuta decât cultul cargo.Pur și simplu nu au învățat suficient din stivă pentru a înțelege cu adevărat ce se întâmplă sub capotă și de ce lucrurile trebuie făcute într-un anumit fel.

de exemplu, într – unul din primele mele cursuri de programare am aflat că în Java punctul de intrare în program este:

public static void main(string args) 

a fost nevoie de ani pentru a ajunge la punctul în care am înțeles fiecare parte a acestei semnături metodă.Chiar dacă mi s-ar fi explicat atunci, nu aș fi înțeles-o.Ar fi trebuit să înțeleg vizibilitatea metodei, clasa vs.metode de instanță, tipuri de returnare, tipuri de parametri, matrice (spre deosebire de liste/vectori), argumente în linia de comandă (și modul în care acestea sunt analizate de shell) și diverse detalii despre implementarea Java.

și asta e OK.Se pare că nu trebuie să înțelegeți nimic din aceste lucruri pentru a scrie linie de comandă sau chiar programe GUI în Java.

nu ne așteptăm ca noii dezvoltatori să cunoască dedesubturile fiecărei decizii pe care o iau.Pur și simplu nu au programat suficient de mult pentru a înțelege fiecare detaliu despre fiecare parte a stivei.

nici nu ne așteptăm să știe că magazinele git se angajează într-un grafic aciclic direcționat și fiecare ramură este un pointer către un nod din graph.It este suficient de bun ca ei să poată face git checkout și git commit și să-și continue munca.Și este suficient de bun dacă respectă o regulă precum” nu merge niciodată înainte „(sau”merge întotdeauna înainte”).

dar chiar și pentru dezvoltatorii seniori este inevitabil.Ce senior dev înțelege cu adevărat toate comenzile git pe care trebuie să le caute pe Stack Overflow?Sauawk șised porțiunea dintr-o singură linie pe care au căutat-o ieri pe GitHub?Sau fiecare antet din răspunsul HTTP cu care au răspuns API-ul aplicației web?Sau când să utilizați HTTPS vs. URL-ul SSH de la repo-ul dvs. GitHub?Sau cum să configurați cel mai bine instanța locală PostgreSQL?Sau instanța ta Neo4j?Sau cum să depanați configurarea rvm/rbenv/chruby / virtualenv fără să o aruncați și să o reconstruiți de la zero?

singura modalitate de a nu cargo cult este de a ști totul.Și nimeni nu știe totul.

cultura de marfă este bună

cultura de marfă este bună atunci când este utilizată responsibly.It ne scutește de a fi nevoiți să știm totul.Atunci când este utilizat bine, este actul de pârghie expertiza hard-a câștigat de toți ceilalți în domeniu.Fără îndoială, folosind orice abstractizare, la toate fără a înțelege cum funcționează (care este întregul punct de abstractizare!) este cultura încărcăturii prin definiția lui Lippert.

în plus, cultivarea încărcăturii este adesea o alegere bună.”Acești oameni par să știe ce fac, așa că le voi urma exemplul”, este o strategie perfect rațională.

de fapt, comunitatea de programare încurajează în mod activ cultul de marfă.Când le spunem oamenilor:” nu folosiți statul global „sau” urmați PEP8″, le spunem cultului cargo.De exemplu, un dezvoltator ar înțelege în mod ideal modurile subtile (uneori nu chiar așa) în care statul global te poate mușca, dar până când înțelegerea nu există, este mai bine să o eviți.

alte mari utilizări ale culturii de marfă:

• „convenție asupra configurației” așa cum se vede în șine (și nenumăratele sale clone), Django și Ember.JS
• ghiduri de stil și instrumentele lor, cum ar fi Rubocop, JSLint și auto PEP8
• multe instrumente de analiză statică, cum ar fi CodeClimate, Reek, Flay și Flog
• liniile directoare ale aplicației 12factor
• code smells

cum să cargo cult responsabil

evident, cargo culting are unele dezavantaje majore, dar acum am văzut și câteva părți în sus.Ne-ar plăcea să folosim instrumente și tehnici care fac treaba acum, fără a fi întotdeauna nevoiți să înțelegem pe deplin de ce funcționează.În loc să evităm cultul de marfă cu totul, cum putem culta în mod eficient?

marele avertisment: riscul inerent al cultivării încărcăturii este că nu veți putea prezice ce va merge prost sau chiar clasa de probleme pe care le puteți întâlni, deoarece în mod fundamental nu înțelegeți deciziile pe care le luați.Acestea fiind spuse, iată câteva sfaturi.

teste de scriere

puteți scrie teste automate pentru a vă asigura că codul dvs. funcționează conform așteptărilor, chiar dacă nu înțelegeți de ce funcționează codul.Un exemplu simplu ar fi dacă copiați și lipiți un algoritm de sortare din Stack Overflow, puteți scrie un test pentru a vă asigura că funcționează.

fiți atenți, totuși, deoarece testarea nu este la fel de bună pentru a dovedi că nu există efecte secundare neașteptate sau margine cases.In exemplul algoritmului de sortare, nu veți ști ce cazuri de margine trebuie să vă faceți griji.

Refactor fără milă

Mai curat vă păstrați codul, cu atât mai ușor va fi să motiv despre atunci când o decizie de marfă culted trebuie să fie schimbat.Și amintiți-vă, nu puteți refactor eficient fără teste.

izolați codul de cultură al încărcăturii

când este posibil, izolați codul de cultură al încărcăturii într-o clasă sau modul.Cu cât îl puteți izola mai mult, cu atât îi limitați daunele potențiale.De asemenea, cu cât este mai izolat, cu atât va fi mai ușor să înlocuiți sau să rescrieți odată ce înțelegeți mai multe despre el.

nu încărcați cult în părțile critice ale aplicației

de exemplu, dacă concurența ridicată este o necesitate absolută pentru aplicația dvs., probabil că nu puteți scăpa copiind un cod de filetare din depășirea stivei.Chiar și alegerea unui limbaj care gestionează în mod inerent concurența bine (cum ar fi Elixir, Go sau Clojure) nu vă va rezolva în mod magic problema.Din păcate (sau din fericire), va trebui cu adevărat să săpați și să învățați ceva.

nu cargo cult în cazul în care eșecul duce la lucruri rele se întâmplă

în cazul în care siguranța oamenilor, intimitate, bani, etc. sunt în pericol, nu încărcați cult.Ca un exemplu evident, dacă cineva ritm-maker rulează un anumit c One-liner ai copiat de la Stack Overflow, ai naibii-bine mai bine știi de ce funcționează micul tău truc și care sunt cazurile de eșec și efectele secundare.

evitați cultivarea încărcăturii atunci când aveți de-a face cu intrări variabile

de exemplu, dacă nu cunoașteți awk foarte bine și intrarea în awk one-liner va veni de la intrarea utilizatorului, este probabil să se rupă.Dacă puteți prezice diferitele forme pe care le poate lua intrarea dvs., acest lucru vă va ajuta, dar ar trebui să rețineți că este probabil să întrerupeți cazurile de intrare pe care nu le-ați putut prevedea.

Monitor în producție

doar pentru că funcționează pe mașina dvs., nu presupuneți că va funcționa în producție unde mediul diferă și utilizatorii fac lucruri pe care nu le-ați considerat niciodată.Monitorizarea erorilor, a excepțiilor, a eșecurilor de afirmare și a performanței vă poate anunța dacă ceva nu este în regulă înainte ca utilizatorii, clienții sau șeful dvs. să-și dea seama.

revizuirea Codului, programarea perechilor, instrumente de analiză statică etc.

ia alți ochi, virtuale sau altfel, să se uite la codul.Programarea perechilor și revizuirea codului sunt exemple evidente, dar instrumentele de analiză statică (de exemplu, CodeClimate) pot fi de asemenea utile.În afară de prinderea greșeli evidente, acestea sunt deosebit de utile pentru subliniind cod care ar putea să nu funcționeze întotdeauna cum era de așteptat.

treceți la o înțelegere mai profundă

începând cu cultivarea încărcăturii, atunci când decideți să vă scufundați adânc în subiect, veți avea deja un anumit context.Calea către o înțelegere mai profundă poate fi studiul de sine, mentoratul, programarea perechilor sau doar o faci singur de dragul învățării.

aceasta este o veste veche

sfaturile enumerate mai sus sunt probabil toate lucrurile pe care le-ați auzit înainte.Asta pentru că toți lucrăm cu cunoștințe limitate.Cu toții încărcăm cultul tot timpul și am dezvoltat intuiție, tehnici și orientări, astfel încât să putem merge mai departe cu cunoștințe parțiale și să limităm daunele pe care le putem face.Mai degrabă decât niciodată cultul de marfă, dezvoltatorii buni învață să cultul de marfă în mod eficient.