Jak udowodnić lub obalić, że „Boskie przedmioty” są błędne?

Podsumowanie problemu:

Krótko mówiąc, odziedziczyłem bazę kodu i zespół programistów, których nie wolno mi zastępować, a korzystanie z God Objects to duży problem. Idąc dalej, chcę, abyśmy ponownie zmienili czynniki, ale dostaję odepchnięcie od zespołów, które chcą robić wszystko z Boskimi Przedmiotami „ponieważ jest to łatwiejsze”, a to oznacza, że ​​nie pozwolę sobie na ponowne uwzględnianie czynników. Odsunąłem się z powrotem, powołując się na moje wieloletnie doświadczenie programistyczne, że jestem nowym szefem, który został zatrudniony do poznania tych rzeczy itp., Podobnie jak przedstawiciel handlowy firm zagranicznych na zagranicznych kontach, a teraz jest to na poziomie wykonawczym i mojego spotkania jest jutro i chcę skorzystać z dużej ilości amunicji technicznej, aby propagować najlepsze praktyki, ponieważ uważam, że w dłuższej perspektywie będzie to tańsze (i osobiście uważam, że to właśnie martwi trzecia strona) dla firmy.

Mój problem dotyczy poziomu technicznego, wiem, że jest dobry w perspektywie długoterminowej, ale mam kłopoty z ultra krótkoterminowym i 6-miesięcznym okresem, a chociaż jest to coś, co „wiem”, nie mogę tego udowodnić za pomocą referencji i cytowanych zasobów poza jednej osoby (Robert C. Martin, alias Wujek Bob), ponieważ właśnie o to mnie proszono, ponieważ powiedziano mi, że posiadanie danych od jednej osoby i tylko jedna osoba (Robert C Martin) nie jest wystarczająco dobrym argumentem .

Pytanie:

Jakie zasoby mogę przytoczyć bezpośrednio (tytuł, rok wydania, numer strony, cytat) przez znanych ekspertów w tej dziedzinie, którzy jednoznacznie twierdzą, że użycie obiektów / klas / systemów „Boga” jest złe (lub dobre, ponieważ szukamy dla najbardziej poprawnego technicznie rozwiązania)?

Badania, które już przeprowadziłem:

1. Mam tutaj kilka książek i przeszukałem ich indeksy pod kątem użycia słów „boski przedmiot” i „boska klasa”. Stwierdziłem, że co dziwne, prawie nigdy nie był używany, a kopia książki GoF, którą mam na przykład, nigdy jej nie używa (przynajmniej według indeksu przede mną), ale znalazłem ją w dwóch poniższych książkach, ale chcę więcej Mogę użyć.
2. Sprawdziłem stronę Wikipedii pod kątem „God Object” i jest to obecnie skrót z niewielkimi odnośnikami, więc chociaż osobiście się z tym zgadzam, to nie ma wiele, z czego mogę korzystać w środowisku, w którym osobiste doświadczenie nie jest uważane za ważne. Cytowana książka jest również uważana za zbyt starą, aby była ważna dla osób, z którymi debatuję nad tymi kwestiami technicznymi, ponieważ argumentują, że „kiedyś uważano ją za złą, ale nikt nie mógł tego udowodnić, a teraz nowoczesne oprogramowanie mówi„ bóg „obiekty są dobre w użyciu”. Osobiście uważam, że to stwierdzenie jest nieprawidłowe, ale chcę udowodnić prawdę, cokolwiek to jest.
3. W „Agile Principles, Patterns and Practices in C #” Roberta C. Martina (ISBN: 0-13-185725-8, twarda okładka), gdzie na stronie 266 jest napisane: „Wszyscy wiedzą, że klasy boskie są złym pomysłem. Nie chcemy aby skoncentrować całą inteligencję systemu w jednym obiekcie lub jednej funkcji. Jednym z celów OOD jest podział i podział zachowań na wiele klas i wiele funkcji. ” - A potem mówi dalej, że czasem lepiej jest używać Boskich klas (podając jako przykład mikrokontrolery).
4. W „Czystym kodzie: Podręcznik zwinnego wytwarzania oprogramowania” Roberta C. Martina strona 136 (i tylko ta strona) mówi o „klasie Boga” i przywołuje ją jako doskonały przykład naruszenia zasady „klasy powinny być małe” stosuje w celu promowania zasady jednolitej odpowiedzialności ”od strony 138.

Problem, który mam, polega na tym, że wszystkie moje odniesienia i cytaty pochodzą od tej samej osoby (Robert C. Martin) i pochodzę od tej samej osoby / źródła. Powiedziano mi, że ponieważ jest tylko jednym poglądem, moje pragnienie, aby nie używać „Boskich klas” jest nieważne i nie jest akceptowane jako standardowa najlepsza praktyka w branży oprogramowania. Czy to prawda? Czy robię coś złego z technicznego punktu widzenia, starając się utrzymać naukę wuja Boba?

Boże obiekty i programowanie i projektowanie obiektowe:

Im więcej o tym myślę, tym bardziej myślę, że jest to coś więcej, czego uczysz się podczas studiowania OOP i nigdy nie jest to wyraźnie wzywane; To, co wynika z dobrego projektu, jest moim myśleniem (proszę, popraw mnie, proszę, jak chcę się uczyć), problem polega na tym, że „wiem” to, ale nie wszyscy, więc w tym przypadku nie jest to uważany za ważny argument, ponieważ Skutecznie nazywam to uniwersalną prawdą, kiedy w rzeczywistości większość ludzi jest statystycznie nieświadoma tego, ponieważ statystycznie większość ludzi nie jest programistami.

Wniosek:

Nie wiem, czego szukać, aby uzyskać najlepsze dodatkowe wyniki do cytowania, ponieważ robią one techniczne roszczenia i chcę poznać prawdę i móc to udowodnić cytatami jak prawdziwy inżynier / naukowiec, nawet jeśli Jestem stronniczy w stosunku do obiektów boskich z powodu mojego osobistego doświadczenia z kodem, który ich używał. Każda pomoc lub cytaty byłyby bardzo mile widziane.

W przypadku każdej zmiany praktyki uzasadnia się identyfikację punktów bólowych stworzonych przez istniejący projekt. W szczególności musisz określić, co jest trudniejsze niż powinno być z powodu istniejącego projektu, co jest kruche, co się teraz psuje, jakich zachowań nie można wdrożyć w prosty sposób jako bezpośredni (lub nawet nieco pośredni) wynik bieżące wdrożenie lub, w niektórych przypadkach, wpływ na wydajność, ile czasu zajmuje przyspieszenie nowego członka zespołu itp.

Po drugie, działający kod przebija wszelkie argumenty dotyczące teorii lub dobrego projektu. Dotyczy to niestety nawet złego kodu. Musisz więc zaoferować lepszą alternatywę, co oznacza, że ​​jako zwolennik lepszych wzorców i praktyk będziesz musiał zreformować, aby wypróbować lepszy projekt. Znajdź wąską płaszczyznę typu tracer-bullet w istniejącym projekcie i zaimplementuj rozwiązanie, które być może w przypadku iteracji utrzymuje implementację obiektu boga w działaniu, ale odkłada faktyczną implementację na nowy projekt. Następnie napisz kod, który wykorzystuje ten nowy projekt i pochwal się tym, co wygrałeś dzięki tej zmianie, czy to wydajność, łatwość konserwacji, funkcje, korekta błędów lub warunki wyścigu, czy zmniejszenie obciążenia poznawczego dla programisty.

Często trudno jest znaleźć wystarczająco małą powierzchnię do ataku w źle zaprojektowanych systemach, może to potrwać dłużej niż chcesz zapewnić początkową wartość, a początkowa wypłata może nie być imponująca dla wszystkich, ale możesz także pracować po znalezieniu zwolenników twojego nowego podejścia, jeśli połączysz go z członkami zespołu, którzy są przynajmniej trochę sympatyczni.

