Problemoversigt:

Lang historie kort, jeg arvede en kodebase og et udviklingsteam, som jeg ikke har lov til at erstatte, og brugen af God Objects er et stort problem. Fremadrettet vil jeg have os til at re-faktorere ting, men jeg får push-back fra de hold, der ønsker at gøre alt sammen med Guds objekter “fordi det er lettere”, og det betyder, at jeg ikke får lov til at re-faktorere. Jeg skubbede tilbage med henvisning til mine mange års udviklingserfaring, at jeg er den nye chef, der blev hyret til at kende disse ting osv. Og det samme gjorde tredjeparts offshore-selskaber med salgssalg, og dette er nu på ledelsesniveau og mit møde er i morgen, og jeg vil gå ind med en masse teknisk ammunition for at gå ind for bedste praksis, fordi jeg føler, at det vil være billigere i det lange løb (og jeg føler personligt, at det er det, tredjemand er bekymret for) for virksomheden. p>

Mit problem er fra et teknisk niveau, jeg ved, at det er godt på lang sigt, men jeg har problemer med ultra kort sigt og 6 måneders sigt, og mens det er noget, jeg “ved”, kan jeg ikke bevise det med referencer og citerede ressourcer uden for en person (Robert C. Martin, alias onkel Bob), da det er det, jeg bliver bedt om at gøre, som jeg har fået at vide at have data fra en person og kun en person (Robert C Martin) ikke er godt nok af et argument.

Spørgsmål:

Hvad er som De ressourcer, jeg kan citere direkte (titel, offentliggjort år, sidetal, citat) af velkendte eksperter inden for området, der udtrykkeligt siger, at denne brug af “Gud” objekter / klasser / systemer er dårlig (eller god, da vi leder efter mest teknisk gyldige løsning)?

Forskning, jeg allerede har gjort:

  1. Jeg har et antal bøger her, og jeg har søgt i deres indekser efter brugen af ordene “god object” og “god class”. Jeg fandt ud af, at det mærkeligt er, at det næsten aldrig er brugt, og kopien af GoF-bogen, jeg har, for eksempel, bruger den aldrig (I det mindste i henhold til indekset foran mig), men jeg har fundet den i de to bøger nedenfor, men jeg vil have mere Jeg kan bruge.
  2. Jeg tjekkede Wikipedia-siden for “Guds objekt” , og den er i øjeblikket en stub med få referencelinks, selvom jeg personligt er enig i, at der står, at den ikke har meget, jeg kan bruge i et miljø, hvor personlig oplevelse ikke betragtes som gyldig. Den citerede bog betragtes også som for gammel til at være gyldig af de mennesker, jeg diskuterer disse tekniske punkter med som argument de laver er, at “det engang blev anset for at være dårligt, men ingen kunne bevise det, og nu siger moderne software” gud “objekter er gode at bruge”. Jeg mener personligt, at denne påstand er forkert, men jeg vil bevise sandheden , uanset hvad det er.
  3. I Robert C Martin “s” Agile Principles, Patterns, and Practices in C # “(ISBN: 0-13-185725-8, hardcover) whe re på side 266 står der “Alle ved, at gudsklasser er en dårlig idé. Vi ønsker ikke at koncentrere al systemets intelligens i et enkelt objekt eller en enkelt funktion. Et af målene med OOD er opdeling og distribution af adfærd i mange klasser og mange funktioner. ” – Og derefter fortsætter med at sige, at det undertiden er bedre at bruge Gudsklasser alligevel nogle gange (citerer mikrokontroller som et eksempel).
  4. I Robert C Martin “s” Clean Code: A Handbook of Agile Software Craftsmanship “side 136 (og kun denne side) taler om” Gudsklassen “og kalder det som et godt eksempel på en krænkelse af” klasser skal være lille “-regel, som han bruger til at fremme princippet om et enkelt ansvar” startende på side 138 .

Det problem, jeg har, er, at alle mine referencer og citater kommer fra den samme person (Robert C. Martin) og kommer fra den samme person / kilde. Jeg får at vide, at fordi han kun er et synspunkt, er mit ønske om ikke at bruge “God Classes” ugyldigt og accepteres ikke som en standard bedste praksis i softwareindustrien. Er det sandt? Gør jeg tingene forkert fra et teknisk perspektiv ved at forsøge at holde mig til onkel Bobs lære?

Gud objekter og objektorienteret programmering og design:

Jo mere jeg tænker på dette, jo mere tror jeg, det er mere noget, du lærer, når du studerer OOP, og det bliver aldrig eksplicit kaldt; det er implicit til godt design er min tænkning (du er velkommen til at rette mig, som jeg vil lære), problemet er, at jeg “ved” dette, men ikke alle gør det, så i dette tilfælde betragtes det ikke som et gyldigt argument, fordi jeg effektivt ringer det ud som en universel sandhed, når de fleste faktisk er statistisk uvidende om det, da de fleste statistisk set ikke er programmører.

Konklusion:

Jeg er vild med hvad jeg skal søge efter for at få de bedste yderligere resultater at citere, da de fremsætter en teknisk påstand, og jeg vil vide sandheden og være i stand til at bevise det med citater som en rigtig ingeniør / videnskabsmand, selvom jeg er partisk mod gudsgenstande på grund af min personlige erfaring med kode, der brugte dem. Enhver hjælp eller citater vil blive dybt værdsat.

Kommentarer

  • Bed dem om dokumentation af Guds objekter som god praksis.
  • Løb væk! Du vil ikke ‘ ikke arbejde der.
  • Definér venligst din forståelse af ” Guds objekt ” og hvordan det relaterer til dit spørgsmål. Du bruger 4 afsnit på at sige, at God Class ikke er ‘ t et standardudtryk i litteraturen. Så hvorfor bruger du det? Hvis du bruger industristandardbetingelser og kan vise, hvordan disse begreber gælder for dit nuværende projekt, kan du muligvis overbevise nogle mennesker om dit punkt. Brug af sammensatte ord på et forretningsmøde vil kun undergrave dit argument. Der findes industristandardbetingelser – du er ‘ t den første person, der nogensinde ser et alt-er-globalt eller mareridt med et enkelt objekt eller hvad du prøver at beskrive.
  • Du ‘ mangler udtrykket ” antipattern “. At foretage en Google-søgning efter ” antipattern for gudsobjekt ” returnerer tons sider om grunde til, at de ‘ er dårligt.
  • Du bør ikke ‘ ikke angribe gudobjektet, men de problemer, det skaber. Ligesom: vi har meget tæt kobling mellem alt, og en ændring i A kræver også ændringer i B, C og D. Så for at hjælpe imod det ‘ vil vi udtrække klasser. Eller: vi vil have koden i en testramme, og vi kan ‘ ikke gøre det, hvad skal vi gøre? Prøv også at undgå at bruge udtrykket ” Gud “, folk, der ikke er modtagelige, vil tro dig ‘ genbruger hyperboler.

Svar

Sagen for enhver ændring af praksis foretages ved at identificere smertepunkterne skabt af det eksisterende design. Specifikt skal du identificere, hvad der er sværere end det burde være på grund af det eksisterende design, hvad der er skrøbeligt, hvad der bryder nu, hvilken adfærd der ikke kan implementeres på en enkel måde som et direkte (eller endda noget indirekte) resultat af den nuværende implementering, eller i nogle tilfælde, hvordan ydeevne lider, hvor lang tid det tager at bringe et nyt teammedlem op på hastighed osv.

For det andet trumfer arbejdskode alle argumenter om teori eller godt design Dette gælder desværre selv for dårlig kode. Så du bliver nødt til at give et bedre alternativ, hvilket betyder, at du som talsmand for bedre mønstre og praksis bliver nødt til at reflektere for at drille et bedre design. Find et smalt tracer-bullet-stilplan gennem det eksisterende design, og implementer en løsning, der måske til iteration én holder gudobjektimplementeringen i gang, men afviger den faktiske implementering til det nye design. Skriv derefter en kode, der drager fordel af dette nye design, og vis hvad du vinder på grund af denne ændring, hvad enten det er ydeevne, vedligeholdelsesevne, funktioner, korrektion af fejl eller race betingelser eller reduktion af kognitiv belastning for udvikleren. / p>

Det er ofte en udfordring at finde et lille nok overfladeareal til at angribe i dårligt arkitekterede systemer. Det kan tage længere tid, end du gerne vil levere en startværdi, og den indledende udbetaling er muligvis ikke så imponerende til alle, men du kan også arbejde på at finde nogle fortalere for din nye tilgang, hvis du parrer den med teammedlemmer, der i det mindste er lidt sympatiske.

