Oppsummering av problem:

Lang historie kort, jeg arvet en kodebase og et utviklingsteam jeg ikke har lov til å erstatte, og bruken av God Objects er et stort problem. Fremover vil jeg at vi skal re-faktorere ting, men jeg får push-back fra lagene som ønsker å gjøre alt med God Objects «fordi det er lettere», og dette betyr at jeg ikke ville få lov til å re-faktorere. Jeg presset tilbake med henvisning til mine mange års utviklingserfaring, at jeg er den nye sjefen som ble ansatt for å vite disse tingene, osv. Det samme gjorde tredjeparts offshore-selskaper salgsrepresentant, og dette er nå på utøvende nivå og mitt møte er i morgen, og jeg vil gå inn med mye teknisk ammunisjon for å gå inn for beste praksis fordi jeg føler at det vil bli billigere i det lange løp (og jeg personlig føler det er det tredjeparten er bekymret for) for selskapet. p>

Problemet mitt er fra et teknisk nivå, jeg vet at det er godt på lang sikt, men jeg har problemer med ultra kort sikt og 6 måneders sikt, og mens det er noe jeg «vet», kan jeg ikke bevise det med referanser og siterte ressurser utenfor en person (Robert C. Martin, aka Uncle Bob), da det er det jeg blir bedt om å gjøre som jeg har blitt fortalt å ha data fra en person og bare en person (Robert C Martin) ikke er godt nok av et argument.

Spørsmål:

Hva er noe e ressurser jeg kan sitere direkte (tittel, utgitt år, sidetall, sitat) av kjente eksperter på feltet som eksplisitt sier at denne bruken av «Gud» -objekter / klasser / systemer er dårlig (eller bra, siden vi ser etter mest teknisk gyldige løsning)?

Undersøkelser jeg allerede har gjort:

  1. Jeg har en rekke bøker her, og jeg har søkt i indeksene deres for å bruke ordene «god object» og «god class». Jeg fant ut at det merkelig nok nesten aldri er brukt, og kopien av GoF-boken jeg har for eksempel, bruker den aldri (i det minste i henhold til indeksen foran meg), men jeg har funnet den i de to bøkene nedenfor, men jeg vil ha mer Jeg kan bruke.
  2. Jeg sjekket Wikipedia-siden for «Guds objekt» og er for øyeblikket en stubbe med lite referanselink, så selv om jeg personlig er enig i at det står, den har ikke mye jeg kan bruke i et miljø der personlig erfaring ikke blir ansett som gyldig. Boken sitert anses også for gammel til å være gyldig av de menneskene jeg diskuterer disse tekniske punktene med som argument. de gjør er at «det en gang ble ansett å være dårlig, men ingen kunne bevise det, og nå sier moderne programvare at» gud «objekter er gode å bruke». Jeg mener personlig at denne påstanden er feil, men jeg vil bevise sannheten , uansett hva det er.
  3. I Robert C Martin «s» Agile Principles, Patterns, and Practices in C # «(ISBN: 0-13-185725-8, innbundet) whe re på side 266 står det «Alle vet at gudsklasser er en dårlig idé. Vi ønsker ikke å konsentrere all intelligens i et system til et enkelt objekt eller en enkelt funksjon. Et av målene med OOD er partisjonering og fordeling av atferd i mange klasser og mange funksjoner. » – Og deretter fortsetter med å si at det er bedre å bruke God Classes uansett noen ganger (siterer mikrokontroller som et eksempel).
  4. I Robert C Martin «s» Clean Code: A Handbook of Agile Software Craftsmanship «side 136 (og bare denne siden) snakker om» Gudsklassen «og kaller den som et godt eksempel på brudd på» klassene skal være små «-regelen han bruker for å fremme det enkeltansvarlige prinsippet» fra side 138 .

Problemet jeg har er at alle referansene og sitatene mine kommer fra samme person (Robert C. Martin), og kommer fra samme person / kilde. Jeg blir fortalt at fordi han bare er ett syn, er mitt ønske om å ikke bruke «Gudsklasser» ugyldig og ikke akseptert som en standardpraksis i programvareindustrien. Er dette sant? Gjør jeg ting galt fra et teknisk perspektiv ved å prøve å holde meg til onkel Bobs lære?

Gudobjekter og objektorientert programmering og design:

