Cargo culting on väistämätöntä

on kiistatonta, että uudet kehittäjät eivät voi muuta kuin cargo cult.He eivät yksinkertaisesti ole oppineet pinosta tarpeeksi ymmärtääkseen, mitä konepellin alla tapahtuu ja miksi asiat pitää tehdä tietyllä tavalla.

esimerkiksi yhdellä ensimmäisistä ohjelmointikursseistani opimme, että Java-kielessä ohjelman aloituspiste on:

public staattinen void main(String args)

kesti vuosia päästä siihen pisteeseen, että ymmärsin tuon metodin allekirjoituksen jokaisen osan.Vaikka se olisi selitetty minulle silloin, en olisi ymmärtänyt sitä.Olisin ollut ymmärtää menetelmän näkyvyyttä, Luokka vs. esimerkiksi menetelmiä, return tyypit, parametrityypit, taulukot (toisin kuin luettelot/vektorit), komentorivi argumentit (ja miten ne jäsennellään komentotulkki), ja erilaisia yksityiskohtia Java täytäntöönpanoa.

ja se on OK.On käynyt ilmi, että sinun tuskin tarvitsee ymmärtää mitään näistä asioista kirjoittaa komentorivin tai jopa GUI ohjelmia Java.

emme odota uusien kehittäjien tietävän jokaisen tekemänsä päätöksen yksityiskohtia.He eivät vain ole ohjelmoineet tarpeeksi kauan ymmärtääkseen jokaista yksityiskohtaa pinon jokaisessa osassa.

emme myöskään odota heidän tietävän, että git stores sitoutuu suunnattuun asykliseen kaavioon ja jokainen haara on osoitin yhteen solmuun graph.It ” s good enough that they can do git checkout and git commit and get on their work.Ja se on tarpeeksi hyvä, jos he noudattavat sääntöä, kuten ” ei koskaan pikakelata yhdistämistä ”(tai”aina pikakelattu yhdistäminen”).

mutta vanhemmillekin kehittäjille se on väistämätöntä.Kuka vanhempi dev todella ymmärtää kaikki git-komennot, joita heillä on etsiä Stack Overflow ’ sta?Tai awk ja sed osa one-linerista, jota he katsoivat eilen GitHubilla?Tai jokainen otsikko HTTP vastaus heillä on web-sovellus API vastata?Tai milloin käyttää HTTPS vs. SSH URL teidän GitHub repo?Tai miten parhaiten määrittää paikallisen PostgreSQL-instanssin?Tai Neo4j-instanssisi?Tai miten debug RVM / rbenv / chruby / virtualenv setup puhaltamatta sitä pois ja uudelleenrakentaminen tyhjästä?

ainoa tapa olla lastikultti on tietää kaikki.Eikä kukaan tiedä kaikkea.

Lastinjalostus on hyvä

Lastinjalostus on hyvä käytössä responsibly.It ei tarvitse tietää kaikkea.Kun sitä käytetään hyvin, se on teko, jolla hyödynnetään kaikkien muiden alalla olevien kovalla työllä hankittua osaamista.Luultavasti, käyttäen mitään abstraktiota lainkaan ymmärtämättä, miten se toimii (joka on koko pointti abstraktio!) on lippertin määritelmän mukaan lastinkuljetusta.

lisäksi lastinkuljetus on usein hyvä valinta.”Nämä ihmiset näyttävät tietävän mitä tekevät, joten seuraan heidän esimerkkiään”, on täysin järkevä strategia.

itse asiassa ohjelmointiyhteisö kannustaa aktiivisesti lastinkulttaukseen.Kun sanomme ihmisille, ” Älä käytä globaalia valtiota ”tai” seuraa PEP8: aa”, kehotamme heitä lastikulttiin.Esimerkiksi Kehittäjä mieluiten ymmärtää (joskus ei niin) hienovarainen tapoja globaali valtio voi purra sinua, mutta kunnes ymmärrys on olemassa, se on parempi vain välttää sitä.

muita suuria lastinkulttauksen käyttötarkoituksia:

• ”Convention over configuration”, kuten Rails (and its myriad clones), Django ja Ember.js
• tyylioppaat ja niiden työkalut, kuten Rubocop, JSLint ja Auto PEP8
• monet staattiset analyysityökalut, kuten CodeClimate, löyhkä, Flay ja Flog
• 12factor app guidelines
• Code smells

How to cargo cult responsible

ilmeisesti, cargo cultingilla on joitain suuria varjopuolia, mutta nyt on nähty myös nousevia puolia.Haluamme käyttää työkaluja ja tekniikoita, joilla homma hoituu nyt ilman, että aina tarvitsee täysin ymmärtää, miksi ne toimivat.Sen sijaan, että välttäisimme lastikultin kokonaan, miten voimme lastata kultin tehokkaasti?

