Cargo culting er uunngåelig

det er ukontroversielt at nye utviklere ikke kan hjelpe, men cargo cult.De har rett og slett ikke lært nok av stabelen for å virkelig forstå hva som skjer under hetten og hvorfor ting må gjøres på en bestemt måte.

for eksempel, i et av mine første programmeringskurs lærte vi At I Java er inngangspunktet til programmet:

offentlig statisk tomrom main(String args)

Det tok år å komme til det punktet hvor jeg forstår alle deler av den metoden signatur.Selv om det ble forklart for meg på den tiden, ville jeg ikke ha forstått det.Jeg ville ha måttet forstå metodesynlighet, klasse vs instansmetoder, returtyper, parametertyper ,arrays( i motsetning til lister / vektorer), kommandolinjeargumenter (og hvordan de analyseres av skallet) og ulike detaljer om Javas implementering.

og det er OK.Det viser seg at du knapt trenger å forstå noe av det for å skrive kommandolinje eller TIL OG MED GUI-programmer I Java.

Vi forventer ikke nye utviklere å vite ins og outs av hver beslutning de gjør.De har bare ikke programmert lenge nok til å forstå alle detaljer om alle deler av stabelen.vi forventer Heller ikke at de skal vite at git-butikkene forplikter seg i en rettet asyklisk graf, og hver gren er en peker til en node i graph.It er god nok til at de kan gjøre git checkout og git commit og fortsett med arbeidet sitt.Og det er godt nok hvis de følger en regel som » aldri spole fremover merge «(eller»alltid spole fremover merge»).

men selv for senior utviklere er det uunngåelig.Hvilken senior dev forstår virkelig alle git-kommandoene de må slå opp på Stack Overflow?Ellerawk ogsed delen av one-liner de så opp i går På GitHub?Eller hver header I HTTP-svaret de har deres WEBAPPLIKASJON API svare med?Eller når du skal bruke HTTPS vs SSH URL fra GitHub repo?Eller hvordan du best konfigurerer din lokale PostgreSQL-forekomst?Eller Din Neo4j-forekomst?Eller hvordan feilsøker du rvm / rbenv/chruby / virtualenv-oppsettet uten å blåse det bort og gjenoppbygge fra bunnen av?

Den eneste måten å ikke laste kult på er å vite alt.Og ingen vet alt.

Cargo culting er bra

Cargo culting er bra når det brukes responsibly.It sparer oss fra å måtte vite alt.Når det brukes godt, er det lov å utnytte hardt vunnet kompetansen til alle andre i feltet.Uten tvil, bruk noen abstraksjon i det hele tatt uten å forstå hvordan det fungerer (som er hele poenget med abstraksjon!) er cargo culting Etter Lipperts definisjon.

videre er cargo culting ofte et godt valg.»Disse menneskene ser ut til å vite hva de gjør, så jeg følger deres ledelse,» er en perfekt rasjonell strategi.

faktisk oppfordrer programmerings samfunnet aktivt cargo culting.Når vi forteller folk, «ikke bruk global stat «eller» følg PEP8″, forteller vi dem å laste kult.For eksempel vil en utvikler ideelt sett forstå (noen ganger ikke så) subtile måter global tilstand kan bite deg på, men til forståelsen er der, er det bedre å bare unngå det.

Noen andre gode bruksområder for cargo culting:

• «Konvensjon over konfigurasjon» som sett i Rails( og dets myriade kloner), Django og Ember.Js
• Stilguider og deres verktøy, Som Rubocop, JSLint og Auto PEP8
• mange statiske analyseverktøy, Som CodeClimate, Reek, Flay og Flog
• retningslinjene for 12factor app
• Kode lukter

Hvordan laste kult ansvarlig

selvfølgelig har lastkulting noen store ulemper, men nå har vi også sett noen opp sider.Vi vil gjerne bruke verktøy og teknikker som får jobben gjort nå, uten alltid å måtte forstå hvorfor de jobber.I stedet for å unngå lastkulting helt, hvordan kan vi laste kult effektivt?den ene store advarselen: den iboende risikoen for lastkulting er at du ikke vil kunne forutsi hva som vil gå galt, eller til og med klassen av problemer du kan støte på, fordi du fundamentalt ikke forstår de avgjørelsene du gjør.Når det er sagt, her er noen tips.

