Brałem kiedyś udział w projekcie, gdzie nie udało się zastosować clean&architecture... No jak się popatrzyło na testy to, testowanie serwisu, który woła inny mikroserwis było ciężkie... Po drugie nie sztuką jest napisanie 10 testów, który jeden z nich testuje scenariusz biznesowy, a 9 pozostałych klocki w domenie... Brak ściśle ustalonych zasad przez architekta na projekcie jest słabe. To co by nie robić potem i jak nie upiększać kodu, i wykrywać bugi to błąd popełniony na początku architektury najwięcej kosztuje. Złe rozdzielenie domain od infrastructure wpływa na testy... W takim projekcie z czasem wychodzą kwiatki,a. potem za późno jest na refactor, cr etc. Wychodzi na projekcie brak architektury --- bo było to dirty architecture, bez anty corruption layer, bez wydzielenia domeny, nie sztuką jest zrobić package o nazwie domain.... To, że ludzie mają na projekcie np. Spock - nie oznacza że wiemy co to TDD/BDD... Potem cała domena jest w BDD otestowana ... Jakiś sens w tym głębszy, skoro jak mamy Bounded Context to on powinien być przez Fasade-Serwis otestowany? Ludzie naoglądają się prezentacji o BDD/TDD/DDD/Ports&Adapter/Microservices a jak przychodzi w miarę prosta rzecz do okodowania to więcej zaczyna się poświęcać o to aby mieć pokrycie testami(źle rozumiane)... No potem też ze względu na złą architekture ciezko odzielic testy funkcjonalne od integracyjnych, albo ktos pisze fukncjonalne uzywajac do tego I/O i testuje sie cos z 3 minuty zamiast 10sekund....
Brałem kiedyś udział w projekcie, gdzie nie udało się zastosować clean&architecture... No jak się popatrzyło na testy to, testowanie serwisu, który woła inny mikroserwis było ciężkie... Po drugie nie sztuką jest napisanie 10 testów, który jeden z nich testuje scenariusz biznesowy, a 9 pozostałych klocki w domenie...
Brak ściśle ustalonych zasad przez architekta na projekcie jest słabe. To co by nie robić potem i jak nie upiększać kodu, i wykrywać bugi to błąd popełniony na początku architektury najwięcej kosztuje. Złe rozdzielenie domain od infrastructure wpływa na testy...
W takim projekcie z czasem wychodzą kwiatki,a. potem za późno jest na refactor, cr etc.
Wychodzi na projekcie brak architektury --- bo było to dirty architecture, bez anty corruption layer, bez wydzielenia domeny, nie sztuką jest zrobić package o nazwie domain....
To, że ludzie mają na projekcie np. Spock - nie oznacza że wiemy co to TDD/BDD... Potem cała domena jest w BDD otestowana ... Jakiś sens w tym głębszy, skoro jak mamy Bounded Context to on powinien być przez Fasade-Serwis otestowany?
Ludzie naoglądają się prezentacji o BDD/TDD/DDD/Ports&Adapter/Microservices a jak przychodzi w miarę prosta rzecz do okodowania to więcej zaczyna się poświęcać o to aby mieć pokrycie testami(źle rozumiane)... No potem też ze względu na złą architekture ciezko odzielic testy funkcjonalne od integracyjnych, albo ktos pisze fukncjonalne uzywajac do tego I/O i testuje sie cos z 3 minuty zamiast 10sekund....
To wszystko mogło trwać 20 minut.
Czego my programiści możemy nauczyć się od księgowych pisze Wujek Bob: michalkulinski.blogspot.com/2018/05/wymowki.html