Jo mer jeg tenker på dette, jo mer tror jeg dette er mer noe du lærer når du studerer OOP, og det blir aldri eksplisitt kalt ut, det er implisitt for godt design er min tenkning (vær så snill å korrigere meg, som jeg vil lære), problemet er at jeg «vet» dette, men ikke alle gjør det, så i dette tilfellet er det ikke ansett som et gyldig argument fordi jeg effektivt ringer det ut som en universell sannhet når de fleste faktisk er statistisk uvitende om det siden statistisk sett de fleste ikke er programmerere.

Konklusjon:

Jeg er tapt på hva jeg skal søke etter for å få de beste tilleggsresultatene for å sitere, siden de gjør et teknisk krav og jeg vil vite sannheten og kunne bevise det med sitater som en ekte ingeniør / vitenskapsmann, selv om jeg er partisk mot gudsobjekter på grunn av min personlige erfaring med kode som brukte dem. All hjelp eller sitater vil bli verdsatt.

Kommentarer

  • Be dem om dokumentasjon av Guds objekter som god praksis.
  • Stikk av! Du vil ikke ‘ ikke jobbe der.
  • Vennligst definer din forståelse av » Guds objekt » og hvordan det forholder seg til spørsmålet ditt. Du bruker 4 avsnitt på å si at God Class ikke er ‘ t et standarduttrykk i litteraturen. Så hvorfor bruker du det? Hvis du bruker industristandardvilkår og kan vise hvordan disse konseptene gjelder for ditt nåværende prosjekt, kan du kanskje overbevise noen om poenget ditt. Å bruke sminkeord på et forretningsmøte vil bare undergrave argumentet ditt. Det finnes bransjestandardbetingelser – du er ikke ‘ t den første personen som noensinne har sett et mareritt som er alt-er-globalt eller ett objekt, eller hva du prøver å beskrive.
  • Du ‘ mangler begrepet » antipattern «. Når du gjør et Google-søk etter » gudsobjekt mot mønster » returnerer tonn sider om grunnene til at de ‘ er dårlig.
  • Du bør ikke ‘ ikke angripe gudobjektet, men problemene det skaper. Som: vi har veldig tett kobling mellom alt og en endring i A krever også endringer i B, C og D. Så, for å hjelpe mot at vi ‘ kommer til å trekke ut klasser. Eller: vi vil at koden skal være i et testrammeverk, og vi kan ‘ t gjøre det, hva skal vi gjøre? Prøv også å unngå å bruke begrepet » Gud «, folk som ikke er mottakelige, vil tro at du ‘ bruker hyperboler.

Svar

Saken for enhver endring av praksis gjøres ved å identifisere smertepunktene skapt av eksisterende design. Spesielt må du identifisere hva som er vanskeligere enn det burde være på grunn av det eksisterende designet, hva som er skjørt, hva som går i stykker nå, hvilken atferd som ikke kan implementeres på en enkel måte som et direkte (eller til og med noe indirekte) resultat av den nåværende implementeringen, eller, i noen tilfeller, hvordan ytelsen lider, hvor lang tid det tar å bringe et nytt teammedlem opp i fart osv.

For det andre trumfer arbeidskoden eventuelle argumenter om teori eller god design Dette gjelder dessverre selv for dårlig kode, så du må gi et bedre alternativ, noe som betyr at du, som talsmann for bedre mønstre og praksis, må reflektere for å erte et bedre design. Finn et smalt, spor-kule-stilplan gjennom det eksisterende designet, og implementer en løsning som, kanskje, for iterasjon en, holder implementeringen av gudobjektet i bruk, men avviser faktisk implementering til det nye designet. Skriv deretter litt kode som utnytter dette nye designet, og vis hva du vinner på grunn av denne endringen, enten det er ytelse, vedlikehold, funksjoner, korrigering av feil eller løpsforhold, eller reduksjon av kognitiv belastning for utvikleren. / p>

Det er ofte en utfordring å finne et lite nok overflateareal til å angripe i dårlig arkitekterte systemer. Det kan ta lengre tid enn du ønsker å levere noen innledende verdi, og den første utbetalingen er kanskje ikke så imponerende til alle, men du kan også jobbe med å finne noen talsmenn for din nye tilnærming hvis du kobler sammen med teammedlemmer som i det minste er litt sympatiske.

Å beklage Guds objekt fungerer bare når du forkynner for koret. Det er et verktøy for å navngi et problem, og fungerer bare for å løse det når du har fått et mottakelig publikum som er eldre og motiverte nok til å gjøre noe med det. Å fikse Gud-objektet vinner argumentet.

