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

• #5485 inf3rno nagyúr Jim-Y #5482

  Új Válasz 2015-09-02 16:07:12 #5485

  Ú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

  

  inf3rno

  nagyúr

  válasz Jim-Y #5482 üzenetére

  Ha van szabadidőd, akkor a helyedben beleolvasnék a "ddd strategic design" részébe egy-két cikknek, könyvnek, ilyesmi, hátha találsz valamit, amit erre az esetre lehet alkalmazni. Rosszul megírt projekteken is lehet vele javítani valamennyit. Azért csodát ez sem tud tenni az eddigiek alapján.

  A tesztek nélküli refaktorálás meg nem egy ajánlott dolog. Érdemes lenne legalább 1-2 e2e tesztet beletenni így utólag a main feature-ök tesztelésére, hogy nagyon fontos dolgok ne törjenek el, ha átírtok valamit. Ez azok alapján, amit elmondtál, bármikor megtörténhet, amikor hozzányúltok a kódhoz.

  Sajna a legacy-val ez van általában. Egy idő után túl nagy erőfeszítés megjavítani, az ember legszívesebben újraírná az egészet, de azért meg nem fizet senki, mert hát a mostani a rendszer is "jól" működik. A refaktorálásért sem fizetnek, hacsak nem sikerül elmagyarázni nekik, hogy minél többször nyúltok hozzá a kódhoz ilyen formában, annál valószínűbb, hogy széthullik az egész.

  Úgy emlékszem, hogy for-in-el próbálkoztam a bejárással, és az Object.defineProperty-nél az enumerable: false eltérően öröklődik az egyes böngészőkben. Valahol nem kerül be bejárásnál a listába az öröklött tulajdonság, valahol meg bekerül. Azt hiszem ugyanígy hibák voltak a setter, getter, congfigurable terén is, de ezt nem mondom biztosra. Küldtem mindegyik major böngészős cégnek bug report-ot, hogy jó lenne közös nevezőre jutni ezzel kapcsolatban, de egyik sem reagált, úgyhogy én inkább nem használom többet azt a függvényt meg a for-in-t bejárásra (kivéve config objecteknél, meg 1-2 helyen). Sugar syntax-hoz kellett volna csak, megoldottam másképp, úgyhogy nem lényeges.

• #5483 inf3rno nagyúr Jim-Y #5482

  Új Válasz 2015-09-02 15:43:24 #5483

  Ú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

  

  inf3rno

  nagyúr

  válasz Jim-Y #5482 üzenetére

  A BDD-t és a DDD-t próbáltátok már, vagy ahhoz meg még túl kicsi a projekt?

  Én most olvasom a Vaugh Vernon könyvet DDD-vel kapcsolatban. Elég jól leírja, hogy hogyan lehet szétszedni kezelhetőbb méretű részekre óriás alkalmazásokat. Szerintem kliens oldalra is használható az elv, ha már akkora lenne a kód.

  A BDD-ehhez többé-kevésbé szorosan kapcsolódik. Nálam kb annyiról szól, hogy cucumber-ben megírod a use case-eket a domain model nyelvén, utána ezeket lefordítod tesztekre step definition-ökkel. Aztán teszteled vele az alkalmazást. Lehet csak a domain model-t is tesztelni, amiben a business logic van, de akár e2e teszteket is lehet írni, és a kliens oldalról megközelítve tesztelni az egész alkalmazást (ez jóval lassabb). Elég széles a tárház, hogy mit tudsz tesztelni, és nagyon rugalmas, mert a step definition-ök szabadon cserélhetőek úgy, hogy közben a use case-ek ugyanazok maradnak felettük. Ha változik a megrendelői igény a logikát tekintve, akkor változik a use case is, ellenkező esetben viszont csak a step definition-höz kell hozzányúlni, ha éppen gombra kell kattintani link helyett vagy ilyesmi egy űrlap küldéshez. Egyelőre ezzel is csak kísérletezek, de egyre inkább úgy tűnik, hogy be tudom venni hagyományos TDD helyett a napi rutinba.

  A kliens oldalon örök szopás, hogy 1000 féle környezetet kell megtámogatni. Nem új dolog. Én futottam már bele mostanában natív js bug-ba is. Nagyon kellemetlen, mert órákon át lehet keresni a kódodban, hogy hol a hiba, miközben nem ott van, hanem a js motorban... Ha nem TDD-vel írtam volna a kódot, akkor elkapálhattam volna magam, mert debug-nál még nehezebb egy ilyet leszűkíteni pár sor kódra. TDD-nél azért képben vagy, hogy éppen mire írtad 1 perce a tesztet.

  Async-hez te milyen lib-eket használsz?

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