Hur bevisar eller motbeviser jag “ Guds objekt ” är fel?

Fallet för varje förändring av praxis görs genom att identifiera smärtpunkterna skapad av den befintliga designen. Specifikt måste du identifiera vad som är svårare än det borde vara på grund av den befintliga designen, vad som är ömtåligt, vad som går sönder nu, vilka beteenden som inte kan implementeras på ett enkelt sätt som ett direkt (eller till och med något indirekt) resultat av den aktuella implementeringen, eller, i vissa fall, hur prestandan lider, hur mycket tid det tar för att få en ny teammedlem att komma igång osv.

För det andra trumpar arbetskoden alla argument om teori eller bra design Detta är sant även för dålig kod, tyvärr. Så du kommer att behöva erbjuda ett bättre alternativ, vilket innebär att du som förespråkare för bättre mönster och praxis kommer att behöva reflektera för att reta ut en bättre design. Hitta ett smalt, tracer-bullet-stilplan genom den befintliga designen och implementera en lösning som, kanske, för iteration en, håller implementeringen av gudobjektet fungerande, men ställer faktisk implementering till den nya designen. Skriv sedan lite kod som utnyttjar den här nya designen och visa upp vad du vinner på grund av denna förändring, oavsett om det är prestanda, underhåll, funktioner, korrigering av buggar eller rasförhållanden eller minskning av kognitiv belastning för utvecklaren. / p>

Det är ofta en utmaning att hitta en tillräckligt liten yta för att attackera i dåligt arkitekterade system, det kan ta längre tid än du vill ge ett initialt värde, och den initiala utdelningen kanske inte är så imponerande till alla, men du kan också arbeta med att hitta några förespråkare för ditt nya tillvägagångssätt om du kopplar ihop det med teammedlemmar som är åtminstone något sympatiska.

Att klaga på Guds objekt fungerar bara när du predikar för kören. Det är ett verktyg för att namnge ett problem och fungerar bara för att lösa det när du har en mottaglig publik som är äldre och motiverad nog för att göra något åt det. Att fixa Guds objekt vinner argumentet.

Eftersom din omedelbara oro verkar vara verkställande inköp tror jag att du är bäst att göra ett ärende om att ersättning av denna kod måste vara ett strategiskt mål och knyta dem till de affärsmål som du är ansvarig för. Jag tror att du kan göra gällande att du kan ge en viss teknisk vägledning genom att först arbeta med en teknisk spik på vad du tycker ska göras för att ersätta den, helst involvera resurser från en eller två tekniska personer som har förbehåll för den aktuella designen.

Jag tror att du har hittat tillräckligt med resurser för att motivera ditt argument. människor i sådana möten kommer bara att uppmärksamma sammanfattningen av din forskning, och de slutar lyssna efter att du nämnt två eller tre bekräftande källor.Ditt fokus bör inledningsvis vara att få buy-off för att lösa problemet du ser, inte nödvändigtvis bevisa någon annan fel eller dig själv rätt. Detta är ett socialt problem, inte ett logiskt problem.

I en teknikledande roll måste du knyta något av dina initiativ till affärsmålen, så det viktigaste för att göra ditt ärende till chefer är vad arbete kommer att göra för dessa mål. Eftersom du också betraktades som den ”nya killen” kan du inte bara förvänta dig att människor ska kasta bort sitt arbete eller förvänta sig att snabbt falla i linje; du måste bygga lite förtroende genom att bevisa att du kan leverera. Som en långsiktig fråga, i en ledarroll, måste du också lära dig att bli fokuserad på resultat, men inte nödvändigtvis vara kopplad till resultatet av resultatet. Du är nu där för att ge strategisk vägledning, ta bort taktiska hinder från ditt team och erbjuda ditt team mentorskap, inte vinna trovärdighetsslag med dina egna teammedlemmar.

Att fatta ett beslut från början och ner kommer att var sällan trovärdig om du inte har lite hud i spelet. Om du befinner dig i en liknande situation om igen bör du fokusera mer på konsensusuppbyggnad i din organisation snarare än att eskalera när du känner att situationen är utom kontroll.

Men med tanke på var du är nu, skulle jag säga att det bästa är att argumentera för att ditt tillvägagångssätt kommer att ge mätbara långsiktiga fördelar baserat på din erfarenhet och att det är i linje med arbetet av välkända utövare som farbror Bob och co., och att du ”vill spendera några dagar / veckor med gott exempel på en smal refactoring av den högsta bang-for-buck aspekten, för att visa hur din syn på bra design ska se ut. Du måste dock anpassa vad som än är fallet till specifika affärsmål utan dina personliga preferenser.

