Cargo culting er uundgåelig

det er ukontroversielt, at nye udviklere ikke kan hjælpe, men cargo cult.De har simpelthen ikke lært nok af stakken til virkelig at forstå, hvad der foregår under hætten, og hvorfor ting skal gøres på en bestemt måde.

for eksempel lærte vi i et af mine første programmeringskurser, at i Java er indgangspunktet til programmet:

public static void main(String args)

det tog år at komme til det punkt, hvor jeg forstår alle dele af denne metodesignatur.Selvom det blev forklaret for mig på det tidspunkt, ville jeg ikke have forstået det.Jeg ville have været nødt til at forstå metodesynlighed, klasse vs. instansmetoder, returtyper, parametertyper, arrays (i modsætning til lister/vektorer), kommandolinjeargumenter (og hvordan de analyseres af skallen) og forskellige detaljer om Java ‘ s implementering.

og det er OK.Det viser sig, at du næppe behøver at forstå noget af det for at skrive kommandolinje eller endda GUI-programmer i Java.

Vi forventer ikke, at nye udviklere kender ind og ud af enhver beslutning, de træffer.De har bare ikke programmeret længe nok til at forstå alle detaljer om hver del af stakken.

Vi forventer heller ikke, at de ved, at git-butikker forpligter sig i en rettet acyklisk graf, og hver gren er en peger til en node i graph.It ‘s godt nok, at de kan gøre git checkout og git commit og komme videre med deres arbejde.Og det er godt nok, hvis de følger en regel som “aldrig hurtig fremadfletning” (eller “altid hurtig fremadfletning”).

men selv for seniorudviklere er det uundgåeligt.Hvilken senior dev forstår virkelig alle de git-kommandoer, de skal slå op på stakoverløb?Ellerawk ogsed del af one-liner de kiggede op i går på GitHub?Eller hver overskrift i HTTP-svaret, de har deres API-API til at svare med?Eller hvornår skal du bruge HTTPS vs. SSH URL fra din GitHub repo?Eller hvordan du bedst konfigurerer din lokale postgraduate instans?Eller din Neo4j-forekomst?Eller hvordan debugger du din RVM/rbenv/chruby / virtualenv-opsætning uden at sprænge den væk og genopbygge fra bunden?

den eneste måde at ikke fragtkult på er at vide alt.Og ingen ved alt.

Cargo culting er god

Cargo culting er god, når den bruges responsibly.It sparer os fra at skulle vide alt.Når det bruges godt, er det handlingen at udnytte den hårdt vundne ekspertise hos alle andre på området.Formentlig ved at bruge nogen abstraktion overhovedet uden at forstå, hvordan det virker (hvilket er hele abstraktionens punkt!) er cargo culting efter Lipperts definition.

desuden er godskultur ofte et godt valg.”Disse mennesker ser ud til at vide, hvad de laver, så jeg følger deres ledelse,” er en perfekt rationel strategi.

faktisk tilskynder programmeringssamfundet aktivt til godskultur.Når vi fortæller folk, “brug ikke global stat” eller “følg PEP8”, fortæller vi dem til cargo cult.For eksempel vil en udvikler ideelt forstå de (nogle gange ikke så) subtile måder global stat kan bide dig, men indtil forståelsen er der, er det bedre at bare undgå det.

nogle andre store anvendelser af cargo culting:

• “Convention over configuration” som det ses i Rails (og dets utallige kloner), Django og Ember.JS
• stilguider og deres værktøjer, som Rubocop, JSLint og Auto PEP8
• mange statiske analyseværktøjer, som CodeClimate, Reek, Flay og Flog
• 12factor app guidelines
• kode lugter

sådan cargo cult ansvarligt

det er klart, at cargo culting har nogle store ulemper, men nu har vi også set nogle op-sider.Vi vil gerne bruge værktøjer og teknikker, der får jobbet gjort nu, uden altid at skulle forstå fuldt ud, hvorfor de fungerer.I stedet for at undgå lastkultning helt, hvordan kan vi fragtkult effektivt?

