néztem / hallgattam Simon Brown nagyszerű beszédét a moduláris Monolitokról a GOTO 2018-ból.
ebben megemlít egy Cargo Cult programozásnak nevezett kifejezést, ami igazán akkordot adott nekem.
nemrég csatlakoztam egy új céghez, új programozási nyelvvel, új eszközökkel, új folyamatokkal és új csapattal. Tulajdonképpen, ez elég sok ‘ új ‘ mindent.
ez sok tanulást okozott nekem az elmúlt hónapokban. Mivel viszonylag tapasztalt vagyok, szeretek inkább a ‘miérteket’ vizsgálni, mint a ‘Hogyan’, amikor új dolgokat tanulok. Rájöttem, hogy ez nem a leggyakoribb megközelítés.
amikor egy felhasználó feladata egy meglévő kódbázis hozzáadása, az aktuális megoldás kiterjesztése, akkor valószínűleg ellenőrizni fogja, hogyan történt ez korábban, lemásolva a megoldás megközelítését. Lehet, hogy vakon követik ezt a mintát, ahogy korábban is tették. További blokkok kerülnek a torony tetejére, anélkül, hogy megkérdőjeleznék, hogy ez a helyes dolog. Ha mindenki ezt teszi, ez végül megtörténik.
innen származik a ‘Cargo Cult programozás’ kifejezés.
A Wikipédia így magyarázza:
a Rakománykultusz programozás a számítógépes programozás olyan stílusa, amelyet a valódi célt nem szolgáló kód vagy programstruktúrák rituális felvétele jellemez. A rakománykultusz programozása általában annak tünete, hogy a programozó nem érti sem a hibát, amelyet megpróbáltak megoldani, sem a látszólagos megoldást (hasonlítsa össze a shotgun hibakeresését, mély varázslat). A cargo cult programozó kifejezés akkor alkalmazható, ha egy képzetlen vagy kezdő számítógépes programozó (vagy egy, aki nem ismeri a problémát) átmásol valamilyen programkódot egyik helyről a másikra, alig vagy egyáltalán nem értve annak működését, vagy hogy új pozíciójában szükség van-e rá.
a Rakománykultusz programozás utalhat arra a gyakorlatra is, hogy vakon alkalmazzák a tervezési mintát vagy a kódolási stílust, anélkül, hogy megértenék a tervezési elv mögött meghúzódó okokat. Ilyen például a felesleges megjegyzések hozzáadása az magától értetődő kódhoz, egy adott programozási paradigma konvencióinak túlbuzgó betartása, vagy törlési kód hozzáadása olyan objektumokhoz, amelyeket a szemétgyűjtés automatikusan összegyűjtött volna.
Képzeljen el egy forgatókönyvet, ahol egy hibán dolgozik, megtalálva a hibát okozó kódot. Nem vagy teljesen biztos abban, hogy mi történik, tehát te;
- Google a hiba.
- talál egy StackOverflow kérdést.
- keresse meg a leginkább felkapott választ.
- másolja és illessze be a megoldást a kódjába.
- próbálja meg a hibakeresést, hogy lássa, megoldotta-e a problémát.
van, tehát ellenőrizze, és lépjen tovább.
Ismerősen hangzik?
miért csináljuk ezt? Miért vesszük vakon ezt a részletet, és használjuk úgy, ahogy van, a megvalósításunkban?
a használati eset valószínűleg nem ugyanaz, ezért meglepődnék, ha a megoldások lennének. Az egyszerű példákat félretéve, a megoldás mögött meghúzódó érvelés megértése fontosabb, mint maga a megoldás. Sok olyan dolog van, amit nem tudsz megtenni azzal, amit nem értesz. Nem lehet módosítani, javítani vagy tesztelni. Nem dokumentálhatod és nem birtokolhatod.
mindannyian szeretjük az újdonságokat, és úgy tűnik, hogy a vezetés különösen szereti követni a népszerű trendeket, lépést tartani a technológiai fejlődéssel.
a legtöbb csapat mostantól agilis megközelítést követ. A TDD és az automatizált tesztelés bizonyos esetekben nagyon hasznos lehet, A folyamatos integráció eltávolítja az infrastrukturális csapat nagy részét, a Big Data és az AI jelentősen javíthatja a felhasználói elégedettséget és a Konténerezést, és legutóbb a mikroszolgáltatások a régi monolith architektúrát kisebb önálló szolgáltatásokká változtatják.
ezek a fejlesztések önmagukban is briliánsak, és egyiket sem nézem el. Az én problémám az, hogy be kell-e fogadnunk őket minden folyamatunkba és kódunkba? Látjuk a Netflix, a Facebook, a Twitter blogbejegyzéseit, amelyek megmutatják, hogy használatuk hogyan változtatta meg működésüket. Ha a nagyvállalatok szükségesnek tartják őket, nem kellene nekünk is? Ez az, ahol a cargo cult programozás ismét felemeli csúnya fejét.
meg kell értenünk a jelenlegi terveinkkel kapcsolatos problémákat, miért történtek, és hogyan lehet őket a jövőben eldobni. Igen, ezek az új folyamatok segíthetnek a problémáink megoldásában, de vakon követni őket abban a halvány reményben, hogy megteszik, nem az előre vezető út, és nincs logikus értelme.
kifejezetten megemlítem a Mikroszolgáltatásokat, mivel úgy tűnik, hogy sok vállalat átáll, hivatkozva az olyan előnyökre, mint:
- gyorsabb fejlesztési idő
- nagy méretezhetőség
- könnyen fejleszthető
- könnyű telepítés
- autonóm csapatok a technológia megválasztásának szabadságával
egy ilyen listával, mit kell gondolni? Ugorjunk mindannyian a kocsira!
várjon egy másodpercet … vannak-e hátrányai ennek a megközelítésnek?
- építészeti komplexitás
a monolitikus architektúrákban a komplexitás és a függőségek száma a kódbázison belül helyezkedik el, míg a mikroszolgáltatások architektúráiban a komplexitás az egyes szolgáltatások interakciói felé mozog, amelyek egy adott tartományt valósítanak meg
- működési komplexitás
- az erőforrások skálázható és költséghatékony módon történő biztosítása
- hogyan működik több tucat vagy több száz mikroszolgáltatás alkatrészek hatékonyan megszorozva erőfeszítések
- hogyan kell kezelni a hiányzó szabványok és heterogén
- hogyan kell kezelni a verziókezelést
- hogyan kell nyomon követni és hibakeresni az interakciókat az egész rendszerben
- hogyan kell nyomon követni a kódtelepítések több száz csővezetékét és azok kölcsönös függőségét
ezeket az Amazon saját “mikroszolgáltatások kihívása” című könyvéből emelték ki. Nem tudom, te hogy vagy vele, de a hátrányok sokkal ijesztőbbek, mint az előnyök. Még egyszer, nem azt mondom, hogy ez nem a megfelelő megközelítés a lemenéshez, de hacsak ezek az előnyök nem haladják meg a hátrányokat, Mit nyersz ezzel a megközelítéssel?
a ‘nyilvános’ probléma.
ez nagyon egyszerű, hagyja abba a nyilvános kulcsszó használatát, hagyja abba a nyilvános osztályok automatikus létrehozását. Miért csináljuk?
a nyilvános kulcsszó használatával az a probléma, hogy kihagyja a kapszulázással kapcsolatos előnyöket. Miért használjuk annyira? Ez nagyjából az alapértelmezett szó, amelyet osztályok létrehozásakor használunk, minden példa nyilvános osztályokat fog használni, a varázslók és a kivonatok nyilvános osztályokat valósítanak meg. Ideje abbahagyni. Hány embernek van nyilvános Facebook-fiókja? A legtöbb dolog ezen a világon magánügy, ahogy az óráinknak is. Alapértelmezés szerint privátvá tegye őket, majd ha nyilvánosnak kell lennie, akkor változtassa meg őket.
nagy tapasztalattal jön nagy félelem.
minél tovább vagy egy területen, annál kevésbé naiv vagy az észlelt fejlesztésekkel kapcsolatban, amelyeket egy új eszköz vagy folyamat hoz. A mai ötletek többsége a terület évtizedes kutatásából származik, amelyeket végül felkarolnak. Miután valami tömeges elfogadásra került, könnyebb jól érezni magát, ha teljes mértékben átfogja. Már ha ez a helyes döntés.
“”
– Rita Mae Brown
tehát nyugodtan keresse tovább az interwebeket megoldások és oktatóanyagok után a problémáira; keressen új nyelveket, keretrendszereket és implementációkat. Csak légy tudatában annak, hogy miért működnek, nem pedig egyszerűen hogyan. Mindannyian tanulunk saját tapasztalatainkból és hibáinkból, így az alapok megértése megakadályozza, hogy a jövőben ugyanazon az úton haladjon.