Ti hogyan indulnátok tovább (java össze-vissza fejlesztés rendbetétele)?

Java

Jelenlegi helyzet:
- webes intranetes alkalmazás
- Rengeteg java / javascript / html / sql / tárolt eljárás kód (kb. 6 év, 5 fejlesztő termése) VelocityServlet-ből örökített
- teszt esetek hiánya
- főnökség gyorsabb fejlesztéseket vár el (teszt esetekre, hogy esetleg több idő lesz a fejlesztés már nem tetszik Nekik - bár lehet, hogy meggyőzhetőek)
- eddig is gyors fejlesztések kellettek, e miatt nincsenek dokumentációk sem
- specifikációk is mindig inkább csak szóban jöttek - jönnek
- objektumorientáltság hiánya, design patternek hiánya - a gyors igények miatt, általában servlet tartalmak másolása, majd átírása volt jellemző
- java nevek (metódus, változók), a legtöbbje nem beszédes
- metódusok stb. túl hosszúak
- svn van, branchek nincsenek - így ha pl. beesik egy nagyobb igény egy modul módosítására, majd beesik egy új igény a régi kód módosítására, gyakorlatilag meg kell várni a nagyobb végét.
(adatbázisnak nincs svn-je tároltak, schema-ák)
- A kódok módosítása a fentiek miatt nehézkes

A fő gond, hogy részemről is hiányoznak az ez irányú fejlesztői tapasztalatok, hogy hogyan is kellene ezeket normálisan levezényelni / csinálni. Most szabira megyek, az alatt jó lenne felszedni / átgondolni néhány dolgot. Pl. teszt esetek írása, hogyan. Adatbázisoknál hogyan. Esetleg milyen irányba kellene tovább menni?

Vannak javaslataitok, hogyan kezdjek hozzá rendbe tenni ezt a rendszert?

  • 12549 megtekintés

( mulder | 2010. 08. 19., cs – 08:29 )

Ha ennyire el van kummantva mar a rendszer, szerintem egyszerubb okosan ujratervezni es ujraimplementalni.

Tisztaba kene tenni, hogy mit vartok a rendszertol.
Jol definialt API-t krealni az egyes retegetk koze.

Ha jol csinaljatok, akkor 2-3 honapnyi brainstorming es tervezes utan nagyon gyorsan lehet fejleszteni. Ha nem, akkor csak mocsarban futas lesz belole, rendszerosszeomlassal bolonditva.

Ha PM-ben el tudod meselni, hogy konkretabban mirol van szo, akkor esetleg tudnek segiteni.

Arra azért kíváncsi leszek, hogy hogyan adja be a főnökségnek, hogy komplett újraírás lenne itt a móka. :)
Főleg úgy, hogy a főnökség gyorsabb fejlesztéseket vár el és eddig is a gyors fejlesztéseket preferálták, gondolom olyan módon, hogy az ostort pattogtatták a droidok mögött. Ebből nekem az jön le, hogy a menedzsment nem egy jól megtervezett és átgondolt szoftvert akart, hanem egy minél gyorsabban összerakottat, ami ennyi év után gyakorlatilag egy összetákolt Titanic, már csak a privát kis jéghegyére vár a habokban. Illetve az is intő jel, hogy a specifikáláson, dokumentáláson és tesztelésen "spóroltak", hogy ezzel se lassítsák a termék kifejlesztését.
Azt a nézetet én is osztom, hogy 6 év és 5 fejlesztő munkáját már nem lehet egyszerű refaktorálással rendbe rakni, ahhoz ez túl sok beleölt munka.

A hibákat amiket felvetettél, elmesélted a főnökségnek is? Mit szóltak hozzá? Beismerik? Tagadják? (ez utóbbi a témaindítónak szólna természetesen :))

( gabrielakos v | 2010. 08. 19., cs – 08:55 )

30 emberévet nem lehet csak úgy refaktorálni. Ez már el van kefélve, addig kell/szabad használni amíg teljesen le nem tudod cserélni.

Szerintem az eljárás:

Keress egy jó frameworköt, esetleg portált (pl. Liferay) és abban kezdd el újraimplementálni.
Természetesen minden általad említett problémára találnod kell megoldást.
Mivel webes a cucc, lehet részleteiben újraimplementálni, a régi rendszert meg szépen beágyazod (link, iframe, akármi) és akkor messze nem fáj annyira a csere.

Kulcsszavak, amik eszembe jutnak, teljesen rendezetlenül:

- svn, struts2, maven, mantis, dokuwiki, hudson, selenium

Adatbázis tesztelés örült szopó általában. Én úgy csinálnám, hogy a teszt adatbázis egy külön példány, esetleg külön virtuális gépen, és mindig 0-ról létre kell hozni. Hogy ez egy dumpból (ami a verzióhoz van csatolva) történik, vagy scripttel, az egyedi döntés kérdése.

Sok sikert, szép nagy falat lesz...

--
Gábriel Ákos

Az atmenet idejere szerintem nem lenne rossz, mert gitben tudsz a svn repotol fuggetlen local branch-okat is csinalni a sajat gepeden, amiben ki tudsz dolgokat tesztelni, majd ha nem tetszik, eldobni anelkul, hogy akar egy pillanatra is a fo svn repo kozelebe kerultek volna ezek a kiserleti kodok. A neked tetszo stuffokat meg mergelheted a master-be, ami jol beallitott git-svn eseteben megegyezik a trunkkel.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( sz332 v | 2010. 08. 19., cs – 08:57 )

Szia,

dobj egy mail-t vagy üzenetet, és megpróbálok segíteni. Igazából úgy látom,
hogy a kód rendberakása csak egy feladat a sok közül...

( danesdzsu | 2010. 08. 19., cs – 10:01 )

"- főnökség gyorsabb fejlesztéseket vár el (teszt esetekre, hogy esetleg több idő lesz a fejlesztés már nem tetszik Nekik - bár lehet, hogy meggyőzhetőek)
- eddig is gyors fejlesztések kellettek, e miatt nincsenek dokumentációk sem"

Hát, én megmondanám, hogy előbb-utóbb kifizetik ezeket, csak utóbb drágább szokott lenni. Sokkal.

( sz332 v | 2010. 08. 19., cs – 10:04 )

Na, most van egy kis időm. Tehát, az első dolog, amit megnéznék nálatok, hogy a fejlesztési folyamatok rendben vannak-e. Igények dokumentálva vannak, tesztelés hogyan (nem) történik, release hogyan zajlik, a változások dokumentálva vannak (normális subversion commit-ok), hibák és hibajavítások között van valami kapcsolat, task kezelésre használtok-e valamit, coding convention-ök vannak-e, és azokat valaki enforce-olja-e (checkstyle, pl.)

Ezek nélkül ha át is állsz egy másik rendszerre, ugyanolyan gányolás fog történni, mint eddig, csak egy másik rendszerben.

Ezek után szépen megnézném, hogy van-e lehetőség/idő a projektet átírni, más alapokra helyezni, vagy pedig az egészet csak lépésről lépésre lehet javítani. Első körben elkülöníteném azokat a kódokat, amelyeket később is fel lehet használni, és azokat, melyek a kukába kerülnek. Akár még az is lehetséges, hogy nem kell olyan sokat átírni, csak néhány 10 ezer sort :D

Innentől jön az, hogy egy teljes átmenetet meg kell tervezni, milyen lépésekben fogod megcsinálni, hogyan fogod mérni a kódminőség javulást (tesztesetek száma, checkstyle hibák száma, field-ről visszajövő hibajelzések száma, ismétlődő hibajelzések száma)

Szép feladat egyébként, én már megcsináltam pár ilyen projektet. Ha kell segítség, dobj egy privi mail-t.

Valószínűleg semmi ilyesmi nincs náluk, amiket felvetettél. Ha lenne és mégis ide jutnak vele, akkor az már önmagában is méretes nagy probléma. Ha nincs, akkor viszont ki kellene alakítani egyet, de ehhez szakértelem is kell, ami meg vagy van házon belül vagy nincs.

Illetve egy fontos kérdés, hogy a menedzsment mennyire áll így a probléma megoldásához. Ugyanis valakinek ki kell fizetni a fejlesztőket, amíg nem termelnek érdemben. A komplett újraírás pedig valószínűleg nem egy 3 hetes munka 2 fejlesztővel, főleg úgy, hogy most illene tervezni is és az általad említett hiányosságokat is pótolni.

( yoursoft | 2010. 08. 19., cs – 11:08 )

Köszönöm a sok hozzászólást. :-)

Kedves sz332!

Köszönöm a felajánlott segítséget. Megkereslek privátban.

( crypton | 2010. 08. 19., cs – 13:49 )