At beklage Guds objekt fungerer kun, når du forkynder for koret. Det er et værktøj til at navngive et problem og fungerer kun til at løse det, når du har et modtageligt publikum, der er ældre og motiveret nok til at gøre noget ved det. At rette Guds objekt vinder argumentet.

Da din umiddelbare bekymring ser ud til at være udøvende buy-in, tror jeg, at du bedst kan argumentere for, at udskiftning af denne kode skal være et strategisk mål og binde dem til de forretningsmål, som du er ansvarlig for. Jeg tror, du kan redegøre for, at du kan give en vis teknisk retning ved først at arbejde på en teknisk stigning i, hvad du mener, der skal gøres for at erstatte det, helst involverer ressourcer fra en eller to tekniske personer, der har forbehold over for det nuværende design.

Jeg tror, du har fundet nok ressourcer til at retfærdiggøre dit argument; mennesker på sådanne møder vil kun være opmærksomme på resuméet af din forskning, og de holder op med at lytte, når du har nævnt to eller tre bekræftende kilder.Dit fokus skulle oprindeligt være at få buy-off til at løse det problem, du ser, og ikke nødvendigvis bevise en anden forkert eller dig selv ret. Dette er et socialt problem, ikke et logisk.

I en teknologilederrolle skal du binde ethvert af dine initiativer til forretningsmål, så det vigtigste for at gøre din sag over for ledere er, hvad arbejde vil gøre for disse mål. Fordi du også betragtes som den “nye fyr”, kan du ikke bare forvente, at folk smider deres arbejde væk eller forventer hurtigt at falde i kø; du skal opbygge en vis tillid ved at bevise, at du kan levere. Som en langsigtet bekymring skal du i en ledende rolle også lære at blive fokuseret på resultater, men ikke nødvendigvis være knyttet til resultatet af resultatet. Du er nu der for at give strategisk retning, fjerne taktiske forhindringer fra dit teams fremskridt og tilbyde dit team mentorskab, ikke vinde troværdighedskampe med dine egne teammedlemmer.

At tage en top-down beslutning vil sjældent være troværdig, medmindre du har noget hud i spillet; hvis du er i en lignende situation igen, skal du fokusere mere på konsensusopbygning i din organisation i stedet for at eskalere, når du føler situationen er ude af kontrol.

Men i betragtning af hvor du er nu, vil jeg sige, at dit bedste valg er at argumentere for, at din tilgang vil give målbare langsigtede fordele baseret på din erfaring, og at det er i tråd med arbejdet fra velkendte praktikere som onkel Bob og co., og at du gerne vil tilbringe et par dage / uger med et godt eksempel på en snæver refactoring af det højeste bang-for-buck-aspekt for at demonstrere, hvordan dit syn på godt design skal se ud. Du bliver dog nødt til at tilpasse, hvad din sag er til bestemte forretningsmål ud over dine personlige præferencer.

Kommentarer

  • Godt ved, at det er en socialt problem. Må være grunden til, at der er så meget dårlig skrevet kode og dårligt designede applikationer derude.
  • +1 for at binde det ind med ‘ business speak ‘ som sådan; sigter mod at gøre det så relevant for dit publikum som muligt. Hvis du ‘ taler til ledere, så gør tale om, hvordan standard for kode har en direkte forbindelse med vedligeholdelse og ydeevne, og diskuter hvordan dette hænger sammen med den samlede projektfinansiering, langsigtet stabilitet og så videre. Det lyder som dig ‘ er ansat på grund af din viden. Husk dette. (Bare don ‘ t bliver en jerk-off manager, som mener han ved altid bedst – men i dette tilfælde er du ‘ 100% korrekt.)
  • +1 til ” arbejdskode trumfer ethvert argument om teori eller godt design. ” Noget vi ofte glemmer i vores søgen for perfekt kode.
  • Fantastisk svar, masser af visdom derinde for håbefulde teamledere.

Svar