Lamentowanie nad Bogiem Obiekt działa tylko wtedy, gdy głosisz chór. Jest to narzędzie do nazywania problemu i działa tylko w celu jego rozwiązania, gdy masz otwartą publiczność, wystarczająco starszą i wystarczająco zmotywowaną, aby coś z tym zrobić. Naprawienie obiektu Boga wygrywa argument.

Ponieważ twoim bezpośrednim zmartwieniem wydaje się być wykupienie przez kierownictwo, myślę, że najlepiej jest uzasadnić, że zastąpienie tego kodu musi być celem strategicznym i powiązać je z celami biznesowymi, za które jesteś odpowiedzialny. Myślę, że możesz uzasadnić, że możesz wskazać jakiś kierunek techniczny, najpierw pracując nad skokiem technicznym tego, co Twoim zdaniem należy zrobić, aby go zastąpić, najlepiej angażując zasoby od jednej lub dwóch osób technicznych, które mają zastrzeżenia do obecnego projektu.

Myślę, że znalazłeś wystarczające zasoby, aby uzasadnić swój argument; osoby biorące udział w takich spotkaniach będą zwracać uwagę tylko na podsumowanie twoich badań i przestaną słuchać, gdy podasz dwa lub trzy potwierdzające źródła. Początkowo należy skupić się na wykupie w celu rozwiązania problemu, który widzisz, niekoniecznie udowadniając, że ktoś jest w błędzie lub masz rację. To problem społeczny, a nie logiczny.

W roli lidera technologii musisz powiązać dowolną inicjatywę z celami biznesowymi, więc najważniejszą rzeczą w przedstawianiu swojego stanowiska kierownictwu jest to, co zrobi dla tych celów. Ponieważ jesteś również uważany za „nowego faceta”, nie możesz po prostu oczekiwać, że ludzie porzucą swoją pracę lub że spodziewają się szybkiego zejścia z szeregu; musisz zbudować zaufanie, udowadniając, że potrafisz dostarczyć. W trosce o długofalową rolę przywódczą musisz także nauczyć się koncentrować na wynikach, ale niekoniecznie przywiązuj się do specyfiki wyniku. Jesteś teraz tam, aby zapewnić kierownictwo strategiczne, usunąć przeszkody taktyczne z postępów zespołu i zaoferować opiekę zespołu, a nie wygrywać bitwy o wiarygodność z członkami własnego zespołu.

Podjęcie decyzji odgórnej rzadko będzie wiarygodne, chyba że masz trochę skórki w grze; jeśli ponownie znajdujesz się w podobnej sytuacji, powinieneś bardziej skoncentrować się na budowaniu konsensusu w swojej organizacji niż na eskalacji, gdy czujesz, że sytuacja wymknęła się spod kontroli.

Ale biorąc pod uwagę, gdzie jesteś teraz, powiedziałbym, że najlepszym rozwiązaniem jest argumentowanie, że twoje podejście przyniesie wymierne długoterminowe korzyści w oparciu o twoje doświadczenie i że jest zgodne z pracą znanych praktyków, takich jak wujek Bob i współpracownicy. , i że chcesz poświęcić kilka dni / tygodni na dawaniu przykładu w wąskim refaktoryzacji aspektu najwyższego zysku za dolara, aby zademonstrować, jak powinien wyglądać Twój pogląd na dobry projekt. Musisz jednak dopasować cokolwiek w swojej sprawie do konkretnych celów biznesowych wykraczających poza osobiste preferencje.

Po pierwsze, musisz wykazać, że każda wymierna organizacja musi przyjąć najlepsze praktyki branżowe. Mówiąc, że „to po prostu działa dla nas!” nie da się zmierzyć ani w czasie, ani w zasobach, ponieważ jest to po prostu nieprzewidywalne. Inżynieria oprogramowania jest nauką tak samo jak każda inna dziedzina nauki, a koncepcje te zostały przestudiowane, zbadane, przetestowane i udokumentowane.

