December 2009


Kértétek, itt van. Alapvetően itt a modultervezésről lesz szó, a komplett rendszerek tervezése egyrészről picit más tészta, másrészt ebből a szempontból meglepően sokszor van megkötve a kezünk. Érdemes elolvasni a cikket is, de a kapcsolódó két esettanulmány a legértékesebb talán.

Ha a specifikáció megvan, hányszor adjuk oda tetszőleges, az implementációs környezetet valamelyest ismerő kollegának azt, már implementált (és titokban: tesztelt) terméket várva vissza cserébe? Mi sem természetesebb ennél, nem igaz? Az alkotói szabadság, a modulok amúgyis függetlenek, a srác amúgyis megbántódna, ha beleszólnának a dolgába… ugye?

Hát egy lúf.szt.

Alapvetően a kód azon részei, amit senki nem menedzsel (nem látja senki a készítőjén kívül), fekete dobozok. A fekete doboz pedig nem elhanyagolható valószinűséggel lehet rossz, hibás. Azt, hogy megvalósítja-e egyáltalán a specifkációt, csak akkor tudjuk, ha ténylegesen leteszteltük (amit általában szintén a programozóra bízunk..). A specifikáció gyakorlatilag mindig interfészspecifikáció: azt mondja meg, adott interfésze(ke)n keresztül milyennek tűnjön a program. Lehet ez UI, lehet ez adatbázis, de lehet épp másik programrész.

A tervezés elsődleges feladata, hogy részekre válassza a megoldandó feladatot, a részek közti összefüggéseket (interfészeket) pedig rögzítse. Tehát eme fázis nem más, mint részekre bontás, és részspecifikálás.

(more…)

Avagy, lusta vagyok leveleket írni

A kedvenc karácsonyi dallamom a Carol of The Bells, másnéven Ukrainan Carol, abbol is Ray Conniff 1962-es feldolgozása:


Ugyanis olyasmit mond el, amit kevés karácsonyi dalban látok viszont.

Ez nem a meleg szobák éneke: ez a vidéké, a hideg télé, a bizonytalanságé, a félve kimondott reményé, a csakazértis Jézusé, amikor már csak kapaszkodóként is ezt énekled, mert bár Tudod, de bizonyos sose lehetsz benne teljes valójában földi léted során, mégha naponta tapasztalod is.

Ez az értékrendeddel ellentétes világban énekelt dallam, aminek része vagy, de mégse úgy jó itt amit jónak hívnak, ahogy szeretnéd, hogy jó legyen, a huszonegyedik századi mindennapok tapasztalata - és a huszadik századi Ukrajnáé is minden bizonnyal. De mégis, bár picit félve, kiállsz, és Jézusért kiáltasz.

Az eredetileg kora tavaszi szerencsekívánó versikét már abban az időben írta át Leontovics kórusművé, amikor Ukrajnában az újévet nem tavasszal, hanem január közepén ünnepelték, megmagyarázva ezzel az eredeti szöveg- és dallamvilág különbözőségét. Keresztény kontextusra és angol szövegre csak a 30-as években ültette át Peter Wilhousky.

Ezt a hangulatot adja vissza olyan jól a Connif-feldolgozás.

Az ukrán eredetit meg lehet hallgatni itt (Oleg Bulaschenko professzor oldaláról).

Ebben a playlistben pedig 3 kiváló feldolgozás szerepel egymás alatt, köztük egy cseh amatőr kvintett zseniális videója.

Mindenkinek Boldog Karácsonyt és - bár addig tervek szerint jelentkezünk - sikeres új évet!

Objektívan nézve a szavazásban ez nyert, így ez az első, de következőnek követi majd a tervezési folyamat. Kevésbé objektíven nézve a szavazószoftver az adblockereseknek jó eséllyel nem működött megfelelően (legalábbis kaptam erre utaló visszajelzéseket), de valami alapján dönteni kellett…

A requirement analysisnek (magyarul: megtudni, mit is kéne csinálni) a gyakorlatban két módja van:

  • az egyiket már félig-meddig bemutattam, ez a use-case analízis. Ez egy lassú, de biztos módszer.
  • A másik egy sajátos európai módszer: a klónozás. Ez általában nem is a programozókat érinti leginkább, hanem a megrendelőket: “egy olyat akarok, mint ez”.

(Hívják ezt kreatív másolásnak is…)

Ez utóbbi módszer megrendelői oldaláról egyszer elmondtam az őszinte véleményemet. Azóta több ember nem hajlandó velem szóbaállni; olyan se, aki részt se vett benne, csak klónozott terméket felügyel. Így most csak azzal foglalkozunk, a fejlesztés műszaki vezetőjeként mit tehetsz a szituációval.

A klónozás ugyanis egy dolgot nem mond meg: hogy mi miért van ott. Pont a legfontosabbat hagyja ki, azt, hogy mikre van szükség. Nem jó általában dolgozni olyan ügyféllel, akit nem lehet túllendíteni ezen.

De mégis, mit lehet tenni?

Ha előre nem megy, kénytelenek vagyunk visszafele.

(more…)

Az architect dolgok sorozatra több megoldásom is lett volna a héten, de sajnos időközben ideiglenesen lekorlátozódtak az energiáim.

Szeretnék azonban némi interakciót is, nem kell komment, kéne egyet szavazni. Remélem, jövő héten már jobban leszek, és akkor tudok tartalmat is mögérakni…

Témajavaslatok:

  • Architect dolgok - mindless cloning, avagy, hogyan kell mérnöki módon kezelni azt, ha a specifikáció annyi “ugyanilyet szeretnék mint ez?”
  • Architect dolgok - Közösségi webalkalmazás építése PHP alapokon, szépen - van elfekvőben egy jó minőségű kis symfonys kódom, közösségi (twitter,facebook, iwiw) appnak, nem túl sok, de sokmindent be lehet rajta mutatni, és senki felé nem licencköteles
  • Architect dolgok - tervezési folyamatok - tovább folytatva az általános részt, rendszertervezési gyakorlat
  • Egyéb - akkor kommentelj :)

A tarsolyban van még egy félkész játék JS-ben, opensocial okosságok, webes modultervezés (ami nem azonos a rendszertervvel), de ezek azok, amik előránthatóak könnyedén.

Nos, mit gondoltok?

(Alant egy poll-r szavazás, ha nem jelenne meg rss-ben)

Eddig megjelent architect cikkek: