Hoe kan ik bewijzen of weerleggen dat “ God-objecten ” fout zijn?

Elke verandering van praktijk wordt bepleit door de pijnpunten te identificeren gemaakt door het bestaande ontwerp. In het bijzonder moet u bepalen wat moeilijker is dan het zou moeten zijn vanwege het bestaande ontwerp, wat kwetsbaar is, wat nu kapot gaat, welke gedragingen niet op een eenvoudige manier kunnen worden geïmplementeerd als een direct (of zelfs enigszins indirect) resultaat van de huidige implementatie, of, in sommige gevallen, hoe de prestaties eronder lijden, hoeveel tijd het kost om een nieuw teamlid op snelheid te brengen, enz.

Ten tweede overtroeft werkende code alle argumenten over theorie of goed ontwerp Dit geldt helaas zelfs voor slechte code. U zult dus een beter alternatief moeten bieden, wat betekent dat u, als pleitbezorger voor betere patronen en praktijken, moet refactoren om tot een beter ontwerp te komen. Zoek een smal vlak in tracer-bullet-stijl door het bestaande ontwerp en implementeer een oplossing die, misschien voor iteratie, de implementatie van het god-object aan het werk houdt, maar de daadwerkelijke implementatie uitstelt naar het nieuwe ontwerp. Schrijf vervolgens wat code die voordeel haalt uit dit nieuwe ontwerp, en laat zien wat u dankzij deze wijziging wint, of het nu gaat om prestaties, onderhoudbaarheid, functies, correctie van bugs of race-omstandigheden, of vermindering van cognitieve belasting voor de ontwikkelaar. / p>

Het is vaak een uitdaging om een oppervlak te vinden dat klein genoeg is om aan te vallen in slecht ontworpen systemen, het kan langer duren dan je zou willen om wat initiële waarde te leveren, en de initiële uitbetaling is misschien niet zo indrukwekkend voor iedereen, maar je kunt ook werken aan het vinden van een aantal voorstanders van je nieuwe aanpak als je er een combinatie van maakt met teamleden die op zijn minst een beetje sympathiek zijn.

Lamenting the God Object werkt alleen als je predikt tot het koor. Het is een hulpmiddel om een probleem te benoemen, en werkt alleen om het op te lossen als je een ontvankelijk publiek hebt dat ouder en gemotiveerd genoeg is om er iets aan te doen. Het repareren van het God-object wint de discussie.

Aangezien uw directe zorg de buy-in van de leiding lijkt te zijn, denk ik dat u het beste kunt pleiten dat het vervangen van deze code een strategisch doel moet zijn en deze moet koppelen aan de bedrijfsdoelstellingen waarvoor u verantwoordelijk bent. Ik denk dat u kan beweren dat je wat technische richting kunt geven door eerst te werken aan een technische piek in wat je denkt dat er moet gebeuren om het te vervangen, bij voorkeur met middelen van een of twee technische mensen die bedenkingen hebben bij het huidige ontwerp.

Ik denk dat je genoeg bronnen hebt gevonden om je argument te rechtvaardigen; mensen in dergelijke bijeenkomsten zullen alleen aandacht besteden aan de samenvatting van uw onderzoek, en ze zullen stoppen met luisteren nadat u twee of drie bevestigende bronnen hebt genoemd.Je focus zou in eerste instantie moeten liggen op het verkrijgen van afkoop om het probleem dat je ziet aan te pakken, niet noodzakelijkerwijs te bewijzen dat iemand anders ongelijk heeft of dat jij gelijk hebt. Dit is een maatschappelijk probleem, geen logisch probleem.

In een technologieleidersrol moet u al uw initiatieven koppelen aan bedrijfsdoelen, dus het belangrijkste om uw zaak voor te leggen aan leidinggevenden is wat de werk zal doen voor die doelstellingen. Omdat je ook als de nieuwe man wordt beschouwd, kun je niet verwachten dat mensen hun werk weggooien of snel in de pas lopen; je moet wat vertrouwen opbouwen door te bewijzen dat je kunt waarmaken. Als een zorg op lange termijn, in een leidende rol, moet u ook leren om gefocust te raken op resultaten, maar niet noodzakelijk gehecht te zijn aan de specifieke kenmerken van de uitkomst. U bent er nu om strategische richting te geven, tactische obstakels voor de voortgang van uw team te verwijderen en uw team mentorschap aan te bieden, geen geloofwaardigheidsgevechten te winnen met uw eigen teamleden.