1. Object Bóg jest anty-wzorzec , który stwierdza, że

   W inżynierii oprogramowania anty-wzorzec (lub wzorzec) to wzorzec stosowany w operacjach społecznych lub biznesowych lub inżynierii oprogramowania, który może być powszechnie stosowany, ale w praktyce jest nieskuteczny i / lub przynosi efekt przeciwny do zamierzonego.

2. Na konferencji Google IO w 2009 r. Ten temat został częściowo wyjaśniony, gdy wyjaśniono wzorzec MVP. Może nie mieć związku z Boskim Przedmiotem, ale może dać ci trochę amunicji.

3. Ponadto stosowanie tego anty-wzoru narusza zasadę pojedynczej odpowiedzialności w projektach obiektowych, która stwierdza, że:

   każda klasa powinna ponosić jedną odpowiedzialność, która powinna być całkowicie zamknięta w klasie. Wszystkie jego usługi powinny być ściśle dostosowane do tej odpowiedzialności.

4. Kod Decaying blog opowiada również o tym i o jego rozwiązanie.

5. Nie możemy mówić o zasadzie pojedynczej odpowiedzialności bez mówienia o sprzężeniu obiektów .

   [...] sprzężenie lub zależność to stopień, w jakim każdy moduł programu opiera się na każdym z pozostałych modułów.

   Gdzie posiadanie ciasno sprzężonego systemu może powodować assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency.Wyższy poziom sprzęgania obiektu oznacza mniejszą spójność i odwrotnie. Boskie obiekty są dobrym przykładem ścisłego połączenia, ponieważ wiedzą więcej niż powinny, w ten sposób obciążając je odpowiedzialnością, a tym samym znacznie ograniczając możliwość ponownego użycia kodu.

6. Projektując złożoną aplikację, należy pamiętać o prostocie . Duże problemy należy rozłożyć na mniejsze, łatwiejsze do zarządzania, testowania i dokumentowania. Jest to szczególnie prawdziwe w paradygmacie obiektowym.

   Za pomocą tego argumentu wracamy do argumentu anty-wzorzec, ale ten paradygmat dotyczy wzorców, reprezentacji obiektów w świecie rzeczywistym i, ostatecznie, enkapsulacji danych.

7. Masz rację, gdy mówisz, że te „dobre praktyki” częściej występują w salach lekcyjnych. Mam jednak doświadczenie w nauczaniu na studiach (i niektórych uniwersytetach) i widziałem tylko te zasady nauczane na uniwersytetach, zwłaszcza na wydziałach inżynierskich. Co jest smutne Ale jak każda dobra praktyka, ci, którzy dążą do lepszego, zwykle uczą się podstawowych wzorców projektowych i ostatecznie rozumieją, jak łączyć między sprzężeniem a spójnością.

   Zazwyczaj uczę studentów, że może wydawać się, że potrzeba więcej wysiłku, aby przyjąć dobre standardy programowania, ale zawsze to się opłaca na dłuższą metę. Dobrym przykładem może być ktoś proszący programistę o napisanie funkcji sortowania. Programista ma dwie możliwości; 1) napisz funkcję szybkiego sortowania bąbelkowego (mniej niż 5 minut), która nie będzie trwała w miarę wzrostu listy elementów, lub 2) napisz bardziej złożony (zoptymalizowany) algorytm sortowania (szybkie sortowanie itp.), Który będzie lepiej skalowany z większymi listami.

Och, proszę bardzo, nekromując kolejne stare pytanie, ale zgaduję, że nie wygrałeś tego argumentu i oto dlaczego.

Brzmi jak problem kulturowy

