jeg så på/lyttet til Denne flotte talen Av Simon Brown På Modulære Monolitter FRA GOTO 2018.
i dette nevner han Et begrep som heter Cargo Cult Programming, og det slo virkelig en akkord med meg.
jeg har nylig blitt med i et nytt selskap med et nytt programmeringsspråk, nye verktøy, nye prosesser og et nytt team. Egentlig er det ganske mye ‘nytt’ alt.
Dette har fått meg til å gjøre mye læring de siste månedene. Å være relativt erfaren, liker jeg å se på ‘whys’ i stedet for’ hows ‘ når jeg lærer nye ting. Det jeg har innsett er at dette ikke er den vanligste tilnærmingen.
når en bruker får i oppgave å legge til en eksisterende kodebase, utvide den nåværende løsningen, vil de mest sannsynlig sjekke hvordan dette har blitt gjort tidligere, og kopiere tilnærmingen til løsningen. De kan / vil blindt følge dette mønsteret som det er hvordan det har blitt gjort før. Ekstra blokker blir lagt på toppen av tårnet, uten å stille spørsmål om det er riktig å gjøre. Hvis alle gjør dette, vil dette til slutt skje.
det er her begrepet ‘Cargo Cult Programming’ kommer fra.
Wikipedia forklarer det slik:
Cargo kultprogrammering er en stil av dataprogrammering preget av rituell inkludering av kode eller programstrukturer som ikke tjener noen reell hensikt. Cargo cult programmering er vanligvis symptomatisk for en programmerer som ikke forstår enten en feil de forsøkte å løse eller den tilsynelatende løsningen (sammenlign shotgun debugging, deep magic). Begrepet cargo cult programmerer kan gjelde når en ufaglært eller nybegynner dataprogrammerer (eller en uerfaren med problemet ved hånden) kopierer noen programkode fra ett sted til et annet med liten eller ingen forståelse av hvordan det fungerer eller om det er nødvendig i sin nye posisjon.
Cargo cult programmering kan også referere til praksisen med å bruke et design mønster eller koding stil blindt uten å forstå årsakene bak at design prinsippet. Eksempler er å legge unødvendige kommentarer til selvforklarende kode, overivrig overholdelse av konvensjonene til et bestemt programmeringsparadigme, eller legge til slettingskode for objekter som søppelsamling ville ha samlet automatisk.
Tenk deg et scenario der du jobber med en feil, og finner koden som forårsaker feilen. Du er ikke helt sikker på hva som skjer, så du;
- Google feilen.
- du finner et StackOverflow-spørsmål.
- Søk etter det mest upticked svaret.
- Kopier og lim inn løsningen i koden din.
- Prøv feilsøking for å se om det er løst problemet ditt.
Det har, så du sjekker det inn og fortsetter.
Høres kjent ut?
Hvorfor gjør Vi det? Hvorfor tar vi blindt denne koden og bruker den som den er, i vår implementering?
brukssaken er sannsynligvis ikke den samme, så jeg ville bli overrasket om løsningene var. Enkle eksempler til side, forstå begrunnelsen bak løsningen er viktigere enn løsningen selv. Det er mange ting du ikke kan gjøre med noe du ikke forstår. Du kan ikke endre, forbedre eller teste det. Du kan ikke dokumentere det, og du kan ikke eie det.
vi alle elsker det som er nytt, og ledelsen spesielt synes å like å følge populære trender, holde tritt med teknologiske fremskritt.
De fleste lag vil nå følge En Smidig tilnærming. TDD og Automatisert Testing kan være svært nyttig i visse scenarier, Kontinuerlig Integrasjon fjerner mye av overhead fra infrastrukturteamet, Big Data og AI kan vesentlig forbedre brukertilfredshet og Containerisering og Sist Mikrotjenester skifter vår gamle monolittarkitektur til mindre selvbetjente tjenester.
Hver av disse fremskrittene er strålende i seg selv, og jeg tolererer ikke noen av dem. Min situasjon er om vi trenger å vedta dem alle i alle våre prosesser og kode? Vi ser blogginnlegg Fra Netflix, Facebook, Twitter som viser hvordan deres bruk har forvandlet hvordan de fungerer. Hvis store selskaper anser dem nødvendige, bør vi ikke også? Det er her cargo cult programmering steiler sitt stygge hode igjen.
Vi må forstå problemene med våre nåværende design, hvorfor de skjedde, og hvordan de kan bli kastet bort i fremtiden. Ja, disse nye prosessene kan hjelpe oss med våre problemer, men blindt å følge dem i svakt håp om at de gjør det, er ikke veien fremover, og det gir heller ingen logisk mening.
jeg nevner Mikrotjenester spesielt som mange selskaper ser ut til å gjøre overgangen, og citerer slike fordeler som:
- Raskere utviklingstid
- Høy skalerbarhet
- Enkel å forbedre
- enkel distribusjon
- Autonome team med frihet til å velge teknologi
med en slik liste, hva er det å tenke på? La oss alle hoppe på bandwagon!
Vent litt… er det noen ulemper med denne tilnærmingen?
- Arkitektonisk Kompleksitet
i monolitiske arkitekturer ligger kompleksiteten og antall avhengigheter inne i kodebasen, mens i mikrotjenestearkitekturer flyttes kompleksiteten til samspillet mellom de enkelte tjenestene som implementerer et bestemt domene
- Operasjonell Kompleksitet
- slik forsyner du ressurser på en skalerbar og kostnadseffektiv måte
- hvordan bruke dusinvis Eller hundrevis Av Microservice Komponenter Effektivt Uten Å Multiplisere Innsats
- hvordan håndtere mangel på standarder og heterogene miljøer som inkluderer ulike teknologier og personer med ulike ferdighetssett
- hvordan håndtere versjonskontroll
- hvordan spore og feilsøke interaksjoner på tvers av hele systemet
- hvordan holde oversikt over hundrevis av rørledninger av kodedistribusjoner og deres gjensidige avhengigheter
disse løftes fra Amazons egen «Utfordring Av Microservices» whitepaper. Nå vet jeg ikke om deg, men ulempene ser mye skremmere ut for meg enn fordelene. Igjen sier jeg ikke at dette ikke er riktig tilnærming til å gå ned, men med mindre disse fordelene oppveier ulempene, hva får du fra å følge denne tilnærmingen?
Det ‘Offentlige’ problemet.
Det er enkelt egentlig, Slutte å bruke Det Offentlige søkeordet, slutte å opprette Offentlige klasser automatisk. Hvorfor gjør vi det?
problemet med å bruke det offentlige søkeordet er at du går glipp av fordelene knyttet til innkapsling. Hvorfor bruker vi det så mye? Det er ganske mye standardordet vi bruker når du lager klasser, alle eksempler vil bruke offentlige klasser, veivisere og utdrag vil implementere offentlige klasser. Det er på tide å stoppe. Hvor mange har En Offentlig Facebook-konto? De fleste ting i denne verden er private, som skal våre klasser være. Gjør dem private som standard, og hvis du trenger dem til å være offentlige, endre dem da.
med stor erfaring kommer stor frykt.
jo lenger du er i et felt, jo mindre naiv er du til oppfattede forbedringer som et nytt verktøy eller en prosess vil bringe. De fleste av dagens ideer kommer fra tiår gammel forskning på feltet som endelig blir omfavnet. Når noe har fått masse adopsjon, er det lettere å føle seg komfortabel med å omfavne det fullt ut. Det er, hvis det er den riktige tingen å gjøre.
«god dømmekraft kommer fra erfaring, og erfaring kommer fra dårlig dømmekraft»
– Rita Mae Brown
så vær så snill å fortsette å skure interwebs for løsninger og opplæringsprogrammer på dine problemer; fortsett å utforske nye språk, rammer og implementeringer. Bare vær klar over hvorfor de jobber, i stedet for bare hvordan. Vi lærer alle av våre egne erfaringer og feil, så å forstå grunnleggende vil holde deg fra å fortsette på samme vei i fremtiden.