jag tittade/lyssnade på detta fantastiska föredrag av Simon Brown på modulära monoliter från GOTO 2018.
i detta nämner han en term som heter Cargo Cult Programming och det slog verkligen ett ackord med mig.
jag har nyligen gått med i ett nytt företag med ett nytt programmeringsspråk, nya verktyg, nya processer och ett nytt team. Faktiskt, det är ganska mycket ’nytt’ allt.
detta har orsakat mig att göra en hel del lärande under de senaste månaderna. Att vara relativt erfaren, jag gillar att titta på ’whys’ snarare än ’hows’ när man lär sig nya saker. Vad jag har insett är att detta inte är det vanligaste tillvägagångssättet.
när en användare har till uppgift att lägga till en befintlig kodbas, utvidga den nuvarande lösningen, kommer de troligen att kontrollera hur detta har gjorts tidigare och kopiera metoden för deras lösning. De kan / kommer blint att följa detta mönster eftersom det är hur det har gjorts tidigare. Ytterligare block läggs till ovanpå tornet, utan att ifrågasätta om det är rätt sak att göra. Om alla gör det kommer det så småningom att hända.
det är här termen ’Cargo Cult Programming’ kommer ifrån.
Wikipedia förklarar det så här:
Cargo cult programmering är en typ av datorprogrammering som kännetecknas av rituell inkludering av kod eller programstrukturer som inte tjänar något verkligt syfte. Lastkultprogrammering är vanligtvis symptomatisk för en programmerare som inte förstår antingen en bugg som de försökte lösa eller den uppenbara lösningen (jämför shotgun debugging, deep magic). Termen cargo cult programmerare kan gälla när en okvalificerad eller nybörjare programmerare (eller en oerfaren med problemet till hands) kopierar någon programkod från en plats till en annan med liten eller ingen förståelse för hur det fungerar eller om det krävs i sin nya position.
Cargo cult programmering kan också hänvisa till praxis att tillämpa ett designmönster eller kodningsstil blint utan att förstå orsakerna bakom den designprincipen. Exempel är att lägga till onödiga kommentarer till självförklarande kod, överdriven efterlevnad av konventionerna för ett specifikt programmeringsparadigm eller lägga till raderingskod för objekt som skräpsamling skulle ha samlat in automatiskt.
Föreställ dig ett scenario där du arbetar med ett fel och hittar koden som orsakar felet. Du är inte massivt säker på vad som händer, så du;
- Google felet.
- du hittar en StackOverflow fråga.
- Sök efter det mest upticked svaret.
- kopiera och klistra in lösningen i din kod.
- försök felsöka för att se om det är fixat ditt problem.
det har, så du checkar in det och går vidare.
låter bekant?
Varför gör vi det? Varför tar vi blint detta utdrag och använder det som det är i vår implementering?
användningsfallet är förmodligen inte detsamma, så jag skulle bli förvånad om lösningarna var. Enkla exempel åt sidan, att förstå resonemanget bakom lösningen är viktigare än själva lösningen. Det finns många saker du inte kan göra med något du inte förstår. Du kan inte ändra, förbättra eller testa det. Du kan inte dokumentera det och du kan inte äga det.
vi älskar alla vad som är nytt, och ledningen verkar särskilt gilla att följa populära trender och hålla jämna steg med den tekniska utvecklingen.
de flesta lag kommer nu att följa ett agilt tillvägagångssätt. TDD och automatiserad testning kan vara mycket användbara i vissa scenarier, kontinuerlig Integration tar bort mycket av kostnaderna från infrastrukturteamet, Big Data och AI kan avsevärt förbättra användarnöjdheten och Containeriseringen och senast flyttar mikrotjänster vår gamla monolitarkitektur till mindre fristående tjänster.
var och en av dessa framsteg är lysande i sin egen rätt, och jag tolererar inte någon av dem. Min situation är om vi behöver anta dem alla i alla våra processer och kod? Vi ser blogginlägg från Netflix, Facebook, Twitter som visar hur deras användning har förändrat hur de fungerar. Om stora företag anser dem nödvändiga, borde vi inte också? Det är här lastkultprogrammering väcker sitt fula huvud igen.
vi måste förstå problemen med våra nuvarande mönster, varför de hände, och hur de kan jettisoned bort i framtiden. Ja, Dessa nya processer kan hjälpa oss med våra problem, men blint följa dem i svagt hopp om att de gör är inte vägen framåt, inte heller gör det någon logisk mening.
jag nämner mikrotjänster specifikt eftersom många företag verkar göra övergången och citerar sådana fördelar som:
- snabbare utvecklingstid
- hög skalbarhet
- lätt att förbättra
- enkel distribution
- autonoma team med friheten att välja teknik
med en lista som det, vad finns det att tänka på? Låt oss alla hoppa på tåget!
vänta en sekund … finns det några nackdelar med detta tillvägagångssätt?
- arkitektonisk komplexitet
i monolitiska arkitekturer ligger komplexiteten och antalet beroenden inuti kodbasen, medan komplexiteten i mikroservices-arkitekturer flyttar till interaktionerna mellan de enskilda tjänsterna som implementerar en specifik domän
- operativ komplexitet
- hur man tillhandahåller resurser på ett skalbart och kostnadseffektivt sätt
- hur man använder dussintals eller hundratals Mikroservicekomponenter effektivt utan att multiplicera ansträngningar
- hur man hanterar brist på standarder och heterogena miljöer som inkluderar olika tekniker och personer med olika kompetensuppsättningar
- hur man hanterar versionshantering
- hur man spårar och felsöker interaktioner över hela systemet
- hur man håller reda på hundratals pipelines av koddistributioner och deras ömsesidiga beroende
dessa lyfts från Amazons egen ”Challenge of Microservices” whitepaper. Nu vet jag inte om dig, men nackdelarna ser mycket skrämmande ut för mig än fördelarna. Återigen säger jag inte att detta inte är rätt sätt att gå ner, men om inte dessa fördelar uppväger nackdelarna, vad får du av att följa detta tillvägagångssätt?
det’ offentliga ’ problemet.
det är enkelt verkligen, sluta använda det offentliga nyckelordet, sluta automatiskt skapa offentliga klasser. Varför gör vi det?
problemet med att använda det offentliga nyckelordet är att du saknar fördelarna med inkapsling. Varför använder vi det så mycket? Det är ganska mycket standardordet vi använder när vi skapar klasser, alla exempel kommer att använda offentliga klasser, guider och utdrag kommer att implementera offentliga klasser. Det är dags att sluta. Hur många har ett offentligt Facebook-konto? De flesta saker i denna värld är privata, som våra klasser borde vara. Gör dem privata som standard, och om du behöver dem för att vara offentliga, ändra dem då.
med stor erfarenhet kommer stor oro.
ju längre du befinner dig i ett fält, desto mindre naiv är du för upplevda förbättringar som ett nytt verktyg eller en process kommer att medföra. De flesta av dagens tankar kommer från årtionden gammal forskning på området som äntligen omfamnas. När något har fått massadoption är det lättare att känna sig bekväm med att omfamna det fullt ut. Det är, om det är rätt sak att göra.
”gott omdöme kommer från erfarenhet, och erfarenhet kommer från dåligt omdöme”
– Rita Mae Brown
så känn dig fri att hålla på skur interwebs för lösningar och handledning till dina problem; hålla utforska nya språk, ramar och implementeringar. Var bara medveten om varför de fungerar, snarare än bara hur. Vi lär oss alla av våra egna erfarenheter och misstag, så att förstå grunderna kommer att hålla dig från att fortsätta på samma väg i framtiden.