„Zbyt obiektowo”

21

Pochodzę z silnego zaplecza OO, a ostatnio zacząłem pracować w organizacji, która choć kod jest napisany w Javie, ma o wiele mniejszy nacisk na dobry projekt OO niż to, do czego jestem przyzwyczajony. Powiedziano mi, że wprowadzam „zbyt dużo abstrakcji” i że zamiast tego powinienem kodować tak, jak zawsze to robiono, co jest stylem proceduralnym w Javie.

TDD również nie jest tu zbytnio praktykowane, ale chcę mieć kod do przetestowania. Zakopywanie logiki biznesowej statycznymi metodami prywatnymi w dużych „klasach boga” (co wydaje się być normą dla tego zespołu) nie jest zbyt testowalne.

Mam trudności z wyraźnym przekazaniem motywacji moim współpracownikom. Czy ktoś ma jakieś rady, jak przekonać moich współpracowników, że korzystanie z OO i TDD prowadzi do łatwiejszego do utrzymania kodu?

To pytanie dotyczące długu technicznego jest powiązane z moim pytaniem. Staram się jednak przede wszystkim unikać zaciągania długu, a nie spłacania go po tym, co obejmuje drugie pytanie.

ThuneGrill
źródło
17
Jaka jest twoja rola? Deweloper Grunt? Jesteś pieprzony - znajdź lepszą pracę. Główny programista? Może uda ci się coś zmienić ...
Matthew Flynn
2
Nie tyle dług technologiczny, co radzenie sobie ze złym designem i ludźmi, którzy się nie zmienią
oz.
1
Zdaję sobie sprawę z argumentów technicznych i biznesowych, pytam, jak najlepiej przekazać tę wiedzę moim współpracownikom, którzy wydają się nieświadomi tego. Widzą wiele klas, widzę testowalny, rozszerzalny system
ThuneGrill
5
Przepraszam, musisz wyjść. Mówisz ponad głowami swoich kolegów. Nie zmieni się, dopóki projekt nie będzie niemożliwy do utrzymania. Jeśli nie lubisz ręcznych testów i marszów śmierci, lepiej idź gdzie indziej.
kevin cline
4
Nie widząc kodu, o którym mowa (tak, trudno jest podać wystarczająco dobrą próbkę, więc musimy tylko zaufać osądowi), trudno jest stwierdzić, czy rzeczywiście brakuje OO, czy też przepychasz nadmiernie zaprojektowany kult ładunków Odejścia OO bez uzasadnionego powodu. Myślę, że wszyscy widzieli przykłady nadmiernie zaprojektowanego OOP, w którym abstrakcje spoczywają na warstwie abstrakcyjnych fabryk produkujących abstrakcyjne fabryki itp.
Kromster mówi o wsparciu Monice

Odpowiedzi:

32

Nie narzekałeś na to, że jest nie do utrzymania, po prostu nie tak jak lubisz. Jeśli jest to celowy wybór stylu, może to być tylko przypadek niemożliwych do pogodzenia różnic twórczych i powinieneś dopasować swój styl, aby pasował, lub znaleźć miejsce, które pasuje do Twojego preferowanego stylu.

Ludzie mogą i ciągle piszą modułowy, wydajny, dobrze abstrakcyjny i stosunkowo wolny od błędów kod w stylu proceduralnym. Java jest dziwnym wyborem języka dla takiego sklepu, ale widzę, że dzieje się tak, jeśli decydują o tym czynniki zewnętrzne, jak na przykład konieczność programowania na Androida.

Każdy jest geniuszem. Ale jeśli osądzisz rybę po zdolności wspinania się na drzewo, przeżyje całe swoje życie, wierząc, że jest głupie. - Albert Einstein

Jeśli był to celowy wybór, nie można tak naprawdę ocenić ich na podstawie tego, jak dobrze stosują się do dobrych, zorientowanych obiektowo zasad projektowania, należy ocenić, na ile są one zgodne z dobrymi procedurami projektowymi, a także odpowiednio je zmienić. Java nie pozwala na pisanie kodu poza klasą, więc sama obecność jednego z nich nie oznacza, że ​​zamierzali moduł być zorientowany obiektowo.

Z drugiej strony, jeśli kod jest bałaganem w jednym z paradygmatów, prawdopodobnie powinieneś po prostu ograniczyć straty.

