Pytanie brzmiało więc:
Czy to rzeczywiście powszechna praktyka, czy w jakikolwiek sposób dobry pomysł?
Wśród obecnie dostępnych odpowiedzi jest głośne „ nie” . Jest więc kilka innych rzeczy, w których mógłbym się w to wtrącić, takich jak; nawet kod proceduralny może być modułowy i zawierać wszystko, ale zlew kuchenny nie jest tym, w jaki sposób można uzyskać modułowość. Co robi jedna wielka klasa podzielona na częściowe, wszystko składa się na jeden wielki bałagan.
Jednak to pytanie jest czerwonym śledziem do prawdziwej części krytycznej, która została pominięta; ponieważ PO ma również do powiedzenia na temat tej sytuacji:
(...) Podczas gdy moją reakcją jelita było oderwanie go od orbity, nalegają ...
(...) Skłaniam się do podjęcia natychmiastowych kroków w celu sprowadzenia tej bestii na ziemię (a przynajmniej powstrzymania jej dalszego rozwoju), ale jestem skłonny uwierzyć, że się mylę.
WSTRZYMAJ SIĘ!
To jest coś, co sprawi, że mój monokl w przenośni spadnie do mojej figuratywnej filiżanki herbaty.
Byłem w podobnych sytuacjach i powiem ci: NIE . Jasne, możesz rzucić Nuke Hammer of Justice na drużynę, ale zanim to zrobisz, prosimy o humor z następującą zagadką:
Co się stanie, jeśli powiesz zespołowi, że jego kod jest do kitu i odpieprzasz ?
(... lub coś w tym rodzaju, ale mniej obraźliwie, to tak naprawdę nie ma znaczenia, ponieważ będą obrażeni bez względu na to, co zrobisz, jeśli zdecydujesz się na nich w pełni wykorzystać)
Jaka jest obecna sytuacja z bazą kodu? Czy to działa? Wtedy będziesz miał duże problemy z wyjaśnieniem klientom, że ich kod jest do kitu . Bez względu na to, jakie mają powody: dopóki działa, większość klientów nie dba o to, jak zorganizowany jest kod.
Postawcie się także na ich miejscu, co by zrobili? Pozwól, że cię rozbawię następującym możliwym rezultatem:
Członek zespołu nr 1: „Więc ten facet mówi nam, że robiliśmy to źle przez ostatnie lata”.
Członek zespołu nr 2 i nr 3: „Co za palant”.
Wpływowy członek zespołu nr 4: „Nie martw się, po prostu pójdę do kierownictwa i zgłosię to jako prześladowanie”.
Zobacz, co zrobił tam wpływowy członek zespołu nr 4 ? Poszedł do kierownictwa i zmniejszył twoją karmę w towarzystwie. Mógł być Amerykaninem-Włochem, mówiąc wszystkim, żeby się tym nie martwił, ale wtedy byłbym rasistą.
Umieszczenie drużyny, która popełniła błąd, w kącie, pozwalając mu przyznać, że tak długo popełniali błąd, jest również złym pomysłem i prowadzi do tego samego. Stracisz szacunek i odrobinę karmowej polityki biurowej.
Nawet jeśli udało ci się skłonić grupę ludzi do podpisania się na tym, aby „nauczyć zespół lekcji”, pamiętaj, że robisz to dość inteligentnym ludziom, którzy najwyraźniej wykonują pewne czynności. Gdy kod zostanie przepisany / zreformowany / przetworzony / z czymkolwiek, powstają problemy, że będziesz odpowiedzialny za to, jak byłeś strażakiem .
Przeciwstawianie się takim sytuacjom to przede wszystkim gra typu przegrana / przegrana, ponieważ grozi im zaklęcie błędnego kręgu obwiniania. Jest to wynik nieoptymalny dla tej sytuacji. Nawet jeśli wygrasz, nagle przekazujesz bałagan, który zrobił ktoś inny.
Istnieją inne (dużo dojrzałe) sposoby
Byłem kiedyś w podobnej sytuacji, ale potem wziąłem strzałę w kolano. Więc po chwili z tą nagłą strzałką zmieniającą karierę w mojej głowie, dostałem książkę Driving Technical Change autorstwa Terrence'a Ryana . Wymienia kilka wzorców sceptyków, ludzie nie działają na dobre pomysły. Wszystkie najprawdopodobniej mają zastosowanie w przypadku PO:
- Niedoinformowani - oni naprawdę nie wiedzieli, że istnieją inne sposoby lub po prostu nie rozumieli. Młodsi programiści zwykle pasują do tej kategorii, ale niekoniecznie. (Szczerze mówiąc: spotkałem młodszych programistów, którzy byliby jaśniejsi niż to.)
- Stado - znali lepsze techniki niż stosowanie klas częściowych, ale nie wiedzieli, że są dozwolone.
- Cynik - po prostu lubią argumentować, że posiadanie częściowych zajęć jest lepsze niż twój pomysł tylko ze względu na kłótnie. Łatwo to zrobić w tłumie zamiast stać przed tłumem.
- The Burned - Z jakiegoś dziwnego powodu nie lubią tworzyć nowych klas, najprawdopodobniej uważają to za zbyt trudne.
- The Time Crunched - Są tak zajęci, że nie mogą zadać sobie trudu, aby naprawić swój kod.
- Szef - myślą: „Cóż, działa; więc po co zawracać sobie głowę?”
- Irracjonalni - Ok, są kompletnie szaleni.
Książka zawiera listę strategii i tak dalej, ale w przypadku PO jest to kwestia perswazji. Mocne podejście z faktami na temat anty-wzoru nie wystarczy.
Jeśli w twoim interesie jest podniesienie jakości kodu, przynajmniej daj drużynie obrażającej szansę powtórzyć i naprawić swój bałagan . Osobiście starałbym się ich przekonać, słuchając i zadając wiodące pytania, pozwól im opowiedzieć swoją historię:
- Co dokładnie robi ich klasa boga?
- Czy napotkali jakieś problemy? Czy mają jakieś błędy? Zaproponuj rozsądne poprawki, nie każąc im tego robić.
- Jeśli jesteś użytkownikiem tej klasy boga jako interfejsu API: Czy istnieją prostsze sposoby korzystania z kodu niż całego? Zaproponuj prostsze przykłady, zobacz jak reagują.
- Czy możesz zamienić niektóre funkcje na inne, bez konieczności pisania funkcji?
- Czy potrzebują szkolenia? Czy potrafisz przekonać kierownictwo, żeby im to wykonało, lub zorganizował lunch na temat wzorców i praktyk?
... i tak dalej. Daj im małe sugestie, aby mogli iść naprzód. To wymaga czasu i będzie wymagało smaru na łokieć klasy biurowej, ale cierpliwość i ciężka praca to zaleta, prawda?