Jak mohu dokázat nebo vyvrátit “ Boží objekty ”, že se mýlí?

Případné změny v praxi spočívají v identifikaci bodů bolesti vytvořené stávajícím designem. Konkrétně musíte identifikovat, co je těžší, než by mělo být kvůli existujícímu designu, co je křehké, co se nyní zlomí, jaké chování nelze jednoduše implementovat jako přímý (nebo dokonce poněkud nepřímý) výsledek aktuální implementace, nebo v některých případech, jak trpí výkon, kolik času trvá, než se nový člen týmu dostane do tempa atd.

Zadruhé, pracovní kód zvítězí nad všemi argumenty ohledně teorie nebo dobrého designu . To bohužel platí i pro špatný kód. Takže budete muset poskytnout lepší alternativu, což znamená, že jako obhájce lepších vzorů a postupů budete muset refaktorovat, abyste mohli vylepšit lepší design. Najděte úzkou rovinu ve stylu stopovací kulky skrz existující design a implementujte řešení, které možná pro iteraci jeden udržuje implementaci objektu god funkční, ale odloží skutečnou implementaci do nového designu. Poté napište nějaký kód, který využije výhody tohoto nového designu, a ukažte, co díky této změně vyhrajete, ať už jde o výkon, udržovatelnost, funkce, opravu chyb nebo podmínky závodu nebo snížení kognitivní zátěže pro vývojáře.

Vyhledat dostatečně malou plochu k útoku ve špatně navržených systémech je často výzvou, může trvat déle, než byste chtěli dodat nějakou počáteční hodnotu, a počáteční výplata nemusí být tak působivá všem, ale můžete také najít nějaké obhájce svého nového přístupu, pokud se s ním spojíte s členy týmu, kteří jsou alespoň trochu sympatičtí.

Lamenting the God Object funguje pouze tehdy, když kážete sbor. Je to nástroj pro pojmenování problému a jeho řešení funguje, pouze když získáte vnímavé publikum, které je starší a dostatečně motivované, aby s tím něco udělalo. Oprava objektu God vyhrává argument.

Vzhledem k tomu, že vaším bezprostředním zájmem se zdá být buy-in pro výkonné pracovníky, myslím, že je nejlepší vytvořit případ, že nahrazení tohoto kódu musí být strategickým cílem a svázat je s obchodními cíli, za které jste zodpovědní. může vytvořit případ, že můžete určit nějaký technický směr tím, že nejprve budete pracovat na technickém špičce toho, co by podle vás mělo být provedeno jako jeho náhrada, nejlépe pokud jde o zdroje od jednoho nebo dvou technických lidí, kteří mají výhrady k aktuálnímu designu.

Myslím, že jste našli dostatek zdrojů, abyste svůj argument ospravedlnili; lidé na takových setkáních budou věnovat pozornost pouze shrnutí vašeho výzkumu a přestanou poslouchat, až zmíníte dva nebo tři potvrzující zdroje.Zpočátku byste se měli zaměřit na získání odkupu za vyřešení problému, který vidíte, a ne nutně prokázat, že se někdo jiný mýlí nebo že máte pravdu. Jedná se o sociální problém, nikoli o logický.

V roli vedoucího v oblasti technologie musíte spojit jakoukoli ze svých iniciativ s obchodními cíli, takže nejdůležitější věcí pro vedení případu je to, co pro tyto cíle bude práce provedena. Protože jste také považováni za „nového chlapa“, nemůžete jen očekávat, že lidé zahodí svou práci, nebo očekávají, že rychle padnou do řady; musíte si vybudovat určitou důvěru tím, že prokážete, že dokážete splnit. Z dlouhodobého hlediska se ve vedoucí roli musíte také naučit soustředit se na výsledky, ale nemusí to nutně souviset se specifiky výsledku. Nyní jste zde, abyste poskytli strategické vedení, odstranili taktické překážky pokroku vašeho týmu a nabídli týmu mentorství, nikoli vyhrávali bitvy o důvěryhodnost se svými vlastními členy týmu.