Siden din umiddelbare bekymring ser ut til å være ledende innkjøp, tror jeg det er best å gjøre en sak om at det å erstatte denne koden må være et strategisk mål og knytte dem til forretningsmålene du er ansvarlig for. Jeg tror du kan lage en sak om at du kan gi litt teknisk retning ved først å jobbe med en teknisk spike på hva du mener skal gjøres for å erstatte den, helst involvere ressurser fra en eller to tekniske personer som har forbehold om gjeldende design.

Jeg tror du har funnet nok ressurser til å rettferdiggjøre argumentet ditt; folk på slike møter vil bare ta hensyn til sammendraget av forskningen din, og de vil slutte å lytte etter at du har nevnt to eller tre bekreftende kilder.Fokuset ditt burde i utgangspunktet være å få buy-off for å løse problemet du ser, ikke nødvendigvis bevise at noen andre tar feil eller at du har rett. Dette er et sosialt problem, ikke et logisk problem.

I en teknologiledelsesrolle må du knytte noen av dine initiativer til forretningsmål, så det viktigste for å gjøre saken din til ledere er hva arbeidet vil gjøre for disse målene. Fordi du også betraktet den «nye fyren», kan du ikke bare forvente at folk kaster arbeidet sitt eller forventer å raskt falle i kø; du må bygge litt tillit ved å bevise at du kan levere. Som en langsiktig bekymring, i en lederrolle, må du også lære å bli fokusert på resultater, men ikke nødvendigvis være knyttet til detaljene i utfallet. Du er nå der for å gi strategisk retning, fjerne taktiske hindringer fra teamets fremgang, og tilby teamet ditt mentorskap, ikke vinne troverdighetskamper med dine egne teammedlemmer.

Å ta en beslutning fra oven og ned vil sjelden være troverdig med mindre du har litt hud i spillet. Hvis du er i en lignende situasjon igjen, bør du fokusere mer på konsensusbygging i organisasjonen din i stedet for å eskalere når du føler at situasjonen er ute av kontroll.

Men med tanke på hvor du er nå, vil jeg si at det beste er å argumentere for at tilnærmingen din vil gi målbare langsiktige fordeler basert på din erfaring og at det er i tråd med arbeidet fra kjente utøvere som onkel Bob og co., og at du gjerne vil tilbringe noen dager / uker med et godt eksempel på en smal refactoring av det høyeste bang-for-buck-aspektet, for å demonstrere hvordan ditt syn på god design skal se ut. Du må imidlertid tilpasse uansett hva din sak er til spesifikke forretningsmål utover dine personlige preferanser.

Kommentarer

  • Bra poeng om at det er en sosialt problem. Må være grunnen til at det er så mye dårlig skrevet kode og dårlig utformede applikasjoner der ute.
  • +1 for å knytte den sammen med ‘ business speak ‘ som sådan; mål å gjøre det så relevant for publikum som mulig. Hvis du ‘ snakker med ledere, så gjør snakk om hvordan kodestandarden har en direkte forbindelse med vedlikehold og ytelse, og diskuter hvordan dette henger sammen med den generelle prosjektøkonomien, langsiktig stabilitet og så videre. Det høres ut som du ‘ har blitt ansatt på grunn av din kunnskap. Husk dette. (Bare ikke ‘ t blir en jerk-off manager som tror han vet alltid best – men i dette tilfellet er du ‘ 100% riktig.)
  • +1 for » arbeidskode trumfer noen argumenter om teori eller god design. » Noe vi ofte glemmer i vår søken for perfekt kode.
  • Flott svar, mye visdom der for aspirerende teamledere.

Svar

