Cargo culting är oundviklig
det är okontroversiellt att nya utvecklare inte kan låta bli cargo cult.De har helt enkelt inte lärt sig tillräckligt med stacken för att verkligen förstå vad som händer under huven och varför saker måste göras på ett visst sätt.
till exempel i en av mina första programmeringskurser lärde vi oss att i Java är ingångspunkten till programmet:
public static void main(String args)
det tog år att komma till den punkt där jag förstår varje del av den metodsignaturen.Även om det förklarades för mig då skulle jag inte ha förstått det.Jag skulle ha behövt förstå metodsynlighet, klass vs instansmetoder, returtyper, parametertyper, arrayer (i motsats till listor/vektorer), kommandoradsargument (och hur de analyseras av skalet) och olika detaljer om Java: s implementering.
och det är OK.Det visar sig att du knappast behöver förstå något av det där för att skriva kommandorad eller till och med GUI-program i Java.
vi förväntar oss inte att nya utvecklare ska känna till alla detaljer i varje beslut de fattar.De har bara inte programmerat tillräckligt länge för att förstå varje detalj om varje del av stapeln.
vi förväntar oss inte heller att de ska veta att git-butiker förbinder sig i en riktad acyklisk graf och varje gren är en pekare till en nod i graph.It är tillräckligt bra för att de kan göra git checkout och git commit och fortsätta med sitt arbete.Och det är tillräckligt bra om de följer en regel som ”aldrig snabbspolning framåt” (eller ”alltid snabbspolning framåt”).
men även för äldre utvecklare är det oundvikligt.Vilken senior dev förstår verkligen alla git-kommandon som de måste leta upp på Stack Overflow?Eller awk och sed delen av one-liner de tittade upp igår på GitHub?Eller varje rubrik i HTTP-svaret de har sin webbapplikation API svara med?Eller när du ska använda HTTPS vs. SSH URL från din GitHub repo?Eller hur konfigurerar du bäst din lokala PostgreSQL-instans?Eller din Neo4j-instans?Eller hur felsöker du din RVM/rbenv/chruby / virtualenv-inställning utan att blåsa bort den och bygga om från början?
det enda sättet att inte lastkult är att veta allt.Och ingen vet allt.
lastkult är bra
Lastkult är bra när den används responsibly.It räddar oss från att behöva veta allt.När den används väl, det är handlingen att utnyttja den svårvunna expertis alla andra i området.Förmodligen, att använda någon abstraktion alls utan att förstå hur det fungerar (vilket är hela abstraktionspunkten!) är lastkulting enligt Lipperts definition.
dessutom är lastkultning ofta ett bra val.”Dessa människor verkar veta vad de gör, så jag följer deras ledning” är en helt rationell strategi.
faktum är att programmeringsgemenskapen aktivt uppmuntrar lastkulturering.När vi säger till folk,” använd inte global stat ”eller” följ PEP8″, säger vi dem till cargo cult.Till exempel skulle en utvecklare helst förstå (ibland inte så) subtila sätt global state kan bita dig, men tills förståelsen är där är det bättre att bara undvika det.
några andra stora användningar av lastkult:
- ”konvention över konfiguration” som ses i Rails (och dess otaliga kloner), Django och Ember.JS
- stilguider och deras verktyg, som Rubocop, JSLint och Auto PEP8
- många statiska analysverktyg, som CodeClimate, Reek, Flay och Flog
- 12factor app guidelines
- kod luktar
hur man laddar kult ansvarsfullt
självklart har lastkult några stora nackdelar, men nu har vi sett några up-sidor, för.Vi skulle vilja använda verktyg och tekniker som får jobbet gjort nu, utan att alltid behöva förstå varför de fungerar.I stället för att undvika lastkult helt och hållet, hur kan vi lasta kult effektivt?
den enda stora försiktigheten: den inneboende risken för lastkultning är att du inte kommer att kunna förutsäga vad som kommer att gå fel, eller till och med den klass av problem du kan stöta på, för att du i grunden inte förstår de beslut du fattar.Som sagt, här är några tips.
skrivtester
Du kan skriva automatiska tester för att säkerställa att din kod fungerar som förväntat, även om du inte förstår varför koden fungerar.Ett enkelt exempel skulle vara om du kopierar och klistrar in en sorteringsalgoritm från Stack Overflow, kan du skriva ett test för att se till att det fungerar.
var försiktig, eftersom testning inte är lika bra för att bevisa att det inte finns oväntade biverkningar eller kant cases.In exemplet med sorteringsalgoritmen, du vet inte vilka kantfall du behöver oroa dig för.
Refactor skoningslöst
renare du håller koden, desto lättare blir det att resonera om när en last culted beslut behöver ändras.Och kom ihåg att du inte kan refactor effektivt utan test.
isolera Cargo culted code
om möjligt, isolera cargo culted code i en klass eller modul.Ju mer du kan isolera det, desto mer begränsar du dess potentiella skada.Ju mer isolerat det är desto lättare blir det att ersätta eller skriva om när du förstår mer om det.
ladda inte kult i kritiska delar av din app
till exempel, om hög samtidighet är en absolut nödvändighet för din app, kan du förmodligen inte komma undan med att kopiera någon trådkod från Stack Overflow.Även att välja ett språk som i sig hanterar samtidighet bra (som Elixir, Go eller Clojure) kommer inte att lösa ditt problem magiskt.Tyvärr (eller lyckligtvis) måste du verkligen gräva in och lära dig något.
Last inte kult om misslyckande leder till dåliga saker som händer
om människors säkerhet, integritet, pengar etc. är i riskzonen, inte Last kult.Som ett uppenbart exempel, om någons pace-maker kör en viss C-liner som du kopierade från Stack Overflow, vet du Jävla Bättre varför ditt lilla trick fungerar och vad felfall och biverkningar är.
Undvik lastkultning när du hanterar varierande inmatning
om du till exempel inte känner till awk super bra och inmatningen till din awk one-liner kommer från användarinmatning, är det troligt att det går sönder.Om du kan förutsäga de olika formerna som din inmatning kan ta, kommer det att hjälpa, men du bör komma ihåg att det sannolikt kommer att bryta på inmatningsfall som du inte kunde förutse.
Monitor i produktion
bara för att det fungerar på din maskin, antar inte att det kommer att fungera i produktion där miljön skiljer sig åt och användarna gör saker du aldrig övervägt.Övervakningsfel, undantag, påståendefel och prestanda kan låta dig veta om något är fel innan dina användare, kunder eller chef inser det.
kodgranskning, parprogrammering,statiska analysverktyg etc.
få andra ögon, virtuella eller på annat sätt, för att titta på din kod.Parprogrammering och kodgranskning är uppenbara exempel, men statiska analysverktyg (t.ex. CodeClimate) kan också vara till hjälp.Förutom att fånga uppenbara misstag är de särskilt användbara för att påpeka kod som kanske inte alltid fungerar som förväntat.
flytta till djupare förståelse
genom att börja med cargo culting, när du bestämmer dig för att dyka djupt in i ämnet har du redan något sammanhang.Vägen till djupare förståelse kan vara självstudier, mentorskap, parprogrammering eller bara göra det själv för lärandets skull.
det här är gamla nyheter
tipsen som räknas upp ovan är sannolikt alla saker du har hört tidigare.Det beror på att vi alla arbetar med begränsad kunskap.Vi lastar alla kult hela tiden och vi har utvecklat intuition, tekniker och riktlinjer så att vi kan gå vidare med delvis kunskap och begränsa den skada vi kan göra.Snarare än aldrig lastkult, lär bra utvecklare att lasta kult effektivt.