Rozhodnutí shora dolů bude zřídka být důvěryhodný, pokud nemáte ve hře nějaký skin; pokud jste v podobné situaci znovu a znovu, měli byste se více zaměřit na budování konsensu ve vaší organizaci než na eskalaci, jakmile máte pocit, že se situace vymkla kontrole.

Ale vzhledem k tomu, kde právě jste, říkám, že nejlepším řešením je tvrdit, že váš přístup přinese měřitelné dlouhodobé výhody na základě vašich zkušeností a že je v souladu s prací známých odborníků, jako jsou strýc Bob a spol., a že byste chtěli strávit několik dní / týdnů příkladem v úzkém refaktoringu aspektu nejvyšší ofenzivy, abyste předvedli, jak by měl vypadat váš pohled na dobrý design. V každém případě však budete muset přizpůsobit konkrétní obchodní cíle nad rámec svých osobních preferencí.

Komentáře

• Dobrá věc, že jde o sociální problém. Musí být důvod, proč je tolik špatného napsaného kódu a špatně navržených aplikací.
• +1 pro jeho propojení s ‚ business speak ‚ jako takové; usilujte o to, aby to bylo pro vaše publikum co nejrelevantnější. Pokud ‚ hovoříte s vedoucími pracovníky, udělejte hovořte o tom, jak má standard kódu přímou souvislost s údržbou a výkonem, a diskutujte o tom, jak to souvisí s celkovými financemi projektu, dlouhodobou stabilitou atd. Zní to jako vy byli jste najati kvůli vašim znalostem; pamatujte si to. (Jen se ‚ nestaňte manažerem blbec-off, který si myslí vždy to ví nejlépe – ale v tomto případě jste ‚ znovu 100% správný.)
• +1 pro “ pracovní kód zvítězí nad jakýmikoli argumenty o teorii nebo dobrém designu. “ Něco, na co při své výpravě často zapomínáme pro dokonalý kód.
• Skvělá odpověď, spousta moudrosti pro aspirující vedoucí týmu.

No, jdeme na to, vyvrtám další starou otázku, ale hádám, že jsi tento argument nevyhrál a tady je proč.

Zní to jako kulturní problém

Jste jejich Správce, ale nemůžete je nahradit a musíte se obrátit na své manažery, aby je přiměli dělat to, o čem si myslíte, že by měli dělat, což v tomto případě předpokládám je přinejmenším srazit s božími objekty vpřed. Zní to jako klasický případ kódu, který zrcadlí kulturu, ve které se narodil. Jinými slovy, božským objektem je to, jak tato společnost funguje. Chcete provést jakoukoli smysluplnou změnu? Vždy pro ni chodíte na stejné místo nakonec, protože všechna rozhodnutí musí být zjevně vyřešena nahoře.

Poté, co byl p Rivy na několik neúspěšných pokusů o vyčištění starších kódů a změny zásad kódu Jsem nyní toho názoru, že nemůžete bojovat proti kultuře, která umožnila tento kód, když je tato kultura stále pevně zakořeněná nebo přinejmenším bojová kultura je velmi tvrdý slogan, že je nepravděpodobné, že by mi někdo někdy mohl dostatečně zaplatit nebo dát dost síly, abych měl pocit, že to bylo užitečné úsilí, které pravděpodobně ještě někdy uspěje.

Než bude možné změnit, musí být motivováni ke změně a bohužel jako programátoři, kteří mají dost času číst občas Stack, je pro nás těžké pochopit, že ne každý je motivován stejnými věcmi. Ve svých zkušenostech jsem vyhrál spoustu racionálních argumentů, ale na konci dne společnost z nějakého důvodu trpí intelektuálně línými vývojáři.