Het nemen van een top-down beslissing zal wees zelden geloofwaardig, tenzij je wat huid in het spel hebt; als je je helemaal opnieuw in een vergelijkbare situatie bevindt, moet je je meer richten op het opbouwen van consensus binnen je organisatie in plaats van te escaleren zodra je voelt dat de situatie niet meer onder controle is.

Maar gezien waar je nu bent, zou ik zeggen dat je het beste kunt beweren dat je aanpak meetbare langetermijnvoordelen oplevert op basis van je ervaring en dat het in overeenstemming is met het werk van bekende beoefenaars zoals oom Bob en co., en dat je graag een paar dagen / weken het goede voorbeeld zou willen geven bij een beperkte refactoring van het hoogste waar voor je geld-aspect, om te laten zien hoe jouw kijk op goed design eruit zou moeten zien. U zult echter, wat uw zaak ook is, moeten afstemmen op specifieke bedrijfsdoelen die verder gaan dan uw persoonlijke voorkeuren.

Opmerkingen

• Goed punt dat het een sociaal probleem. Moet de reden zijn waarom er zo veel slecht geschreven code en slecht ontworpen applicaties zijn.
• +1 voor het koppelen aan ‘ business speak ‘ als zodanig; probeer het zo relevant mogelijk te maken voor uw publiek. Als u ‘ praat met leidinggevenden, doe praten over hoe de standaard van code een directe link heeft met onderhoud en prestaties, en bespreek hoe dit aansluit bij de algemene projectfinanciën, stabiliteit op de lange termijn, enzovoort. Het klinkt alsof jij ‘ zijn ingehuurd vanwege uw kennis; onthoud dit. (‘ word geen aftrekmanager die denkt hij weet het altijd het beste – maar in dit geval ‘ bent 100% correct.)
• +1 voor ” werkende code overtreft alle argumenten over theorie of goed ontwerp. ” Iets wat we vaak vergeten tijdens onze zoektocht voor perfecte code.
• Geweldig antwoord, veel wijsheid erin voor aspirant-teamleiders.

Ten eerste moet u laten zien dat elke meetbare organisatie best practices uit de branche moet toepassen. Zeggen dat “het gewoon voor ons werkt!” kan niet worden gemeten, noch in tijd noch in middelen, omdat het eenvoudigweg onvoorspelbaar is. Software engineering is net zo goed een wetenschap als alle andere wetenschapsgebieden, en deze concepten zijn bestudeerd, onderzocht, getest en gedocumenteerd.

1. de God Object is een antipatroon waarin staat dat

   In software-engineering is een antipatroon (of antipatroon) een patroon dat wordt gebruikt in sociale of zakelijke operaties of software-engineering dat vaak wordt gebruikt, maar in de praktijk ineffectief en / of contraproductief is.

2. In de Google IO-conferentie van 2009 werd dit onderwerp gedeeltelijk toegelicht toen de MVP patroon werd uitgelegd. Het is misschien niet relevant voor het God-object, maar het kan je wat munitie geven.

3. Ook is het gebruik van dit antipatroon in strijd met het principe van enkele verantwoordelijkheid in objectgeoriënteerde ontwerpen, dat stelt dat:

   elke klasse een enkele verantwoordelijkheid zou moeten hebben, en die verantwoordelijkheid zou volledig worden ingekapseld door de klas. Al zijn services moeten nauw aansluiten bij die verantwoordelijkheid.

4. De De blog Decaying Code spreekt ook over dit en zijn oplossing.

5. We kunnen niet praten over het principe van enkele verantwoordelijkheid zonder over object te praten koppeling .

   […] koppeling of afhankelijkheid is de mate waarin elke programmamodule afhankelijk is van elk een van de andere modules.

   Waar het hebben van een nauw gekoppeld systeem assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency. Een hoger niveau van objectkoppeling betekent minder samenhang, en vice versa. God-objecten zijn een goed voorbeeld van nauwe koppeling, omdat ze meer weten dan ze zouden moeten, en dus overbelast ze met verantwoordelijkheid, en zo de herbruikbaarheid van code aanzienlijk beperken.