Først må du presentere at enhver målbar organisasjon trenger å ta i bruk bransjens beste praksis. Sier at «det bare fungerer for oss!» kan ikke måles, verken i tid eller i ressurs, da det rett og slett er uforutsigbart. Programvareteknikk er en vitenskap like mye som alle andre vitenskapsfelt, og disse begrepene er studert, undersøkt, testet og dokumentert.

  1. Guds objekt er et antimønster som sier at

    I programvareteknikk er et antimønster (eller antipattern) et mønster som brukes i sosial eller forretningsdrift eller programvareutvikling som ofte kan brukes, men som er ineffektivt og / eller kontraproduktivt i praksis. «9bc0ca1127»>

  • I Google IO-konferansen fra 2009 ble dette emnet delvis forklart da MVP mønster ble forklart. Det er kanskje ikke relevant for Guds objekt, men kan gi deg litt ammunisjon.

  • Bruk av dette antimønsteret bryter også med enkeltansvarsprinsipp i objektorienterte design, som sier at:

    hver klasse skal ha et enkelt ansvar, og at ansvaret skal være helt innkapslet av klassen. Alle tjenestene skal være smalt tilpasset dette ansvaret.

  • Decaying Code blogg snakker også om dette og om den løsning.

  • Vi kan ikke snakke om prinsippet om enkeltansvar uten å snakke om objekt kobling .

    […] kobling eller avhengighet er i hvilken grad hver programmodul er avhengig av hver en av de andre modulene.

    Hvor å ha et tett sammenkoblet system kan føre til assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency. Et høyere nivå av objektkupping betyr mindre kohesjon, og omvendt. Gud-objekter er et godt eksempel på tett kobling, ettersom de vet mer enn de burde, og overbelaster dem med ansvar, og begrenser dermed sterkt gjenbrukbarhet for koder.

  • Når du designer en kompleks applikasjon, enkelhet må komme til hjernen. Store problemer må nedbrytes til mindre, som er lettere å administrere, teste og dokumentere. Dette gjelder spesielt i et objektorientert paradigme.

    Med dette argumentet slår vi tilbake til antimønsterargumentet, men dette paradigmet handler om mønstre, representasjon av den virkelige verden og, ytterst, data innkapsling.

  • Du har en del rett når du sier at disse «god praksis» er mer eksisterende i klasserom. Imidlertid har jeg undervisningserfaringer på høyskolen (og noen universiteter), og jeg så bare disse prinsippene ble undervist på universitetene, spesielt på ingeniørfakultetene. Noe som er trist. Men som enhver god praksis, lærer de som prøver å forbedre seg selv, vanligvis noen grunnleggende designmønstre , og til slutt forstår hvordan man kan jungelen mellom kobling og sammenheng.

    Det jeg vanligvis lærer elevene er at det kan synes å kreve mer innsats for å vedta gode programmeringsstandarder, men det alltid lønner seg i det lange løp. Et godt eksempel er noen som ber en programmerer om å skrive en sorteringsfunksjon. Programmereren har to valg; 1) skriv en rask boblesorteringsfunksjon (mindre enn 5 minutter) som ikke vil være bærekraftig ettersom elementelisten vokser, eller 2) skrive en mer kompleks (aka optimalisert) sorteringsalgoritme (rask sortering osv.) Som skalerer bedre med større lister.

    • Kommentarer

    • Objektorienterte programmeringsspråk krever ofte at hvis to uavhengige kildesamlinger er ansvarlige for forskjellige aspekter av et objekts ‘ -atferd, må det opprettes uavhengige objektforekomster for å innkapsle denne atferd. Dessverre, selv om de mest logiske inndelingene av funksjonalitet mellom kodesamlinger i mange tilfeller ikke ‘ ikke sammenfaller med den mest logiske underinndelingen av funksjonalitet mellom objektforekomster, er jeg ‘ har ikke sett mye diskusjon om å skille mellom de to typer underavdeling.
    • Jeg tror dette er litt utenfor temaet for dette spørsmålet. Vi ‘ snakker ikke her om Guds objekt mot-mønster, men kodekobling og kohesjon, som er et mye bredt tema og veldig subjektivt.

    Svar

    Oh here I go, necroing an another old question but I m going to guess you didn t won this argument and here «s hvorfor.

    Det høres ut som et kulturproblem

    Du er deres manager, men du kan ikke erstatte dem, og du må gå til lederne dine for å få dem til å gjøre det du mener de burde gjøre, som i dette tilfellet antar jeg at det i det minste er å slå det av med gudsobjektene fremover. Det høres ut for meg som et klassisk tilfelle av kode som speiler kulturen den ble født i. Med andre ord er gudobjektet hvordan dette selskapet fungerer. Vil du gjøre noen form for meningsfull forandring? Du går alltid til samme sted for det til slutt siden alle avgjørelser tilsynelatende må ryddes på toppen.

    Etter å ha vært s kjenne til flere mislykkede forsøk på eldre kodeoppryddinger og kodepolitiske endringer. Jeg er nå av den oppfatning at du ikke kan bekjempe kulturen som muliggjorde koden i utgangspunktet når kulturen fortsatt er fast forankret eller i det minste kampkamp en veldig hard oppoverbakke at det er lite sannsynlig at noen noen gang kan betale meg nok eller gi meg nok kraft til å føle at det var en verdig innsats som sannsynligvis vil lykkes igjen.

    Før det kan skje forandring, de må være motiverte til å forandre seg, og dessverre er det som vanskelig for oss å forstå at ikke alle er motivert av det samme. Jeg har vunnet mange av de rasjonelle argumentene i mine erfaringer, men på slutten av dagen lider selskapet av intellektuelt late devs av en grunn.

    Kanskje virksomhetsproblemene har vært motivert til å tenke bare på i morgen i stedet for neste uke eller fem år ut (et spesielt frustrerende scenario når du er barn til innvandrere fra et land som bygget et frøhvelv i Arktis i tilfelle apokalypse). Kanskje de er redde for forandring.Kanskje verdsetter de ansiennitet for mye til det punktet at kommandokjeden er meningsløs, selv når de må ansette utenfra for å hente inn en teamleder eller leder, fordi de kjenner seg igjen i at ingen i deres all-lifer-team har vokst nok i sin tid der (eller fordi nevnte livere ikke vil ha risikoen forbundet med ansvar). Eller, og jeg har sett dette, kanskje det er det veldig virkelige og deprimerende fenomenet med middelmådighet som kjemper for seg selv fordi den vet innerst inne at den kan » t konkurrerer med kvalitet, og når det er nok tomfoolery å gå rundt, er det umulig å finne ut hvem du kan klandre når alt regelmessig går i stykker.

    Hvordan bekjemper du problemer som til slutt er forankret i frykt eller ødelagte beregninger for suksess? Jeg vil fortelle deg dette, det tar mye mer enn til og med et engasjert kvalitetsutviklingslag, og du hadde mye mindre enn det fra lyden den da Q ble lagt ut.

    I den umulige hendelsen at det ikke er et uoppnåelig kulturproblem …

    Forutsatt nå at folk på toppen er veldig mottakelige for endring, og de er faktisk villige til å stole på at du klarer det, du trenger egentlig bare å poengtere alle argumentene dine med penger og tapte muligheter.

    Hver gang det tar lengre tid å trene noen nye opp på denne latterlige kodebasen, hver gang det tar lengre tid å endre eller legge til en ny funksjon til noe, hver gang det blir uoverkommelig vanskelig å eksponere endepunkter for et annet system fra et selskap du vil samarbeide med, koster det penger. freaking money. Viktigst av alt, det etterlater et vindu åpent for en mindre smidig konkurrent å svinge inn, sette deg i en posisjon der alt du kan gjøre er å reagere på dem altfor slo og til slutt ta det hele fra deg.

    Bare erkjenn at en spesielt sta og dum kultur vil opprettholde status quo for enhver pris, selv om det faktiske fysiske taket på selskapet faktisk er i brann fordi av det.

    Kommentarer

    • Jeg forlot selskapet kort tid etter. de prøvde å ansette meg på heltid og få meg til å flytte til NY fra Seattle for å godta tilbudet; Jeg sa i utgangspunktet til dem » Ingen måte, jeg ‘ kommer ikke til å flytte til NY når teamet jeg skulle administrere er i Bellevue, WA » og på det tidspunktet gikk jeg i utgangspunktet over gaten og fikk jobb på MSFT til jeg fant noe bedre.
    • @honestduane Ja, det settet med forventninger alene snakker volumer. Bra for deg på GTFO.

    Svar

    Du kan sitere noen av de mest grunnleggende OOP-prinsippene som f.eks. løs kobling og høy kohesjon. Et «Guds objekt» høres ut som om det er sammenhengende klasser og har lite sammenheng.

    Svar

    Du kan alltid spørre onkel Bob selv .

    Saken er at den er så åpenbar for folk med en hvilken som helst forstand at når den først er stavet, trenger den ikke å bli referert av en rekke forfattere. Det trenger bare være én kilde.

    Andre begreper du kanskje vil begynne med når du leter etter kilder, er:

    • SOLID
    • Demeter Law
    • Big Ball of Mud

    Alle disse uttrykker relaterte begreper som kan gi levedyktige referansekilder, selv om de ikke egentlig kaller det slik.

    Til slutt skjønt, du er sjefen. Årsaken til å gjøre det er fordi du sier det, og selv om du for å bli ansett som en god leder, bør du virkelig være forberedt på å rettferdiggjøre dine beslutninger. Du har gjort det, og hvis det fremdeles er motstand, riktig fremgangsmåte er at teamet ditt gjør som de får beskjed om.

    Kommentarer

    • » hvis det fremdeles er motstand, er det rette handlingen for teamet ditt å gjøre som de ‘ får beskjed om » Den riktige handlingen er kanskje å slutte i stedet for å gjøre teamet ditt elendig ..?
    • Lederen ‘ s avgjørelsen er tilstrekkelig begrunnet, og hvis teamet ikke ‘ ikke er enig, så er problemet med teamet. OP ble ansatt for sin ekspertise og ikke lov til å bruke den til fordel for virksomheten fordi kolleger vant ‘ t oppfører seg rimelig, er ikke ‘ t akseptabel. La ‘ s slå påstanden på hodet – hvorfor skulle ikke ‘ t motstandsdyktige teammedlemmer slutte hvis deres syn på jobben er uforenlig med det av virksomheten?
    • Rettferdig poeng. Det kommer an på hvordan du vil lede teamet. Men etter min erfaring å tvinge folk til å gjøre ting mot sin vilje, fører det bare til elendighet. Jeg vil heller se God Objects gjennom hele kodebasen enn et elendig utviklingsteam. Kanskje er svaret å sende dem på et kurs. Alle elsker et kurs. Vinn-vinn.
    • Lederutvikleren / lederen / hva som helst bør absolutt ta alle rimelige tiltak for å sikre at teamet beholder et godt samarbeid med hverandre. Hvis tilleggsopplæring er nyttig, bør du i det hele tatt vurdere det som et alternativ – men dette ser ut til å være som et tilfelle av bevisst uvitenhet, og fortelle noen at de trenger å bli opplært til å forstå ideen din når det de tror de ‘ vi har gjort er uenig, i stedet for ikke å forstå, kan komme tilbake. Jeg har vanskelig for å forestille meg måter å håndtere mennesker som ikke ‘ ikke vil lære.

    Svar

    Hvordan kan jeg bevise eller avkrefte at «gud» -objekter er gale?

    Du kan ikke.

    Denne form for formodning er ikke mottakelig for matematisk bevis, og matematisk bevis er den eneste typen bevis som er lydig.

    Selv om du prøver å erstatte det følelsesmessige ordet «feil» med målbare mål på effekten av å bruke gudobjekter, vil du finne at:

    1. de tilgjengelige tiltakene er rå,
    2. det er få troverdige studier der disse tiltakene er blitt kvantifisert for kode produsert av profesjonelle programmerere
    3. er det få om noen troverdige studier der språkkonstruksjoner eller design (anti-) mønstre er knyttet til disse tiltakene.

    Og det ignorerer spørsmålet om å bestemme når et bestemt objekt er et «gud» -objekt.

    I beste fall kunne denne typen studier bare demonstrere en empirisk sammenheng. Ikke et ekte bevis.

    Det du faktisk gjør er å diskutere fordeler og ulemper med «gud» objekter med tanke på å endre andre folks « meninger … og så praktiserer organisasjonen din.

    Ikke bruk ord som «bevis» eller folk du diskuterer med kan le i ansiktet ditt.

    Svar

    Det kan være lurt å se Ukens guru # 84 . Det handler om gudsobjekter (monolitter) og hvordan de er dårlige.

    Utdrag:

    (Major) Det isolerer potensielt uavhengig funksjonalitet i en klasse […] (Mindre) Det kan motvirke utvidelse av klassen med ny funksjonalitet […]

    Svar

    Jeg er ikke sikker på om teamet ditt virkelig er interessert i et akademisk bevis på at «Guds objekter er gale».

    Fra et psykologisk synspunkt kan refactoring-tiltaket ditt misforstås som angrep på teamets kompetanse a la: «teamet har gjort en dårlig jobb» selv om programmet fungerer som forventet.

    Det du virkelig vil gjøre er å takle de negative bivirkningene av «spagetti code» og «God objects»: explodig koster å legge til nye funksjoner på grunn av økende feil forårsaket av bivirkninger.

    Bee veldig spesifikke og stille spørsmål i stedet for å gi svar kan være mer 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

    Legg igjen en kommentar

    Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *