A program komplexitás skálázódásáról

Michael Feathers nevű úriembernek hála ismerkedtem meg a Reg Braithwaite nevű úriember munkásságával. Azt kell tudni róla, hogy egy ideje már a szakmában van és rengeteget ír, amit az évek során elég változatos formában tett meg.

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.

Káosz és kód

Mostanában olvasom James Gleick: Káosz című könyvét. Érdekes gondolatokat ébreszt az emberben.

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.

Feature Bits – kikapcsolható funkcionalitás menet közben

Egész jó kis előadás, érdemes megnézni Feature Bits: Enabling Flow Within and Across Teams.

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

Nem mai, de érdekes írás Michael Nygard-tól:

Nem mai, de érdekes írás Michael Nygard-tól: The Future of Software Development

Bringing Balance to the Force

Uncle Bob újabb írásai: Bringing Balance to the Force, Software Craftsmanship: What it’s all about.

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.

The Land that Scrum Forgot

Kis adalék scrum témában. Ezúttal Uncle Bob letisztult írásában: The Land that Scrum Forgot

“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?

Let Scrum Die

Érdekes és elgondolkoztató írás: Striking a Balance: Let Scrum Die.

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)?

The Deep Synergy Between Testability and Good Design

Nagyon jó kis előadás Feathers bácsitól design, tesztelhetőség témakörben.

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.

A következő kis lépés

Ha TDDzésre adja a fejét az ember, nagyon gyorsan hozzászokik, hogy kis-apró lépésekben tud haladni. Inkremetálisan nő ki a kódból az a funkcionalitás, amit elvársz tőle. Az alapmű (Kent Beck: Test Driven Development By Examples) gyönyörűen bemutatja, hogyan működik ez a gyakorlatban. Azonban már az első fejezetben folyamatosan felmerül, lépésről-lépésre a kérdes, melyik teszt legyen a következő? Mi alapján történik a választás: ad-hoc (nem hiszem) vagy van mögötte valami elv? Erre a kérdésre nem ad választ a könyv, viszont Uncle Bob pont ezt a kérdést feszegeti The Transformation Priority Premise írásában.

Ubuntu és Mobilitiy Radeon

Elég érdekesen tud működni egy ubuntu egy mobil radeon kártyás notin, különösen a linux driver .

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