Først skal du præsentere, at enhver målbar organisation har brug for at anvende branchens bedste praksis. At sige at “det virker bare for os!” kan ikke måles, hverken i tid eller i ressource, da det simpelthen er uforudsigeligt. Software engineering er så videnskabelig som alle andre videnskabelige områder, og disse begreber er blevet undersøgt, undersøgt, testet og dokumenteret.

  1. Guds objekt er et anti-mønster , der siger, at

    I softwareteknik er et antimønster (eller antipattern) et mønster, der bruges i social eller forretningsdrift eller softwareteknik, der ofte kan bruges, men som er ineffektivt og / eller kontraproduktivt i praksis.

  2. I Google IO-konferencen fra 2009 blev dette emne delvist forklaret, da MVP mønster blev forklaret. Det er muligvis ikke relevant for Guds objekt, men kan give dig noget ammunition.

  3. Brug af dette antimønster krænker også princip om enkelt ansvar i objektorienterede designs, der siger, at:

    hver klasse skal have et enkelt ansvar, og at ansvaret skal være helt indkapslet af klassen. Alle dets tjenester skal være snævert tilpasset dette ansvar.

  4. Råtnende kode blog taler også om dette og om dets løsning.

  5. Vi kan ikke tale om princippet om et enkelt ansvar uden at tale om objekt kobling .

    […] kobling eller afhængighed er den grad, som hvert programmodul er afhængig af hver et af de andre moduler.

    Hvor det at have et tæt koblet system kan forårsage assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency. Et højere niveau af objektkobling betyder mindre samhørighed, og omvendt. Guds objekter er et godt eksempel på tæt kobling, da de ved mere, end de burde, og overbelaster dem således med ansvar og begrænser således stærkt genanvendelighed af kode.

  6. Når du designer en kompleks applikation, enkelhed skal komme til at tænke på. Store problemer skal nedbrydes til mindre, som er lettere at styre, teste og dokumentere. Dette gælder især i et objektorienteret paradigme.

    Med dette argument løber vi tilbage til antimønsterargumentet, men dette paradigme handler om mønstre, repræsentation af den virkelige verden og ultimat data indkapsling.

  7. Du har ret i det, når du siger, at disse “god praksis” findes mere i klasselokaler. Imidlertid har jeg undervisningserfaringer på college (og nogle universiteter), og jeg så kun disse principper undervises på universiteter, især inden for ingeniørfakulteter. Hvilket er trist. Men som enhver god praksis lærer dem, der stræber efter at forbedre sig selv, normalt nogle grundlæggende designmønstre og til sidst forstår, hvordan de kan springe mellem kobling og samhørighed.

    Hvad jeg normalt lærer eleverne er, at det måske synes at kræve mere indsats for at vedtage gode programmeringsstandarder, men det altid lønner sig i det lange løb. Et godt eksempel ville være nogen, der beder en programmør om at skrive en sorteringsfunktion. Programmøren har to valg; 1) skriv en hurtig boblesorteringsfunktion (mindre end 5 minutter), der ikke er bæredygtig, da listen over elementer vokser, eller 2) skriv en mere kompleks (aka optimeret) sorteringsalgoritme (hurtig sortering osv.), Der skalerer bedre med større lister.

Kommentarer

  • Objektorienterede programmeringssprog kræver ofte, at hvis to uafhængige kildesamlinger er ansvarlige for forskellige aspekter af et objekts ‘ -adfærd skal der oprettes uafhængige objektforekomster for at indkapsle denne adfærd. Desværre, selvom de mest logiske underopdelinger af funktionalitet mellem kodesamlinger i mange tilfælde ikke ‘ ikke falder sammen med den mest logiske underopdeling af funktionalitet mellem objektforekomster, er jeg ‘ har ikke set meget diskussion om at skelne mellem de to slags underinddeling.
  • Jeg tror, det er lidt uden for emnet for dette spørgsmål. Vi ‘ taler ikke her om Guds objekt-anti-mønster, men kodekobling og samhørighed, som er et meget bredt emne og meget subjektivt.

Svar

Åh jeg går, necroing endnu et gammelt spørgsmål, men jeg vil gætte på, at du ikke vandt dette argument og her “s hvorfor.

Det lyder som et kulturproblem

Du er deres manager, men du kan ikke erstatte dem, og du er nødt til at gå til dine ledere for at få dem til at gøre, hvad du mener, de skal gøre, som i dette tilfælde antager jeg, at det i det mindste er at slå det af med gudens objekter bevæger sig fremad. Det lyder for mig som et klassisk tilfælde af kode, der afspejler den kultur, den blev født i. Med andre ord, gudobjektet er, hvordan dette firma fungerer. Vil du foretage nogen form for meningsfuld forandring? Du går altid til det samme sted for det i sidste ende, da alle beslutninger tilsyneladende skal ryddes øverst.

