No właśnie. Próbuję już na różne sposoby, ale spotykam się ze ścianą (przecież działa). Jak byście przemówili do współpracowników, żeby przekonać ich do tego, że loose coupling jest zdecydowanie lepszym podejściem*?
*pomijam rzeczy typu wbudowane systemy operacyjne i inne, gdzie tight coupling może być sensowny.
Jak macie tight coupling to w jaki sposób piszecie testy?
Aż musiałem wygooglać co to tight coupling XD
Jakie macie objawy tego że macie tight coupling ?
I na co te objawy chcesz zmieniać?
Jak chcesz je leczyć?
No bo jakbyś mi na review powiedział Masz tight coupling, zmień na loose coupling to bym chciał żebyś wytłumaczył i na przyszlość był precyzyjniejszy przy robienu review :D
U nas w pracy niektóre części były bardzo mocno ze sobą powiązane zanim przyszedłem i dyskusje były takie:
O testach nic nie mówiłem, do tego doszliśmy dopiero po czasie i wtedy to był zachwyt, że istnieją testy jednostkowe :)
Z moich obserwacji wynika, że ciężko przekonać ludzi lubiących pływanie w szambie do tego, że może istnieć lepsze życie.
Ogólnie najpierw chyba sobie trzeba wyrobić jakiś taki respekt - np. naprawić srogi fakap, aby w ogóle zaczęli słuchać, a potem powoli można przemycać różne drobne rozwiązania. Jak się przemyci ich odpowiednio dużo, to ciężko będzie wrócić do stanu poprzedniego. Tylko to wymaga czasu i cierpliwości, które nie każdy ma.
No i z tym loose też bym uważał, żeby czasem nie wyszło zbyt loose. ;)
Zmiana czegokolwiek w mocno powiązanym projekcie powoduje zmianę działania w przypadkowych miejscach tego systemu. Ale przekonywanie będzie ciężkie, do takich rzeczy trzeba dojrzeć, zwykle przez kilkukrotne przywalenie w ścianę na pełnej prędkości ;)
Pokaż konsekwencje takie sposobu uprawiania kodu, tak jak zasugerował @KamilAdam
Juhas napisał(a):
No właśnie. Próbuję już na różne sposoby, ale spotykam się ze ścianą (przecież działa). Jak byście przemówili do współpracowników, żeby przekonać ich do tego, że loose coupling jest zdecydowanie lepszym podejściem*?
*pomijam rzeczy typu wbudowane systemy operacyjne i inne, gdzie tight coupling może być sensowny.
Czy w ogóle da się ich przekonać? Czy ich podejście wynika z nieopierzenia czy z betonu?
Jeśli z nieopierzenia, to możesz podejść z entuzjazmem, jakiś lightning talk o tym, slajdy, pokazywanie, w jaki sposób zrefaktorowałeś dane moduły, żeby były niezależne, co ci to dało itp.
Jak z betonu, to nic się nie da zrobić.
Inna sprawa - czym się przejawia ten tight coupling, a w jaki sposób chcesz, żeby się przejawiał loose coupling?
Bo można przesadzić w drugą stronę i iść w cargo cult wydzielania wszystkiego tylko dlatego, że można (Hello World enteprise edition), a potem robi się ileś warstw abstrakcji i overengineering. Czasami gorszy, ale prosty kod jest lepszy od lepszego, ale bardziej pokomplikowanego (ale to zależy od konkretnej sytuacji).
@Juhas: jaki konkretnie (istniejący) problem rozwiążesz przekonując współpracowników do swoich racji?
yarel napisał(a):
@Juhas: jaki konkretnie (istniejący) problem rozwiążesz przekonując współpracowników do swoich racji?
Chociażby wstęp do unit testów. Ale nie wiem jak gadać, żeby ich przekonać do zmiany czegokolwiek. No bo przecież "działa", to po co ruszać?
@Juhas: To przekonuj ich do pisania UT, do "loose coupling" przekonają się sami. Tylko wszystko zależy od tego z kim pracujesz. Jeżeli z ludźmi nawykłymi do defekowania kodu i przekazywania tego testerom, bo może poprawka trafi na kogoś innego, to będzie ciężko. Może być jeszcze ciężej, jak już te testy zaczną pisać :D
yarel napisał(a):
@Juhas: jaki konkretnie (istniejący) problem rozwiążesz przekonując współpracowników do swoich racji?
Chociażby wstęp do unit testów. Ale nie wiem jak gadać, żeby ich przekonać do zmiany czegokolwiek. No bo przecież "działa", to po co ruszać?
Czyli Waszym konkretnym problemem jest brak wstępu do unit testów? Drążąc temat, posiadanie wstępu do unit testów jaki problem rozwiązuje? ;-)
Powinieneś dotrzeć do tego jaki faktycznie macie problem i pokazać jak loose coupling go rozwiązuje/upraszcza rozwiązanie.
Odbiorcą takiej argumentacji nie muszą być koledzy z zespołu odpowiedzialni za tworzenie kodu, tylko ten kto nimi zarządza/wykłada kasę i ma możliwość zdefiniowania wymagań jakościowych na kod i ich wyegzekwowanie. W ten sposób nie musisz przekonywać wszystkich, a tylko osobę decyzyjną.
Alternatywnie... ludzie uczą się na przykładach, więc możesz sam pisać "dobry kod" i jak ktoś będzie gadał o jakimś problemie, to możesz napomknąć, że miałeś podobny i rozwiązałeś go bardzo szybko, bo miałeś unit testy i loose coupling, ewentualnie ktoś podejrzy Twój kod i zrobi copy&paste ;)
piotrpo napisał(a):
@Juhas: To przekonuj ich do pisania UT, do "loose coupling" przekonają się sami.
Raczej stwierdzą, że nie da się pisać UT i nie będą tego robić.
yarel napisał(a):
Odbiorcą takiej argumentacji nie muszą być koledzy z zespołu odpowiedzialni za tworzenie kodu, tylko ten kto nimi zarządza/wykłada kasę i ma możliwość zdefiniowania wymagań jakościowych na kod i ich wyegzekwowanie. W ten sposób nie musisz przekonywać wszystkich, a tylko osobę decyzyjną.
Jak do tej pory nie piszą UT, to "osoba decyzyjna" nie dostrzega korzyści, więc jak jeden nowy oszołom jej powie, że trzeba pisać testy, a 5 innych powie, że nie trzeba to zgadnij jaka będzie decyzja? Ktoś to spaghetti napisał, zakładam, że nie OP, więc dodatkowo tamci siedzą dłużej w projekcie "i wszystko działa".
Alternatywnie... ludzie uczą się na przykładach, więc możesz sam pisać "dobry kod" i jak ktoś będzie gadał o jakimś problemie, to możesz napomknąć, że miałeś podobny i rozwiązałeś go bardzo szybko, bo miałeś
unit testyiloose coupling, ewentualnie ktoś podejrzy Twój kod i zrobi copy&paste ;)
Podziwiam twoją pozytywistyczną wiarę w człowieka i zdolność do zmiany. Programiści są leniwi, niestety najczęściej w głupi sposób i zamiast coś zrobić, żeby później mieć mniej pracy, to wolą tego nie robić, bo później jakoś to będzie. Dlatego nie pomyślą 10 minut nad zaplanowaniem pracy i później tracą kilka godzin bo nie pomyśleli. To samo dotyczy pisania testów, zapoznania się z dokumentacją, czy przeczytania ze zrozumieniem historyjki.
somekind napisał(a):
Raczej stwierdzą, że nie da się pisać UT i nie będą tego robić.
Też zakładam taki rozwój sytuacji. Tu trzeba nabyć trochę wprawy, nauczyć się pisać testowalny kod, poczekać trochę na korzyści i je dostrzec. Niby oczywiste, że przyzwoite testy są wygodniejsze niż debugger i prinf("dupa"), ale praktyka pokazuje, że nie dla każdego.
Loose coupling daje pewną elastyczność, ale jednoczesnie wnosi dodatkową złożoność - czy się przyda to zależy w sumie od potrzeb.
MOŻLIWOŚCI:
Z mojej perspektywy oznacza to, że jest większa szansa na to, że będę tworzył rozszerzenia (pisał nowy kod bez edycji istniejącego). Natomiast, gdy kod za bardzo nie idzie roszerzać no.. cóż, wtedy pozostaje modyfikowanie, a modyfikacja to nie tylko wstawianie nowych lini, ale również edycja i wpływanie na to co wcześniej działało.
Zatem na pierwszy rzut oka loose coupling:
Oczywiście rozszerzenia mogą mieć także strategiczny wydźwięk, mogę dzięki nim jeden komponent zastąpić drugim. Np. teraz robię naiwną implementację, a za jakiś czas wracam i podpinam inny komponent, który wykonuje swoją pracę lepiej. Albo kupuje gotowy komponent, a z czasem gdy warunki nie będą korzystne to przechodzę do konkurencji lub robię własny. Nie mniej to otwiera bardziej furtkę i możliwości dla kadry zarządzającej niż samych programistów.
Programiści będą bardziej cenić fakt, że w ogóle pewne rzeczy będą mogli przetestować. To logika rozumowanie jest następująca spokój jest lepszy niż frustracja, a testy są lepsze niż debuggowanie.
OGRANICZENIA:
Wspomniałem wcześniej o dodatkowej złożoności. Gdzie ona się więc ukrywa?
Pomyśl, że znajomy chce poczęstować Cię ciastem swojej żony, ale zanim to zrobi wyciąga koło, kręci nim i rzuca ciasto w szprychy twierdząc, że tak małe porcje to łatwiej idzie przełknąć.
Myślę, że mniej więcej tak to widzą to inni programiści, którzy nie są przekonani do loose coupling. Oni jak czytają kod nie potrafią interpretewać tego zapisu, bo nie widać już scenariusza procedury jaką wcześniej realizował program. Tak posiekany kod ma dla nich wątpliwą wartość, ponieważ na czytanie i modyfikację muszą poświęcić więcej czasu, by skleić w głowie obraz jaki wynika ze skoków po 5 czy 10 plikach.
Ponadto w projektach IT jedyne co jest pewne to zmiana. Jeśli biznes robi stosunkowo świeży produkt i jesli postawnowi ostrzej skręcić to jak to później rzutuje na interfejsy? No cóż.. wtedy to jest kruche, rozszerzania zmienia się w modyfikację i pracy jest wiecej niż mniej.
Argument dotyczący testów jest wątpliwy, ponieważ testy bez loose coupling też da się pisać. Po prostu mamy wolne/ciężkie testy, ale z tego co widze to mało programistów woli małe testy na mockach. Ludzie wolą pisać integracyjne testy, by sprawdzić czy to działa na bazie z prawdziwego zdarzenia.
Natomiast jak ktoś lepi cruda w oparciu o gotowe ramy to przeważnie nie musi się tym zbytnio przejmować, bo ramy na ogół dostarczają różne implementacje do typowych zadań od IO, a te da się w zasadzie przepinać poprzez zmianę konfiguracji.
Na minus z mojej strony to jakieś skrajne rozwiązania do jakich prowadzi loose coupling to typu kontener zależności. Taki twór to dodatkowa wiązka magii, psucie stacktrace i możliwość napotkania nietypowych błedów.
Loose coupling zwraca się częściej, gdy projekt zależy od innych serwisów (zwłaszcza tych zewnetrznych), ale wtedy nie musisz nikogo przekonywać, ponieważ człowiek sam dojdzie do wniosku, że przydałaby się jakaś udawana implementacja i sposób na jej podmianę.
LUŹNE PRZEMYŚLENIA:
Tak pół żartem, pół serio to gdybym używał loose coupling w każdym projekcie to wiem, że można tak łatwo utrudnić pracę innym programistom. Dużo osób nie radzi sobie z tym, bo nie widzą pełnego projektu, zadania będą robić wolniej, a przetrwają tylko Ci, którym takie podejście po prostu pasuje (mniejszość). Natomiast mi to daje renomowaną podstawę, by zachęcić ("zmusić") kogoś do pisania kodu bardzo małymi porcjami, bo wtedy lżejszy jest code review i większa szansa, że ktoś odważy się napisać test obejmujący przypadki brzegowe.
piotrpo napisał(a):
Tu trzeba nabyć trochę wprawy, nauczyć się pisać testowalny kod, poczekać trochę na korzyści i je dostrzec. Niby oczywiste, że przyzwoite testy są wygodniejsze niż debugger i prinf("dupa"), ale praktyka pokazuje, że nie dla każdego.
No właśnie. Myślę, że jeśli komuś debuger i dupowanie na ekranie nie utrudnia życia, i sam nie wpadł na to, aby spróbować inaczej, a do tego ma wiele lat doświadczenia, to nic z takiego kogoś już nie będzie.
Wbrew wizji forsowanej przez scrum-coachy tego forum, nie każdego da się przekonać.
Skoro wszystko działa, to nie masz żadnych argumentów. Po zmianie podejścia też będzie wszystko działać, ale przedtem wielu ludzi będzie musiało się wysilić. A po drodze jeszcze może coś przestać działać.
Więc zadajmy sobie pytanie, czy naprawdę chcesz rozwiązać jakieś konkretne problemy, czy to tylko tak dla zasady.
@fgh: Dla mnie pojęcie loose coupling jest wpisane w programowanie obiektowe i bezpośrednio wynika z single responsibility principle, IoC (jako idei, nie kontenerów do wstrzykiwania zależności), open-close principle.
Jeżeli ktoś woli pracować z klasami, które nie wiadomo co robią, składającymi się z metod również robiących wszystko, sterowane zmiennymi dostępnymi z dowolnego miejsca, bez wydzielonego publicznego API klasy, bo kod w "kawałkach" jest dla niego nieczytelny to ścieżki myślenie takiej osoby są dla mnie zagadką. Jak ten kod został napisany, że trzeba do niego zaglądać? Zaglądałeś kiedyś do kodu jakiejś dobrze napisanej biblioteki, czy jednak wystarczy, że wiesz co ta biblioteka robi i jak ją wywołać i co dostajesz na wyjściu? Problem w tym, że żeby zastosować takie podejście, trzeba przez chwilę pomyśleć - zastanowić się co ma robić jakiś moduł, zdefiniować jego zewnętrzny interface, podzielić odpowiedzialności na klasy, dopisać testy i zająć się właściwą implementacją. I rzadko kiedy takie podejście wymaga więcej pracy. Zwyczajnie wymaga pomyślenia przez chwilę na początku i wpojenia sobie odpowiednich nawyków. Każdą funkcjonalność da się zakodować w postaci jednej metody, tylko jak ktoś tak woli, to ja wolę z nim nie pracować.
Swoja droga to na to moze juz byc po prostu za pozno. Teraz to pewnie wiekszosc projektu by trzeba bylo zaorac.
piotrpo napisał(a):
yarel napisał(a):
Odbiorcą takiej argumentacji nie muszą być koledzy z zespołu odpowiedzialni za tworzenie kodu, tylko ten kto nimi zarządza/wykłada kasę i ma możliwość zdefiniowania wymagań jakościowych na kod i ich wyegzekwowanie. W ten sposób nie musisz przekonywać wszystkich, a tylko osobę decyzyjną.
Jak do tej pory nie piszą UT, to "osoba decyzyjna" nie dostrzega korzyści, więc jak jeden nowy oszołom jej powie, że trzeba pisać testy, a 5 innych powie, że nie trzeba to zgadnij jaka będzie decyzja? Ktoś to spaghetti napisał, zakładam, że nie OP, więc dodatkowo tamci siedzą dłużej w projekcie "i wszystko działa".
Jak powie, że "piszmy testy", to słaba argumentacja (różnie dobrze może powiedzieć "przepiszmy wszystko od zera") :-). Bo jaki problem to rozwiązuje (gdzie zysk?) i czyj to problem?
Jeśli nie jest to problem programistów, to są słabą grupą docelową do ewangelizacji. Kierownik też może mieć to głęboko w poważaniu, ale klient już niekoniecznie. Więc chcąc zmienić kierunek, trzeba iść do właściwego "udziałowca"/"orędownika zmiany" z odpowiednią siłą przebicia. Nie ma tu znaczenia, czy to będzie UT, coupling, technologia etc.
Przykład z życia: w zespole developerskim chcieliśmy, żeby zespół ziomków od konfiguracji dodał "2 kolumny do excela". Nie dało się, bo ten drugi zespół nie widział korzyści dla siebie, a jedynie dodatkową pracę (bo musieliby te kolumny wypełniać). Wyjaśniliśmy zespołowi testowemu, że gdyby mieli dodatkowe "2 kolumny w excelu", to byłoby im łatwiej wnioskować o poprawne dane testowe od klienta -> poprawne dane wejściowe -> mniej fałszywych błędów zgłaszanych do dev/konfiguracji (a to już to była korzyść dla zespołu konfiguracyjnego, który dostawał mniej błędów i był mniej zaangażowany w diagnostykę problemów).
Podziwiam twoją pozytywistyczną wiarę w człowieka i zdolność do zmiany. Programiści są leniwi, niestety najczęściej w głupi sposób i zamiast coś zrobić, żeby później mieć mniej pracy, to wolą tego nie robić, bo później jakoś to będzie. Dlatego nie pomyślą 10 minut nad zaplanowaniem pracy i później tracą kilka godzin bo nie pomyśleli. To samo dotyczy pisania testów, zapoznania się z dokumentacją, czy przeczytania ze zrozumieniem historyjki.
Co do lenistwa masz rację. Dodałbym, że nie dotyczy jedynie programistów i że oprócz lenistwa, inną siłą napędową jest chęć zysku. Dla programistów zakładam copy&paste dobrego kodu wyzwalane prze lenistwo ;-) Skoro nie widzą zysku w UT, to pewnie są zbyt leniwi na edukację.
Jeżeli ta osoba decyzyjna jest z biznesu, to pisanie dobrego kodu i pokrycie go testami jednostkowymi nie ma dla niej żadnego znaczenia. Tym bardziej nie ma to znaczenia dla klienta. Obie te osoby interesuje funkcjonalność, koszt i czas realizacji.
Unit testy są dla programistów, bo to najczęściej najszybsza droga do udowodnienia działania napisanego kodu, powstrzymuje dużą część głupot przed dostaniem się do mainline, pozwala szybko sprawdzić, czy dokonana zmiana nie powoduje jakiegoś nie przewidzianego działania i stanowi przykład użycia jakiejś części, którą się napisało, więc później im się głowy nie zawraca pytaniami.
Praktycznie każdy kto wchodził w UT podchodził do nich jak do niepotrzebnego ustrojstwa, które jest jakimś tam dziwacznym wymysłem programistycznych ewangelistów, który generuje sporo pracy, a efekty wydają się być dyskusyjne. Dopiero z czasem, zaczyna się widzieć korzyści typu czytelność kodu, mniej problemów, nikt ci nie rozwali roboty, bo "nie pomyślał, że to ma wpływ" itd. Tylko jak masz mentalnych dziadków (mogą mieć i 20 lat), którzy weszli w programowanie ileś lat temu, nauczyli się tej Javy 1.2 i uważają, ze to powinno im starczyć aż do przejścia na emeryturę, to będą się trzymać swoich pozycji jak kot kosza podczas wizyty u weterynarza.
piotrpo napisał(a):
Jeżeli ta osoba decyzyjna jest z biznesu, to pisanie dobrego kodu i pokrycie go testami jednostkowymi nie ma dla niej żadnego znaczenia. Tym bardziej nie ma to znaczenia dla klienta. Obie te osoby interesuje funkcjonalność, koszt i czas realizacji.
Niby tak, ale nie zawsze :) Miałem raz sytuację że w małej polskiej firmie produktowej zacząto pisać testy jednostkowe bo klient zarządał raportów z pokrycia testami. Oczywiście widziałem to tylko raz i była to sytuacja specyficzna bo klient też był techniczny i nasz produkt opakowywał w swój produkt i sprzedawał dalej. Ale czasem się zdarza :D
UPDATE czy mam w związku z tym jakiś wniosek? Tak, jak chce się coś zmienić to trzeba atakować tym pomysłem wszystkich :D Oczywiście jest to męczące, ale rośnie szansa że pomysł chwyci :)
piotrpo napisał(a):
Tylko jak masz mentalnych dziadków (mogą mieć i 20 lat), którzy weszli w programowanie ileś lat temu, nauczyli się tej Javy 1.2 i uważają, ze to powinno im starczyć aż do przejścia na emeryturę, to będą się trzymać swoich pozycji jak kot kosza podczas wizyty u weterynarza.
Tak bywa niestety, niektórzy to będą sobie starali zapewnić "dożywocie" na ciepłej posadzie specjalnie komplikując kod, infrastrukturę czy cokolwiek co ma wpływ na rozwój/wdrażanie.
Tym bardziej nie ma to znaczenia dla klienta. Obie te osoby interesuje funkcjonalność, koszt i czas realizacji.
A potem takie kwiatki:
https://tvn24.pl/biznes/z-kraju/awaria-w-credit-agricole-podwojnie-zaksiegowane-transakcje-karta-dwa-razy-taka-sama-kwota-sciagnieta-z-konta-5398292
A kto traci na tym hajs? No klient a nie programista.
Testy dla klienta mogą nie mieć znaczenia, ale dlaczego klient miałby tu o czymś decydować?
On zleca wykonanie czegoś, firma rzuca stawką i tyle z jego decyzyjności dotyczących sposobu wykonania - zakładając oczywiście że piszemy system sami a nie dołączamy jako dodatkowy zespół do zespołu klienta.
Pracowałem dla firmy gdzie jeden z zespołów przepisywał stary moduł. Z założenia miało być lepiej ale zaczęło się od tego, że projekt bazy zrobiła osoba po zootechnice, która bazę chyba widziała po raz pierwszy w życiu. No ale według "managementu" ona "najlepiej znała domenę" i ciężko było to programistom odkręcić. Nie wiem jak się to skończyło ale było to niewesołe.
@stivens: Skoro to jest tak ważne dla klienta, to dlaczego w materiałach marketingowych oprogramowania, które kupuję nie ma na pierwszym miejscu 97% unit test coverage? Bo to nikogo nie interesuje, chociażby z tego powodu, że związek pomiędzy UT a jakością produktu (w sensie robienia tego do czego się to pisze) jest bardzo luźny. Jeżeli już, to wynika z bardziej dojrzałego podejścia do robienia oprogramowania niż z tego, ze testy jednostkowe coś dają. Oczywiście ma to wpływ na tworzenie nowych ficzerów, czas potrzebny do wydania oprogramowania, ale jeżeli masz dobrze zorganizowane testy (nie ważne, czy ręczne, czy automatyczne), to jesteś w stanie dostarczyć działający program klientowi.
Odnosząc się do problemu z księgowaniem, to w systemach bankowych zwykle najbardziej porąbana jest integracja różnych produktów - coś tam do kart, coś tam do bankowości internetowej, na ślinę przylepione do systemu transakcyjnego. Nie sądzę, żeby w takim przypadku testy na poziomie kilku klas mogły cos pomóc.
A ja zadam przewrotne pytanie. Jak testujecie to co produkujecie? Przeczytałem pół tematu i nikt nie pomyślał nawet że apke można testować inaczej niż unit testami...
YourFrog2 napisał(a):
A ja zadam przewrotne pytanie. Jak testujecie to co produkujecie? Przeczytałem pół tematu i nikt nie pomyślał nawet że apke można testować inaczej niż unit testami...
Przewrotność nie polega na braku związku z tematem. Nikt nie pomyślał o testowaniu apek, bo temat nie dotyczy testowania apek, apek też nie testuje się unit testami.
To jest wręcz straszne, że takie rzeczy trzeba tłumaczyć.
Juhas napisał(a):
No właśnie. Próbuję już na różne sposoby, ale spotykam się ze ścianą (przecież działa). Jak byście przemówili do współpracowników, żeby przekonać ich do tego, że loose coupling jest zdecydowanie lepszym podejściem*?
*pomijam rzeczy typu wbudowane systemy operacyjne i inne, gdzie tight coupling może być sensowny.
Nawet w ASM lepiej użyć JSR niż JMP., stosuje się wektory skoków, przerwania i relokacje.
Posługiwanie się książkowymi terminami, jeszcze do tego po angielsku, jest fajne jak ktoś Cię słucha, ale jak masz komuś kto tego nie zna udowodnić swoje racje to lepiej posługuj się terminami praktycznymi, sposobami realizacji i widocznymi gołym okiem benefitami.
Poza tym jest to termin subiektywny. W odróżnieniu od np. DRY czy YAGNI "tight coupling" określasz zwykle na review naocznie. Lepiej zgłaszać uwagi obiektywne (np. "tu będziesz miał NPE" a tam "nic nie znajdziesz gdy X"). No chyba że macie takie wyczesane CICD że wam to automatem wylicza, wtedy możesz do problemu podejść ilościowo: "jakość była X, po zmianie jest Y".
Nie warto komukolwiek coś tłumaczyc w tej branży, lepiej prace zmienic