Jak udowodnić lub obalić “ Obiekty Boga ” są błędne?

Każda zmiana praktyki jest uzasadniona poprzez zidentyfikowanie punktów bólu stworzony przez istniejący projekt. W szczególności należy określić, co jest trudniejsze niż powinno być ze względu na istniejący projekt, 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 aktualna implementacja lub, w niektórych przypadkach, jak spada wydajność, ile czasu potrzeba, aby przyspieszyć pracę nowego członka zespołu itp.

Po drugie, działający kod ma przewagę nad wszelkimi argumentami dotyczącymi teorii lub dobrego projektu . Dotyczy to niestety nawet złego kodu. Będziesz więc musiał zapewnić lepszą alternatywę, co oznacza, że jako orędownik lepszych wzorców i praktyk będziesz musiał dokonać refaktoryzacji, aby wydobyć lepszy projekt. Znajdź wąską płaszczyznę w stylu znacznika-pocisku w istniejącym projekcie i zaimplementuj rozwiązanie, które być może w przypadku iteracji utrzyma działanie implementacji obiektu boskiego, ale odracza rzeczywistą implementację do nowego projektu. Następnie napisz kod, który wykorzysta ten nowy projekt i pokaż, co zyskujesz dzięki tej zmianie, niezależnie od tego, czy chodzi o wydajność, łatwość konserwacji, funkcje, poprawki błędów lub warunków wyścigu, czy też zmniejszenie obciążenia poznawczego programisty.

Często wyzwaniem jest znalezienie wystarczająco małej powierzchni do ataku w słabo zaprojektowanych systemach, dostarczenie początkowej wartości może zająć więcej czasu, a początkowa wypłata może nie być tak imponująca do wszystkich, ale możesz też popracować nad znalezieniem zwolenników nowego podejścia, jeśli połączysz je z członkami zespołu, którzy są przynajmniej trochę sympatyczni.

Lamentowanie nad Boskim Obiektem działa tylko wtedy, gdy „głosisz chór. Jest to narzędzie do nazywania problemu i działa tylko w celu rozwiązania go, gdy masz wrażliwą publiczność, która jest starsza i wystarczająco zmotywowana, aby coś z tym zrobić. Naprawienie obiektu Boga wygrywa spór.

Ponieważ Twoim głównym zmartwieniem wydaje się być poparcie dla kierownictwa, myślę, że najlepiej będzie, jeśli chcesz argumentować, że zastąpienie tego kodu musi być celem strategicznym i powiązać je z celami biznesowymi, za które jesteś odpowiedzialny. Myślę, że Ty możesz argumentować, że możesz zapewnić pewne wskazówki techniczne, pracując najpierw nad skokiem technicznym nad tym, co Twoim zdaniem należy zrobić, aby go zastąpić, najlepiej angażując zasoby 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 uczestniczące w takich spotkaniach będą zwracały uwagę tylko na podsumowanie twoich badań i przestaną słuchać, gdy wymienisz dwa lub trzy potwierdzające źródła.Na początku powinieneś skupić się na tym, aby przekonać się do rozwiązania problemu, który widzisz, niekoniecznie udowadniając, że ktoś inny się myli lub masz rację. To problem społeczny, a nie logiczny.

W roli lidera technologicznego musisz powiązać każdą ze swoich inicjatyw z celami biznesowymi, więc najważniejszą rzeczą przy przedstawianiu swojej argumentacji kierownictwu jest to, co praca wystarczy 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 szybko ustawią się w kolejce; musisz zbudować zaufanie, udowadniając, że możesz to osiągnąć. Na dłuższą metę, pełniąc rolę lidera, musisz także nauczyć się koncentrować się na wynikach, ale niekoniecznie być przywiązanym do ich specyfiki. Jesteś teraz po to, aby zapewnić strategiczne kierownictwo, usunąć taktyczne przeszkody z postępów swojego zespołu i zaoferować swojemu zespołowi opiekę mentora, a nie wygrywać bitwy o wiarygodność z członkami własnego zespołu.