Efter at have været s forsøg på flere mislykkede forsøg på ældre kodeoprydninger og kodepolitiske ændringer Jeg er nu af den opfattelse, at du ikke kan bekæmpe den kultur, der muliggjorde koden i første omgang, når den kultur stadig er fast forankret eller i det mindste kampkamp er en meget hård opadgående slog, at det er usandsynligt, at nogen nogensinde kunne betale mig nok eller give mig kraft nok til at føle, at det var en god indsats, der sandsynligvis ville lykkes nogensinde igen.

Før der kan ske ændringer, de skal være motiverede til at ændre sig, og desværre er det som svært for programmerere, der giver nok af en fornemmelse at læse Stack, svært for os at forstå, at ikke alle er motiverede af de samme ting. Jeg har vundet masser af de rationelle argumenter i mine erfaringer, men i slutningen af dagen lider virksomheden intellektuelt dovne af en grund.

Måske har forretningsmæssige bekymringer været motiverede til kun at tænke på i morgen i stedet for næste uge eller fem år ud (et særligt frustrerende scenarie, når du er barn til indvandrere fra et land, der byggede et frøhvelv i Arktis i tilfælde af apokalypse). Måske er de bange for forandring.Måske værdsætter de anciennitet alt for meget til det punkt, at kommandokæden er meningsløs, selv når de er nødt til at ansætte udefra for at hente en dev teamleder eller manager, fordi de genkender ingen i deres all-lifer team er vokset nok i deres tid der (eller fordi de nævnte livere ikke ønsker risikoen forbundet med ansvar). Eller, og jeg har set dette, måske er det det meget virkelige og deprimerende fænomen med middelmådighed, der kæmper for sig selv, fordi den dybt inde ved, at den kan ” t konkurrerer med kvalitet, og når der er nok tomfoolery til at gå rundt, er det umuligt at finde ud af, hvem der kan bebrejdes, når alt regelmæssigt går i stykker.

Hvordan bekæmper man spørgsmål, der i sidste ende er rodfæstet i frygt eller brudte målinger for succes? Jeg vil fortælle dig dette, det kræver meget mere end endda et engageret kvalitetsudviklingshold, og du havde meget mindre end det fra lyden på det tidspunkt, hvor denne Q blev sendt.

I den ikke umulige begivenhed, at det ikke er et uhelbredeligt kulturproblem …

Antager nu, at folk øverst er meget modtagelige for forandring, og de er faktisk villige til at stole på dig til at klare det, du behøver virkelig kun at punktere alle dine argumenter med penge og mistet mulighed.

Hver gang det tager længere tid at træne nogen nyt på denne latterlige kodebase, hver gang det tager længere tid at ændre eller tilføje en ny funktion til noget, hver gang det bliver uoverkommeligt vanskeligt at udsætte slutpunkter for et andet system fra et firma, du vil samarbejde med, koster det penge. Masser af freaking money. Vigtigst er det, at det efterlader et vindue åbent for en mindre mere adræt konkurrent at svinge ind, sætte dig i en position, hvor alt hvad du kan gøre er at reagere på dem alt for slo og i sidste ende snuppe det hele væk fra dig.

Bare erkend, at en særlig stædig og dum kultur vil opretholde status quo for enhver pris, selvom det faktiske fysiske tag af virksomheden faktisk er i brand, fordi af det.

Kommentarer

  • Jeg forlod virksomheden kort tid efter. de forsøgte at ansætte mig på fuld tid og få mig til at flytte til NY fra Seattle for at acceptere tilbuddet; Jeg fortalte dem dybest set ” Ingen måde, jeg ‘ Jeg vil ikke flytte til NY, når det hold, jeg ville lede, er i Bellevue, WA ” og på det tidspunkt gik jeg dybest set over gaden og fik et job hos MSFT, indtil jeg fandt noget bedre.
  • @honestduane Ja, det sæt forventninger alene taler mængder. Godt for dig på GTFO.

Svar

Du kan citere nogle af de mest basale OOP-principper som f.eks. løs kobling og høj samhørighed. Et “Guds objekt” lyder som om det parrer uafhængige klasser og har lav samhørighed.

Svar

Du kan altid spørge onkel Bob selv .

Sagen er, det er så indlysende for folk med enhver forstand, at når det først er stavet, behøver det ikke at blive henvist til af et stort antal forfattere. Der behøver kun være en kilde.

Andre udtryk, du måske vil starte med, når du leder efter kilder, er:

  • SOLID
  • Demeter Law
  • Big Ball of Mud

Alle disse udtrykkende relaterede begreber, der muligvis giver levedygtige referencekilder, selvom de faktisk ikke navngiver det som sådan.

