A Cargo kultusz elkerülhetetlen

vitathatatlan, hogy az új fejlesztők nem tudnak segíteni, de a cargo cult.Egyszerűen nem tanultak eleget a veremből, hogy valóban megértsék, mi folyik a motorháztető alatt, és miért kell a dolgokat bizonyos módon elvégezni.

például az egyik első programozási tanfolyamomon megtudtuk, hogy a Java-ban a program belépési pontja:

public static void main(String args)

évekbe telt, mire eljutottam arra a pontra, ahol megértettem a módszer aláírásának minden részét.Még ha akkor elmagyarázták volna nekem, akkor sem értettem volna meg.Meg kellett volna értenem a metódus láthatóságát, az osztály vs. példány metódusokat, a visszatérési típusokat, a paraméter típusokat, a tömböket (szemben a listákkal/vektorokkal), a parancssori argumentumokat (és azt, hogy a shell hogyan értelmezi őket), valamint a Java implementációjának különféle részleteit.

és ez rendben van.Kiderült, hogy alig kell megértenie ezeket a dolgokat, hogy parancssort vagy akár GUI programokat írjon Java – ban.

nem várjuk el, hogy az új fejlesztők ismerjék minden döntésük csínját-bínját.Csak nem programoztak elég régóta ahhoz, hogy megértsék a verem minden részletét.

azt sem várjuk el tőlük, hogy tudják, hogy a git stores elkötelezi magát egy irányított aciklusos gráfban, és minden ág egy mutató a graph.It ‘ s elég jó, hogy meg tudják csinálni git checkout és git commit és folytassa a munkát.És elég jó, ha olyan szabályt követnek, mint a “soha ne fast-forward merge” (vagy “mindig fast-forward merge”).

de még a vezető fejlesztők számára is elkerülhetetlen.Milyen senior dev valóban megérti az összes git parancsot, amelyet fel kell keresniük a Stack Overflow-n?Vagy a awk és sed része az egyvonalas néztek fel tegnap GitHub?Vagy a HTTP válasz minden fejlécével válaszol a webalkalmazás API-ja?Vagy mikor kell használni a HTTPS vs .. az SSH URL-t a GitHub repo-ból?Vagy hogyan lehet a legjobban konfigurálni a helyi PostgreSQL példányt?Vagy a Neo4j példányod?Vagy hogyan lehet hibakeresni az rvm/rbenv/chruby / virtualenv beállítást anélkül, hogy elfújná és újjáépítené a semmiből?

az egyetlen módja annak, hogy nem rakomány kultusz tudni mindent.És senki sem tud mindent.

A Rakománykultálás jó

a Rakománykultálás jó, ha használják responsibly.It megment minket attól, hogy mindent tudjunk.Ha jól használják, ez a cselekmény kihasználva a nehezen nyert szakértelem mindenki más a területen.Vitathatatlanul bármilyen absztrakció használata anélkül, hogy megértenénk, hogyan működik (ami az absztrakció lényege!) a rakománykultálás Lippert meghatározása szerint.

ezenkívül a rakománykultálás gyakran jó választás.”Úgy tűnik, hogy ezek az emberek tudják, mit csinálnak, ezért követem a vezetésüket” – ez egy tökéletesen racionális stratégia.

valójában a programozó közösség aktívan ösztönzi a rakománykultúrát.Amikor azt mondjuk az embereknek, hogy” ne használja a globális állapotot “vagy” kövesse a PEP8-at”, azt mondjuk nekik, hogy cargo cult.Például egy fejlesztő ideális esetben megértené azokat a (néha nem annyira) finom módszereket, amelyekkel a globális állam megharaphat, de amíg nincs megértés, jobb, ha csak elkerüljük.

a rakománykultálás néhány további nagyszerű felhasználása:

• “Convention over configuration”, mint a Rails (és számtalan klónja), Django és Ember.js
• stílus útmutatók és eszközeik, mint a Rubocop, JSLint, Auto PEP8
• sok statikus elemző eszközök, mint a CodeClimate, Reek, Flay, és Flog
• a 12factor app Irányelvek
• Kód szaga

hogyan cargo Cult felelősségteljesen

nyilvánvaló, hogy a cargo culting van néhány jelentős hátrányai, de most már láttuk néhány up-oldalán is.Szeretnénk olyan eszközöket és technikákat használni, amelyek most elvégzik a munkát, anélkül, hogy mindig teljesen meg kellene értenünk, miért működnek.Ahelyett, hogy teljesen elkerülnénk a rakománykultúrát, hogyan tudjuk hatékonyan szállítani a rakománykultust?