6. Bij het ontwerpen van een complexe applicatie, eenvoud moet in je opkomen. Grote problemen moeten worden opgesplitst in kleinere, die gemakkelijker te beheren, testen en documenteren zijn. Dit geldt vooral voor een objectgeoriënteerd paradigma.

   Met dit argument gaan we terug naar het antipatroonargument, maar dit paradigma gaat helemaal over patronen, representatie van objecten in de echte wereld en, uiteindelijk, data inkapseling.

7. Je hebt gedeeltelijk gelijk als je zegt dat deze “goede praktijken” vaker voorkomen in klaslokalen. Ik heb echter wel leservaring op de universiteit (en sommige universiteiten) en ik zag deze principes alleen op universiteiten worden onderwezen, vooral in technische faculteiten. Dat is triest. Maar zoals bij elke goede gewoonte, leren degenen die ernaar streven zichzelf te verbeteren, gewoonlijk enkele basis ontwerppatronen , en uiteindelijk begrijpen ze hoe ze kunnen kammen tussen koppeling en samenhang.

   Wat ik meestal aan studenten leer, is dat het misschien lijkt meer inspanningen te vergen om goede programmeerstandaarden te gebruiken, maar het altijd loont op de lange termijn. Een goed voorbeeld is iemand die een programmeur vraagt om een sorteerfunctie te schrijven. De programmeur heeft twee keuzes; 1) schrijf een snelle bubbelsorteerfunctie (minder dan 5 minuten) die niet duurzaam zal zijn naarmate de lijst met elementen groeit, of 2) schrijf een complexer (ook wel geoptimaliseerd) sorteeralgoritme (snel sorteren, enz.) Dat beter zal schalen met grotere lijsten.

Reacties

• Objectgeoriënteerde programmeertalen vereisen vaak dat als twee onafhankelijke bronassemblages verantwoordelijk zijn voor verschillende aspecten van het gedrag van een object ‘, zullen onafhankelijke objectinstanties moeten worden gemaakt om dat gedrag in te kapselen. Helaas, hoewel in veel gevallen de meest logische onderverdelingen van functionaliteit tussen code-assemblys niet ‘ t samenvallen met de meest logische onderverdeling van functionaliteit tussen objectinstanties, I ‘ heb niet veel discussie gezien over het onderscheiden van de twee soorten onderverdelingen.
• Ik denk dat dit een beetje buiten het onderwerp valt voor deze vraag. We ‘ hebben het hier niet over het God Object antipatroon, maar over codekoppeling en samenhang, wat een veel breed onderwerp is en zeer subjectief.

Oh alsjeblieft, necro nog een oude vraag maar ik denk dat je dit argument niet gewonnen hebt en hier is het waarom.

Het klinkt als een cultuurprobleem

Jij bent hun manager, maar je kunt ze niet vervangen en je moet naar je managers gaan om ze te laten doen wat je denkt dat ze zouden moeten doen. In dit geval neem ik aan dat je het op zijn minst afslaat terwijl de goddelijke objecten vooruit gaan. Het klinkt voor mij als een klassiek geval van code die de cultuur weerspiegelt waarin het is geboren. Met andere woorden, het goddelijke object is hoe dit bedrijf werkt. Wil je een zinvolle verandering aanbrengen? Je gaat er altijd voor naar dezelfde plek. uiteindelijk omdat alle beslissingen blijkbaar bovenaan moeten worden goedgekeurd.

Having been p rivaliseren met meerdere mislukte pogingen om legacy code op te schonen en codebeleid te veranderen Ik ben nu van mening dat je niet kunt vechten tegen de cultuur die de code mogelijk heeft gemaakt in de eerste plaats als die cultuur nog stevig verankerd is of op zijn minst vechtcultuur een zeer moeilijke bergopwaartse ploetering dat het onwaarschijnlijk is dat iemand me ooit genoeg zou kunnen betalen of me genoeg kracht zou kunnen geven om het gevoel te hebben dat het een waardevolle onderneming was die waarschijnlijk ooit weer zou slagen.

