Új hozzászólás Aktív témák

• #5255 stevve veterán modder #5254

  Új Válasz 2011-06-23 16:24:50 #5255

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  stevve

  veterán

  válasz modder #5254 üzenetére

  Teljesen érthető álláspont. Jó néha a nézeteket ütköztetni, mert abból lehet tanulni.

  Én sem 1-2 fős csapatokról beszéltem, bár ez nem jött le abból, amit írtam. Én a következőket alkalmazom - természetesen úgy, hogy ma Magyarországon nem gyakorlat a vízeséstől eltérő projektvezetés, hiszen legtöbbször előre rögzített doksikért fizetnek, azok jelentik az első mérföldköveket és azokat lobogtatják másfél évvel később is bőszen.

  "Persze a dokumentáció mennyiségének növekedésével a szoftverfejlesztés időtartama kitolódik."

  Ezért látom én úgy, hogy a minimális jelenthet 0 közeli állapotot is ezeknél, vagyis a kód maga a dokumentáció. Ezt a fenti modell tükrében nem lehet kivitelezni, ám sok doksi gyártható utólag, menet közben is, generálva. A lényeg, minimális legyen a fejlesztők által dokumentálásra fordított idő, így az UML jó része is kimarad a fejlesztőknek - ez legyen a projektvezető vagy rendszerszervező.

  Olyan projektnél, ahol modulokat építünk egybe, írtam is, hogy a kapcsolódási pontokhoz kell valamiféle támpont, az pedig lehet UML is akár. Minimális áldozat, de előre legyártani ezt is éppoly veszélyes, mint egy rendszertervet. Jobb pár meetinget tartani a többi fejlesztővel és kódba belemenni, esetleg már bemutatható, legalább mock interfészekről beszélni. Rengeteg példa van arra, hogy a rendszer változott, csak a doksikban nem vezették át.

  A használati eset és az activity diagramm legyen a projektvezető dolga szintén. Nem fogom ezzel a fejlesztőket terhelni, mert nekik ehhez nem sok közük van közvetlenül. Ez max. arra jó, hogy csekkolni lehessen, hogy a feladatok hol tartanak, mi van még, de erre a prototípusok, release-ek is megfelelnek és abból legalább lát is valamit az ügyfél.

  Class és szekvencia utólag generálandó szerintem, különben erőforrást köt le huzamosabban, ami nem jó. Igen, erre gondoltam, hogy ez lényegesen eltérhet a kiindulási állapottól. Szerintem több modul esetén is simán működhetnek a mock interfészek vagy a sűrű release-ek. Ezek specifikációját viszont nem feltétlenül szükséges UML-ben megadni.

  "A diagramok egy része az implementáció megkezdése előtt születik, más részük közben, megint más részük utólag. Természetesen elkerülhetetlen a változás, mert nem lehet minden eshetőséget lefedni a fejlesztés során. "

  Én is így látom. Előre nem lehet kőbe vésni még nem látható dolgokat. A fejlesztő, architect nem jós.

  "Sajnos rossz gyakorlat az, hogy a dokumentációt fejlesztés után készítik el, és a fejlesztés gyakorlatilag ad-hoc módon történik: a fejlesztők egymás között ledumálják ki mit csinál, aztán probléma van, amikor össze kell hegeszteni a dolgot egy egésszé."

  Nem lehet egyenlőséget tenni az ad-hoc fejlesztés és az utólag dokumentálás között. Ismét megemlítem, hogy a legjobb dokumentáció maga a kód - abban nincs és nem is lehet összebeszélés, háttéralku. Ilyet egyébként sem lehet megengedni, de egy class diagram mégis akkor lehet teljes, ha a kész/félkész kódból generáljuk.

  Amit itt írsz, pont a kis csapatokra vonatkozik (leosztják egymás között a feladatokat, megy a susmus, stb.), de nagyobbaknál is jól működhet az, hogy nem egy bizonytalan és régi rendszerterv és UML-ek alapján fejlesztenek, amiket nem tartanak karban, hanem az igények szerint és a haladást maga a termék jelenti. Így az ügyfél is hamarabb lát belőle valamit és így jobban is tud gondolkodni, mint ábrák alapján.

  "El kell fogadni, hogy a dokumentáció a fejlesztés szerves része, és mint említettem, nagyobb projekteknél a kommunikáció folyamatossága érdekében elkerülhetetlen rossz vagy éppen jó."

  A régi szemlélet szerint igen. A vízesés modellben máshogy el sem lehet képzelni a fejlesztést, de maga a modell eleve csak rossz példaként lett régen is megemlítve, amikor felkapták. Ha a levelezést nem tekintjük dokumentációnak, akkor a kommunikációhoz nincs szükség rendszertervre, UML-re és egyebekre. Nem kell kizárni, mert lehet, hogy azt valaki annyira vágja, hogy azonnal lát mindent, de sok esetben a kód, az alkalmazás sokkal hasznosabb forrás.

  Nem mondom, hogy ez a szuper és ultimate módszer, meg így kell mindenkinek, de én így látom. Az agilis és egyszerű, letisztult fejlesztést részesítem előnyben és ez nem csak idea.

  Egy példa még a végére:
  Régi vesszőparipám az, hogy sok projekt az adatbázis megtervezésével indul, holott ez a rész 90% eséllyel szinte azonnal megváltozik. Ha a "dekompzíció" és a funkciók mentén haladunk, akkor elemi feladatokkal gyorsabban lehet bemutatható alkalmazást készíteni, mint a legnagyobb falattal szöszmötölni.

  Természetesen ehhez befogadó projektvezetés és ügyfél is kell.

  Hű, de hosszú lett. bocs.

Új hozzászólás Aktív témák