Ez egyértelműen egy managment szintű döntés, hisz hónapokig esetleg évekig nem lenne új fejlesztés, csak a meglévő újraírása, tervezése, újdonságok, technológiák bevezetése, ezért nézzük a mgmt szemével. Mivel ezzel fogsz dolgozni, (vagy már most is ezt teszed) ha lesz rendbetétel ha nem, mindenképp meg kell tanulnod csukott szemmel is ha kell belenyúlni a rendszerbe, bárhová, utána lehet megtervezni az újat vagy tovább építeni a várat. Az rendbetételhez amugylen nem biztos hogy fejlesztői tapasztalatok hiányoznak, hanem managmenti, architecti, db, tesztelői, doku stb. A fejlesztői tapasztalat a konkrést fejlesztéshez, kód refaktoringhoz, részek újraírásához fog kelleni. Amennyiben a fent leírtakat egy embernek kell megtenni belátható időn belül, akkor ide nem egy fejlesztőt kell alkalmazni hanem egész mást.

( mkristof | 2010. 08. 19., cs – 17:44 )

Nahát, ez ilyen Spolsky nap.

Pár érv, hogy miért ne írjátok újra az egész rendszert:
http://www.joelonsoftware.com/articles/fog0000000069.html

10 éves írás, de az érvek nagyon jók. [És mivel nem is annyira programozásról, hanem az emberi természetről szól ezért nem hinném, hogy ennyi idő alatt elavult. :)]

-----------
"Generally, Russian technology assumes dumb machines and smart humans, not the other way around." -- The Russian Tea HOWTO

Maga az írás tényleg jó, olvasmányosak a cikkek, de azért pár dologgal lehetne vitatkozni a párhuzamot illetően. Ugyanis ebben a konkrét esetben sem specifikációjuk, sem dokumentációjuk, sem teszttervük nincs. Kétlem, hogy a Netscape, a Borland vagy a Microsoft ilyen módon állna a fejlesztésekhez.

Ez valóban így van, a cikk nem teljesen illik a fent vázolt helyzetre. De azért szerintem megfontolandó azok a kitételek, hogy:

1, amíg újraírják a rendszert, bukik a cég (amíg kitesztelik, amíg az élesben felmerülő hibákat kijavítják, fokozatosan újraírják ZS feature-t)

2, semmi nem garantálja, hogy X jobban megírja (*elsőre*) mint Y (jó, nagyon gány kódnál lehet, hogy nem így van. De az is lehet, hogy a cégnél olyan a környezet (főnök, etc), hogy X sem tudna jobb kódot és dokumentációt produkálni.)

3, ez a kód valamennyire illeszkedik az infrastruktúrába, egy csomó bugot már elkaptak. Az új kódban ezeket újra végig kéne vadászni.

A cikk javaslata, miszerint elsőre meg kéne érteni a kódot, szerintem hasznos lehet itt is. Főleg, ha a "megérteni"-ben az is benne van, hogy miért lett ilyen... (lásd a kettes pontot)

-----------
"Generally, Russian technology assumes dumb machines and smart humans, not the other way around." -- The Russian Tea HOWTO

A mostaninál csak jobb dokumentációt lehet készíteni, mert a semminél a valami már jobb. :)

Az lehet, hogy egy csomó bugot elkaptak, de sose lehet tudni, hogy ha megpiszkálnak valamit, akkor azzal esetlegesen mi mást rontanak el.

Arra szerintem nehéz szakmailag értelmes magyarázatot adni, hogy miért is lett olyan amilyen. Ha pedig a fejlesztés során a szakmaiság a háttérbe szorul vagy mellőzik, akkor tudható, hogy mi fog kisülni belőle.

( phaul | 2010. 08. 19., cs – 19:26 )

> Ti, hogyan indulnátok tovább (java össze-vissza fejlesztés rendbetétele)?