den ene store advarsel: den iboende risiko for lastkulting er, at du ikke vil være i stand til at forudsige, hvad der vil gå galt, eller endda den klasse af problemer, du måtte støde på, fordi du grundlæggende ikke forstår de beslutninger, du tager.Det sagt, her er et par tip.

skriv test

Du kan skrive automatiserede tests for at sikre, at din kode fungerer som forventet, selvom du ikke forstår, hvorfor koden fungerer.Et simpelt eksempel ville være, hvis du kopierer og indsætter en sorteringsalgoritme fra stakoverløb, kan du skrive en test for den for at sikre, at den fungerer.

Vær dog forsigtig, fordi test ikke er så god til at bevise, at der ikke er uventede bivirkninger eller kant cases.In eksemplet med sorteringsalgoritmen, du ved ikke, hvilke kantsager du skal bekymre dig om.

Refactor nådesløst

jo renere du holder koden, jo lettere vil det være at begrunde, hvornår en lastkulturel beslutning skal ændres.Og husk, Du kan ikke refactor effektivt uden test.

Isoler cargo culted code

når det er muligt, isoler cargo culted code i en klasse eller et modul.Jo mere du kan isolere det, jo mere begrænser du dets potentielle skade.Jo mere isoleret det er, jo lettere bliver det at erstatte eller omskrive, når du først har forstået mere om det.

må ikke cargo cult i kritiske dele af din app

for eksempel, hvis høj samtidighed er en absolut nødvendighed for din app, du sandsynligvis ikke kan slippe af sted med at kopiere nogle tråde kode fra stak overløb.Selv at vælge et sprog, der iboende håndterer samtidighed godt (som eliksir, Go eller Clojure) vil ikke magisk løse dit problem.Desværre (eller heldigvis) bliver du virkelig nødt til at grave dig ind og lære noget.

lad ikke lastkult, hvis fiasko fører til dårlige ting, der sker

Hvis folks sikkerhed, privatliv, penge osv. er i fare, ikke fragtkult.Som et indlysende eksempel, hvis en persons tempo-maker kører en bestemt C one-liner, du kopierede fra stakoverløb, ved du bedre, hvorfor dit lille trick fungerer, og hvad fejlsager og bivirkninger er.

undgå cargo culting, når der beskæftiger sig med varierende input

for eksempel, hvis du ikke kender yok super godt, og input til din yok one-liner kommer fra brugerinput, vil det sandsynligvis gå i stykker.Hvis du kan forudsige de forskellige former, dit input kan tage, vil det hjælpe, men du skal huske på, at det sandsynligvis vil bryde på inputsager, du ikke kunne forudse.

Monitor i produktion

bare fordi det virker på din maskine, må du ikke antage, at det vil fungere i produktion, hvor miljøet er forskelligt, og brugerne gør ting, du aldrig har overvejet.Overvågning af fejl, undtagelser, påstandsfejl og ydeevne kan fortælle dig, om der er noget galt, før dine brugere, klienter eller chef er klar over det.

Kodeanmeldelse, parprogrammering, statiske analyseværktøjer osv.

få andre øjne, virtuelle eller på anden måde, til at se på din kode.Par programmering og kode gennemgang er indlysende eksempler, men statiske analyseværktøjer (f.eks CodeClimate) kan være nyttige, også.Udover at fange åbenlyse fejl, de er især nyttige til at påpege kode, der måske ikke altid fungerer som forventet.

Flyt til dybere forståelse

ved at starte med cargo culting, når du beslutter dig for at dykke dybt ind i emnet, har du allerede en vis sammenhæng.Vejen til dybere forståelse kan være selvstudium, mentoring, parprogrammering eller bare gøre det selv for læringens skyld.

dette er gamle nyheder

de tips, der er nævnt ovenfor, er sandsynligvis alle ting, du har hørt før.Det er fordi vi alle arbejder med begrænset viden.Vi alle cargo cult hele tiden, og vi har udviklet intuition, teknikker og retningslinjer, så vi kan komme videre med delvis viden og begrænse den skade, vi kan gøre.I stedet for aldrig cargo cult lærer gode udviklere at cargo cult effektivt.