Cargo culting is onvermijdelijk

Het is onbetwistbaar dat nieuwe ontwikkelaars niet anders kunnen dan cargo cult.Ze hebben gewoon niet genoeg geleerd van de stapel om echt te begrijpen wat er gaande is onder de motorkap en waarom dingen moeten worden gedaan op een bepaalde manier.

bijvoorbeeld, in een van mijn eerste programmeercursussen leerden we dat in Java het beginpunt van het programma is:

public static void main(String args)

het duurde jaren voordat ik elk deel van die handtekening van die methode begreep.Zelfs als het me toen was uitgelegd, had ik het niet begrepen.Ik zou hebben gehad om methode zichtbaarheid te begrijpen, klasse vs.instance methoden, return types, parameter types, arrays (in tegenstelling tot lijsten/vectoren), command line argumenten (en hoe ze worden ontleed door de shell), en verschillende details over Java ‘ s implementatie.

en dat is OK.Het blijkt dat je nauwelijks hoeft te begrijpen een van die dingen te schrijven command line of zelfs GUI programma ‘ s in Java.

We verwachten niet dat nieuwe ontwikkelaars de ins en outs kennen van elke beslissing die ze nemen.Ze programmeren alleen nog niet lang genoeg om elk detail van elk deel van de stapel te begrijpen.

noch verwachten we dat ze weten dat Git commits opslaat in een gerichte acyclische grafiek en dat elke branch een pointer is naar één node in de graph.It is goed genoeg dat ze git checkout en git commit kunnen doen en verder kunnen gaan met hun werk.En het is goed genoeg als ze een regel volgen als ” never fast-forward merge “(of”always fast-forward merge”).

maar zelfs voor senior ontwikkelaars is het onvermijdelijk.Welke senior dev begrijpt echt alle Git commando ‘ s die ze moeten opzoeken op Stack Overflow?Of hetawk ensed gedeelte van de one-liner die ze gisteren op GitHub hebben opgezocht?Of elke header in de HTTP-reactie hebben ze hun webapplicatie API reageren met?Of wanneer gebruik je de HTTPS VS. de SSH URL van je GitHub repo?Of hoe configureer je lokale PostgreSQL instantie het best?Of je Neo4j instantie?Of hoe te om uw RVM/rbenv/chruby/virtualenv opstelling te debuggen zonder het weg te blazen en van nul te herbouwen?

de enige manier om niet te cargo cult is om alles te weten.En niemand weet alles.

culteren van lading is goed

culteren van lading is goed bij gebruik responsibly.It dan hoeven we niet alles te weten.Wanneer het goed wordt gebruikt, is het de handeling van het benutten van de hard-wonde expertise van iedereen in het veld.Zonder te begrijpen hoe het werkt (wat het hele punt van abstractie is!) is cargo culting volgens Lippert ‘ s definitie.

bovendien is het culteren van vracht vaak een goede keuze.”Deze mensen lijken te weten wat ze doen, dus Ik zal hun voorbeeld volgen,” is een perfect rationele strategie.

in feite moedigt de programmeringsgemeenschap het cultiveren van vracht actief aan.Als we tegen mensen zeggen: “gebruik Geen global state” of “volg PEP8”, zeggen we dat ze cult moeten vervoeren.Een ontwikkelaar zou bijvoorbeeld idealiter de (soms niet zo) subtiele manieren begrijpen waarop global state je kan bijten, maar totdat het begrip er is, is het beter om het gewoon te vermijden.

enkele andere grote toepassingen van cargo culting:

• “Convention over configuration” zoals te zien in Rails (en zijn talloze klonen), Django, en Ember.js
• Style guides en hun tools, zoals Rubocop, JSLint, en Auto PEP8
• veel statische analyse tools, zoals CodeClimate, Reek, Flay, en Flog
• de 12factor app guidelines
• Code smells

How To cargo Cult responsibly

uiteraard heeft cargo culting een aantal belangrijke nadelen, maar nu hebben we ook een aantal positieve kanten gezien.We willen graag tools en technieken gebruiken die de klus nu klaren, zonder altijd volledig te hoeven begrijpen waarom ze werken.Hoe kunnen we, in plaats van cargo culting helemaal te vermijden, effectief cargo cult?