menekulnek, jo messzire :)
==
`Have some wine,' the March Hare said in an encouraging tone.
Alice looked all round the table, but there was nothing on it but tea.

En is csak ezt javaslom, futas az ellenkezo iranyba, ha vezetesben nincs meg az akarat, hogy jobban menjenek a dolgok, akkor teljesen felesleges. Mindig lesz aki tovabb ganyolja, es egyre nehezebben fog menni, es akkor ha megerett a helyzet, akkor majd jon valaki es ujrairja, es innentol kezdodik elorol a tortenet. Hany ilyen ceget lattam.

( _Franko_ v | 2010. 08. 19., cs – 23:12 )

Vannak javaslataitok, hogyan kezdjek hozzá rendbe tenni ezt a rendszert?

Apránként. Mindig egy kis lépést, csak akkor nagyobbat tenni, ha feltétlen szükséges.

Kezdésképp a verziókezelést kell rendbetenni, ezek után esetleg Maven2 alapra tenni az egészet, ez ugyanis letisztítja a build folyamatot, egy fába szervezi a modulokat gráf helyett. Ezek után minden új feladat mellé oda kell tenni, hogy az érintett modulok refactor munkái is beleférjenek, a lehető legtöbb refactor arányt kell átnyomni a vezetőségen (amely valószínűleg hallani se akar erről :).

Ezek után ki kell találni/mérni/próbálni egy platformot, maxmimum egy-két keretrendszert és oda átmigrálni a meglévő kódokat, nem egyszerre, hanem egy-egy menüpont, folyamat hónapról-hónapra az új platformra kerüljön. Ha jól sikerült kitalálni a koncepciót, akkor drasztikusan csökken a fejlesztési idő, és ezt észre kell vegye a vezetőség, illetve a felszabaduló időt dokumentálásra és tesztírásra lehet majd fordítani.

A lényeg: ne egyszerre történjen minden... :)
--
http://wiki.javaforum.hu/display/FREEBSD

Igen, egy hudsonnal vezérelt maven alapú automatikus build svn commit eseten, 5 perccel kesobb kapsz egy emailt (mint a commit elkövetője) a fordítás eredményéről és a különböző tesztekről, az valami álom :)
sőt, a hudson tud jabberen is üzennni.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

1) biztos kerdeztem mar, de van mavenhez valami total alap tutorial, ami az uj mavenhez is jo? Egyszer probaltam keresgelni, de azok nem voltak jok ahhoz a mavenhez, ami nekem felment.
2) hudson jo dolog, azt viszont nem tudtam, hogy jabbert is tud :o
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( radix | 2010. 08. 20., p – 00:03 )

Azt javaslom, hogy először próbáld megérteni a mostani rendszert, szépen ledokumentálni, hogy mi van.
Ha megértetted, akkor rajzold le magadnak egy darab A4-es papírra.

Eközben jönnek majd az ötletek dögivel - kis, segítő ötletek.
Az mindenféleképpen kell, hogy átlásd az egész rendszert.
Ágyuval nem lövünk verébre, lehet, hogy a fenti dolgok nem is mind kellenek nektek (SVN, teszt esetek, objektumorientáltság).

Ja, és a legfontosabb: SZABI ALATT PIHENJ!!!!!!!!!!!!!!!

( yoursoft | 2010. 08. 20., p – 08:06 )

Köszönöm a sok ötletet. Elsősorban sz332-nek, akivel tegnap este kb. 2.5 órát beszéltünk.

Úgy néz ki, hogy nem olyan szörnyű nagy munka lesz. A rendszer modul rendszerű, az egyes modulok jól működnek. Az utóbbi időben futottunk bele nagyobb modulokba, amelyeknek inkább a sürgős módosításai rontottak jelentősen a kód minőségén.

Még át szeretném beszélni a kollégákkal az új felállást. Viszont első körben úgy néz ki lesz Hudson, Checkstyle egybe integrálva az svn-el. Még lesz wiki is, és hiba követő (Mantis). Valamint elkezdünk unit teszteket is gyártani az új kódokhoz, illetve ahhoz, amihez hozzányúlunk.
Ezzel párhuzamosan igyekszünk "modernizálni" a rendszert valamiféle keretrendszerrel. Első körben lehet, hogy új fejlesztéseknél a VelocityServlet-ek helyett lesz, a Velocity új megközelítésével fejlesztve. Illetve az adatbázisra tolt sok logikát kell majd csökkenteni - új fejlesztéseknél elkerülni.
Illetve igyekszünk meggyőzni a vezetőséget is ezek szükségességéről. Ha nem megy, akkor meg van rá a megoldás, hogy miként oldjuk ezt meg saját berkeken belül. ;-)

Esetleg, ha van még alternatív javaslatotok a felsorolt rendszerekre, vagy további ötlet, azt szívesen veszem. :-)

A probléma, hogy technológiai oldalról közelítesz. Először a projekt folyamatait kell rendberakni, úgy, hogy a menedzsment számára látható legyen a projekt állapota. Sokkal könnyebben fogadja el a (normális) menedzsment, hogy valami mennyi ideig tart, ha látja az előrehaladást pontosan.

Erre egy jó módszer, ha idő alapú release-eket csináltok. Tehát minden hónap végén mondjuk van egy új release.
Az "ügyféligényeket" (= a vezetőség igényeit) gyűjteni kell egy priorizált listában. Amikor a következő release-t tervezitek, mindig a legmagasabb prioritású igényeket csináljátok. Ugyanígy, minden release-be tervezzetek be bizonyos mennyiségű időt a technológiai javításoknak, refaktorálásoknak. Úgy tervezzetek az első időben, hogy ha 4 hét a release periódus, akkor 2 hétig dolgoztok új feature-ön (beleértve a saját technológiai javításokat), 1 hét bugfixelés / tesztelés (régi + új feature), 1 hét pedig release-re felkészülés.

Azt mindenképpen kommunikálni kell a vezetőség felé, hogy a kezdeti időben lassabb lesz a haladás - egyszerűen azért, mert több olyan feladatot kell csinálnotok, amit eddig nem. Meg kell indokolni szépen, hogy nekik miért lesz jobb már 1-2 hónap után: pl. mert pontosan látja a haladást, tudja, hogy egy feature mikorra lesz kész ... stb.

Ezt persze támogatni kell egy jó eszközzel, én is a Redmine-t javaslom. Tud magyarul, és minden benne van, amire szükséged lehet. A menedzsment is tudja kezelni, látni fogják a release-eknél ahogy csúszik a szép zöld csík ... stb.

Aztán ha ez megvan, akkor neki lehet állni a technológiai javításoknak, amik persze mindig sokkal érdekesebbek, de muszáj először a folyamatokat rendberakni. És az első technológiai javítás legyen az, hogy legyenek rendes release meg feature branchok, igy a bugfixek nem akadályozzák a fejlesztést.

A fenti megoldás egyébként az agilis módszertanokra jellemző megközelítés, érdemes pl. egy Scrum könyvet elolvasni, aztán átbeszélni a csapatban, hogy miket vesztek át belőle.

Üdv,
Gergely

Nem meglepő a dolog, az agilis módszertanok is azért népszerűek mert _működnek_ :)
Annyit tennék még hozzá a parenthez, hogy sok agilis dolgot lehet jól csinálni és lehet ScrumButt módon, amikor szépen elmegy a csapat kedve az egésztől... ilyenen a könyv ritkán segít, olcsóbb megbízni valakit, aki már csinált ilyent, hogy segítsen...

( yoursoft | 2010. 08. 20., p – 08:14 )

Illetve, ha már itt tartunk, ki milyen frameworkot használ és miért?
Mik az erősségei illetve gyengéi?
Illetve ha portal rendszert használtok, akkor ugyanezek a kérdések.

( tibyke | 2010. 08. 23., h – 21:17 )

a cimben minek a vesszo a "Ti" utan? valami buta meggyozodes, hogy a "hogy" elott mindig kell vesszo, es ha a hogy elott kell, akkor biztos a hogyan elott is?

t

( b | 2010. 08. 24., k – 06:56 )

Már leírták az összes lehetőséget:

- komplett újraírás (legdrágább, legidőigényesebb),
- meglevő prefab frameworkön újraírni (ehhez embert kell találni, aki ért az új cucchoz),
- folytatni tovább a gányolást (legolcsóbb, de csak bizonyos ideig bírja el a rendszer),
- elfucc jó messzire.

--
GPLv3-as hozzászólás.

Azért vannak fokozatok, szerintem. Ha már valahol módosítani kell, ott lehet egy kis időt "ellopni" arra, hogy valóban javíts is a helyzeten.
Az, hogy webes a cucc, külön jó, mert egyszerű úgy alátenni teljesen más rendszert, hogy ne is látsszon.

Ja és azt senki nem mondta, hogy nem lehet két branchet fenntartani az svn-ben, és a javítások közötti időben az újraíráson dolgozni. :)

Ezért persze hálát hiába is vár a management-től, igazi elszántság kell hozzá, viszont esetleg megadhatja az alkotás örömét.

--
Gábriel Ákos

Természetesen a határok nem élesek, akár össze is moshatóak, de attól még megállják a helyüket. :)

Nem biztos, hogy a javítások közt van idő, mert a leírásból úgy tűnt, hogy elég feszített a munkatempó. Hisz ha lenne idő, akkor azt nyugodtan fordíthatnák mondjuk dokumentálásra. :)
Esetleg az is lehet, hogy ilyen tempó mellett a kedvet is kiölik belőled, hogy csinálj valami értelmeset.

Azt viszont külön kockázatnak tartom, hogy a szabad idejében javítgat rajta vagy éppen újraírja (egyedül nem túl valószínű, hogy belátható időn jut valamire) a menedzsment tudta és beleegyezése nélkül, mert ha azzal éppen szét fog szállni átadáskor a szoftver, akkor ott bizony megüti a bokáját. Persze ez kiderülhetne még akár időben is, ha ráeresztené az összes tesztesetet, de nekik olyan sincs. :)

A menedzsmenttől pedig nem hála kell, hanem beleegyezés és támogatás. :)

Nem tudom, nekem a hg lassabb volt, mint a git. Raadasul nem tudom, a hg tud-e annyira transzparensen svn-t hasznalni, mint a git tud (gyakorlatilag nem csak importal, hanem kepes a valtozasokat a svn-be visszanyomni).
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Lokális műveletek nálam gyorsak, távoli repohoz pl. a kiln ideális, és elég cool interfészt is ad. Git-et nem használtam, nem szeretek pilótavizsgás eszközöket használni :) . A subversion integrációhoz ez a kiindulási anyag van, talán ebben a git mögött van: http://mercurial.selenic.com/wiki/WorkingWithSubversion

( yoursoft | 2013. 01. 24., cs – 09:30 )

Most látom csak mennyi idő telt el.
A lényeg:
Nem adtam fel, hiszen nekem is közöm volt az összevisszaság létrehozásában.
Az új fejlesztések mellett sikerült csendben rendet rakni. A szemétdombok eltűntek. :-)
Még vannak apróságok, de már jól állunk.

1. FindBugs és társaival amit komolyabbnak ítéltem javítottam.
2. Hogy ne keletkezzenek újabb hibák ezért Jenkins + a fenti ellenőrzések automatizálása (figyelmeztető levél - ki commitált és milyen hibát utoljára - az összes fejlesztőnek)
3. Refaktor tömkelege, ezt első kőrben csak azokon csináltam amihez amúgy is hozzá kellett nyúlni
4. Áttértünk JSF 2-re, itt már maga a fejlesztés is valamennyire strukturálja magát, könnyebb teszteket írni rá stb.
5. Régi velocity-s kódok kipucolása, ha nem is fedik le tesztesetek, de mivel elég stabilak voltak, így ezzel már nem küzdöttem - elég, hogy átláthatóbb lett a kód.
6. sokat segített a clipx nevű jószág, ide fel tudtam venni template-ket, az ismert kódfélreírásokra. Már fejből tudtam, hogy pl. e.printStacTrace sor kijelölése, majd clipx gyorsbill. + f és már is egy Logger került a helyére, csak módosítgatni kellett az "e" nevét.
7. Tomcat logok elemzésével sok hibát megtaláltam és javítottam. Előbb a láthatólag sok előfordulásúakra mentem rá, majd a kisebbekre.
8. Mivel sokan beköltöztek a szerverünkre saját alkalmazásokkal, ezért a Db usereket amit nem mi használunk átneveztem és limitáltam a hozzáférésüket (pl. konnekció szám). A mi alkalmazásainkat beraktam egy külön Tomcat alá, Ők meg a másik alatt azt csinálnak amit akarnak. :-)
Így egyből nem az jött elő, hogy a mi alkalmazásunk állt le, mert valaki felette pl. a db konnekciókat, vagy a memóriát, hanem Náluk csapódott le a saját maguk által kreált probléma.
9. Egy megfigyelő alkalmazás beállítása, ha nem működik a szerver csörög.

Van még dolog bőven, de nem izgulok már annyira, hogy mikor dől be a szerver nagyobb user használatnál. :-)

Groovy -ra migrálni nem feltétlenül kifizetődő, ha nagy a kódbázis, akkor elképesztő időt vehet el, ráadásul még Java develből is hiány van...
szerk.: amúgy köszi a linket, átfutva érdekesnek tűnik, bookmarked

--
http://developersideas.blogspot.hu/
http://neurogadget.com/

Nem erre probaltam utalni, hanem hogy ha valaki tenyleg csak az egyszeru setter/getterek miatt hasznalna lombokot, akkor inkabb gondolkozzon el a Groovy bevezetesen a kodbazisba (nem arra portolni, csak belekeverni).
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.