I sidste ende selvom du er chef. Årsagen til at gøre det er fordi du siger det, og selvom du for at blive betragtet som en god leder virkelig burde være parat til at retfærdiggøre dine beslutninger; du har gjort det, og hvis der stadig er modstand, det korrekte handlingsforløb er for dit team at gøre, som de bliver fortalt.

Kommentarer

  • ” Hvis der stadig er modstand, er det rigtige for dit team at gøre, som de ‘ får besked på ” Måske er den korrekte fremgangsmåde at afslutte i stedet for at gøre dit team elendigt ..?
  • Manager ‘ s beslutningen er tilstrækkeligt begrundet, og hvis holdet ikke ‘ ikke er enig, så er problemet med holdet. OPen blev ansat for sin ekspertise og ikke få lov til at bruge den til gavn for virksomheden, fordi kolleger vandt ‘ t opfører sig med rimelighed, er ikke ‘ t acceptabelt. Lad ‘ s vende din påstand på hovedet – hvorfor skulle ‘ ikke de modstandsdygtige holdmedlemmer holde op, hvis deres syn på jobbet er uforeneligt med forretningens?
  • Fair point. Det afhænger af, hvordan du vil lede holdet. Men min erfaring med at tvinge folk til at gøre ting mod deres vilje fører bare til elendighed. Jeg vil hellere se God Objects i hele kodebasen end et elendigt udviklingsteam. Måske er svaret at sende dem på et kursus. Alle elsker et kursus. Vind-vind.
  • Hovedudvikleren / lederen / hvad som helst bør absolut tage alle rimelige forholdsregler for at sikre, at holdet bevarer et godt samarbejdsforhold med hinanden. Hvis yderligere træning er nyttig, så overvej det som en mulighed – men det ser ud til at være som et tilfælde af forsætlig uvidenhed og fortælle nogen, at de har brug for at blive trænet til at forstå din idé, når hvad de tror, de ‘ er færdig er uenig, snarere end ikke at forstå, kunne komme til at slå tilbage. Jeg har svært ved at forestille mig måder at håndtere mennesker, der ikke ‘ ikke vil lære.

Svar

Hvordan kan jeg bevise eller afkræfte “gud” objekter er forkerte?

Du kan ikke.

Denne form for formodning kan ikke matematisk bevises, og matematisk bevis er den eneste slags bevis, der er sund.

Selvom du prøver at erstatte det følelsesmæssige ord “forkert” med kvantificerbare målinger af virkningerne af at bruge gudobjekter finder du, at:

  1. de tilgængelige mål er rå,
  2. der er få troværdige undersøgelser, hvor disse mål er blevet kvantificeret for kode produceret af professionelle programmører
  3. er der få, hvis nogen troværdige studier, hvor sprogkonstruktioner eller design (anti-) mønstre er bundet til disse foranstaltninger.

Og det ignorerer spørgsmålet om at beslutte, hvornår et bestemt objekt er et “gud” -objekt.

I bedste fald kunne denne form for undersøgelse kun demonstrere en empirisk sammenhæng. Ikke et ægte bevis.

Hvad du rent faktisk laver er debattering fordele og ulemper ved “gud” objekter med henblik på at ændre andre folks “ meninger … og derefter er din organisations praksis.

Brug ikke ord som “bevis”, eller de mennesker, du diskuterer med, kan grine i dit ansigt.

Svar

Det kan være en god idé at se Ugens guru # 84 . Det handler om gudobjekter (monolitter) og hvordan de er dårlige.

Uddrag:

(Major) Det isolerer potentielt uafhængig funktionalitet i en klasse […] (Mindre) Det kan modvirke at udvide klassen med ny funktionalitet […]

Svar

Jeg er ikke sikker på, om dit team virkelig er interesseret i et akademisk bevis på, at “Guds objekter er forkerte”.

Fra et psykologisk synspunkt kan din refactoring-tilgang misforstås som angreb på holdets kompetence a la: “holdet har gjort et dårligt stykke arbejde”, selvom programmet fungerer som forventet.

Hvad du virkelig vil gøre er at håndtere de negative bivirkninger af “spagetti-kode” og “Guds objekter”: eksplodig koster at tilføje nye funktioner på grund af stigende fejl forårsaget af bivirkninger.

Bee meget specifikke og stille spørgsmål i stedet for at give svar kan være mere nyttige: 

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

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *