jeg så / lyttede til denne store tale af Simon brun på modulære monolitter fra GOTO 2018.
i dette nævner han et udtryk kaldet Cargo Cult programmering, og det slog virkelig en akkord med mig.
jeg er for nylig blevet medlem af et nyt firma med et nyt programmeringssprog, nye værktøjer, nye processer og et nyt team. Faktisk er det stort set’ nyt ‘ alt.
dette har fået mig til at gøre en masse læring i de seneste måneder. Da jeg er relativt erfaren, kan jeg godt lide at undersøge ‘hvorfor’ snarere end ‘hvordan’, når jeg lærer nye ting. Hvad jeg har indset er, at dette ikke er den mest almindelige tilgang.
når en bruger har til opgave at tilføje til en eksisterende kodebase og udvide den aktuelle løsning, vil de sandsynligvis kontrollere, hvordan dette er gjort tidligere, og kopiere tilgangen til deres løsning. De kan / vil blindt følge dette mønster, da det er sådan, det er blevet gjort før. Yderligere blokke tilføjes oven på tårnet uden at stille spørgsmålstegn ved, om det er den rigtige ting at gøre. Hvis alle gør dette, vil dette til sidst ske.
det er her udtrykket ‘Cargo Cult Programming’ kommer fra.
Cargo cult programmering er en stil af computerprogrammering, der er kendetegnet ved den rituelle inkludering af kode-eller programstrukturer, der ikke tjener noget reelt formål. Cargo cult programmering er typisk symptomatisk for en programmør, der ikke forstår enten en fejl, de forsøgte at løse eller den tilsyneladende løsning (sammenlign shotgun debugging, deep magic). Udtrykket cargo cult programmør kan gælde, når en ufaglært eller nybegynder computer programmør (eller en uerfaren med problemet ved hånden) kopierer nogle programkode fra et sted til et andet med ringe eller ingen forståelse af, hvordan det fungerer, eller om det er nødvendigt i sin nye position.
Cargo cult programmering kan også henvise til praksis med at anvende et designmønster eller kodestil blindt uden at forstå årsagerne bag dette designprincip. Eksempler er at tilføje unødvendige kommentarer til selvforklarende kode, overdreven overholdelse af konventionerne i et specifikt programmeringsparadigme eller tilføje sletningskode for genstande, som affaldsindsamling automatisk ville have indsamlet.
Forestil dig et scenarie, hvor du arbejder på en fejl og finder den kode, der forårsager fejlen. Du er ikke massivt sikker på, hvad der sker, så du;
- Google fejlen.
- du finder et spørgsmål om Stackoverløb.
- Søg efter det mest upticked svar.
- Kopier og indsæt løsningen i din kode.
- prøv fejlfinding for at se, om det er løst dit problem.
det har, så du tjekker det ind og går videre.
lyder bekendt?
Hvorfor gør vi det? Hvorfor tager vi blindt dette uddrag og bruger det som det er, i vores implementering?
brugssagen er sandsynligvis ikke den samme, så jeg ville blive overrasket, hvis løsningerne var. Enkle eksempler til side, forståelse af ræsonnementet bag løsningen er vigtigere end selve løsningen. Der er mange ting, du ikke kan gøre med noget, du ikke forstår. Du kan ikke ændre, forbedre eller teste det. Du kan ikke dokumentere det, og du kan ikke eje det.
vi elsker alle det, der er nyt, og ledelsen synes især at kunne lide at følge populære tendenser og holde trit med den teknologiske udvikling.
de fleste hold vil nu følge en agil tilgang. TDD og automatiseret test kan være meget nyttigt i visse scenarier, Kontinuerlig Integration fjerner meget af omkostningerne fra infrastrukturteamet, Big Data og AI kan i høj grad forbedre brugertilfredsheden og containeriseringen, og senest skifter mikroservices vores gamle monolitharkitektur til mindre selvstændige tjenester.
hver af disse fremskridt er strålende i sig selv, og jeg tolererer ikke nogen af dem. Mit problem er, om vi skal vedtage dem alle i alle vores processer og kode? Vi ser blogindlæg fra Facebook, Facebook, der viser, hvordan deres brug har ændret, hvordan de fungerer. Hvis store virksomheder anser dem for nødvendige, skal vi ikke også? Det er her cargo cult programmering stikker sit grimme hoved igen.
vi er nødt til at forstå problemerne med vores nuværende design, hvorfor de skete, og hvordan de kan blive kastet væk i fremtiden. Ja, Disse nye processer kan hjælpe os med vores problemer, men blindt at følge dem i det svage håb, de gør, er ikke vejen frem, og det giver heller ingen logisk mening.
jeg nævner Microservices specifikt som en masse virksomheder synes at gøre overgangen, citerer sådanne fordele som:
- hurtigere udviklingstid
- høj skalerbarhed
- let at forbedre
- nem implementering
- autonome hold med friheden til at vælge teknologi
med en sådan liste, hvad er der at tænke på? Lad os alle hoppe på vognen!
vent et sekund… er der nogen ulemper ved denne tilgang?
- arkitektonisk kompleksitet
i monolitiske arkitekturer ligger kompleksiteten og antallet af afhængigheder inde i kodebasen, mens kompleksiteten i mikroservices arkitekturer flytter til interaktionerne mellem de enkelte tjenester, der implementerer et specifikt domæne
- operationel kompleksitet
- sådan tilvejebringes ressourcer på en skalerbar og omkostningseffektiv måde
- Sådan betjenes snesevis eller hundreder af Mikroservicekomponenter effektivt uden at multiplicere indsatsen
- Sådan håndteres en mangel på standarder og heterogen miljøer, der inkluderer forskellige teknologier og mennesker med forskellige færdigheder
- Sådan håndteres versionering
- sådan spores og debugges interaktioner på tværs af hele systemet
- Sådan holder du styr på hundreder af rørledninger med kodeudrulninger og deres indbyrdes afhængighed
disse løftes fra
det ‘offentlige’ problem.
det er simpelt virkelig, Stop med at bruge det offentlige søgeord, stop automatisk med at oprette offentlige klasser. Hvorfor gør vi det?
problemet med at bruge det offentlige søgeord er, at du går glip af fordelene ved indkapsling. Hvorfor bruger vi det så meget? Det er stort set standardordet, vi bruger, når vi opretter klasser, alle eksempler bruger offentlige klasser, guider og uddrag implementerer offentlige klasser. Det er tid til at stoppe. Hvor mange mennesker har en offentlig Facebook-konto? De fleste ting i denne verden er private, ligesom vores klasser skal være. Gør dem private som standard, og hvis du har brug for dem til at være offentlige, skal du ændre dem derefter.
med stor erfaring kommer stor frygt.
jo længere du er i et felt, jo mindre naiv er du til opfattede forbedringer, som et nyt værktøj eller en ny proces vil bringe. De fleste af dagens ideer kommer fra årtier gammel forskning i området, som endelig bliver omfavnet. Når noget har fået masseadoption, er det lettere at føle sig godt tilpas med at omfavne det fuldt ud. Det vil sige, hvis det er det rigtige at gøre.
“god dømmekraft kommer fra erfaring, og erfaring kommer fra dårlig dømmekraft”
– Rita Mae brun
så er du velkommen til at fortsætte med at skure intervallerne for løsninger og tutorials til dine problemer; fortsæt med at udforske nye sprog, rammer og implementeringer. Bare vær opmærksom på, hvorfor de arbejder, snarere end blot hvordan. Vi lærer alle af vores egne oplevelser og fejl, så forståelse af de grundlæggende vil forhindre dig i at fortsætte den samme vej i fremtiden.