olin katsomassa / kuuntelemassa tätä Simon Brownin hienoa puhetta modulaarisista Monolitheista Goto 2018: sta.
tässä hän mainitsee termin nimeltä Cargo Cult Programming ja se todella osui minuun.
olen vastikään liittynyt uuteen yritykseen, jolla on uusi ohjelmointikieli, uudet työkalut, uudet prosessit ja uusi tiimi. Itse asiassa se on aika lailla ’uutta’ kaikkea.
tämä on saanut minut opettelemaan paljon viime kuukausina. Koska olen suhteellisen kokenut, haluan tarkastella ’miksi’ eikä ’Miten’, kun opin uusia asioita. Olen tajunnut, että tämä ei ole yleisin lähestymistapa.
kun käyttäjä saa tehtäväkseen lisätä olemassa olevaan koodirivistöön nykyisen ratkaisun laajentamisen, hän mitä todennäköisimmin tarkistaa, miten tämä on tehty aiemmin, kopioimalla ratkaisunsa lähestymistavan. He saattavat / tulevat sokeasti seuraamaan tätä kaavaa kuten se on tehty ennenkin. Tornin päälle lisätään lisäpalikoita kyseenalaistamatta, onko se oikein. Jos kaikki tekevät näin, tämä tapahtuu lopulta.
tästä tulee termi ”Cargo Cult Programming”.
Wikipedia selittää sen näin:
Cargo cult-ohjelmointi on tietokoneohjelmoinnin tyyli, jolle on ominaista koodin tai ohjelmarakenteiden rituaalinen sisällyttäminen, joilla ei ole todellista tarkoitusta. Cargo Cultin ohjelmointi on tyypillisesti oireellista siinä, että ohjelmoija ei ymmärrä joko heidän ratkaisemaansa bugia tai näennäistä ratkaisua (vertaa shotgun debugging, deep magic). Termiä cargo cult programmer voidaan käyttää, kun kouluttamaton tai aloitteleva tietokoneohjelmoija (tai sellainen, jolla ei ole kokemusta käsillä olevasta ongelmasta) kopioi jonkin ohjelmakoodin paikasta toiseen ymmärtämättä, miten se toimii tai tarvitaanko sitä uudessa asemassaan.
Cargo cult-ohjelmoinnilla voidaan viitata myös käytäntöön soveltaa suunnittelukaavaa tai koodaustyyliä sokeasti ymmärtämättä suunnitteluperiaatteen taustalla olevia syitä. Esimerkkejä ovat tarpeettomien kommenttien lisääminen itsestään selvään koodiin, tietyn ohjelmointiparadigman konventioiden yli-innokas noudattaminen tai poistokoodin lisääminen kohteille, jotka roskankeräys olisi kerännyt automaattisesti.
Kuvittele tilanne, jossa työskentelet vian parissa ja etsit vian aiheuttavan koodin. Et ole varma, mitä tapahtuu, joten … ;
- googleta virhe.
- löytyy StackOverflow-kysymys.
- Etsi upokkain vastaus.
- kopioi ja liitä liuos koodiisi.
- kokeile vianetsintää nähdäksesi, onko se korjannut ongelmasi.
sillä on, joten se merkitään sisään ja jatketaan matkaa.
Kuulostaako tutulta?
miksi näin tehdään? Miksi me sokeasti otamme tämän pätkän ja käytämme sitä sellaisenaan, meidän täytäntöönpanossamme?
käyttötapaus ei liene sama, joten yllättyisin, jos ratkaisut olisivat. Yksinkertaisista esimerkeistä huolimatta ratkaisun perustelujen ymmärtäminen on tärkeämpää kuin itse ratkaisu. On monia asioita, joita ei voi tehdä sellaisella, mitä ei ymmärrä. Sitä ei voi muokata, parantaa tai testata. Sitä ei voi dokumentoida eikä omistaa.
me kaikki rakastamme uutta, ja erityisesti johto tuntuu pitävän suosittujen trendien seuraamisesta, teknologisen kehityksen perässä pysymisestä.
useimmat joukkueet noudattavat nyt ketterää lähestymistapaa. TDD ja automatisoitu testaus voivat olla erittäin hyödyllisiä tietyissä skenaarioissa, jatkuva integrointi poistaa suuren osan infrastruktuuritiimin kustannuksista, Big Data ja tekoäly voivat merkittävästi parantaa käyttäjien tyytyväisyyttä ja Konttiarkkitehtuuria ja viimeisimpänä Mikropalvelut siirtävät vanhan monoliittisen arkkitehtuurimme pienempiin itsenäisiin palveluihin.
jokainen näistä edistysaskeleista on nerokas omana itsenään, enkä hyväksy yhtäkään niistä. Minun pulmani on, pitääkö meidän ottaa ne kaikki osaksi kaikkia prosessejamme ja koodejamme? Näemme Netflixin, Facebookin ja Twitterin Facebook-postauksia, joissa näkyy, miten niiden käyttö on muuttanut niiden toimintaa. Jos suuryritykset pitävät niitä tarpeellisina, eikö meidänkin pitäisi? Täällä cargo cult-ohjelmointi nostaa taas rumaa päätään.
meidän on ymmärrettävä nykyisten suunnitelmiemme ongelmat, Miksi ne tapahtuivat ja miten ne voidaan tulevaisuudessa poistaa. Nämä uudet prosessit voivat tosiaan auttaa meitä ongelmissamme, mutta niiden sokeasti seuraaminen siinä Heikossa toivossa, että ne auttavat, ei ole tie eteenpäin, eikä siinä ole mitään johdonmukaista järkeä.
mainitsen erityisesti Mikropalvelut, koska monet yritykset näyttävät tekevän siirtymävaiheen vedoten sellaisiin etuihin kuin:
- nopeampi kehitysaika
- suuri skaalautuvuus
- helppo parantaa
- käyttöönoton helppous
- autonomiset tiimit, joilla on vapaus valita tekniikka
tuollaisella listalla, mitä mietittävää? Hypätään kelkkaan!
Wait a second … onko tässä lähestymistavassa haittapuolia?
- arkkitehtoninen monimutkaisuus
monoliittisissa arkkitehtuureissa kompleksisuus ja riippuvuuksien määrä piilevät koodikannan sisällä, kun taas mikropalveluissa arkkitehtuureissa kompleksisuus siirtyy niiden yksittäisten palvelujen vuorovaikutukseen, jotka toteuttavat tietyn osa-alueen
- operatiivinen monimutkaisuus
- resurssien tarjoaminen skaalautuvasti ja kustannustehokkaasti
- kuinka käyttää kymmeniä tai satoja Mikropalvelukomponentteja tehokkaasti Moninkertaistamatta ponnisteluja
- miten käsitellä standardien puutetta ja epäyhtenäisyyttä ympäristöt, jotka sisältävät erilaisia teknologioita ja ihmisiä, joilla on erilaiset taidot
- miten käsitellä versiointia
- miten seurata ja debug-vuorovaikutusta koko järjestelmässä
- miten seurata satoja koodinsiirron putkistoja ja niiden keskinäisiä riippuvuuksia
nämä on poimittu Amazonin omasta ”Challenge of Microservices” – valkopaperista. En tiedä sinusta, mutta haitat ovat pelottavampia kuin hyödyt. Jälleen kerran, en sano, että tämä ei ole oikea lähestymistapa mennä alas, mutta jos nämä hyödyt ylittävät haitat mitä saat noudattamalla tätä lähestymistapaa?
”Julkinen” ongelma.
se on yksinkertaista oikeastaan, lopeta julkisen avainsanan käyttäminen, lopeta automaattisesti julkisten luokkien luominen. Miksi teemme sen?
julkisen hakusanan käytön ongelmana on, että kapselointiin liittyvät hyödyt jäävät saamatta. Miksi käytämme sitä niin paljon? Se on melko paljon oletussana käytämme luotaessa luokkia, kaikki esimerkit käyttävät julkisia luokkia, velhot ja snippets toteuttaa julkisia luokkia. On aika lopettaa. Kuinka monella on julkinen Facebook-tili? Useimmat asiat tässä maailmassa ovat yksityisiä, kuten meidän kurssien pitäisi olla. Tee niistä oletusarvoisesti yksityisiä,ja jos haluat niiden olevan julkisia, muuta ne sitten.
suuren kokemuksen myötä tulee suuri pelko.
mitä kauemmin olet alalla, sitä vähemmän naiivi olet uuden työkalun tai prosessin tuomien parannusten suhteen. Suurin osa tämän päivän ideoista on peräisin vuosikymmeniä vanhasta alan tutkimuksesta,joka on vihdoin omaksuttu. Kun jokin on saavuttanut massadoption, on helpompi tuntea olonsa mukavaksi omaksua se täysin. Jos se on oikein.
”hyvä arvostelukyky tulee kokemuksesta, ja kokemus tulee huonosta arvostelukyvystä”
– Rita Mae Brown
joten voit vapaasti etsiä ratkaisuja ja oppaita ongelmiisi; tutki jatkuvasti uusia kieliä, kehyksiä ja toteutuksia. Vain olla tietoinen siitä, miksi ne toimivat, eikä vain miten. Me kaikki opimme omista kokemuksistamme ja virheistämme, joten perusasioiden ymmärtäminen estää sinua jatkamasta samalla tiellä tulevaisuudessa.