Jesteś ich menedżerem, ale nie możesz ich zastąpić i musisz udać się do swoich menedżerów, aby nakłonili ich do zrobienia tego, co według ciebie powinni robić, co w tym przypadku zakładam, że przynajmniej powalą to na boga obiekty poruszające się do przodu. Brzmi dla mnie jak klasyczny przypadek kodu odzwierciedlający kulturę, w której się urodził. Innymi słowy, boskim przedmiotem jest to, jak działa ta firma. Chcesz dokonać jakiejkolwiek znaczącej zmiany? Zawsze ostatecznie wybierasz się w to samo miejsce, ponieważ najwyraźniej wszystkie decyzje muszą być najwyżej u góry.

Będąc wtajemniczonym w wiele nieudanych prób wyczyszczenia starszego kodu i zmian zasad kodu, jestem teraz zdania, że ​​nie można walczyć z kulturą, która umożliwiła kodowi przede wszystkim, gdy kultura ta jest jeszcze mocno zakorzeniona lub przynajmniej walczy Kultura jest bardzo trudnym hasłem pod górę, że jest mało prawdopodobne, aby ktokolwiek kiedykolwiek zapłacił mi wystarczająco dużo lub dał mi wystarczającą moc, aby poczuć, że było to wartościowe przedsięwzięcie, które prawdopodobnie odniesie sukces.

Zanim będzie możliwa zmiana, trzeba ją zmotywować do zmiany i niestety, ponieważ programiści, którzy cholernie starają się czytać stos, czasami trudno nam zrozumieć, że nie wszyscy są motywowani przez te same rzeczy. Wygrałem wiele racjonalnych argumentów w moich doświadczeniach, ale pod koniec dnia firma cierpi z powodu leniwych intelektualnie deweloperów.

Być może obawy biznesowe były motywowane do myślenia tylko o jutrze, a nie o przyszłym tygodniu lub pięciu latach (szczególnie frustrujący scenariusz, gdy jesteś dzieckiem imigrantów z kraju, który zbudował sklepienie nasienne w Arktyce na wypadek apokalipsy). Może boją się zmian. Być może zbyt cenią sobie starszeństwo do tego stopnia, że ​​łańcuch dowodzenia jest bez znaczenia, nawet gdy muszą zatrudnić z zewnątrz, aby doprowadzić lidera lub menedżera zespołu deweloperów, ponieważ nie zauważają, że nikt w zespole wszechczasów urósł wystarczająco dużo w swoim czasie tam (lub ponieważ wspomniani ratownicy nie chcą ryzyka związanego z odpowiedzialnością). Albo, i widziałem to, być może jest to bardzo realne i przygnębiające zjawisko popierania przeciętności, ponieważ głęboko wie, że może ”

Jak walczysz z problemami, które ostatecznie są zakorzenione w strachu lub zepsutych miernikach sukcesu? Powiem wam to, że wymaga to dużo więcej niż nawet zaangażowanego zespołu projektantów, a miałeś o wiele mniej niż dźwięk z tego, kiedy był w tym Q.

W wydarzeniu niemożliwym, że nie jest to problem z kulturą nierozerwalną ...

Teraz, zakładając, że ludzie na szczycie są bardzo otwarci na zmiany i naprawdę są gotowi Ci zaufać, że tak się stanie, naprawdę wystarczy interpunkować wszystkie swoje argumenty pieniędzmi i straconą szansą.

Za każdym razem, gdy trenowanie kogoś nowego na temat tej absurdalnej bazy kodu trwa dłużej, za każdym razem, gdy modyfikowanie lub dodawanie nowej funkcji trwa dłużej, za każdym razem staje się zbyt trudne ujawnianie punktów końcowych innym systemom firmy, z którą chcesz współpracować , kosztuje pieniądze. Dużo cholernych pieniędzy. Co najważniejsze, pozostawia otwarte okno dla mniejszego, bardziej zwinnego konkurenta, który może wślizgnąć się do środka, ustawić cię w pozycji, w której wszystko, co możesz zrobić, to zareagować na nich zbyt wolno i ostatecznie wyrwać to wszystko od ciebie.

Po prostu zauważ, że szczególnie uparta i głupia kultura zachowa status quo za wszelką cenę, nawet jeśli rzeczywisty fizyczny dach firmy faktycznie się z tego powodu pali.

