A továbbiakban egy írására szeretnék koncentrálni, ami a szürreális számokról szól. Valójában pedig a program komplexitás skálázódásáról. A szürreális számok példája csak egy rendkívül elegáns példa a téma bemutatásához, megértéséhez. Nem kívánom összefoglalni a cikket, mindenkinek javaslom az elolvasását. (a szépséghez hozzátartozik, hogy a github repoban a példakód is ott csücsül a post mellett.)

Az ok pedig, ami ezt a postot ihlette az, hogy egy adott programnyelven a kód ábrázolása mennyibe marad egyszerű ahogy a probléma komplexitása nő. A mai általános célú nyelvek mindegyike Turing-teljes nyelv (még a Brainfuck is), azaz konyhanyelven bármely probléma leírható vagyis arra megoldás adható bennük. Ez azonban csak egy matematikai állítás, pusztán egy egzisztencia tétel. Arról nem szól, hogy mennyi idő alatt, mennyire karbantartható módon és mennyi fájdalom árán tehető meg mindez.

Nekem pedig egyre inkább fáj, amikor hihetetlen mennyiségű boilerplate kódot kell leírnom, ha ki akarok fejezni valami egyszerű dolgot (PHP-ról beszélgetünk) a lehető legegyszerűbben, és ezen a design minták sem segítenek. Sőt. Kérdés, hogy mennyiben teszik egyszerűbbé a design patternek a fejlesztést és mennyiben language smellek.

A káosz természetesen, mint káoszelmélet szerepel a könyvben és az írásomban is. Csakhogy a káosz egy (eléggé elcsépelt) hétköznapi szavunk és (sajnos) elég gyakran találkozunk vele a napi rutin során. Azonban ha úgy fogalmazunk, hogy érzékenység a kiinduló feltételekre, akkor érdekes következtetésekre juthatunk.

Az itt következő leírás feltételezi, hogy legacy kódról beszélünk:

• unit és/vagy end-to-end test suite teljes vagy részleges hiánya.
• metrikák hiánya

És akkor a következtetések:

1. Eddig tapasztalatom alapján a legkisebb változtatások a kódban (értsd 1-2 sor, de még inkább kevesebb, mint 10 karakter) okozhatják a legnagyobb bonyodalmat a rendszerben. Ez lehet akár elég alattomos rejtett hiba bevezetése vagy a kód komplexitása miatti, már beláthatatlan következményeket előidéző változtatás. Sok embernél láttam, magam is tapasztaltam.
   Ez eléggé ellentmondani látszik általános (lineáris) világfelfogásunkkal, azzal ahogy a kódot látjuk.
2. Ennek azonban van egy másik oldala. A “változás” nem mindig azonnal észlelhető, sőt lehet, hogy nem is észlelhető igazán. Tehát meglátásom szerint a legbrutálisabb shotgun surgery sem feltétlen jár látható fájdalommal, nem feltétlenül áll meg tőle az élet, hiába a rossz design és/vagy a védőháló (test suite) hiánya.

A fentiek következménye az a jelenség, hogy egy fejlesztő egy sok osztályon, fileon átívelő átalakítás után kommitolt kódja akár jobb állapotba hozza a kódot (bár adott esetben ezt szinte semmivel sem tudja alátámasztani előre). Később pedig ugyanez a fejlesztő egy egysoros módosítással a feje tetejére állítja a világot (és ebben az esetben sem tudja semmivel alátámasztani előre a módosítás hatását).

Innen nézve a kód sokszor kaotikus, megjósolhatatlan viselkedést mutat. Úgy gondolom, hogy ezt elsősorban a metrikák hiánya okozza. Ha nem látható, hogy egy módosítás milyen komplexitást vezet be (ne adj isten vezet ki) a rendszerbe, ha semmilyen metrika nem ad segítséget, hogy felismerjük az éppen bevezetett/használt design buktatóit/hibáit, ha nem biztosítanak a tesztek védőhálót, akkor a kód viselkedése a jövőben is egy előre meg nem jósolható tényező lesz az életünkben.

Vélemény?

Sok elgondolkoztató dolog hangzik el, komoly érvek mellette és ellene is. A bácsiknak úgy tűnik van tapasztalata a témában.

A probléma nagyonis érezhető a mai scrum irományokon, scrum coachokon. A technikai részek, részletek kimaradnak, elsikkadnak. Én még nem találkoztam olyan scrummal foglalkozó írással, könyvvel, amely konkrétan fejlesztők számára irányelveket (principle-pattern-practice) fogalmazott volna meg. Mind arról szól, hogy van valami olyasmi is, de azt majd a fejlesztők úgyis tudják.

Nem. Nem tudják. Meg kell őket tanítani rá, mert nem abból az irányból jönnek, ahol az agile értékeket bármilyen módon figyelembevették volna. Ez alapvető fontosságú lenne. Enélkül semmit sem ér a scrum (vagy bármelyik agilis irányzat), és leginkább csak a baj van vele.

“A Scrum team is hyper-productive at making messes.”

“We can measure messes by implementing engineering disciplines and practices like Test Driven Development (TDD), Continuous Integration, Pair Programming, Collective Ownership, and Refactoring; i.e. the engineering practices of eXtreme Programming (XP).” – miért olyan nehéz ezt belátni és elfogadni?

Ha hozzávesszük Uncle Bob írását (félelmét) a scrumról, akkor érdekes következtetésre jutunk. Magyarán hogy egy evoluciós lépés a scrum és ki lehet nőni belőle (pl. kidobni a csapatból a scrum mastert). Csakhogy mennyiben lehetséges ez, ha a waterfallból “kidobott” emberek épp ilyen és ehhez hasonló pozíciókban keresnek “menedéket” az új agilis világban? Mennyiben nőhető ki egy módszertan, ha az azt bevezető ember(ek)nek a folyamatos tanácsadásból anyagi hasznuk származik, hogy fenttartsák azt (certified scrum master)?

Külön tetszik ahogy a DIC megoldásokról vélekedik. (vö. “Dependency Injection” Considered Harmful)

A Framework Frustration részt pedig ajánlom mindenki figyelmébe. Magyarul a frameworkök célja, hogy egyszerűvé tegye alkalmazások készítését, de ez nem jelenti azt, hogy egy jó desginhoz jutsz a végén. Sőt, általában pont az ellenkezőjét jelenti. Ezért elég nehéz pl Doctrinenal normális, egyszerű, tesztelhető kódot írni.

Sokszor belefuttotam, hogy az fglrx eltávolításakor elég szép hibaüzeneteket dobál az apt. De megvan végre a megoldás: http://hartlessbydesign.com/blog/ati-driver-issues-in-ubuntu-1004-lucid.html