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

• #5257 modder aktív tag stevve #5255

  Új Válasz 2011-06-23 17:56:15 #5257

  Ú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

  

  modder

  aktív tag

  válasz stevve #5255 üzenetére

  Igaz, hogy a kód lehet jó dokumentáció, de ehhez a kód jól dokumentáltsága is szükséges, amiből aztán jó dokumentáció generálható. Nem Javadoc, mert az nem mutat semmit, de pl. Doxygen (vagy fizetős vállalati eszközök). -- ezt csak megjegyzésben írtam, tegyük fel, hogy ez adott.

  Jól kifejtetted, a teljesség igénye nélkül néhány dolog ami még eszembe jut.

  Mint mondtad, különböző modulok kapcsolódási pontjához hasznos a dokumentáció. Tegyük fel, hogy egy library-t megírt egy fejlesztő, aminek a használata szükségessé válik a projekt egy előrehaladottabb fázisában. Itt már nem biztos, hogy az automatikusan generált osztálydiagram elég, mert az nem fog semmit jelenteni a többi fejlesztő számára a lib használatát illetően. ilyen esetben, akár a hivatalos fejlesztői dokumentációban is megjeleníthető legalább valami kollaborációs diagramra szükség lesz, amit a fejlesztőnek kell létrehozni. -- te is hasonlóra gondoltál?

  Egy kis csoportról beszélve, akik egy modulon dolgoznak, pedig szintén nem árt, ha ismerik az UML-t. Egy megbeszélés alkalmával rögzített program flow-t lehet rögzíteni akár papírra, így az adott iterációban vissza lehet hivatkozni rá. Kvázi ez egyenlő azzal, hogy nem kell fejben tartani. Ez egy informális dokumentáció, de UML-t használva még kevesebb hibához is vezethet, mint egy "móriczkarajz"

  A használati eset és az activity diagramm legyen a projektvezető dolga szintén.
  Ebben igazad van, de valakinek (a szoftverfejlesztőnek) el kell tudni olvasni azt.

  Rengeteg példa van arra, hogy a rendszer változott, csak a doksikban nem vezették át.
  Igen, sajnos a dokumentációt is karban kell tartani. Ha már automatikusan generált doksit említettem, ezt lehet a buildelési fázishoz is kötni. Viszont elvetemült öltet lenne minden iterációban újravizsgálni a dokumentációt is.

  Egyetértek azzal, hogy nem kell túldokumentálni mindent, és jól működik általában a szoftverfejlesztés formális és informális megbeszélések alapján. Ami igazából a mondanivalóm, az az , hogy az UML teljesen alkalmas ezen megbeszélések alkalmával információátadásra, ideiglenes dokumentációként.

  Dekompozició elve:
  Minden dekompozició legvégül egy adatbázis tervhez vezet, de tényleg fölösleges az egész rendszert megtervezni adatbázis szinten az elején. Tulajdonképpen az iteratív szoftverfejlesztés pont erről szól, nem? Nem lehet úgy végigcsinálni egy szoftverfejlesztést, mint egy hidat: terv -> implementáció -> kész

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