Kommentarer

• Bra poäng om att det är en socialt problem. Det måste vara anledningen till att det finns så mycket dålig skriven kod och dåligt utformade applikationer där ute.
• +1 för att koppla in den med ’ business speak ’ som sådan; sträva efter att göra det så relevant för din publik som möjligt. Om du ’ pratar med chefer så gör prata om hur standarden för kod har en direkt koppling till underhåll och prestanda, och diskutera hur detta hänger samman med projektets totala ekonomi, långsiktiga stabilitet och så vidare. Det låter som du ’ har anställts på grund av din kunskap. Kom ihåg det här. (Bara ’ t bli en jerk-off manager som tycker han vet alltid bäst – men i detta fall är du ’ 100% korrekt.)
• +1 för ” arbetskod trumpar alla argument om teori eller bra design. ” Något vi ofta glömmer i vår strävan för perfekt kod.
• Bra svar, mycket visdom där inne för blivande teamledare.

Först måste du presentera att varje mätbar organisation måste anta branschens bästa praxis. Att säga att ”det fungerar bara för oss!” kan inte mätas, varken i tid eller i resurs eftersom det helt enkelt är oförutsägbart. Programvaruteknik är en vetenskap lika mycket som alla andra vetenskapsområden, och dessa begrepp har studerats, undersökts, testats och dokumenterats.

1. Guds objekt är ett antimönster som säger att

   Inom programvaruteknik är ett antimönster (eller antipattern) ett mönster som används i social eller affärsverksamhet eller mjukvaruteknik som ofta kan användas men är ineffektivt och / eller kontraproduktivt i praktiken.

2. I Google IO-konferensen 2009 förklarades detta ämne delvis när MVP mönster förklarades. Det kanske inte är relevant för Guds objekt, men kan ge dig lite ammunition.

3. Att bryta mot detta mönster bryter också mot enhetsprincip i objektorienterade mönster, som säger att:

   varje klass ska ha ett enda ansvar, och att ansvaret bör vara helt inkapslad av klassen. Alla dess tjänster bör vara snävt anpassade till det ansvaret.

4. Ruttnande kod -bloggen talar också om detta och om den lösning.

5. Vi kan inte prata om principen om enskilt ansvar utan att prata om objekt koppling .

   […] koppling eller beroende är i vilken grad varje programmodul bygger på varje en av de andra modulerna.

   Om ett tätt kopplat system kan orsaka assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency. En högre nivå av objektkoppling betyder mindre sammanhållning och vice versa. Gudobjekt är ett bra exempel på tät koppling eftersom de vet mer än de borde, vilket överbelastar dem med ansvar, vilket begränsar kraftigt återanvändbarhet.

6. När du utformar en komplex applikation, enkelhet måste komma ihåg. Stora problem måste sönderdelas i mindre, som är lättare att hantera, testa och dokumentera. Detta är särskilt sant i ett objektorienterat paradigm.

   Med detta argument slingrar vi oss tillbaka mot antimönsterargumentet, men detta paradigm handlar om mönster, verklig objektrepresentation och, slutligen, data inkapsling.

7. Du har rätt när du säger att dessa ”goda metoder” finns mer i klassrummen. Jag har dock undervisningserfarenheter på college (och på vissa universitet) och jag såg bara dessa principer undervisas vid universitet, särskilt inom ingenjörsfakulteter. Vilket är sorgligt. Men som alla goda praxis lär de som strävar efter att förbättra sig själva vanligtvis några grundläggande designmönster och förstår så småningom hur man djunglar mellan koppling och sammanhållning.

   Det jag brukar lära eleverna är att det kanske verkar kräva fler ansträngningar för att anta bra programmeringsstandarder, men det alltid lönar sig på lång sikt. Ett bra exempel skulle vara någon som ber en programmerare att skriva en sorteringsfunktion. Programmeraren har två val; 1) skriv en snabb bubbelsorteringsfunktion (mindre än 5 minuter) som inte kommer att vara hållbar när listan över element växer, eller 2) skriva en mer komplex (aka optimerad) sorteringsalgoritm (snabb sortering etc.) som ska skalas bättre med större listor.

Kommentarer

• Objektorienterade programmeringsspråk kräver ofta att två oberoende källaggregat är ansvariga för olika aspekter av ett objekts ’ -beteende måste oberoende objektinstanser skapas för att inkapsla dessa beteenden. Tyvärr, även om de mest logiska indelningarna av funktionalitet mellan kodaggregat i många fall inte ’ inte sammanfaller med den mest logiska indelningen av funktionalitet mellan objektinstanser, så ’ har inte sett mycket diskussion om att skilja mellan de två typerna av indelning.
• Jag tror att det här är lite av ämnet för denna fråga. Vi ’ talar inte här om Guds objekt mot mönster, utan kodkoppling och sammanhållning, vilket är ett mycket brett ämne och mycket subjektivt.

