A cégnél, akiknek dolgozom, több csapat is azt a módszert alkalmazza, hogy a Continuous Integration eszközéből (Hudson/Jenkins ill. TeamCity) deployál a tesztkörnyezetekbe. Minden tesztelőnek van egy saját környezete, és mindegyik környezethez tartozik egy nyomógomb a CI eszközben. Ha a tesztelő megnyomja a környezetéhez tartozó gombot, akkor a CI eszköz deployálja az SVN trunkben lévő utolsó revisionhöz tartozó verziót a környezetébe.
Korábbi munkahelyemen abban a szerencsés helyzetben lehetett részem, hogy egyazon terméket fejleszthettem a kezdetektől 3 éven keresztül. A termék “vállalati” alkalmazás, ami nagymegrendelőknek (több tízezres felhasználószámnak) készült. Talán másoknak ez egy csapásnak tűnhet, hogy miért kell évekig ugyanazt a szoftvert túrni, én azonban ezen a projekten tanultam eddig a legtöbbet. Egy kisebb méretű (6-7 fős) szoftverfejlesztői csapattal dolgoztunk, a feladatom a bitfaragás mellett az ügyfélelvárások és az üzleti folyamatok megértése is volt, tehát üzleti elemzőként is funkcionáltam.
Pár év fejlesztés során a rendszerbe folyamatosan kerültek be az újabbnál újabb funkciók, amely egy iszonyúan komplex (vagy bonyolult?) rendszert eredményezett. Nagyon jól értettem az üzleti elvárásokat, azt is értettem, hogy ezek hátterében mi húzódik meg, és nagyon jól értettem a kódot, mert magam is aktívan fejlesztettem. Egy idő után az ügyfél által elvárt újabb funkciók komoly dilemmát jelentettek a szoftver továbbfejlesztésében. Ha lefejlesztjük az újabb funkciót, akkor az még bonyolultabbá teszi az eddigi modellt, amellyel az üzleti környezetet próbáltuk leképezni.
Legtöbbször ilyenkor egy fejlesztő cég próbálja lepattintja magáról a továbbfejlesztési (változáskezelési) igényeket, mert már nem képes kezelni a kódban fellépő komplexitást. Természetszerűleg mi is törekedtünk arra, hogy minél egyszerűbb megoldást vállaljunk be, de még így is sokszor nehézségekbe ütköztünk. Ekkor vetődött fel a gondolat:
Miért ne töröljünk régi kódokat, kódrészleteket, miért ne egyszerűsítsük őket, ha tudjuk, hogy nincs rájuk szükség?
Ha ezt nem tesszük, egyre csak lassítjuk a munkánkat, mert az új funkciók implementálása és a jelentkező hibák javítása egyre tovább tart.
Hosszas munka eredményeképpen Csutorás Zoltán barátommal elkészültünk az infoq.com-on, 2009 év végén megjelent Kanban and Scrum – making the most of both elektronikus könyv magyar fordításával. A magyar címnek ezt választottuk: Kanban és Scrum – mindkettőből a legjobbat!
A könyv a Scrum és a Kanban módszerek egyik legjobb összefoglalását adja. Mindenkinek ajánljuk, akik az agilis projektvezetési módszertanok iránt érdeklődik akár megrendelői vagy szoftverfejlesztői oldalon, ezen belül is üzleti elemző, projektmenedzser, fejlesztő vagy akár tesztelő szerepkörben.
A könyv eredeti verziója – az azóta több nyelven is elkészült fordításokkal – elérhető az infoq oldalán.
A héten résztvettem egy szoftverfejlesztői álláshirdetés megfogalmazásában. A kiírás rendhagyóra sikeredett: az első oldalon leírtuk, milyen – szerintünk – egy jó szoftverfejlesztő, a másik oldal pedig arról szólt, milyen egy szoftverfejlesztő napja a cégnél.
Ketten dolgoztunk ennek a provokatív, figyelemfelkeltő álláshirdetésnek az elkészítésében. Pont ez a provokáció volt az, ami nekem tetszett az egészben. A cég vezetőségében viszont úgy döntöttek, hogy finomítanak az eredeti megfogalmazásunkon, és a szövegben fellelhető “vadhajtásokat” lenyesegetik. Az egyik mondat, amelyikre a legbüszkébb voltam (és akár egy buddhista tanításnak is beillene), végül kikerült a végleges szövegből:
A jó szoftverfejlesztő nem lepődik meg azon, ha állandóan “változnak a követelmények”, mert tudja, hogy valójában azok nincsenek is, mert egyetlen cél létezik csupán: a végén jó szoftvert előállítani.
Felkértek részvételre egy programozói verseny zsűrijébe.
Ha pályakezdő vagy, szeretsz Javában szoftvert fejleszteni, és kíváncsi vagy arra, hogy mit gondol munkádról a szakmai zsűri, mindenképpen ajánlom, próbáld ki magad!
A célunk, hogy egy viszonylag egyszerű feladat megvalósításával hívjuk versenybe az érdeklődőket, és a legjobbakkal hosszátávú együttműködést alakítsunk ki.
Nem kell hosszú hetekig “reszelni”, inkább azt teszteljük, hogy hogyan készíted el az alkalmazást.
A feladatot pár héten belül publikáljuk, további részletekről keresd a verseny honlapját: http://legjobbfejleszto.com
Ahogy telnek az évek, és egyre idősebbé válik az ember, annál többet nosztalgiázik. “Bezzeg az én időmben!” – hangzik a sokat nem érő kijelentés.
SOA, SOAP, BPEL, Workflow, Design Patterns, EJB, GUI-technológiák, cluster, mindenféle alkalmazásszerverek. Folytathatnám a sort. Nincs jó kedvem, amikor rájuk gondolok. Bezzeg, amikor még Turbo Pascalban írtam az alkalmazásokat, és assembly-betétekkel interruptokat hívtam! Saját MOD-lejátszó. Azok voltak ám a szép idők! A BGI-driverrekkel én magam rajzoltam a Hercules monitorra, és mindig tudtam, hogy mi történik… CTRL-F9: fut a program!
Continue reading
2010. szeptember 23-25. között kerül megrendezésre Prágában Közép-Európa legnagyobb webbel foglalkozó konferenciája a WebExpo 2010. Fókuszban a webfejlesztés, design, az internetes businessek és az agilis szoftverfejlesztés.
A jelentkezés díj augusztus 31-ig 160 EUR, utána 200 EUR. (Diákoknak 80 ill. 120 EUR.) Részletek a rendezvény oldalán, a http://webexpo.net címen. A program folyamatosan bővül, ezért érdemes vissza-vissza tekinteni az oldalra.
Ajánlom mindenkinek, aki szeretne találkozni a téma legjobbjaival a gyönyörű Prágában!
Szofverfejlesztési projekteknél gyakori jelenség a rövid határidő. Szinte látom is lelki szemeim előtt a PM-et, ahogy projekttervet készít: feladatokra bont, ütemezi a feladatokat, erőforrásokat rendel hozzá és szintez. Közben a kirajzolódó Gantt-diagramban gyönyörködik: belenagyít, jobbra-balra szkrollozza. “Ezek a feladatok kritikus úton találhatóak. Rövid a határidő, rendeljünk több embert ezekhez a feladatokhoz!” Vagy: “Késésben vagyunk, rakjunk rá még embert a projektre!”
Több, mint 30 éve tudjuk már, hogy az elképzelés teljesen hibás.
Continue reading
Szeretném a következő képregény zsenialitására felhívni a figyelmet. Önmagáért beszél J
Forrás: http://flood.blog.hu/2010/07/22/szoftver_specifikacio
Miután végig olvastam a Clean Code-os könyvet, azon gondolkodtam: tök jó volt ez a könyv, de hogyan fogjuk tudni a projektben alkalmazni a több száz oldalon keresztül ismertetett mintákat, szabályokat?
Aztán eszembe jutott egy ötlet: kiválasztom, hogy szerintem mi az az 5 legfontosabb szabály vagy smell, ami leginkább befolyásolja a tiszta kód kialakulását, és aminek az alkalmazását szigorúan vesszük, miközben kódolunk. Íme az én listám.
JTechLog – Viczián István java blogja Tajti Ákos C és Java blogja QualityOnTime Adaptive PM Menedzsmentor blog