sledoval jsem / poslouchal tento skvělý rozhovor Simona Browna o modulárních Monolitech z GOTO 2018.
v tomto zmiňuje termín nazvaný Cargo Cult programování a to opravdu udeřil akord se mnou.
nedávno jsem se připojil k nové společnosti s novým programovacím jazykem, novými nástroji, novými procesy a novým týmem. Vlastně je to skoro všechno „nové“.
to způsobilo, že jsem se v posledních měsících hodně učil. Být relativně zkušený, rád se při učení nových věcí dívám spíše na „whys“ než na „How“. Uvědomil jsem si, že to není nejběžnější přístup.
když je uživatel pověřen přidáním do existující kódové základny a rozšířením aktuálního řešení, pravděpodobně zkontroluje, jak to bylo provedeno dříve, a zkopíruje přístup k jejich řešení. Mohou / budou slepě následovat tento vzor, jak to bylo provedeno dříve. Další bloky se přidávají na vrchol věže, aniž by se ptali, zda je to správná věc. Pokud to všichni udělají, nakonec se to stane.
odtud pochází termín „Cargo Cult Programming“.
Wikipedia to vysvětluje takto:
programování Cargo cult je styl počítačového programování charakterizovaný rituálním začleněním kódových nebo programových struktur, které neslouží žádnému skutečnému účelu. Programování Cargo cult je typicky příznačné tím, že programátor nerozumí ani chybě, kterou se pokoušeli vyřešit ,ani zdánlivému řešení(porovnejte ladění brokovnice, deep magic). Termín cargo kult programátor může platit, když nekvalifikovaný nebo začínající počítačový programátor (nebo jeden nezkušený s problémem na dosah ruky) zkopíruje nějaký programový kód z jednoho místa na druhé s malou nebo žádnou pochopení toho, jak to funguje, nebo zda je požadováno ve své nové pozici.
programování Cargo cult může také odkazovat na praxi slepého použití návrhového vzoru nebo kódovacího stylu bez pochopení důvodů tohoto konstrukčního principu. Příkladem je přidání zbytečných komentářů k samovysvětlujícímu kódu, přílišné dodržování konvencí konkrétního programovacího paradigmatu nebo přidání odstraňovacího kódu pro objekty, které by sběr odpadků shromažďoval automaticky.
Představte si scénář, kdy pracujete na chybě a najdete kód, který způsobuje chybu. Nejste si jisti, co se děje, takže vy;
- Google chybu.
- najdete otázku StackOverflow.
- vyhledejte nejvíce upticked odpověď.
- zkopírujte a vložte řešení do kódu.
- zkuste ladění, abyste zjistili, zda je problém vyřešen.
to má, takže si to zkontrolovat a jít dál.
Zní to povědomě?
proč to děláme? Proč slepě bereme tento úryvek a používáme ho tak, jak je, v naší implementaci?
případ použití pravděpodobně není stejný, takže bych byl překvapen, kdyby řešení byla. Jednoduché příklady stranou, pochopení zdůvodnění řešení je důležitější než samotné řešení. Je mnoho věcí, které nemůžete dělat s něčím, čemu nerozumíte. Nemůžete jej upravovat, vylepšovat ani testovat. Nemůžete to zdokumentovat a nemůžete to vlastnit.
všichni milujeme to, co je nového, a zdá se, že vedení má rády populární trendy a drží krok s technologickým pokrokem.
většina týmů se nyní bude řídit agilním přístupem. TDD a automatizované testování mohou být v určitých scénářích velmi užitečné, nepřetržitá integrace odstraňuje velkou část režijních nákladů z týmu infrastruktury, velká Data a AI mohou výrazně zlepšit spokojenost uživatelů a Kontejnerizaci a v poslední době Mikroservisy přesouvají naši starou architekturu monolith na menší samostatné služby.
každý z těchto pokroků je sám o sobě skvělý a já žádný z nich neomlouvám. Mým problémem je, zda je musíme Všechny přijmout do všech našich procesů a kódu? Vidíme blogové příspěvky od Netflixu, Facebook, Twitter ukazuje, jak jejich použití změnilo způsob, jakým fungují. Pokud je velké společnosti považují za nezbytné, neměli bychom také? To je místo, kde programování cargo cult opět vychovává svou ošklivou hlavu.
musíme pochopit problémy s našimi současnými návrhy, proč k nim došlo a jak je lze v budoucnu odhodit. Ano, Tyto nové procesy nám mohou pomoci s našimi problémy, ale slepě je sledovat ve slabé naději, že to dělají, není cesta vpřed, ani to nedává žádný logický smysl.
zmiňuji Mikroservisy konkrétně, protože se zdá, že mnoho společností provádí přechod a cituje takové výhody jako:
- rychlejší vývojový čas
- vysoká škálovatelnost
- snadné vylepšení
- snadné nasazení
- autonomní týmy se svobodou volby technologie
s takovým seznamem, o čem je třeba přemýšlet? Pojďme všichni skočit do rozjetého vlaku!
počkejte chvíli … existují nějaké nevýhody tohoto přístupu?
- architektonická složitost
v monolitických architekturách se složitost a počet závislostí nachází uvnitř kódové základny, zatímco v architekturách mikroservisů se složitost pohybuje k interakcím jednotlivých služeb, které implementují konkrétní doménu
- provozní složitost
- jak poskytovat zdroje škálovatelným a nákladově efektivním způsobem
- jak efektivně provozovat desítky nebo stovky komponent mikroslužeb bez násobení úsilí
- jak se vypořádat s nedostatkem standardů a heterogenní prostředí, která zahrnují různé technologie a lidi s různými sadami dovedností
- jak se vypořádat s verzováním
- jak sledovat a ladit interakce v celém systému
- jak sledovat stovky potrubí nasazení kódu a jejich vzájemné závislosti
tyto jsou zvednuty z Amazonova vlastního whitepaperu „Challenge of Microservices“. Teď nevím jak vy, ale nevýhody mi připadají mnohem děsivější než výhody. Ještě jednou, neříkám, že to není správný přístup jít dolů, ale pokud tyto výhody nepřeváží nevýhody, co získáváte z tohoto přístupu?
„veřejný“ problém.
je to opravdu jednoduché, přestat používat veřejné Klíčové slovo, přestat automaticky vytvářet veřejné třídy. Proč to děláme?
problém s používáním veřejného klíčového slova je, že vám chybí výhody související s zapouzdřením. Proč ho tolik používáme? Je to do značné míry výchozí slovo, které používáme při vytváření tříd, všechny příklady budou používat veřejné třídy, průvodci a úryvky budou implementovat veřejné třídy. Je čas přestat. Kolik lidí má veřejný Facebook účet? Většina věcí na tomto světě je soukromá, stejně jako naše třídy. Ve výchozím nastavení je udělejte soukromými, a pokud je potřebujete, aby byly veřejné, změňte je.
s velkou zkušeností přichází velké obavy.
čím déle jste v poli, tím méně jste naivní, abyste vnímali vylepšení, která nový nástroj nebo proces přinese. Většina dnešních myšlenek pochází z desetiletí starého výzkumu v oboru, který je konečně přijat. Jakmile něco získalo masové přijetí, je snazší se cítit pohodlně s úplným přijetím. Tedy pokud je to správné.
„dobrý úsudek vychází ze zkušeností a zkušenosti pocházejí ze špatného úsudku“
– Rita Mae Brown
takže neváhejte pokračovat v prohledávání interwebů pro řešení a návody k vašim problémům; pokračujte v zkoumání nových jazyků, rámců a implementací. Jen si uvědomte, proč fungují, spíše než jednoduše jak. Všichni se učíme z vlastních zkušeností a chyb, takže pochopení základů vám v budoucnu zabrání pokračovat stejnou cestou.