DSL.
Azt nem kétlem, hogy a scriptnyelven belül maradva annak teljes eszköztára elérhető. A kérdés az, hogy a beépített/interfészelt scriptnyelvből eléred a fogadó nyelv összes szolgáltatását? Illetve mindenhol használhatod-e?
A LISP-ben egy nyelv "beágyazása" olyan szintű integrációt jelent, hogy attól az egész továbbra is egy nyelv marad. Esetünkben a JAVAScript (és html) a GUI miatt használt, és a kódban teljesen vegyesen lehet használni mindkét nyelv elemeit. Erre példát remélem majd betesz ide valami rendes kódoló a csapatból (én nem vagyok az), de valahogy így néz ki (html:b (lakosság-of önkormányzat)) azaz egy bodyba bele az lakosság száma.
Keretrendszer
A keretrendszert 2 éve - egy kivétellel félmunkaidőben - tolják elsősorban a többiek. Ez a munka azért volt, hogy legyen a jővőben egy olyan fejlesztői és alkalmazásfuttató környezet (esetünkben a kettő ugyanaz), amivel majdan lehet dolgozni. Ez a framework még fog bővülni - van egy csomó elnapolt ötlet - de elméletileg többet nem kellene vele foglalkozni. Mostantól indulhatnak az alkalmazásfejlesztések. És a 2 év előre befektetett munka megtérülhet akár 1 év alatt is, ha igaz a produktivítási előny.
A 3 hónap valós idő sem a projektspecifikus részek megoldására ment el. Egyrész itt is javarészt félmunkaidőben dolgoztunk rajta, illetve a befektetett munka fele a framework továbbfejlesztésére ment el, ami később kényelmesebbé teszi a következő projekteket.
A teljes alkalmazás kb. 10.000 sor kódot jelent (felfelé kerekítve és tartalmaz(hat) még olyan részeket, amiket később kiemelve a framework részét képezik majd, illetve olyanokat is amikkel kicsit megelőztük az ügyfél jelenlegi igényeit és jelenleg nem használt.)
A framework már most többet tud, mint az Oracle alkalmazásszerver architektúrája, illetve az Oracle új frameworkje (ezeket ismerem, többiek jópár egyebet) a 2 év munkát azok fejlesztésével kell összehasonlítani.
Pénzügy
Ha 10x (de legyen 8x) hatékonyabbak vagyunk, akkor van min osztozkodni az ügyféllel. Fele idő alatt, fele annyi pénzért, kétszer annyit lehet nyújtani. És mi még mindig dupla olyan jól járunk ahhoz képest mintha mással dolgoznánk. (Emberhónapban számolva 8 hónapnyi munkára mi 4-et fizettetünk meg, fele annyi idő alatt végzünk és dupla annyit csinálunk meg. Mindenki jól jár.)
Fejlesztés módszertan
Szerencsére az ügyfél részéről nagyon jó koponya volt vett részt a projektben. A módszertanunkat még alakítgatjuk.
Ezzel kapcsolatban irtam valamikor egy szösszenetet (egy nagyobb doksiból copyztam ide), ami nem biztos, hogy most is helytálló, de nagyjából tükrözi az állaspontunkat:
-------------------------
Minden jelenlegi szoftverfejlesztési módszertanban elkülönült lépésként jelen van a specifikáció és az implementálás. Aztán a módszertanok próbálnak megoldást adni ezen két termék - dokumentumok és a ténylegesen megvalósult programok - közötti konzisztencia biztosítására, ami sajnos szinte lehetetlen feladat.
Forward engineering - Reverse engineering. Ezen két kulcsszó köré épülnek különféle modellező, fejlesztést támogató eszközök a probléma kiküszöbölése érdekében. Azonban ezek alkalmazása jellemzően csak további ráfordításokat indukálnak, és a projekt korai szakaszát leszámítva nem is tudnak teljes körű megoldást nyújtani.
A CL-DWIM kihasználva az architektúra reflexív képességét, miszerint a nemcsak a forráskód, hanem a teljes LISP VM futás közben bejárható (megfigyelhető) és elemezhető, képes önmagát dokumentálni.
Ezzel nem a rendszertervezés, modellezés szükségességét kérdőjelezzük meg, csak azt állítjuk, hogy hatékonyabb:
• ha a specifikációképpen – egy erre a célra szolgáló probléma specifikus nyelven – egyből kvázi programkódot írunk,
• és ha dokumentációra van szükség, akkor azt készítse el az alkalmazás saját magáról.
Ehhez szükséges, hogy a programozási nyelv nagyon nagy kifejező erővel rendelkezzen. Szükséges, hogy implementációként közel azonos, de inkább kevesebb szóval/kóddal leírható legyen a probléma, vagy annak megoldása egy specifikáció írásához képest. Ugyanakkor az is szükséges, hogy az implementációt rugalmasan lehessen később változtatni.
Ezzel a megközelítéssel két dolgot is nyerünk. Egyrészt már a szoftverfejlesztés korai szakaszában is rendelkezésre áll működőképes prototípus, amit használva sokkal pontosabb igénylefedésre lesz lehetőség. Másrészt a termék teljes életciklusa alatt biztosított a teljes körű dokumentáltság.
Ezt kibővítjük azzal, hogy maga a fejlesztés egy az alkalmazással teljes körűen integrált projektvezetési rendszer keretében történik, amely a későbbiekben egyben a rendszer változáskövetésének az alapja is lesz. Maga a leendő alkalmazás már a projekt indulásától kezdve mindent tudhat önmagáról. Munkafolyamatokba szervezhetően nyomon követhető, hogy hogyan és mivé válik egy követelmény.