[Khaine]

#programowanie #csharp #wpf

Zastanawiam się jak mogłem żyć kiedyś bez kontenerów wstrzykiwania zależności? W poprzedniej firmie mieli masę rzeczy zrobionych na WPFie i funkcjonowali bez MVVMLight jakimś cudem wlekąc po klasach referencje (ꖘ‸ꖘ)

Dzisiaj musiałem zrobić na szybko pewien utility projekcik, to pierwsze co zrobiłem oczywiście to zapięcie do niego MVVMLight. SimpleIoc + Messenger + DispatcherHelper i 90% gównobloatu odpada na dzień dobry. 3 godzinki, pyk pyk a kod wynikowy dosłownie sterylny. Wszystkie strategiczne klasy siedzą grzecznie w pojemniku i jednocześnie są wszędzie dostępne w razie potrzeby. Odbieracze wiadomości mają w dupie skąd się biorą a wysyłacze mają w dupie kto tego słucha i wszystko działa.

Ale jak ktoś tego nie zobaczy w akcji w jakimś nieco większym projekcie, to chyba się nie przekona do tego tak łatwo ( ͡º ͜ʖ͡º)

[k.....e]

@Khaine: Dependency injection to nadwzorzec. Wszyscy możemy być wdzięczni programistom Javy EE (wtedy jeszcze J2EE), że we wczesnych latach 2000 spopularyzowali to

[Khaine]

@kebab-case: Bez niego jest niemiłosierny syf w kodzie. Mamy taki jeden projekt, gdzie mamy sterowanie kilkoma rodzajami maszyn na raz i każda ma swoją specyfikę... ale też elementy wspólne. Dzięki odpowiedniej segregacji można było po prostu dać te interfejsy/klasy jako argumenty konstruktorów, wrzucić to w kontener a on sam już przy tworzeniu instancji tworzy sobie co trzeba, przekazuje w argumentach i wszystko z--------a w kilku linijkach bez nawet dotykania instancji

[k.....e]

@Khaine: DI jest przydatne jeszcze podczas testów, bo możesz sobie wstrzykiwać zmockowane wersje zależności

[Khaine]

@kebab-case: Wiem, ale rzeczy którymi się zajmuję są praktycznie nietestowalne inaczej niż manualnie, dosyć abstrakcyjne rzeczy.

[k.....e]

@Khaine: Jeżeli coś jest nietestowalne to jest po prostu źle zaprojektowane xD Change my mind

[Khaine]

Jeżeli coś jest nietestowalne to jest po prostu źle zaprojektowane

@kebab-case: Raczej nie ma czasu na robienie takich testów jakie byłyby potrzebne aby stwierdzić czy wszystko dobrze działa. U nas mówimy o zastosowaniach pokroju komunikacja z PLC i sterowanie maszyną, nie widzę tutaj zastosowania dla testów jednostkowych. Więcej byłoby kombinowania niż faktycznego pożytku. Lepiej po prostu zapiąć wszystko ze sobą, klikać z GUI tak jak użytkownik by to robił i

[k.....e]

@Khaine: NIe muszą być testy jednostkowe. Mogą być testy end to end, które sprawdzają czy są spełnione cosy z poszczególnych user story, dzięki temu chociaż wiesz czy nie zrobiono jakiejś regresji w kodzie

[Mazowia]

@Khaine: Pamiętam jeden stary projekt bez DI, jedna zmiana w konkretnym miejscu i wszystko sypało się jak domki w Czeczenii. ( ͡° ͜ʖ ͡°)

[Khaine]

@kebab-case: Nie no, end-to-end to akurat muszą być xD Jak inaczej można by w ogóle cokolwiek sprawdzać? Testerzy mają porobione scenariusze w Squashu i są informowani kiedy coś co mogło mieć potencjalnie wpływ zostało dotknięte, żeby mogli przelecieć je od nowa.

Mój sceptycyzm tyczy się przede wszystkim testów jednostkowych, które generalnie uważam często za zbędny i kosztowny bloat, który nic konstruktywnego nie wnosi w ostatecznym rozrachunku. W tym projekcie z

[k.....e]

@Khaine:

Nie no, end-to-end to akurat muszą być xD

No ale chodzi mi o automatyczne xd

[Khaine]

@kebab-case: No to u nas nie zrobisz automatycznych end-to-end, po prostu ¯\_(ツ)_/¯ A przynajmniej nie w tym konkretnym projekcie o którym mówię. Tzn dać to się da i parasol w dupie otworzyć, ale nie jestem pewien czy dysponujemy przenośną aparaturą pomiarową do porównywania stanu faktycznego z tym co się kręci w kodzie xD Tzn dysponujemy - nazywa się "oczy" xD

To nie taka prosta sprawa jak w komunikacji między frontem

[k.....e]

@Khaine: u mnie się robi automatyczne testy e2e z hardwarem

[Khaine]

@kebab-case: Jak jest kasa i czas, to się można bawić ¯\_(ツ)_/¯ I to też jest pytanie o jakim hardware mówimy, bo hardware to zarówno jakiś sterownik, któremu się bajty raczej nie poprzestawiają jak i urządzenia pomiarowe oraz mechaniczne, które są tutaj największym problemem - szczególnie że maszyna ma pracować w dosyć ekstremalnych warunkach i nawet nie wiemy czego się spodziewać.

Po prostu i tak zawsze się skończy tak, że ktoś

[villager]

@Khaine: byłem sceptyczny co do DI ale ostatnio napisałem pierwszy projekt na nim, zajebisty szajs