Skriv tester

du kan skrive automatiserte tester for å sikre at koden fungerer som forventet, selv om du ikke forstår hvorfor koden fungerer.Et enkelt eksempel ville være hvis du kopierer og limer inn en sorteringsalgoritme fra Stack Overflow, kan du skrive en test for den for å sikre at den fungerer.

Vær forsiktig, fordi testing ikke er så god til å bevise at det ikke er uventede bivirkninger eller kant cases.In eksemplet på sorteringsalgoritmen, du vet ikke hvilke kantsaker du trenger å bekymre deg for.

Refactor nådeløst

renere du holde koden, jo lettere vil det være å resonnere om når en last culted avgjørelse må endres.Og husk, du kan ikke refactor effektivt uten tester.

Isoler cargo culted kode

når det er mulig, isoler cargo culted kode i en klasse eller modul.Jo mer du kan isolere det, desto mer begrenser du potensiell skade.Også, jo mer isolert det er, desto lettere blir det å erstatte eller omskrive når du forstår mer om det.

ikke last kult i kritiske deler av appen din

For eksempel, hvis høy samtidighet er en absolutt nødvendighet for appen din, kan du sannsynligvis ikke komme unna med å kopiere noen threading-kode fra Stack Overflow.Selv å velge et språk som iboende håndterer samtidighet godt (Som Elixir, Go eller Clojure) vil ikke løse problemet ditt magisk.Dessverre (eller heldigvis), må du virkelig grave inn og lære noe.

ikke last kult hvis feil fører til dårlige ting skjer

hvis folks sikkerhet, personvern, penger, etc. er i fare, ikke last kult.Som et opplagt eksempel, hvis noens tempo-maker kjører en viss c one-liner du kopierte Fra Stack Overflow, du jævla-vel bedre vet hvorfor din lille trikset fungerer og hva svikt tilfeller og bivirkninger er.

Unngå cargo culting når du arbeider med varierende inngang

For eksempel, hvis du ikke kjenner awk super godt og inngangen til awk one-liner kommer fra brukerinngang, er det sannsynlig å bryte.Hvis du kan forutsi de forskjellige skjemaene dine kan ta, vil det hjelpe, men du bør huske på at det sannsynligvis vil bryte på innsatssaker du ikke kunne forutse.

Monitor i produksjon

Bare Fordi det fungerer på maskinen din, ikke anta at det vil fungere i produksjon der miljøet er forskjellig og brukere gjør ting du aldri har vurdert.Overvåking av feil, unntak, påstandsfeil og ytelse kan gi deg beskjed hvis noe er galt før brukerne, klientene eller sjefen innser det.

Kodegjennomgang, parprogrammering, statiske analyseverktøy, etc.

Få andre øyne, virtuelle eller på annen måte, for å se på koden din.Parprogrammering og kodegjennomgang er åpenbare eksempler, men statiske analyseverktøy (F.Eks. CodeClimate) kan også være nyttige.Foruten å fange åpenbare feil, er de spesielt nyttige for å peke ut kode som kanskje ikke alltid fungerer som forventet.

Flytt til dypere forståelse

ved å starte med cargo culting, når du bestemmer deg for å dykke dypt inn i emnet, har du allerede litt kontekst.Veien til dypere forståelse kan være selvstudium, veiledning, parprogrammering, eller bare gjøre det selv for læringens skyld.

dette er gamle nyheter

tipsene som er oppført ovenfor, er sannsynligvis alt du har hørt før.Det er fordi vi alle jobber med begrenset kunnskap.Vi laster alle kult hele tiden, og vi har utviklet intuisjon, teknikker og retningslinjer, slik at vi kan gå videre med delvis kunnskap og begrense skaden vi kan gjøre.Snarere enn aldri cargo cult, gode utviklere lære å laste kult effektivt.