het enige grote voorbehoud: het inherente risico van cargo culting is dat je niet in staat zult zijn om te voorspellen wat er mis zal gaan, of zelfs de klasse van problemen die je kunt tegenkomen, omdat je fundamenteel niet begrijpt welke beslissingen je neemt.Dat gezegd hebbende, hier zijn een paar tips.

schrijf tests

u kunt geautomatiseerde tests schrijven om ervoor te zorgen dat uw code werkt zoals verwacht, zelfs als u niet begrijpt waarom de code werkt.Een eenvoudig voorbeeld zou zijn als je een sorteeralgoritme kopieert en plakt van Stack Overflow, dan kun je er een test voor schrijven om er zeker van te zijn dat het werkt.

wees echter voorzichtig, omdat testen niet zo goed is om aan te tonen dat er geen onverwachte bijwerkingen of randverschijnselen zijn cases.In het voorbeeld van het sorteeralgoritme, u zult niet weten over welke randgevallen u zich zorgen moet maken.

refactor genadeloos

hoe schoner u de code bewaart, hoe gemakkelijker het zal zijn om te redeneren wanneer een cargo culted beslissing moet worden gewijzigd.En vergeet niet, je kunt niet effectief refactor zonder tests.

isoleer de code van de gecultiveerde lading

indien mogelijk, isoleer de code van de gecultiveerde lading in een klasse of module.Hoe meer je het kunt isoleren, hoe meer je de potentiële schade beperkt.Ook, hoe meer geïsoleerd het is, hoe gemakkelijker het zal zijn om te vervangen of te herschrijven als je er meer over begrijpt.

cargo cult niet in kritieke delen van uw app

bijvoorbeeld, als hoge concurrency een absolute noodzaak is voor uw app, kunt u waarschijnlijk niet wegkomen met het kopiëren van een aantal threading code van Stack Overflow.Zelfs het kiezen van een taal die inherent omgaan concurrency goed (zoals Elixir, Go, of Clojure) zal niet magisch uw probleem op te lossen.Helaas (of gelukkig), je zult echt moeten graven in en iets leren.

cargo cult niet als falen leidt tot slechte dingen gebeuren

als de veiligheid van mensen, privacy, geld, enz. zijn in gevaar, niet cult cargo.Als een voor de hand liggend voorbeeld, als iemands pace-maker een bepaalde C one-liner draait die je van Stack Overflow hebt gekopieerd, kun je verdomd goed beter weten waarom je kleine truc werkt en wat de mislukkings gevallen en bijwerkingen zijn.

vermijd cargo culting bij het omgaan met wisselende invoer

bijvoorbeeld, als u awk niet super goed kent en de invoer naar uw awk one-liner van gebruikersinvoer komt, is het waarschijnlijk te breken.Als je de verschillende vormen kunt voorspellen die je invoer kan aannemen, zal dat helpen, maar je moet in gedachten houden dat het waarschijnlijk zal breken op invoergevallen die je niet kon voorzien.

Monitor in productie

alleen omdat het werkt op uw machine, neem niet aan dat het zal werken in productie waar de omgeving verschilt en gebruikers dingen doen die je nooit overwogen hebt.Het controleren van fouten, uitzonderingen, assertiefouten en prestaties kan u laten weten of er iets mis is voordat uw gebruikers, klanten of baas het zich realiseren.

code beoordeling, paar programmering, statische analyse tools, enz.

laat andere ogen, virtueel of anderszins, naar uw code kijken.Pair programming en code review zijn voor de hand liggende voorbeelden, maar statische analysetools (bijvoorbeeld CodeClimate) kunnen ook nuttig zijn.Naast het vangen van voor de hand liggende fouten, ze zijn vooral nuttig voor het wijzen op code die misschien niet altijd werken zoals verwacht.

Ga naar een dieper begrip

door te beginnen met cargo culting, als je besluit om diep in het onderwerp te duiken heb je al een context.Het pad naar dieper begrip kan zelfstudie, mentoring, pair programmeren, of gewoon doen het zelf voor het belang van het leren.

dit is oud nieuws

de tips hierboven opgesomd zijn waarschijnlijk alle dingen die je eerder hebt gehoord.Dat komt omdat we allemaal werken met beperkte kennis.We hebben allemaal de hele tijd gecultiveerd en we hebben intuïtie, technieken en richtlijnen ontwikkeld zodat we verder kunnen met gedeeltelijke kennis en de schade kunnen beperken die we kunnen aanrichten.In plaats van nooit cargo cult, goede ontwikkelaars leren om cargo cult effectief.