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

• #5276 stevve veterán Sk8erPeter #5272

  Új Válasz 2011-06-24 23:08:12 #5276

  Ú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 Sk8erPeter #5272 üzenetére

  A refaktorálás jó dolog, de tudni kell abbahagyni, mert a végén sosem leszel kész vele.

  Én is ismerem az UML-t és ha kérik, használom is(projektvezetők sokszor kérnek legalább sequence diagramot, használati esetet). Aki használja, biztosan előnyére használja, nem hobbiból. Viszont egy projektbe belekényszeríteni, időt, erőforrást pazarolni rá, azt nem szeretem.

  Ahogy cucka is írja, egyre többen vannak, akik az agilis fejlesztés felé hajlanak és nem a vízesés hülyeségei felé, így az UML is kezd az ügyfél és a projektvezető, rendszertervező közötti kommunikáció irányába eltolódni. Természetesen egy utólag generált class diagram mindig jól jön, főleg ismeretlen kódnál.

  A patternekről hasonlóan vélekedek, mint cucka. Ezek nem kőbe vésett dolgok, ráadásul sok már obsolate is a GOF-ból, ami mellé viszont számtalan érkezett az idők során. Én leginkább példák alapján tudom megjegyezni ezeket, de ez egyéni dolog. Sok suliban már tanítják legalább, de az nem túl hasznos, hogy vizsgán fejből kell tudni az UML-t, holott a diák még egy dekorátort nem írt meg. Mondjuk ez nem az UML hibája. Persze vannak alapvető elvek is a minták mellett, mint a DRY, a DIP vagy a SOLID, amiket jó megfontolni és jó volna oktatni.

  Amúgy mindenkinek köszi, hogy ezt ilyen jól meg tudjuk beszélni. Nagyon jó több nézőpontot látni.

• #5275 cucka addikt Sk8erPeter #5272

  Új Válasz 2011-06-24 21:41:22 #5275

  Ú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

  

  cucka

  addikt

  válasz Sk8erPeter #5272 üzenetére

  Ha már erről van szó - a különböző tervezési minták alkalmazása esetén is szinte elkerülhetetlen szerintem az áttekinthetőség érdekében egy normális UML-diagram megalkotása a programunkban szereplő objektumok kapcsolódásáról ahhoz, hogy a megfelelő tervezési mintát rá tudjuk húzni a saját feladatunkra.
  Ezt így írják a tankönyvekben, a valóság azért kicsit más. A tervezési minták egyáltalán nem mindenhatóak, tulajdonképpen csupa olyan dolog, amire magától is elég hamar rájön az ember, ha mereven ragaszkodsz hozzájuk, akkor az inkább árt, mint használ.
  Persze, az egyetemen van olyan tantárgy, ahol ezt tanítják, ott nyilván azt fogod hallani, hogy ezek aztán elengedhetetlenül fontos dolgok és ezek nélkül nincs minőségi szoftver.

  Az van, hogy a valóságban egyre több helyen agilis módszertan szerint fejlesztik a szoftvert (sokszor nem tudatosan), ott meg nem úgy működnek a dolgok, hogy a felhasználó által előzetesen jóváhagyott specifikáció alapján hetekig-hónapokig reszeljük a különféle uml diagramokat, majd amikor menet közben változik a specifikáció, akkor megint csak reszelgetjük hetekig, hogy a valódi állapotokat tükrözzék.
  (Te csak osztálydiagramról beszéltél, van még ezen kívül pár fajta UML diagram)

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