Podjęcie odgórnej decyzji będzie Rzadko bądź wiarygodny, chyba że masz jakąś skórkę w grze; jeśli jesteś w podobnej sytuacji od nowa, powinieneś skupić się bardziej na budowaniu konsensusu w swojej organizacji niż na eskalowaniu, gdy poczujesz, że sytuacja wymknęła się spod kontroli.

Ale biorąc pod uwagę to, gdzie teraz jesteś, powiedziałbym, że najlepiej jest argumentować, że twoje podejście przyniesie wymierne i długoterminowe korzyści w oparciu o twoje doświadczenie i że jest zgodne z pracą znanych praktyków, takich jak wujek Bob i spółka, i że chciałbyś poświęcić kilka dni / tygodni, dając przykład na wąską refaktoryzację najwyższego punktu za grosze, aby zademonstrować, jak powinien wyglądać Twój pogląd na dobry projekt. Jednak niezależnie od tego, jaki jest Twój przypadek, musisz dostosować się do konkretnych celów biznesowych wykraczających poza Twoje osobiste preferencje.

Komentarze

• Dobra uwaga, problem społeczny. Pewnie dlatego jest tyle źle napisanego kodu i źle zaprojektowanych aplikacji.
• +1 za powiązanie go z ' językiem biznesowym ' jako taki; postaraj się, aby był jak najbardziej odpowiedni dla odbiorców. Jeśli ' rozmawiasz z kierownictwem, zrób porozmawiaj o tym, w jaki sposób standard kodu ma bezpośredni związek z konserwacją i wydajnością, i omów, jak to się wiąże z ogólnymi finansami projektu, długoterminową stabilnością itd. Brzmi jak Ty zostałeś zatrudniony ze względu na Twoją wiedzę; pamiętaj o tym. (Po prostu nie ' nie zostań menedżerem palantem, który myśli zawsze wie najlepiej – ale w tym przypadku ' w 100% dobrze.)
• +1 dla ” działającego kodu przebija wszelkie argumenty dotyczące teorii lub dobrego projektu. ” Coś, o czym często zapominamy w naszych zadaniach dla doskonałego kodu.
• Świetna odpowiedź, dużo mądrości dla aspirujących liderów zespołu.

Och, zaczynam niszczyć kolejne stare pytanie, ale zgadnę, że nie wygrałeś tej kłótni i oto dlaczego.

To brzmi jak problem kulturowy

Jesteś ich menadżera, ale nie możesz ich zastąpić i musisz udać się do swoich menedżerów, aby skłonić ich do zrobienia tego, co uważasz, że powinni robić, co w tym przypadku zakładam, że przynajmniej zniweczy to, gdy obiekty boga poruszają się do przodu. Brzmi to dla mnie jak klasyczny przykład kodu odzwierciedlającego kulturę, w której się narodził. Innymi słowy, przedmiotem boga jest sposób działania tej firmy. Chcesz wprowadzić jakąkolwiek znaczącą zmianę? Zawsze udajesz się po nią w to samo miejsce ostatecznie, ponieważ wszystkie decyzje najwyraźniej muszą być zatwierdzone na górze.

Byłem str rywalizując z wieloma nieudanymi próbami czyszczenia starego kodu i zmian w polityce kodu. Jestem teraz zdania, że nie można walczyć z kulturą, która umożliwiła kod w pierwszej kolejności, kiedy ta kultura jest nadal mocno zakorzeniona lub przynajmniej kultura walki jest bardzo ciężki podjazd 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 kiedykolwiek odniesie sukces.

Zanim będzie można zmienić, muszą być zmotywowani do zmiany i niestety, jako programiści, którzy mają dość cholernego czytania od czasu do czasu Stack, trudno nam zrozumieć, że nie każdy jest motywowany tym samym. W moich doświadczeniach wygrałem wiele racjonalnych argumentów, ale pod koniec dnia firma cierpi z powodu intelektualnie leniwych programistów.