Možná, že obchodní zájmy byly motivovány k tomu, aby myslely spíše na zítřek než na příští týden nebo pět let ven (obzvláště frustrující scénář, když jste dítětem přistěhovalců ze země, která v případě apokalypsy postavila v Arktidě trezor semen). Možná se bojí změn.Možná si nadměrně váží seniority do té míry, že velení je nesmyslné, i když se musí najímat zvenčí, aby přivedli vedoucího nebo manažera vývojového týmu, protože si uvědomují, že nikdo v jejich all-life týmu v jejich době dostatečně nevyrostl. tam (nebo proto, že zmínění doživotní lidé nechtějí riziko spojené s odpovědností). Nebo, a já jsem to viděl, možná je to „velmi skutečný a depresivní fenomén průměrnosti, který se prosazuje, protože hluboko uvnitř ví, že může“ Nesoutěžíte s kvalitou a když je tu dost bláznivých věcí, které to dokážou obejít, je nemožné zjistit, kdo je vinen, když se všechno pravidelně rozpadá.

Jak bojujete proti problémům, které jsou nakonec zakořeněny ve strachu nebo nefunkční metriky pro úspěch? Řeknu vám to, vyžaduje to mnohem víc, než dokonce oddaný tým kvalitních vývojářů, a vy jste toho měli mnohem méně, než zvuk v době, kdy byl tento Q zveřejněn.

V případě, že to není nemožná událost, není to problém s neochvějnou kulturou …

Nyní předpokládejme, že lidé nahoře jsou velmi vstřícní ke změnám a jsou skutečně ochotni vám věřit, že to zvládnete, stačí jen vyložit všechny vaše argumenty penězi a ztracenou příležitostí.

Pokaždé, když někoho zaškolíte, trvá déle novinka v této směšné základně kódů, pokaždé, když trvá déle upravit nebo přidat k něčemu novou funkci, pokaždé, když je prohibitivně obtížné vystavit koncové body jinému systému od společnosti, se kterou chcete uzavřít partnerství, stojí to peníze. Nejdůležitější je, že nechává otevřené okno pro menší, hbitějšího konkurenta, který se může vrhnout, a postaví vás do situace, kdy vše, co můžete udělat, je reagovat na ně příliš daleko Wly, a nakonec to všechno od sebe odtrhněte.

Jen si uvědomte, že obzvláště tvrdohlavá a hloupá kultura udrží status quo za každou cenu, i když skutečná fyzická střecha společnosti je ve skutečnosti v ohni, protože toho.

Komentáře

• Krátce poté jsem opustil společnost. pokusili se mě najmout na plný úvazek a přinutit mě přestěhovat se do NY ze Seattlu, abych nabídku přijal; V podstatě jsem jim řekl “ V žádném případě se nebudu stěhovat do NY, když bude tým, který řídím, v Bellevue, WA “ a v tom okamžiku jsem v podstatě přešel ulici a dostal práci na MSFT, dokud jsem nenašel něco lepšího.
• @honestduane Jo, ta sada očekávání sám mluví hodně. Dobré pro GTFO.

Můžete uvést některé z nejzákladnějších principů OOP, jako je volné spojení a vysoká soudržnost. „Bůh objekt“ zní, jako by spojoval nesouvisející třídy a má nízkou soudržnost.

Vždy se můžete zeptat samotného strýčka Boba .

Jde o to, že je to tak zřejmé lidem v jakémkoli smyslu, že jakmile je to vysvětleno, není třeba na něj znovu odkazovat mnoho autorů. Je třeba pouze jeden zdroj.

Další pojmy, které byste mohli začít hledat při hledání zdrojů, jsou:

• SOLID
• Law of Demeter
• Big Ball of Mud

Všechny tyto pojmy vyjadřují související pojmy, které by mohly přinést životaschopné referenční zdroje, i když to tak vlastně nepojmenují.

Nakonec „Jste však šéf. Důvodem je to, že to říkáte, a přestože byste měli být považováni za dobrého manažera, měli byste být opravdu připraveni zdůvodnit svá rozhodnutí; udělali jste to, a pokud stále existuje odpor, správný postup je v tom, aby váš tým udělal to, co mu bylo řečeno.

