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

56

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.

szczery
źródło
19
Poproś ich o udokumentowanie obiektów Boga jako dobrej praktyki.
Don Roby
43
Uciec! Nie chcesz tam pracować.
Don Roby
11
Proszę zdefiniować swoje rozumienie „Boskiego przedmiotu” i jak odnosi się ono do twojego pytania. Spędzasz 4 akapity, mówiąc, że Boska klasa nie jest standardowym terminem w literaturze. Więc dlaczego go używasz? Jeśli użyjesz standardowych warunków branżowych i potrafisz pokazać, w jaki sposób te koncepcje odnoszą się do twojego obecnego projektu, możesz przekonać niektóre osoby o swoim punkcie. Używanie gotowych słów na spotkaniu biznesowym tylko podważy twoją argumentację. Istnieją standardowe warunki branżowe - nie jesteś pierwszą osobą, która kiedykolwiek widziała koszmar o zasięgu globalnym lub pojedynczym obiekcie, czy cokolwiek, co próbujesz opisać.
GlenPeterson
18
Brakuje Ci terminu „antipattern”. Wyszukanie w Google hasła „antipattern obiektu Boga” zwraca mnóstwo stron z powodów, dla których są złe.
Izkata,
21
Nie powinieneś atakować obiektu Boga, ale problemy, które stwarza. Na przykład: mamy bardzo ścisłe sprzężenie między wszystkim, a zmiana A wymaga również zmian w B, C i D. Aby temu przeciwdziałać, wyodrębnimy klasy. Lub: chcemy, aby kod był w środowisku testowym i nie możemy tego zrobić, co będziemy robić? Staraj się też unikać używania słowa „Bóg”, ludzie nieczuli będą myśleć, że używasz hiperboli.
Pieter B

Odpowiedzi:

51

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.

JasonTrue
źródło
4
Dobrze, że jest to problem społeczny. Pewnie dlatego jest tak dużo źle napisanego kodu i źle zaprojektowanych aplikacji.
Yanick Rochon,
5
+1 za powiązanie go z „mówieniem biznesowym” jako takim; staraj się, aby była jak najbardziej odpowiednia dla odbiorców. Jeśli rozmawiasz z kadrą kierowniczą , porozmawiaj o tym, jak standard kodu ma bezpośredni związek z utrzymaniem i wydajnością, i omów, w jaki sposób wiąże się to z ogólnymi finansami projektu, długoterminową stabilnością i tak dalej. Brzmi, jakbyś został zatrudniony z powodu swojej wiedzy; Pamiętaj to. (Tylko nie zostań menedżerem, który myśli, że zawsze wie najlepiej - ale w tym przypadku masz 100% rację.)
Fergus In London
2
+1 za „działający kod przebija wszelkie argumenty dotyczące teorii lub dobrego projektu”. Coś, o czym często zapominamy w poszukiwaniu idealnego kodu.
Bjarke Freund-Hansen
Świetna odpowiedź, mnóstwo mądrości dla aspirujących liderów zespołu.
jimmy_terra
24

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.

Yanick Rochon
źródło
1
Zorientowane obiektowo języki programowania często wymagają, aby jeśli dwa niezależne zespoły źródłowe były odpowiedzialne za różne aspekty zachowania obiektu, konieczne będzie utworzenie niezależnych instancji obiektów w celu kapsułkowania tych zachowań. Niestety, chociaż w wielu przypadkach najbardziej logiczne podziały funkcji między zestawami kodu nie pokrywają się z najbardziej logicznym podziałem funkcji między instancjami obiektów, nie widziałem wiele dyskusji na temat rozróżniania dwóch rodzajów podziału.
supercat
1
Uważam, że to trochę nie na temat tego pytania. Nie mówimy tu o anty-wzorcu Boskiego Obiektu, ale o sprzężeniu kodu i spójności, która jest bardzo szerokim tematem i bardzo subiektywnym.
Yanick Rochon
7

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.

Erik Reppen
źródło
3
Niedługo potem opuściłem firmę. usiłowali mnie zatrudnić na pełny etat i zmusić do przeprowadzki do Seattle z Seattle w celu zaakceptowania oferty; Powiedziałem im w zasadzie: „Nie ma mowy, nie przeprowadzę się do Nowego Jorku, kiedy zespół, którym będę kierował, będzie w Bellevue, WA” i wtedy po prostu przeszedłem przez ulicę i znalazłem pracę w MSFT, dopóki nie znalazłem czegoś lepszy.
uczciwy
1
@honestduane Tak, ten zestaw samych oczekiwań mówi wiele. Dobre dla ciebie na GTFO.
Erik Reppen
3

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ść.

Nat
źródło
2

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.

Tom W.
źródło
„jeśli nadal występuje opór, twój zespół powinien postępować tak, jak im powiedziano”. Może właściwym działaniem jest odejście, a nie sprawienie, by zespół był nieszczęśliwy…?
Tom
Decyzja menedżera została odpowiednio uzasadniona, a jeśli zespół się nie zgadza, problem leży po stronie zespołu. OP został zatrudniony ze względu na jego wiedzę specjalistyczną i nie wolno mu wykorzystywać go dla korzyści firmy, ponieważ koledzy nie zachowują się w sposób rozsądny, jest to nie do przyjęcia. Odwróćmy twoje twierdzenie od głowy - dlaczego odporni członkowie zespołu nie powinni odejść, jeśli ich pogląd na pracę jest niezgodny z poglądem firmy?
Tom W
3
Uczciwy punkt. To zależy od tego, jak chcesz zarządzać zespołem. Ale z mojego doświadczenia zmuszanie ludzi do robienia rzeczy wbrew ich woli prowadzi do nieszczęścia. Wolałbym widzieć God Objects w całej bazie kodu niż nieszczęsny zespół programistów. Może odpowiedzią jest wysłanie ich na szkolenie. Wszyscy kochają szkolenie. Win-win.
Tom
Główny programista / manager / cokolwiek powinien bezwzględnie podjąć wszelkie uzasadnione środki, aby zapewnić utrzymywanie dobrych relacji roboczych między sobą. Jeśli dodatkowe szkolenie jest pomocne, to z całą pewnością rozważ to jako opcję - ale wydaje się, że jest to przypadek umyślnej ignorancji i mówienie komuś, że trzeba go przeszkolić, aby zrozumiał twój pomysł, kiedy to, co według niego zrobili, nie zgadza się , zamiast nie rozumieć, może się odwrócić. Trudno mi wyobrazić sobie sposoby radzenia sobie z ludźmi, którzy nie chcą się uczyć.
Tom W
1

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.

Stephen C.
źródło
0

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ść [...]

użytkownik1882585
źródło
0

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
k3b
źródło