Åh här går jag, necroing en annan gammal fråga men jag kommer att gissa att du inte vann detta argument och här ”s varför.

Det låter som ett kulturproblem

Du är deras chef men du kan inte ersätta dem och du måste gå till dina chefer för att få dem att göra vad du tror att de borde göra, vilket i det här fallet antar jag är att åtminstone slå av det med gudobjekten framåt. Det låter för mig som ett klassiskt fall av kod som speglar kulturen den föddes i. Med andra ord är gudobjektet hur detta företag fungerar. Vill du göra någon form av meningsfull förändring? Du går alltid till samma plats för det i slutändan eftersom alla beslut tydligen måste rensas högst upp.

Har varit s bero på flera misslyckade försök till äldre kodrensningar och kodpolicyändringar Jag är nu av den uppfattningen att du inte kan bekämpa kulturen som möjliggjorde koden i första hand när den kulturen fortfarande är fast förankrad eller åtminstone är kampkulturen en mycket hård uppförsbacke att det är osannolikt att någon någonsin skulle kunna betala mig tillräckligt eller ge mig tillräckligt med kraft för att känna att det var ett värdefullt arbete som sannolikt skulle lyckas någonsin igen.

Innan det kan bli förändring, de måste vara motiverade att förändras och tyvärr som programmerare som ger tillräckligt med att läsa Stack ibland är det svårt för oss att förstå att inte alla motiveras av samma saker. Jag har vunnit många av de rationella argumenten i mina upplevelser men i slutet av dagen lider företaget av intellektuella lata anledningar av en anledning. nästa vecka eller fem år ute (ett särskilt frustrerande scenario när du är barn till invandrare från ett land som byggde ett frövalv i Arktis vid apokalyps). Kanske är de rädda för förändring.Kanske värdesätter de senioritet alltför mycket till att kommandokedjan är meningslös även när de måste anställa utifrån för att få in en teamledare eller chef för att de känner igen att ingen i deras all-lifer-team har vuxit nog i sin tid där (eller för att nämnda livsstilar inte vill ha den risk som är förknippad med ansvar). Eller, och jag har sett detta, kanske är det det mycket verkliga och deprimerande fenomenet medelmåttighet som kämpar för sig själv eftersom det vet inifrån att det kan ” tävla med kvalitet och när det finns tillräckligt med tomfoolery för att gå runt är det omöjligt att räkna ut vem som ska skylla på när allt regelbundet går i bitar.

Hur bekämpar man frågor som i slutändan är rotade i rädsla eller trasiga mätvärden för framgång? Jag kommer att säga dig det, det tar mycket mer än till och med ett engagerat kvalitetsutvecklingslag och du hade mycket mindre än det från ljudet vid den tid då denna Q publicerades.

I det omöjliga händelsen att det inte är ett otroligt kulturproblem …

Nu antar vi att människor högst upp är väldigt mottagliga för förändring, och de är faktiskt villiga att lita på dig för att göra det, du behöver egentligen bara punktera alla dina argument med pengar och förlorade möjligheter.

Varje gång det tar längre tid att träna någon nyhet på denna löjliga kodbas, varje gång det tar längre tid att modifiera eller lägga till en ny funktion till något, varje gång det blir oerhört svårt att exponera slutpunkter för ett annat system från ett företag som du vill samarbeta med, kostar det pengar. freaking money. Viktigast är att det lämnar ett fönster öppet för en mindre smidigare konkurrent att sopa in, placera dig i en position där allt du kan göra är att reagera på dem alldeles för slo och slutligen ta bort allt från dig.

Inse bara att en särskilt envis och dum kultur kommer att upprätthålla status quo till varje pris även om företagets faktiska fysiska tak faktiskt är i brand av det.

Kommentarer

• Jag lämnade företaget strax efter. de försökte anställa mig på heltid och få mig att flytta till NY från Seattle för att acceptera erbjudandet. Jag sa i grund och botten till dem ” Inget sätt, jag ’ kommer inte att flytta till NY när laget jag skulle hantera är i Bellevue, WA ” och då gick jag i princip över gatan och fick jobb på MSFT tills jag hittade något bättre.
• @honestduane Ja, den uppsättningen förväntningar ensam talar volymer. Bra för dig på GTFO.

