„Zbyt obiektowo”

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.

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.

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ę.

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.

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.