Komentáře

• “ pokud stále existuje odpor, je správný postup vašeho týmu provést tak, jak ‚ řekl “ Možná je správný postup ukončit, než aby byl váš tým nešťastný ..?
• Manažer ‚ s rozhodnutí bylo dostatečně odůvodněno, a pokud tým ‚ t nesouhlasí, pak je problém s týmem. OP byl najat pro jeho odborné znalosti a nesměl jej využívat ve prospěch podnikání, protože kolegové se ‚ nebudou chovat rozumně není ‚ t přijatelný. Nechte ‚ s obrátit vaše tvrzení na hlavu – proč by ‚ t měli rezistentní členové týmu skončit, pokud jejich pohled na práci není kompatibilní s to podnikání?
• Fair point. Záleží na tom, jak chcete tým řídit. Ale podle mých zkušeností nutí lidi dělat věci proti jejich vůli jen vede k bídě. Raději bych viděl God Objects v celé kódové základně než mizerný vývojový tým. Možná odpověď je poslat je na školicí kurz. Všichni milují výcvikový kurz. Výhra-výhra.
• Vedoucí vývojář / manažer / cokoli by měl absolutně přijmout veškerá přiměřená opatření, aby zajistil, že si tým zachová dobré pracovní vztahy. Pokud je další školení užitečné, pak to ve všech ohledech považujte za alternativu – ale zdá se, že to je jako případ úmyslné nevědomosti a říkat někomu, kdo potřebuje, aby byl vyškolen, aby porozuměl vaší myšlence, když si myslí, že ‚ udělal jsem nesouhlas, spíše než nerozumím, mohl by selhat. Těžko si představuji způsoby jednání s lidmi, kteří se ‚ nechtějí učit.

Jak mohu dokázat nebo vyvrátit, že „božské“ objekty jsou špatné?

Nelze.

Tento druh domněnky není vhodný pro matematický důkaz a matematický důkaz je jediný druh důkazu, který je zdravý.

I když se pokusíte nahradit emotivní slovo „špatně“ s vyčíslitelnými měřítky účinků používání božských objektů zjistíte, že:

1. dostupná opatření jsou hrubá,
2. existuje několik důvěryhodných studií, kde byla tato měřítka kvantifikována pro kód vytvořený profesionálními programátory
3. existuje jen málo důvěryhodných studií, kde byly jazykové konstrukce nebo designové (anti-) vzory spojeny s těmito opatřeními.

A to ignoruje otázku rozhodování, kdy je určitý objekt „božským“ objektem.

V nejlepším případě by tyto druhy studia mohly prokázat pouze empirickou korelaci. Není to skutečný důkaz.

To, co ve skutečnosti děláte, je debata o výhodách a nevýhodách „božích“ předmětů s cílem změnit jiné národy názory … a pak praxe vaší organizace.

Nepoužívejte slova jako „důkaz“ nebo lidé, s nimiž debatujete, se vám mohou smát do očí.

Možná budete chtít vidět guru týdne # 84 . Je to všechno o božských objektech (monolitech) a o tom, jak jsou špatné.

Extrakt:

(Hlavní) Izoluje potenciálně nezávislá funkce uvnitř třídy […] (menší) Může odrazovat od rozšiřování třídy o nové funkce […]

Nejsem si jistý, jestli váš tým má skutečný zájem o akademické dokázání, že „Boží objekty se mýlí“.

Z psychologického hlediska může být váš refaktoringový přístup nepochopen jako útok na kompetenci týmu a la: „tým odvedl špatnou práci“, i když program funguje podle očekávání.

To, co opravdu chcete udělat, je vyrovnat se s negativními vedlejšími účinky „spagetti code“ a „god objects“: explodig stojí za přidání nových funkcí z důvodu narůstajících chyb způsobených vedlejšími účinky.

Užitečnější může být konkrétní a kladení otázek namísto poskytnutí odpovědí:

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