Karl Bielefeldt
źródło
3
jest proceduralna i niechlujna. Ale mówię o nowym kodzie, który piszę, nazywanym „zbyt zorientowanym obiektowo”
ThuneGrill
5
niechlujny kod proceduralny rozszerzony o kod OO może wcale nie być poprawą, tylko wprowadzając zamieszanie.
wirrbel
7
@ThuneGrill, zakładasz, że wybrali styl kodowania z powodu nieznajomości projektowania obiektowego, że gdybyś mógł je po prostu wyedukować, zobaczyłby światło. Jeśli ktoś z dochodowym biznesem programistycznym w języku silnie zorientowanym obiektowo nie analizował do tej pory zalet OOD, nie ma mowy, żeby „nowy facet” go przekonał. Uwierz mi na słowo i na komentarze innych komentatorów. Jeśli nie możesz lub nie chcesz dostosować swojego stylu, aby ułatwić zespołowi czytanie, powinieneś zmniejszyć swoje straty.
Karl Bielefeldt,
3
@ThuneGrill: Karl ma rację. Trzymaj się pragmatycznych powodów, a nie religijnych. OOP to z pewnością dobry pomysł, ale widziałem, że doprowadzono go do absurdalnych ekstremów. Rezultatem jest tworzenie gór z kretowisk. Rzeczy, które można wykonać za pomocą 1000 linii kodu, kończą się na 10 000 linii kodu z mnóstwem klas. Więc, Gee, trudno jest utrzymać, a wydajność jest do kitu. (Bez względu na to, jakie klasy kolekcji zostaną wykorzystane.)
Mike Dunlavey,
1
Nie musiałbym rezygnować z pomysłu, że można przekonać ludzi do tego. To trudne, ale da się to zrobić - już to zrobiłem. Ponieważ to pytanie wydaje się zamknięte, patrz workplace.stackexchange.com/questions/9703/…
Amy Blankenship
7

Czytając twoje pytanie, przypomniałem sobie jedną końcówkę książki Pragmatic Programmer.

Jedną z jego wskazówek jest Be a Catalyst for Change:

Możesz znajdować się w sytuacji, w której dokładnie wiesz, co należy zrobić i jak to zrobić. Cały system pojawia się na twoich oczach - wiesz, że ma rację. Ale poproś o pozwolenie na zajęcie się całą sprawą, a spotkasz się z opóźnieniami i pustymi spojrzeniami. Ludzie będą tworzyć komitety, budżety będą wymagały zatwierdzenia, a sprawy się skomplikują. Wszyscy będą strzec własnych zasobów. Czasami nazywa się to „zmęczeniem na starcie”.

Czas ugotować Kamienną Zupę. Ustal, o co możesz racjonalnie poprosić. Rozwijaj to dobrze. Gdy już go zdobędziesz, pokaż ludziom i pozwól im się dziwić. Następnie powiedz „oczywiście, byłoby lepiej, gdybyśmy dodali…”. Udawaj, że to nie jest ważne. Usiądź wygodnie i zaczekaj, aż zaczną prosić o dodanie funkcji, której pierwotnie chciałeś. Ludziom łatwiej jest przyłączyć się do ciągłego sukcesu. Pokaż im spojrzenie na przyszłość, a zmusisz ich do zjazdu.

Myślę więc, że jeśli zaczniesz dobrze wykonywać swoją pracę z wiedzą OO i TDD, wkrótce zaczną szukać i pytać o twoją pracę.

Rodrigo
źródło
Próbuje być, ale architekt Uber (który nie koduje) nie będzie go miał.
ThuneGrill
Gdy tylko zauważy zalety TDD i lepszego OO (niezawodność, wydajność, ...), zwrócisz uwagę!
Rodrigo
3

Aby sprzedawać nowe sposoby pracy, musisz wykazać oczywiste korzyści. Pisanie kolejnych warstw abstrakcji, bez wyraźnej korzyści, ale niejasne: „może być korzystne dla przyszłości”, nie zadziała.

Twórz fabryki, w których fabryki wytwarzają więcej niż jeden typ obiektu. Użyj iniekcji zależności, gdzie natychmiast pokazuje korzyści. Twórz interfejsy, które faktycznie będą implementowane przez więcej niż jedną klasę.

Zbyt często widzę w „prawdziwym OO” to, że zaawansowane techniki są używane do rozwiązywania naprawdę prostych problemów w zbyt skomplikowany sposób.

Jak możesz wykazać korzyści płynące z fabryki, jeśli będzie ona produkować tylko ten sam obiekt? Znajdź problem w kodzie, który korzysta z zaawansowanych technik i pokazuje swój punkt widzenia i pracę z tego miejsca.

Wojny wygrywa się po jednej bitwie na raz.

Pieter B.
źródło
1

Możesz je tylko przekonać, biorąc niewielki fragment kodu i wdrażając TDD oraz lepsze praktyki OO, aby uzyskać korzyści. Doprowadziłeś ich do ziemi obiecanej, nie tylko pokazując jej ładne kartki pocztowe.

Z pewnością uważam, że w wielu bazach kodu istnieją przypadki nadmiernej abstrakcji. Włóż tylko to, czego potrzebujesz, a także abstrakcje.

Jon Raynor
źródło
1
Właśnie tak zrobiłem, to właśnie spowodowało całą dyskusję. Wprowadziłem tylko 3-4 abstrakty
oprócz