yksi suuri varoitus: lastin kulottamisen luontainen riski on se, että et pysty ennustamaan, mikä menee vikaan, tai edes kohtaamiesi ongelmien luokkaa, koska et pohjimmiltaan ymmärrä tekemiäsi päätöksiä.Se sanoi, Tässä on muutamia vinkkejä.

Kirjoita testit

voit kirjoittaa automaattisia testejä varmistaaksesi, että koodi toimii odotetusti, vaikka et ymmärtäisikään miksi koodi toimii.Yksinkertainen esimerkki olisi, jos kopioit ja liität lajittelualgoritmin pinon ylivuodosta, voit kirjoittaa sille testin varmistaaksesi, että se toimii.

ole kuitenkin varovainen, sillä testaus ei ole yhtä hyvä todistamaan, ettei odottamattomia sivuvaikutuksia tai reunaa ole cases.In lajittelualgoritmin esimerkistä et tiedä, mistä reunatapauksista kannattaa olla huolissaan.

Refactor armottomasti

mitä puhtaammin koodia pitää, sitä helpompi on järkeillä, milloin lastin purkupäätöstä pitää muuttaa.Muista, että ilman testejä ei voi toimia tehokkaasti.

eristetään lopetettu lastikoodi

, Jos mahdollista, eristetään lopetettu lastikoodi luokkaan tai moduuliin.Mitä enemmän voit eristää sen, sitä enemmän rajoitat sen mahdollisia vaurioita.Myös, enemmän eristetty se on, sitä helpompi se on korvata tai kirjoittaa, Kun ymmärrät enemmän siitä.

älä lastaa kulttia sovelluksesi kriittisissä osissa

esimerkiksi, jos Korkea samanaikaisuus on sovelluksellesi ehdoton välttämättömyys, et luultavasti pääse pälkähästä kopioimalla jotain ketjukoodia Stack Overflowista.Jopa valitsemalla kieli, joka luonnostaan käsittelee samanaikaisuutta hyvin (kuten Elixir, Go tai Clojure) ei maagisesti ratkaise ongelmaasi.Valitettavasti (tai onneksi), sinun todella täytyy kaivaa ja oppia jotain.

älä lastaa kulttia, jos epäonnistuminen johtaa ikävien asioiden tapahtumaan

Jos ihmisten turvallisuus, yksityisyys, raha jne. ovat vaarassa, älä lastikultti.Ilmiselvänä esimerkkinä, jos jonkun vauhti-maker ajaa tietty C one-liner kopioinut Stack Overflow, sinun hitto-no parempi tietää, miksi pikku temppu toimii ja mitä vika tapauksissa ja sivuvaikutuksia ovat.

Vältä lastinkulttausta, kun käsittelet vaihtelevia syötteitä

esimerkiksi, jos et tunne awk: ta erittäin hyvin ja awk one-linerisi syöttö tulee käyttäjän syötteestä, se todennäköisesti rikkoutuu.Jos voit ennustaa eri muotoja syöte voi ottaa, se auttaa, mutta sinun pitäisi pitää mielessä, että se on todennäköisesti rikkoa syöte tapauksissa et voinut ennakoida.

Monitor in production

vain siksi, että se toimii koneessasi, älä oleta sen toimivan tuotannossa, jossa ympäristö on erilainen ja käyttäjät tekevät asioita, joita et ole koskaan ajatellut.Seuranta virheitä, poikkeuksia, väitteen epäonnistumisia, ja suorituskyky voi kertoa, jos jotain on vialla ennen kuin käyttäjät, asiakkaat, tai pomo ymmärtää sen.

koodikatselmus, pariohjelmointi, staattiset analyysityökalut jne.

Hanki muut silmät, virtuaaliset tai muut, katsomaan koodiasi.Pariohjelmointi ja koodikatselmus ovat ilmeisiä esimerkkejä, mutta myös staattiset analyysityökalut (esim.CodeClimate) voivat olla hyödyllisiä.Sen lisäksi kiinni ilmeisiä virheitä, ne ovat erityisen hyödyllisiä huomauttaa koodi, joka ei ehkä aina toimi odotetulla tavalla.

Siirry syvempään ymmärrykseen

aloittamalla lastinkulttauksesta, kun päätät sukeltaa syvälle aiheeseen, sinulla on jo jonkinlainen konteksti.Polku syvempään ymmärrykseen voi olla itseopiskelu, mentorointi, pariohjelmointi tai vain sen tekeminen itse oppimisen vuoksi.

tämä on vanha uutinen

yllä luetellut vinkit ovat todennäköisesti kaikki asiat, joita olet kuullut aiemmin.Se johtuu siitä, että meillä kaikilla on rajallinen tietämys.Me kaikki lastaamme kulttia koko ajan ja olemme kehittäneet intuitiota, tekniikoita ja ohjeita, jotta voimme siirtyä eteenpäin osittaisella tiedolla ja rajoittaa tekemäämme vahinkoa.Sen sijaan, että ei koskaan cargo cult, hyvät kehittäjät oppivat cargo cult tehokkaasti.