Być może obawy biznesowe zostały zmotywowane do myślenia tylko o jutrze, a nie w przyszłym tygodniu lub za pięć lat (szczególnie frustrujący scenariusz, kiedy jesteś „dzieckiem imigrantów z kraju, który zbudował w Arktyce magazyn nasion na wypadek apokalipsy). Może „boją się zmian”.Może zbytnio cenią sobie staż pracy do tego stopnia, że łańcuch dowodzenia jest bez znaczenia, nawet jeśli muszą zatrudniać z zewnątrz, aby sprowadzić kierownika zespołu programistów lub menedżera, ponieważ uznają, że nikt z ich zespołu przez całe życie nie rozwinął się wystarczająco w swoim czasie tam (lub dlatego, że ci dożywotni 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, w którym przeciętność walczy o siebie, ponieważ głęboko wie, że może. konkurować z jakością, a kiedy jest wystarczająco dużo głupstw, aby je obejść, niemożliwe jest ustalenie, kogo winić, gdy wszystko regularnie się rozpada.

Jak walczyć z problemami, które są ostatecznie zakorzenione w strachu lub zepsute wskaźniki sukcesu? Powiem ci to, potrzeba o wiele więcej niż nawet zaangażowany zespół programistów zajmujących się jakością, a miałeś o wiele mniej z dźwięku, jaki był w czasie, gdy publikowano ten Q.

W niemożliwym przypadku, że nie jest to trudny do rozwiązania problem kulturowy …

Teraz ludzie na szczycie są bardzo otwarci na zmiany i naprawdę są gotowi zaufać Ci, że to zrobisz, tak naprawdę musisz tylko przerywać wszystkie swoje argumenty pieniędzmi i straconą szansą.

Za każdym razem, gdy przeszkolenie kogoś zajmuje więcej czasu nowość w tej absurdalnej bazie kodów, za każdym razem, gdy modyfikacja lub dodanie nowej funkcji zajmuje więcej czasu, za każdym razem, gdy ujawnienie punktów końcowych w innym systemie firmy, z którą chcesz współpracować, staje się zbyt trudne, kosztuje to dużo pieniędzy. szalone pieniądze. Co najważniejsze, pozostawia otwarte okno dla mniejszego, bardziej zwinnego konkurenta, który może wkroczyć, i stawia Cię w pozycji, w której wszystko, co możesz zrobić, to zareagować na niego zbyt wolno wly i ostatecznie wyrwie ci to wszystko.

Po prostu uświadom sobie, że szczególnie uparta i głupia kultura utrzyma status quo za wszelką cenę, nawet jeśli rzeczywisty fizyczny dach firmy płonie tego.

Komentarze

• Niedługo potem opuściłem firmę. próbowali zatrudnić mnie na pełny etat i zmusić mnie do przeniesienia się do Nowego Jorku z Seattle w celu przyjęcia oferty; Zasadniczo powiedziałem im ” Nie ma mowy, ' nie zamierzam przeprowadzać się do Nowego Jorku, gdy zespół, którym będę zarządzał, będzie w Bellevue, WA ” iw tym momencie przeszedłem przez ulicę i dostałem pracę w MSFT, aż znalazłem coś lepszego.
• @honestduane Tak, ten zestaw oczekiwań sam mówi wiele. Dobrze dla Ciebie w GTFO.

Możesz przytoczyć niektóre z najbardziej podstawowych zasad OOP, takich jak luźne sprzężenie i wysoka kohezja. „Obiekt Boga” brzmi tak, jakby łączył niepowiązane ze sobą klasy i miał niską spójność.

Zawsze możesz zapytać samego wujka Boba .

Rzecz w tym, że jest to tak oczywiste dla ludzi z jakimkolwiek wyczuciem, że kiedy zostanie już przeliterowane, wielu autorów nie musi do niego odnosić się ponownie. Wystarczy, że jedno źródło.

Inne terminy, od których warto zacząć, szukając źródeł, to:

• SOLIDNY
• Prawo Demeter
• Wielka Kula Błota

Wszystkie te wyrażają powiązane koncepcje, które mogą dostarczyć realnych źródeł odniesienia, nawet jeśli tak naprawdę ich nie nazywają.

Ostatecznie chociaż „jesteś szefem”. Powodem jest to, że tak mówisz i chociaż aby być uważanym za dobrego menedżera, naprawdę powinieneś być przygotowany na uzasadnianie swoich decyzji. Zrobiłeś to i jeśli nadal jest opór, właściwy sposób działania to dla Twojego zespołu postępowanie zgodnie z zaleceniami.

Komentarze

• ” Jeśli nadal występuje opór, właściwym sposobem działania jest wykonanie przez zespół tak, jak ' ponownie ” Może właściwym sposobem działania jest rezygnacja, a nie osłabianie zespołu ..?
• Menedżer ' s decyzja została odpowiednio uzasadniona, a jeśli zespół nie ' się zgadza, to problem leży po stronie zespołu. Operator został zatrudniony ze względu na swoją wiedzę i nie pozwolono mu korzystać z niej dla korzyści firmy, ponieważ koledzy wygrali ', aby zachowywać się rozsądnie, nie ' t do przyjęcia. Niech ' obróci twoje twierdzenie na głowie – dlaczego nie ' t odporni członkowie zespołu rezygnują, jeśli ich pogląd na pracę jest niezgodny z że z biznesem?
• Słuszna uwaga. To zależy od tego, jak chcesz prowadzić zespół. Ale z mojego doświadczenia wynika, że zmuszanie ludzi do robienia rzeczy wbrew ich woli prowadzi tylko do nieszczęścia. Wolałbym widzieć God Objects w całym kodzie niż żałosny zespół programistów. Może odpowiedzią jest wysłanie ich na szkolenie. Każdy kocha szkolenia. Win-win.
• Główny programista / menedżer / ktokolwiek powinien bezwzględnie podjąć wszelkie rozsądne środki, aby zapewnić, że zespół utrzymuje ze sobą dobre stosunki robocze. Jeśli dodatkowe szkolenie jest pomocne, zdecydowanie rozważ je jako opcję – ale wydaje się, że jest to przypadek świadomej ignorancji i mówienia komuś, że musi zostać przeszkolony, aby zrozumiał twój pomysł, kiedy to, co myślą, ' już się nie zgadzam, zamiast nie rozumieć, może przynieść odwrotny skutek. Trudno mi sobie wyobrazić sposoby radzenia sobie z ludźmi, którzy nie ' nie chcą się uczyć.

Jak udowodnić lub obalić obiekty „boga” są nieprawidłowe?

Nie możesz.

Tego rodzaju przypuszczenia nie można poddać dowodowi matematycznemu, a dowód matematyczny jest jedynym rozsądnym dowodem.

Nawet jeśli spróbujesz zastąpić emotywne słowo „źle” z wymiernymi miarami skutków używania obiektów boskich, przekonasz się, że:

1. dostępne miary są prymitywne,
2. istnieje niewiele wiarygodnych badań, w których te miary zostały określone ilościowo w przypadku kodu tworzonego przez profesjonalnych programistów.
3. istnieje niewiele wiarygodnych badań, w których konstrukcje językowe lub wzorce (anty) projektowe byłyby powiązane z tymi środkami.

I że ignoruje kwestię decydowania, kiedy dany obiekt jest obiektem „boga”.

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

To, co faktycznie robisz, to debatowanie na temat zalet i wad „boga” obiektów w celu zmiany opinii innych ludzi. … a potem praktyka twojej organizacji.

Nie używaj słów takich jak „dowód” lub osoby, z którymi debatujesz, mogą śmiać się ci w twarz.

Możesz chcieć zobaczyć guru tygodnia nr 84 . Chodzi o obiekty bogów (monolity) i ich zły stan.

Wyodrębnij:

(Major) Wyodrębnia potencjalnie niezależna funkcjonalność wewnątrz klasy […] (Minor) Może zniechęcać do rozszerzania klasy o nowe funkcje […]

Nie jestem pewien, czy Twój zespół jest naprawdę zainteresowany akademickimi dowodami, że „obiekty Boga są złe”.

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

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

Bycie bardzo konkretne 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