ik keek/luisterde naar deze geweldige talk van Simon Brown over modulaire monolieten uit GOTO 2018.
hierin noemt hij een term genaamd Cargo Cult Programming en dat raakte me echt.
ik ben onlangs toegetreden tot een nieuw bedrijf met een nieuwe programmeertaal, nieuwe tools, nieuwe processen en een nieuw team. Eigenlijk is het zo ’n beetje’ nieuw ‘ alles.
hierdoor heb ik de afgelopen maanden veel geleerd. Omdat ik relatief ervaren ben, kijk ik graag naar het ‘waarom’ in plaats van het ‘hoe’ bij het leren van nieuwe dingen. Wat ik me realiseerde is dat dit niet de meest voorkomende aanpak is.
wanneer een gebruiker wordt belast met het toevoegen aan een bestaande codebase, waardoor de huidige oplossing wordt uitgebreid, zullen zij hoogstwaarschijnlijk controleren hoe dit eerder is gedaan, door de aanpak voor hun oplossing te kopiëren. Ze kunnen / zullen blindelings volgen dit patroon als het is hoe het is eerder gedaan. Extra blokken worden toegevoegd op de top van de toren, zonder de vraag of het is de juiste ding om te doen. Als iedereen dit doet, zal dit uiteindelijk gebeuren.
Hier komt de term ‘Cargo Cult Programming’ vandaan.
Wikipedia legt het als volgt uit:
Cargo cult programmeren is een stijl van computerprogrammeren die wordt gekenmerkt door de rituele opname van code-of programmastructuren die geen echt doel dienen. Cargo cult programmeren is typisch symptomatisch voor een programmeur die niet begrijpt een bug ze probeerden op te lossen of de schijnbare oplossing (vergelijk shotgun debugging, deep magic). De term cargo cult programmeur kan van toepassing zijn wanneer een ongeschoolde of beginnende computer programmeur (of een onervaren met het probleem bij de hand) kopieert sommige programma code van de ene plaats naar de andere met weinig of geen begrip van hoe het werkt of of het nodig is in zijn nieuwe positie.
Cargo cult programmeren kan ook verwijzen naar de praktijk van het blind toepassen van een ontwerppatroon of codeerstijl zonder de redenen achter dat ontwerpprincipe te begrijpen. Voorbeelden zijn het toevoegen van onnodige opmerkingen aan zelfverklarende code, overijverige naleving van de conventies van een specifiek programmeerparadigma, of het toevoegen van verwijderingscode voor objecten die garbage collection automatisch zou hebben verzameld.
stel je een scenario voor waarin je aan een bug werkt en de code vindt die de fout veroorzaakt. Je weet niet zeker wat er gebeurt.;
- Google de fout.
- u vindt een StackOverflow-vraag.
- zoek naar het meest upticked antwoord.
- kopieer en plak de oplossing in uw code.
- probeer debuggen om te zien of dat uw probleem is opgelost.
het heeft, dus je checkt het in en gaat verder.
klinkt bekend?
Waarom doen we dat? Waarom nemen we dit fragment blindelings en gebruiken we het zoals het is, in onze implementatie?
de use case is waarschijnlijk niet hetzelfde, dus ik zou verbaasd zijn als de oplossingen waren. Eenvoudige voorbeelden terzijde, het begrijpen van de redenering achter de oplossing is belangrijker dan de oplossing zelf. Er zijn veel dingen die je niet kunt doen met iets wat je niet begrijpt. Je kunt het niet aanpassen, verbeteren of testen. Je kunt het niet documenteren en je kunt het niet bezitten.
we houden allemaal van wat nieuw is, en vooral het management lijkt het leuk te vinden om populaire trends te volgen en gelijke tred te houden met de technologische vooruitgang.
de meeste teams zullen nu een Agile aanpak volgen. TDD en geautomatiseerde testen kunnen zeer nuttig zijn in bepaalde scenario ‘ s, continue integratie verwijdert een groot deel van de overhead van het infrastructuurteam, Big Data en AI kan enorm verbeteren gebruikerstevredenheid en containerisatie en meest recent Microservices verschuiven onze oude monolith architectuur in kleinere zelfstandige diensten.
elk van deze ontwikkelingen is briljant op zichzelf, en Ik keur ze niet goed. Mijn hachelijke situatie is of we ze allemaal moeten overnemen in al onze processen en code? We zien blogberichten van Netflix, Facebook en Twitter die laten zien hoe hun gebruik de manier waarop ze werken heeft veranderd. Als grote bedrijven dat nodig achten, moeten wij dat dan ook niet doen? Dit is waar cargo cult programming weer zijn lelijke kop op steekt.
we moeten de problemen met onze huidige ontwerpen begrijpen, waarom ze zijn gebeurd en hoe ze in de toekomst kunnen worden weggegooid. Ja, deze nieuwe processen kunnen ons helpen met onze problemen, maar ze blindelings volgen in de vage hoop dat ze doen is niet de weg vooruit, noch heeft het enige logische zin.
ik noem Microservices in het bijzonder omdat veel bedrijven de overstap lijken te maken, waarbij ik de voordelen als:
- snellere ontwikkeltijd
- hoge schaalbaarheid
- gemakkelijk te verbeteren
- gemak van implementatie
- autonome teams met de vrijheid om technologie te kiezen
met een dergelijke lijst, wat valt er te denken over? Laten we allemaal op de bandwagon springen!
wacht even … zijn er nadelen aan deze aanpak?
- Architectonische Complexiteit
In monolithische architectuur, de complexiteit en het aantal afhankelijkheden wonen in de code base, terwijl in microservices architecturen complexiteit verschuift naar interacties van de individuele diensten die de uitvoering van een specifiek domein
- Operationele Complexiteit
- Hoe bepaling middelen in een schaalbare en kostenefficiënte manier
- Hoe werkt het tientallen of honderden microservice componenten effectief zonder vermenigvuldigen inspanningen
- Hoe om te gaan met een gebrek aan normen en heterogene omgevingen met verschillende technologieën en mensen met verschillende vaardigheden
- hoe om te gaan met versiebeheer
- hoe interacties in het hele systeem te volgen en te debuggen
- hoe honderden pijpleidingen van code-implementaties en hun onderlinge afhankelijkheden bij te houden
deze zijn ontleend aan Amazon ‘ s eigen whitepaper “Challenge of Microservices”. Ik weet niet hoe het met jou zit, maar de nadelen zien er veel enger uit dan de voordelen. Nogmaals, ik zeg niet dat dit niet de juiste aanpak is om naar beneden te gaan, maar tenzij deze voordelen opwegen tegen de nadelen wat wint u van het volgen van deze aanpak?
het “publieke” probleem.
het is heel eenvoudig, Stop met het gebruik van het publieke sleutelwoord, stop automatisch met het maken van publieke klassen. Waarom doen we het?
het probleem met het gebruik van het publieke sleutelwoord is dat u de voordelen met betrekking tot encapsulation mist. Waarom gebruiken we het zo vaak? Het is vrijwel het standaard woord dat we gebruiken bij het maken van klassen, alle voorbeelden zullen publieke klassen gebruiken, wizards en fragmenten zullen publieke klassen implementeren. Het is tijd om te stoppen. Hoeveel mensen hebben een openbare Facebook-account? De meeste dingen in deze wereld zijn privé, zoals onze lessen zouden moeten zijn. Maak ze standaard privé en als je ze openbaar wilt maken, verander ze dan.
met veel ervaring komt grote bezorgdheid.
hoe langer u in een veld bent, hoe minder naïef u bent om verbeteringen te ervaren die een nieuw gereedschap of proces met zich mee zal brengen. De meeste ideeën van vandaag komen uit tientallen jaren oud onderzoek op het gebied die eindelijk worden omarmd. Zodra iets massaal is aangenomen, is het makkelijker om je op je gemak te voelen met het volledig te omarmen. Dat wil zeggen, als het het juiste is om te doen.
“Good judgment comes from experience, and experience comes from bad judgment”
– Rita Mae Brown
dus voel je vrij om de interwebs te blijven doorzoeken naar oplossingen en tutorials voor je problemen; blijf nieuwe talen, frameworks en implementaties verkennen. Wees je bewust van waarom ze werken, in plaats van gewoon hoe. We leren allemaal van onze eigen ervaringen en fouten, dus het begrijpen van de fundamenten zal je ervan weerhouden om verder te gaan op dezelfde weg in de toekomst.