Voordat er verandering kan komen, ze moeten gemotiveerd zijn om te veranderen en helaas, als programmeurs die er genoeg van geven om Stack af en toe te lezen, is het moeilijk voor ons te begrijpen dat niet iedereen door hetzelfde gedreven wordt. Ik heb in mijn ervaringen veel van de rationele argumenten gewonnen, maar aan het eind van de dag lijdt het bedrijf om een reden met intellectueel luie ontwikkelaars.

Misschien zijn de zakelijke zorgen gemotiveerd om alleen aan morgen te denken in plaats van volgende week of over vijf jaar (een bijzonder frustrerend scenario als je het kind bent van immigranten uit een land dat in het geval van een apocalyps een zaadkelder in het noordpoolgebied heeft gebouwd). Misschien zijn ze bang voor verandering.Misschien hechten ze veel waarde aan anciënniteit tot het punt dat de commandostructuur zinloos is, zelfs als ze van buitenaf moeten inhuren om een ontwikkelaarsteamleider of manager in te schakelen, omdat ze erkennen dat niemand in hun all-lifer-team genoeg is gegroeid in hun tijd daar (of omdat die lifers het risico van verantwoordelijkheid niet willen). Of, en ik heb dit gezien, misschien is het het zeer reële en deprimerende fenomeen van middelmatigheid die zichzelf verdedigt omdat het diep van binnen weet dat het kan. t concurreren met kwaliteit en als er genoeg gekkigheid is om rond te lopen, is het onmogelijk om erachter te komen wie de schuldige is als alles regelmatig kapot gaat.

Hoe vecht je tegen problemen die uiteindelijk zijn geworteld in angst of gebroken statistieken voor succes? Ik zal je dit vertellen, er is veel meer voor nodig dan zelfs een toegewijd ontwikkelaarsteam van hoge kwaliteit en je had veel minder dan dat van het geluid toen deze Q werd gepost.

In de niet onmogelijke gebeurtenis dat het geen hardnekkig cultuurprobleem is …

Neem nu aan dat mensen bovenaan staan zijn erg ontvankelijk voor verandering, en ze zijn eigenlijk bereid erop te vertrouwen dat u het haalt, u hoeft eigenlijk alleen al uw argumenten te onderstrepen met geld en gemiste kansen.

Elke keer duurt het langer om iemand op te leiden nieuw op deze belachelijke codebase, elke keer dat het langer duurt om iets te wijzigen of een nieuwe functie aan iets toe te voegen, elke keer dat het onbetaalbaar moeilijk wordt om eindpunten bloot te stellen aan een ander systeem van een bedrijf waarmee je wilt samenwerken, kost het geld. geld verdienen. Het belangrijkste is dat het een venster openlaat voor een kleinere, meer behendige concurrent om naar binnen te duiken, waardoor u in een positie komt waarin u alleen veel te traag op hen kunt reageren. wly, en ruk het uiteindelijk allemaal van je weg.

Bedenk gewoon dat een bijzonder koppige en domme cultuur koste wat het kost de status quo zal behouden, zelfs als het fysieke dak van het bedrijf in feite in brand staat, want ervan.

Opmerkingen

• Ik verliet het bedrijf kort daarna. ze probeerden me fulltime in dienst te nemen en me vanuit Seattle naar New York te laten verhuizen om het aanbod te accepteren; Ik heb ze eigenlijk gezegd ” Echt niet, ik ‘ zou niet naar New York verhuizen als het team dat ik zou leiden in Bellevue is, WA ” en op dat punt liep ik eigenlijk de straat over en kreeg ik een baan bij MSFT totdat ik iets beters vond.
• @honestduane Ja, die set van verwachtingen alleen spreekt boekdelen. Goed voor je op de GTFO.

Je zou enkele van de meest elementaire OOP-principes kunnen noemen, zoals losse koppeling en hoge cohesie. Een “God-object” klinkt alsof het niet-verwante klassen koppelt en weinig samenhang heeft.

Je kunt het altijd aan oom Bob zelf vragen .

Het punt is, het is zo duidelijk voor mensen met enig gevoel dat als het eenmaal is gespeld, het niet opnieuw hoeft te worden gerefereerd door een groot aantal auteurs. Er hoeft alleen maar één bron.