Du kan citera några av de mest grundläggande OOP-principerna som t.ex. lös koppling och hög sammanhållning. Ett ”Gudobjekt” låter som om det kopplar ihop orelaterade klasser och har låg sammanhållning.

Du kan alltid fråga farbror Bob själv .

Saken är att den är så uppenbar för människor med någon mening att när den väl stavats behöver den inte hänvisas till av en mängd författare. Det behöver bara finnas en källa.

Andra termer du kanske vill börja med när du letar efter källor är:

• SOLID
• Demeter Law
• Big Ball of Mud

Alla dessa uttrycksrelaterade begrepp som kan ge livskraftiga referenskällor, även om de inte egentligen heter det som sådant.

I slutändan Men du är chef. Anledningen till att du gör det är för att du säger det, och även om du bör betraktas som en bra chef bör du vara beredd att motivera dina beslut. Du har gjort det och om det fortfarande finns motstånd, rätt handlingssätt är att ditt team ska göra som de får veta.

Kommentarer

• ” om det fortfarande finns motstånd är det rätta för ditt team att göra som de ’ får höra ” Det kanske är rätt sätt att sluta snarare än att göra ditt team eländigt ..?
• Chefen ’ s beslutet har motiverats tillräckligt, och om laget inte ’ inte håller med, så är problemet med laget. OP anställdes för sin expertis och inte fick använda den för att gynna verksamheten eftersom kollegor vann ’ t beter sig rimligt är inte ’ t godtagbar. Låt ’ s vända ditt påstående på huvudet – varför ska inte ’ t de motståndande lagmedlemmarna sluta om deras syn på jobbet är oförenligt med det för verksamheten?
• Rättvis poäng. Det beror på hur du vill driva laget. Men min erfarenhet av att tvinga människor att göra saker mot sin vilja leder bara till elände. Jag skulle hellre se Gudobjekt genom hela kodbasen än ett eländigt utvecklingsteam. Kanske är svaret att skicka dem på en utbildningskurs. Alla älskar en utbildning. Vinn-vinn.
• Huvudutvecklaren / chefen / vad som helst borde absolut vidta alla rimliga åtgärder för att säkerställa att teamet behåller ett bra samarbete med varandra. Om ytterligare utbildning är till hjälp, så anser du det i alla fall som ett alternativ – men det verkar vara som ett fall av avsiktlig okunnighet och berätta för någon att de behöver utbildas för att förstå din idé när vad de tror att de ’ har gjort är oense, snarare än att inte förstå, skulle kunna slå tillbaka. Jag har svårt att föreställa mig sätt att hantera människor som inte ’ inte vill lära sig.

Hur kan jag bevisa eller motbevisa att ”gud” -objekt är fel?

Du kan inte.

Denna typ av gissningar är inte mottagliga för matematiska bevis, och matematiska bevis är den enda typen av bevis som är sund.

Även om du försöker ersätta det känslomässiga ordet ”fel” med kvantifierbara mått på effekterna av att använda gudobjekt kommer du att finna att:

1. de tillgängliga måtten är råa,
2. det finns få trovärdiga studier där dessa mått har kvantifierats för kod som produceras av professionella programmerare
3. det finns få om några trovärdiga studier där språkkonstruktioner eller design (anti-) mönster har kopplats till dessa åtgärder.

Och det ignorerar frågan om att bestämma när ett visst objekt är ett ”gud” -objekt.

I bästa fall kunde dessa typer av studier endast visa en empirisk korrelation. Inte ett genuint bevis.

Vad du faktiskt gör är att debattera fördelarna och nackdelarna med ”gud” -objekt i syfte att ändra andra folks ” åsikter … och sedan använder din organisation.

Använd inte ord som ”bevis” eller de personer du diskuterar med kan skratta i ditt ansikte.

Du kanske vill se Veckans guru # 84 . Det handlar om gudobjekt (monoliter) och hur de är dåliga.

Extrahera:

(Major) Det isolerar potentiellt oberoende funktionalitet i en klass […] (Mindre) Det kan avskräcka att utvidga klassen med ny funktionalitet […]

Jag är inte säker på om ditt team verkligen är intresserad av akademiska bevis på att ”Gud motsätter sig fel”.

Ur ett psykologiskt perspektiv kan din refaktoreringsprocess missförstås som angrepp på lagets kompetens a la: ”laget har gjort ett dåligt jobb” även om programmet fungerar som förväntat.

Vad du verkligen vill göra är att hantera de negativa biverkningarna av ”spagettikod” och ”Guds objekt”: explodig kostar att lägga till nya funktioner på grund av ökande buggar orsakade av biverkningar.

Bee mycket specifika och ställa frågor istället för att ge svar kan vara mer användbara:

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