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

• Sk8erPeter nagyúr

  #5616

  #5603 inf3rno

  2015-11-03 19:02:25

  Új Válasz

  Ú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

  

  Sk8erPeter

  nagyúr

  #5603 inf3rno

  #5603 inf3rno

  Én jelenleg hobbi projekteknél fejlesztek így, most éles projektjeim nincsenek. Régebben éles projekteknél még nem ismertem ezeket a technikákat, személyes tapasztalatom annyi, hogy volt olyan projekt, aminél utólag írtam meg a teszteket, és az SQL-ek felében volt kisebb nagyobb hiba, amik nem derültek ki azonnal, mert csak ritkán használt útvonalakról volt szó.
  Tudok olyan multiról, ahol TDD + SOLID + OOP alapvető, és a backend-et így fejlesztik, nem véletlenül írtam. Nem hinném, hogy nyugis munkahely lenne, inkább csak elvárják a minőségi kódot, meg egy méret (pár ezer sor) felett széthullik a szemét, amit tesztek nélkül fejlesztesz. A GUI-t nem feltétlen éri meg e2e tesztekről indulva fejleszteni, de azért érdemes lehet bedobni párat a fontosabb feature-ök ellenőrzésére, ha nem is minden apróbb hülyeségre. A DDD egy projekt méret felett éri meg jobban, mint a monolit, én személy szerint ezzel nem értek egyet, próbálom kisebb projekteknél is alkalmazni. Arra, hogy a TDD/BDD többlet idővel járna mutathatnál valami bizonyítékot, mert pont az ellenkezője igaz. Debugra összességében több idő megy el, mint arra, hogy a teszteket előre megírd, és az alapján fejlessz. Persze ha nem veszed komolyan az egészet, vagy nem fotnos a minőség, akkor nyugodtan fejleszthetsz tesztek nélkül is.

  "Arra, hogy a TDD/BDD többlet idővel járna mutathatnál valami bizonyítékot, mert pont az ellenkezője igaz."
  Ha nem baj, megfordítanám a dolgot: arra mutathatnál nekem olyan általánosítható bizonyítékot, hogy minden esetben gyorsabb összeállítani egy gigarendszerben - annak összes függőségével, aktuális használati esetnek megfelelő konfigurációjával, stb. - egy valóban komplett tesztkészletet egy kisebb/nagyobb feature időre történő fejlesztéséhez, mint TDD/BDD aktuális alkalmazása nélkül azt elkészíteni. Mint minden általánosítás, a tiéd is itt sántít. Ha előre megvan hozzá minden infrastruktúra, valóban csakis mindenki úgy készített kódot, és valóban mindenki töltötte az idejét a minden esetre kiterjedő tesztesetek lefedésével, akkor előfordulhat, hogy nem akkora para, de van, amikor tényleg para.
  De hidd el, ezt nem bántásból vagy kötekedésből írtam le, hanem azért, mert a gyakorlat sokszor sajnos messze kell, hogy kerüljön az elméleti bullshittől, még ha az elméleti bullshitnek nyilvánvalóan lehet bőven létjogosultsága.

  "Persze ha nem veszed komolyan az egészet, vagy nem fotnos a minőség, akkor nyugodtan fejleszthetsz tesztek nélkül is."
  Hümm, tehát arra, aki valaha életében merészelt leírni TDD/BDD-elvek alkalmazása nélkül kódot céges környezetben (alap, hogy az első kör nem az éles), Te most itt ünnepélyesen kijelentetted, hogy nem veszi komolyan az egészet, meg annak nem is fontos a minőség, értem.
  Sajnos nem lettem meggyőzve - de még egyszer megemlíteném, cseppet sem becsülöm le a TDD/BDD előnyeit és szépségeit. (Egyébként meggyőzésként említettél EGY multit, ahol állítólag csak olyan kódot adnak ki a kezükből, ami ezen elvek mentén készül - egyrészt nem tudhatjuk ennek valódiságát, másrészt nem egy nagy merítési minta. De a gondolkodásmódod alapján biztos csakis ott lehet a szakma krémje, ahol ez percről-percre szem előtt van, máshol csak noobok és igénytelen k×csögök vannak. )

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