Andere termen waarmee u misschien wilt beginnen bij het zoeken naar bronnen zijn:

• SOLID
• Law of Demeter
• Big Ball of Mud

Al deze uitdrukkelijke gerelateerde concepten die levensvatbare referentiebronnen kunnen opleveren, ook al noemen ze het eigenlijk niet zo.

Uiteindelijk u bent echter de baas. De reden hiervoor is dat u het zegt, en hoewel u, om als een goede manager te worden beschouwd, echt bereid moet zijn om uw beslissingen te rechtvaardigen; dat heeft u gedaan, en als er nog steeds weerstand is, de juiste manier van handelen is dat uw team doet wat ze “wordt opgedragen.

Opmerkingen

• ” als er nog steeds weerstand is, is de juiste handelwijze dat uw team doet wat ze ‘ hebben verteld ” Misschien is het juist om te stoppen in plaats van je team ellendig te maken ..?
• De manager ‘ s beslissing is voldoende gerechtvaardigd, en als het team het niet eens is ‘, dan ligt het probleem bij het team. Het OP werd ingehuurd vanwege zijn expertise en mocht het niet gebruiken om het bedrijf ten goede te komen omdat collegas hebben gewonnen ‘ zich niet redelijk te gedragen is niet ‘ t aanvaardbaar. Laat ‘ uw bewering op zijn kop zetten – waarom zouden ‘ t de resistente teamleden stoppen als hun mening over de baan onverenigbaar is met dat van het bedrijf?
• Eerlijk punt. Het hangt ervan af hoe u het team wilt leiden. Maar in mijn ervaring leidt het dwingen van mensen om dingen tegen hun wil te doen, gewoon tot ellende. Ik zou liever God Objects in de hele codebasis zien dan een ellendig ontwikkelingsteam. Misschien is het antwoord om ze op training te sturen. Iedereen houdt van een opleiding. Win-win.
• De hoofdontwikkelaar / manager / wat dan ook moet absoluut alle redelijke maatregelen nemen om ervoor te zorgen dat het team een goede werkrelatie met elkaar behoudt. Als aanvullende training nuttig is, beschouw het dan in elk geval als een optie – maar dit lijkt een geval van opzettelijke onwetendheid en iemand vertellen dat ze moeten worden opgeleid om uw idee te begrijpen wanneer wat ze denken dat ze ‘ als je het niet eens bent, eerder dan het niet begrijpt, kan het averechts werken. Ik vind het moeilijk om me manieren voor te stellen om met mensen om te gaan die niet ‘ willen leren.

Hoe kan ik bewijzen of weerleggen dat “god” -objecten fout zijn?

Dat kan niet.

Dit soort vermoeden is niet vatbaar voor wiskundig bewijs, en wiskundig bewijs is het enige soort bewijs dat klopt.

Zelfs als je probeert het emotionele woord fout te vervangen met kwantificeerbare metingen van de effecten van het gebruik van god-objecten, zul je ontdekken dat:

1. de beschikbare metingen grof zijn,
2. er weinig geloofwaardige studies zijn waarin die metingen zijn gekwantificeerd voor code geproduceerd door professionele programmeurs
3. er zijn weinig of geen geloofwaardige studies waarin taalconstructies of ontwerp (anti-) patronen zijn gekoppeld aan die maatregelen.

En dat negeert de kwestie van beslissen wanneer een bepaald object een “god” -object is.

In het beste geval konden dit soort onderzoeken alleen een empirische correlatie aantonen. Geen echt bewijs.

Wat je eigenlijk doet, is debatteren over de voor- en nadelen van “god” -objecten met het oog op het veranderen van de “ mening van andere mensen … en dan de praktijk van uw organisatie.

Gebruik geen woorden als bewijs, want de mensen met wie u debatteert, zullen u uitlachen.

Misschien wil je goeroe van de week # 84 zien . Het gaat allemaal om god-objecten (monolieten) en hoe ze slecht zijn.

Extract:

(Major) Het isoleert potentieel onafhankelijke functionaliteit binnen een klasse […] (Minor) Het kan het uitbreiden van de klasse met nieuwe functionaliteit […]