Az egyetlen nagy figyelmeztetés: a rakománykultálás eredendő kockázata az, hogy nem tudja megjósolni, mi fog rosszul menni, vagy akár a problémák osztályát, amellyel találkozhat, mert alapvetően nem érti a meghozott döntéseket.Hogy az említett, itt van néhány tipp.

írási tesztek

automatikus teszteket írhat annak biztosítására, hogy a kód a várt módon működjön, még akkor is, ha nem érti, miért működik a kód.Egy egyszerű példa lenne, ha másolja be a rendezési algoritmus Stack Overflow, akkor írjon egy tesztet, hogy megbizonyosodjon arról, hogy működik.

legyen óvatos, mert a tesztelés nem olyan jó annak bizonyításában, hogy nincsenek váratlan mellékhatások vagy edge cases.In a rendezési algoritmus példáján nem fogja tudni, hogy mely élesesetek miatt kell aggódnia.

Refactor könyörtelenül

a tisztább tartani a kódot, annál könnyebb lesz érvelni, ha a rakomány Kulturált döntést meg kell változtatni.Ne feledje, hogy tesztek nélkül nem lehet hatékonyan refaktorálni.

rakománykultált kód elkülönítése

ha lehetséges, izolálja a rakománykultált kódot egy osztályba vagy modulba.Minél jobban el tudja különíteni, annál inkább korlátozza a lehetséges károkat.Továbbá, minél elszigeteltebb, annál könnyebb lesz kicserélni vagy átírni, ha többet megértesz róla.

ne szállítson kultuszt az alkalmazás kritikus részeiben

például, ha a magas egyidejűség feltétlenül szükséges az alkalmazás számára, akkor valószínűleg nem tud megúszni néhány threading kód másolását a Stack Overflow-ból.Még egy olyan nyelv kiválasztása sem, amely eredendően jól kezeli a párhuzamosságot (például Elixir, Go vagy Clojure), nem fogja varázslatosan megoldani a problémát.Sajnos (vagy szerencsére), akkor tényleg meg kell ásni, és tanulni valamit.

ne szállítson kultuszt, ha a kudarc rossz dolgokhoz vezet

Ha az emberek biztonsága, magánélet, pénz stb. veszélyben vannak, nem rakomány kultusz.Nyilvánvaló példa, ha valaki ütemkészítője fut egy bizonyos C one-liner-t, amelyet a Stack Overflow-ból másolt, akkor jobban tudod, hogy miért működik a kis trükk, és mi a hiba és a mellékhatások.

kerülje a rakománykultálást, amikor változó bemenettel foglalkozik

például, ha nem ismeri az awk-t szuper jól, és az awk one-liner bemenete felhasználói bemenetből származik, akkor valószínűleg megszakad.Ha meg tudja jósolni a bemenet különböző formáit, az segít, de ne feledje, hogy valószínűleg megszakad olyan bemeneti esetekben, amelyeket nem tudott előre látni.

Monitor a gyártásban

csak azért, mert működik a gépen, ne feltételezze, hogy működni fog a gyártásban, ahol a környezet különbözik, és a felhasználók olyan dolgokat tesznek, amelyekre soha nem gondolt.A hibák, kivételek, állításhibák és teljesítmény figyelése értesítheti Önt, ha valami nincs rendben, mielőtt a felhasználók, az ügyfelek vagy a főnök észrevenné.

Kód áttekintés, páros programozás, statikus elemző eszközök stb.

kap más szemek, virtuális vagy más módon, hogy nézd meg a kódot.A páros programozás és a kód felülvizsgálata nyilvánvaló példák, de a statikus elemző eszközök (pl. CodeClimate) is hasznosak lehetnek.A nyilvánvaló hibák elkapása mellett különösen hasznosak olyan kódok rámutatására, amelyek nem mindig működnek a várt módon.

lépjen a mélyebb megértéshez

a rakománykultálással kezdve, amikor úgy dönt, hogy mélyen belemerül a témába, már lesz némi kontextusa.A mélyebb megértés útja lehet önálló tanulás, mentorálás, páros programozás, vagy csak a tanulás érdekében saját maga csinálja.

ez régi hír

a fent felsorolt tippek valószínűleg mindaz, amit korábban hallottál.Ez azért van, mert mindannyian korlátozott tudással dolgozunk.Mindannyian rakománykultusz vagyunk, és kifejlesztettünk intuíciókat, technikákat és irányelveket, így részleges ismeretekkel haladhatunk előre, és korlátozhatjuk az okozott károkat.Ahelyett, hogy soha cargo cult, jó fejlesztők megtanulják, hogy a cargo cult hatékonyan.