Możesz przytoczyć niektóre z najbardziej podstawowych zasad OOP, takie jak luźne sprzęganie i wysoka kohezja. „Boski obiekt” brzmi, jakby łączy niepowiązane klasy i ma niską spójność.

Zawsze możesz zapytać samego wuja Boba.

Chodzi o to, że jest to tak oczywiste dla ludzi w jakimkolwiek sensie, że kiedy zostanie to przeliterowane, nie musi być ponownie przywoływane przez wielu autorów. Potrzebne jest tylko jedno źródło.

Inne warunki, od których możesz zacząć szukać źródeł:

• SOLIDNY
• Prawo Demetera
• Wielka kula błota

Wszystkie te wyrażają pokrewne pojęcia, które mogą dać realne źródła odniesienia, nawet jeśli tak naprawdę nie nazywają tego jako takie.

Ostatecznie jednak jesteś szefem. Powodem tego jest to, że tak mówisz i chociaż być uważanym za dobrego kierownika, naprawdę powinieneś być przygotowany na uzasadnienie swoich decyzji; zrobiłeś to, a jeśli nadal występuje opór, twój zespół powinien postępować zgodnie z zaleceniami.

Jak udowodnić lub obalić, że „boskie” przedmioty są złe?

Nie możesz.

Tego rodzaju przypuszczenie nie podlega matematycznemu dowodowi, a matematyczny dowód jest jedynym rodzajem dowodu, który jest zdrowy.

Nawet jeśli spróbujesz zamienić emocjonalne słowo „źle” na wymierne miary efektów używania boskich przedmiotów, przekonasz się, że:

1. dostępne środki są surowe,
2. istnieje niewiele wiarygodnych badań, w których środki te zostały skwantyfikowane dla kodu opracowanego przez profesjonalnych programistów
3. niewiele jest wiarygodnych badań, w których konstrukcje językowe lub wzorce (anty-) wzorcowe zostały powiązane z tymi miernikami.

I to ignoruje kwestię decydowania, kiedy dany obiekt jest „bogiem”.

W najlepszym wypadku tego rodzaju badania mogą jedynie wykazać korelację empiryczną. To nie jest prawdziwy dowód.

Co to są rzeczywiście robi to debatują plusy i minusy „Bóg” obiektów z myślą o zmianie innych ludzi opinie ... a potem praktyka organizacji.

Nie używaj słów takich jak „dowód” lub ludzie, z którymi rozmawiasz, mogą śmiać się z twojej twarzy.

Możesz zobaczyć guru tygodnia # 84 . Chodzi o boskie przedmioty (monolity) i to, jak są złe.

Wyciąg:

(Ważny) Izoluje potencjalnie niezależną funkcjonalność w klasie [...] (Drobne) Może zniechęcać do rozszerzania klasy o nową funkcjonalność [...]

Nie jestem pewien, czy wasz zespół naprawdę interesuje się akademickim dowodem, że „Boskie przedmioty są złe”.

Z psychologicznego punktu widzenia twoje podejście do refaktoryzacji może być źle zrozumiane jako atakowanie kompetencji zespołu a la: „zespół wykonał złą robotę”, chociaż program działa zgodnie z oczekiwaniami.

To, co naprawdę chcesz zrobić, to radzenie sobie z negatywnymi skutkami ubocznymi „kodu spagetti” i „obiektów Boga”: koszty eksplozji związane z dodawaniem nowych funkcji z powodu rosnącej liczby błędów powodowanych przez efekty uboczne.

Bycie bardziej szczegółowym i zadawanie pytań zamiast udzielania odpowiedzi może być bardziej pomocne:

manager > Why did implement the new tax-calculation schema took more than 4 weeks
team > because {reason a}
manager > And why was {reason a}?
team > because {reason b}
manager > And why was {reason b}?
...
team > because {reason z}
manager > what could we do to avoid {reason z} ?
team > refactor code