Riepilogo del problema:

Per farla breve, ho ereditato una base di codice e un team di sviluppo che non sono autorizzato a sostituire e luso di God Object è un grosso problema. Andando avanti, voglio che ri-fattorizziamo le cose, ma ricevo respingimenti dai team che vogliono fare tutto con God Objects “perché è più facile” e questo significa che non mi sarebbe permesso di ri-fattorizzare. Ho respinto citando i miei anni di esperienza nello sviluppo, che sono il nuovo capo che è stato assunto per sapere queste cose, ecc. E così ha fatto il rappresentante di vendita di società offshore di terze parti, e questo è ora a livello esecutivo e il mio incontro è domani e voglio entrare con un sacco di munizioni tecniche per sostenere le migliori pratiche perché penso che sarà più economico a lungo termine (e personalmente ritengo che questo sia ciò di cui la terza parte è preoccupata) per lazienda.

Il mio problema è di livello tecnico, so che è buono a lungo termine ma ho problemi con il termine ultra breve e 6 mesi, e sebbene sia qualcosa che “so” non posso “provarlo con riferimenti e risorse citate al di fuori di una persona (Robert C. Martin, alias Uncle Bob), poiché questo è ciò che mi viene chiesto di fare poiché mi è stato detto di avere dati da una persona e solo una persona (Robert C. Martin) non lo è argomento abbastanza buono.

Domanda:

Cosa sono i som Le risorse che posso citare direttamente (titolo, anno di pubblicazione, numero di pagina, citazione) da noti esperti del settore che affermano esplicitamente che questo uso di Oggetti / Classi / Sistemi “Dio” è cattivo (o buono, dato che stiamo cercando il soluzione tecnicamente più valida)?

Ricerche che ho già fatto:

  1. Ho diversi libri qui e ho cercato nei loro indici luso delle parole “oggetto di dio” e “classe di dio”. Ho scoperto che stranamente non è quasi mai usato e la copia del libro GoF che ho per esempio, non lo usa mai (almeno secondo lindice di fronte a me) ma lho trovato nei due libri qui sotto, ma ne voglio di più Posso usare.
  2. Ho controllato la pagina di Wikipedia per “God Object” ed è attualmente uno stub con pochi link di riferimento, quindi anche se personalmente concordo con quello che dice, non ha molto che possa usare in un ambiente in cui lesperienza personale non è considerata valida. Il libro citato è anche considerato troppo vecchio per essere valido dalle persone con cui sto discutendo questi punti tecnici come argomento stanno facendo è che “una volta si pensava che fosse cattivo ma nessuno poteva provarlo, e ora il software moderno dice che gli oggetti” dio “sono buoni da usare”. Personalmente credo che questa affermazione non sia corretta, ma voglio provare la verità , qualunque esso sia.
  3. In “Agile Principles, Patterns, and Practices in C #” di Robert C Martin (ISBN: 0-13-185725-8, copertina rigida) A pagina 266 si afferma “Tutti sanno che le classi di dio sono una cattiva idea. Non vogliamo concentrare tutta lintelligenza di un sistema in un singolo oggetto o una singola funzione. Uno degli obiettivi di OOD è il partizionamento e la distribuzione del comportamento in molte classi e molte funzioni. ” – E poi prosegue dicendo che a volte è meglio usare le classi di Dio comunque a volte (citando microcontrollori come esempio).
  4. In Robert C Martin “s” Clean Code: A Handbook of Agile Software Craftsmanship “pagina 136 (e solo questa pagina) parla della” classe di Dio “e la definisce come un ottimo esempio di violazione della regola” le classi dovrebbero essere piccole “che usa per promuovere il principio di responsabilità unica” a partire da pagina 138 .

Il problema che ho è che tutti i miei riferimenti e le mie citazioni provengono dalla stessa persona (Robert C. Martin) e provengono dalla stessa singola persona / fonte. Mi viene detto che, poiché è solo un punto di vista, il mio desiderio di non utilizzare “God Classes” non è valido e non è accettato come best practice standard nellindustria del software. È vero? Sto facendo cose sbagliate dal punto di vista tecnico cercando di attenermi agli insegnamenti di zio Bob?

Oggetti di Dio e programmazione e progettazione orientata agli oggetti:

Più ci penso più penso che questo sia più qualcosa che impari quando studi OOP e non viene mai esplicitamente chiamato; È implicito a buono il design è il mio pensiero (sentiti libero di correggermi, per favore, poiché voglio imparare), il problema è che io “lo so”, ma non tutti lo fanno, quindi in questo caso non è considerato un argomento valido perché sto effettivamente chiamando come verità universale quando in realtà la maggior parte delle persone ne è statisticamente ignorante poiché statisticamente la maggior parte delle persone non sono programmatori.

Conclusione:

Non so cosa cercare per ottenere i migliori risultati aggiuntivi da citare, dal momento che stanno facendo unaffermazione tecnica e voglio conoscere la verità ed essere in grado di dimostrarla con citazioni come un vero ingegnere / scienziato, anche se sono prevenuto contro gli oggetti di Dio a causa del mio personale esperienza con il codice che li ha utilizzati. Qualsiasi assistenza o citazione sarebbe profondamente apprezzata.

Commenti

  • Chiedere loro la documentazione degli oggetti di Dio come buona pratica.
  • Scappa! Non ‘ vuoi lavorare lì.
  • Definisci la tua comprensione di ” God Object ” e come si collega alla tua domanda. Spendi 4 paragrafi dicendo che God Class non è ‘ un termine standard in letteratura. Allora perché lo stai usando? Se utilizzi termini standard del settore e puoi mostrare come questi concetti si applicano al tuo progetto attuale, potresti convincere alcune persone del tuo punto di vista. Usare parole inventate in un incontro di lavoro non farà che minare la tua argomentazione. Esistono termini standard del settore: non sei ‘ la prima persona a vedere un incubo tutto è globale o un oggetto singolo o qualunque cosa tu stia cercando di descrivere.
  • ‘ manca il termine ” antipattern “. Lesecuzione di una ricerca su Google per ” god object antipattern ” restituisce tonnellate di pagine sui motivi per cui ‘ non funziona.
  • Non dovresti ‘ attaccare loggetto dio ma i problemi che crea. Ad esempio: abbiamo un accoppiamento molto stretto tra tutto e un cambiamento in A richiede anche cambiamenti in B, C e D. Quindi, per aiutare contro ciò, ‘ andremo a estrarre le classi. Oppure: vogliamo che il codice sia in un framework di test e possiamo ‘ non farlo, cosa faremo? Inoltre, prova a evitare di utilizzare il termine ” Dio “, le persone non ricettive penseranno che tu ‘ stai usando le iperboli.

Risposta

Il caso per qualsiasi cambiamento di pratica è fatto identificando i punti dolenti creato dal design esistente. In particolare, è necessario identificare cosa è più difficile di quanto dovrebbe essere a causa del design esistente, cosa è fragile, cosa si sta rompendo ora, quali comportamenti non possono essere implementati in modo semplice come risultato diretto (o anche piuttosto indiretto) di limplementazione corrente, o, in alcuni casi, come ne risentono le prestazioni, quanto tempo ci vuole per portare un nuovo membro del team al passo con i tempi, ecc.

In secondo luogo, il codice di lavoro prevale su qualsiasi argomento sulla teoria o sul buon design . Questo è vero anche per codice difettoso, sfortunatamente. Quindi dovrai fornire unalternativa migliore, il che significa che tu, come sostenitore di schemi e pratiche migliori, dovrai rifattorizzare per estrarre un design migliore. Trova un piano stretto in stile tracciante attraverso il progetto esistente e implementa una soluzione che, forse, per literazione uno, mantenga in funzione limplementazione delloggetto dio, ma rimanda limplementazione effettiva al nuovo design. Quindi scrivi del codice che sfrutti questo nuovo design e mostra ciò che hai vinto grazie a questo cambiamento, che si tratti di prestazioni, manutenibilità, funzionalità, correzione di bug o condizioni di gara o riduzione del carico cognitivo per lo sviluppatore.

È spesso una sfida trovare una superficie sufficientemente piccola per attaccare in sistemi mal progettati, potrebbe essere necessario più tempo di quanto si vorrebbe per fornire un valore iniziale e il profitto iniziale potrebbe non essere così impressionante a tutti, ma puoi anche lavorare per trovare alcuni sostenitori del tuo nuovo approccio se lo accoppi con membri del team che siano almeno leggermente solidali.

Lamentare loggetto di Dio funziona solo quando “re predicando a il coro. È uno strumento per dare un nome a un problema e funziona solo per risolverlo quando hai un pubblico ricettivo che è sufficientemente anziano e motivato per fare qualcosa al riguardo. Risolvere loggetto Dio vince la discussione.

Poiché la tua preoccupazione immediata sembra essere il buy-in dei dirigenti, penso che tu “sia meglio sostenere che la sostituzione di questo codice deve essere un obiettivo strategico e collegarli agli obiettivi di business di cui sei responsabile. Penso che tu può dimostrare che puoi fornire una direzione tecnica lavorando prima su un picco tecnico su ciò che pensi dovrebbe essere fatto per sostituirlo, preferibilmente coinvolgendo le risorse di uno o due tecnici che hanno delle riserve sul progetto corrente.

Penso che tu abbia trovato risorse sufficienti per giustificare la tua argomentazione; le persone in tali riunioni presteranno attenzione solo al sommario della tua ricerca e smetteranno di ascoltare dopo che avrai menzionato due o tre fonti di conferma.Il tuo obiettivo inizialmente dovrebbe essere quello di ottenere il buy-off per risolvere il problema che vedi, non necessariamente dimostrare che qualcun altro ha torto o te stesso. Questo è un problema sociale, non logico.

In un ruolo di leadership tecnologica, devi legare le tue iniziative agli obiettivi di business, quindi la cosa più importante per far valere il tuo caso ai dirigenti è ciò che il lavoro andrà bene per questi obiettivi. Poiché “sei anche considerato il” nuovo ragazzo “, non puoi semplicemente aspettarti che le persone buttino via il loro lavoro o che si mettano rapidamente in riga; devi costruire un po di fiducia dimostrando che puoi mantenere. Come preoccupazione a lungo termine, in un ruolo di leadership, devi anche imparare a concentrarti sui risultati, ma non necessariamente essere attaccato alle specifiche del risultato. Ora sei lì per fornire una direzione strategica, rimuovere gli ostacoli tattici dal progresso della tua squadra e offrire il tutoraggio della tua squadra, non vincere battaglie di credibilità con i membri del tuo stesso team.

Prendere una decisione dallalto verso il basso lo farà. raramente sii credibile a meno che tu non abbia un po di pelle nel gioco; se ti trovi di nuovo in una situazione simile, dovresti concentrarti maggiormente sulla costruzione del consenso allinterno della tua organizzazione piuttosto che sullescalation una volta che senti che la situazione è fuori controllo.

Ma considerando dove ti trovi ora, direi che la soluzione migliore è sostenere che il tuo approccio porterà benefici misurabili a lungo termine in base alla tua esperienza e che è in linea con il lavoro di noti professionisti come zio Bob e co., e che vorresti trascorrere alcuni giorni / settimane dando lesempio su un ristretto refactoring dellaspetto più redditizio, per dimostrare come dovrebbe essere la tua visione di un buon design. Tuttavia, dovrai allineare qualunque sia il tuo caso a obiettivi aziendali specifici al di là delle tue preferenze personali.

Commenti

  • Buon punto sul fatto che si tratta di un problema sociale. Deve essere il motivo per cui cè così tanto codice scritto male e applicazioni mal progettate là fuori.
  • +1 per averlo collegato con ‘ linguaggio commerciale ‘ in quanto tale; cerca di renderlo il più pertinente possibile per il tuo pubblico. Se ‘ stai parlando con i dirigenti, fallo parla di come lo standard del codice ha un collegamento diretto con la manutenzione e le prestazioni e discuti di come questo si collega alle finanze complessive del progetto, alla stabilità a lungo termine e così via. Suona come te ‘ sono stato assunto per le tue conoscenze; ricordalo. (Basta non ‘ diventare un manager stronzo che pensa sa sempre meglio , ma in questo caso ‘ hai ragione al 100%.)
  • +1 per ” codice funzionante supera qualsiasi argomento sulla teoria o sul buon design. ” Qualcosa che spesso dimentichiamo nella nostra ricerca per un codice perfetto.
  • Ottima risposta, molta saggezza per aspiranti team leader.

Risposta

In primo luogo, è necessario dimostrare che qualsiasi organizzazione misurabile deve adottare le migliori pratiche del settore. Dicendo che “funziona solo per noi!” non può essere misurato, né in tempo né in risorse in quanto è semplicemente imprevedibile. Lingegneria del software è una scienza tanto quanto qualsiasi altro campo della scienza e questi concetti sono stati studiati, ricercati, testati e documentati.

  1. il God Object è un anti-pattern che afferma che

    Nellingegneria del software, un anti-pattern (o antipattern) è un modello utilizzato nelle operazioni sociali o aziendali o nellingegneria del software che può essere comunemente usato ma è inefficace e / o controproducente nella pratica.

  2. Nella conferenza Google IO del 2009 , questo argomento è stato parzialmente spiegato quando lMVP modello è stato spiegato. Potrebbe non essere rilevante per lOggetto Dio, ma potrebbe darti delle munizioni.

  3. Inoltre, luso di questo anti-pattern viola le principio di responsabilità unica nei progetti orientati agli oggetti, che afferma che:

    ogni classe dovrebbe avere ununica responsabilità e tale responsabilità dovrebbe essere interamente incapsulato dalla classe. Tutti i suoi servizi dovrebbero essere strettamente allineati a tale responsabilità.

  4. Il Il blog di Decaying Code parla anche di questo e della sua soluzione.

  5. Non si può parlare del principio di responsabilità unica senza parlare delloggetto accoppiamento .

    […] accoppiamento o dipendenza è il grado in cui ogni modulo del programma fa affidamento su ciascuno uno degli altri moduli.

    Dove avere un sistema strettamente accoppiato può causare assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency. Un livello più alto di accoppiamento di oggetti significa meno coesione e vice versa. Gli oggetti Dio sono un buon esempio di accoppiamento stretto poiché sanno più di quanto dovrebbero, quindi sovraccaricano di responsabilità, limitando così notevolmente la riusabilità del codice.

  6. Quando si progetta unapplicazione complessa, semplicità . I problemi grandi devono essere scomposti in problemi più piccoli, più facili da gestire, testare e documentare. Ciò è particolarmente vero in un paradigma orientato agli oggetti.

    Con questo argomento, torniamo allargomento anti-pattern, ma questo paradigma riguarda i modelli, la rappresentazione degli oggetti del mondo reale e, in definitiva, i dati incapsulamento.

  7. Hai ragione quando dici che queste “buone pratiche” sono più presenti nelle classi. Tuttavia, ho esperienze di insegnamento al college (e in qualche università) e ho visto questi principi insegnati solo nelle università, specialmente nelle facoltà di ingegneria. Il che è triste. Ma come ogni buona pratica, coloro che si sforzano di migliorare se stessi di solito imparano alcuni modelli di design di base e alla fine capiscono come fare una giungla tra accoppiamento e coesione.

    Quello che di solito insegno agli studenti è che può sembrare richiedere più sforzi per adottare buoni standard di programmazione, ma sempre ripaga nel lungo periodo. Un buon esempio potrebbe essere qualcuno che chiede a un programmatore di scrivere una funzione di ordinamento. Il programmatore ha due scelte; 1) scrivi una funzione di ordinamento veloce delle bolle (meno di 5 minuti) che non sarà sostenibile man mano che lelenco di elementi cresce, o 2) scrivi un algoritmo di ordinamento più complesso (anche ottimizzato) (ordinamento rapido, ecc.) Che scalerà meglio con elenchi più grandi.

Commenti

  • I linguaggi di programmazione orientati agli oggetti spesso richiedono che se due assembly sorgente indipendenti sono responsabili per diversi aspetti del comportamento di un oggetto ‘, occorrerà creare istanze di oggetti indipendenti per incapsulare quei comportamenti. Sfortunatamente, anche se in molti casi le suddivisioni più logiche di funzionalità tra gli assembly di codice non ‘ t coincidono con la suddivisione più logica di funzionalità tra istanze di oggetti, io ‘ non ho visto molte discussioni sulla distinzione dei due tipi di suddivisione.
  • Credo che questo sia un po fuori tema per questa domanda. ‘ non stiamo parlando dellanti-pattern God Object, qui, ma dellaccoppiamento e della coesione del codice, che è un argomento molto ampio e molto soggettivo.

Risposta

Oh, eccomi, necro unaltra vecchia domanda ma immagino che non hai vinto questo argomento e qui “s perché.

Sembra un problema culturale

Tu “sei il loro manager ma non puoi sostituirli e devi andare dai tuoi manager per convincerli a fare quello che credi dovrebbero fare, il che in questo caso presumo sia almeno smetterla con gli oggetti divini che si muovono in avanti. Mi sembra un classico caso di codice che rispecchia la cultura in cui è nata. In altre parole, loggetto divino è il modo in cui funziona questa azienda. Vuoi apportare qualsiasi tipo di cambiamento significativo? Vai sempre nello stesso posto per questo in ultima analisi, dal momento che apparentemente tutte le decisioni devono essere chiarite allinizio.

Essendo stato p rivy a molteplici tentativi falliti di pulizia del codice legacy e modifiche alla policy del codice Sono ora dellopinione che non si possa combattere la cultura che ha reso possibile il codice in primo luogo quando quella cultura è ancora saldamente radicata o, per lo meno, la cultura del combattimento lo è un duro lavoro in salita che è improbabile che qualcuno possa mai pagarmi abbastanza o darmi abbastanza potere per sentire come se fosse uno sforzo proficuo che probabilmente avrebbe avuto successo ancora una volta.

Prima che ci possa essere un cambiamento, devono essere motivati a cambiare e sfortunatamente, come programmatori che si danno abbastanza da leggere Stack di tanto in tanto, è difficile per noi capire che non tutti sono motivati dalle stesse cose. Ho vinto molte argomentazioni razionali nelle mie esperienze, ma alla fine della giornata lazienda soffre di sviluppatori intellettualmente pigri per un motivo.

Forse le preoccupazioni aziendali sono state motivate a pensare solo al domani piuttosto che la prossima settimana o cinque anni fuori (uno scenario particolarmente frustrante quando sei il figlio di immigrati da un paese che ha costruito un deposito di semi nellArtico in caso di apocalisse). Forse hanno paura del cambiamento.Forse apprezzano eccessivamente lanzianità al punto che la catena di comando è priva di significato anche quando devono assumere dallesterno per portare un responsabile o un manager del team di sviluppo perché riconoscono che nessuno nel loro team all-lifer è cresciuto abbastanza nel loro tempo lì (o perché detti lifer non vogliono il rischio associato alla responsabilità). Oppure, e ho visto questo, forse è “il fenomeno molto reale e deprimente della mediocrità che si difende perché sa dentro di sé che può” t competere con la qualità e quando ci sono abbastanza stupidaggini da aggirare è impossibile capire a chi dare la colpa quando tutto va regolarmente in pezzi.

Come si affrontano i problemi che alla fine sono radicati nella paura o metriche non funzionanti per il successo? Ti dirò questo, ci vuole molto di più di un team di sviluppo di qualità impegnato e tu ne avevi molto meno dal suono al momento in cui è stato pubblicato questo Q.

Nelleventualità non impossibile che non sia un problema culturale intrattabile …

Ora supponendo che le persone al vertice sono molto ricettivi al cambiamento e sono effettivamente disposti a fidarsi di te per farcela, devi solo punteggiare tutti i tuoi argomenti con denaro e opportunità perse.

Ogni volta che ci vuole più tempo per addestrare qualcuno nuovo su questa ridicola base di codice, ogni volta che ci vuole più tempo per modificare o aggiungere una nuova funzionalità a qualcosa, ogni volta che diventa proibitivamente difficile esporre gli endpoint a un altro sistema di unazienda con cui vuoi collaborare, costa denaro. soldi. Soprattutto, lascia una finestra aperta affinché un concorrente più piccolo e più agile possa piombare dentro, mettendoti in una posizione in cui tutto ciò che puoi fare è reagire troppo furbo, e alla fine strapparti tutto.

Riconosci solo che una cultura particolarmente testarda e stupida manterrà lo status quo a tutti i costi anche se il tetto fisico dellazienda è in realtà in fiamme perché di esso.

Commenti

  • Ho lasciato lazienda poco dopo. hanno cercato di assumermi a tempo pieno e di farmi trasferire a New York da Seattle per accettare lofferta; In pratica ho detto loro ” Assolutamente no, ‘ non mi trasferirò a New York quando la squadra che avrei gestito è a Bellevue, WA ” ea quel punto ho praticamente attraversato la strada e ho trovato un lavoro presso MSFT finché non ho trovato qualcosa di meglio.
  • @honestduane Sì, quellinsieme di aspettative da solo la dice lunga. Buon per te su GTFO.

Risposta

Potresti citare alcuni dei principali OOP più basilari come accoppiamento sciolto e alta coesione. Un “oggetto Dio” sembra accoppiare classi non correlate e ha una bassa coesione.

Risposta

Puoi sempre chiedere a zio Bob in persona .

Il fatto è che è così ovvio per le persone con un po di buon senso che una volta enunciato, non ha bisogno di essere re-referenziato da una moltitudine di autori. Ci deve essere solo una fonte.

Altri termini con cui potresti iniziare quando cerchi le fonti sono:

  • SOLIDO
  • Legge di Demetra
  • Big Ball of Mud

Tutti questi esprimono concetti correlati che potrebbero fornire fonti di riferimento valide, anche se in realtà non lo chiamano come tale.

In definitiva tuttavia, tu sei il capo. La ragione per farlo è perché lo dici, e sebbene per essere considerato un buon manager dovresti essere davvero pronto a giustificare le tue decisioni; lhai fatto, e se cè ancora resistenza, la linea di condotta corretta è che il tuo team faccia come gli viene detto.

Commenti

  • ” se cè ancora resistenza, il modo corretto di agire è che il tuo team faccia come ‘ ha detto ” Forse la linea di condotta corretta è abbandonare piuttosto che rendere infelice la tua squadra ..?
  • Il manager ‘ s la decisione è stata adeguatamente giustificata e se la squadra non ‘ è daccordo, il problema è con la squadra. LOP è stato assunto per la sua esperienza e non gli è stato permesso di usarla a vantaggio dellazienda perché i colleghi ‘ non si sono comportati ragionevolmente ‘ t accettabile. Lascia che ‘ capovolga la tua affermazione: perché ‘ i membri del team resistenti non dovrebbero rinunciare se la loro visione del lavoro è incompatibile con quello del business?
  • Giusto punto. Dipende da come vuoi dirigere la squadra. Ma nella mia esperienza costringere le persone a fare cose contro la loro volontà porta solo alla miseria. Preferirei vedere God Objects in tutta la base del codice piuttosto che un miserabile team di sviluppo. Forse la risposta è mandarli in un corso di formazione. Tutti amano un corso di formazione. Win-win.
  • Lo sviluppatore / manager principale / qualunque cosa dovrebbe assolutamente adottare tutte le misure ragionevoli per garantire che il team mantenga un buon rapporto di lavoro reciproco. Se la formazione aggiuntiva è utile, allora considerala con tutti i mezzi unopzione, ma questo sembra essere come un caso di ignoranza intenzionale e dire a qualcuno che hanno bisogno di essere addestrati per capire la tua idea quando quello che pensano di ‘ aver fatto è in disaccordo, piuttosto che non capire, potrebbe ritorcersi contro. Faccio fatica a immaginare modi per trattare con persone che non ‘ vogliono imparare.

Risposta

Come posso dimostrare o confutare che gli oggetti “dio” sono sbagliati?

Non puoi.

Questo tipo di congettura non è suscettibile di dimostrazione matematica e la dimostrazione matematica è lunico tipo di dimostrazione valida.

Anche se provi a sostituire la parola emotiva “sbagliato” con misure quantificabili degli effetti delluso di oggetti divini, scoprirai che:

  1. le misure disponibili sono rozze,
  2. ci sono pochi studi credibili in cui tali misure sono state quantificate per il codice prodotto da programmatori professionisti
  3. ci sono pochi studi credibili in cui costrutti linguistici o modelli di progettazione (anti-) sono stati legati a queste misure.

E quello sta ignorando il problema di decidere quando un particolare oggetto è un oggetto “dio”.

Nella migliore delle ipotesi, questo tipo di studio potrebbe solo dimostrare una correlazione empirica. Non una vera prova.

Quello che stai effettivamente facendo è dibattere i pro e i contro degli oggetti “dio” al fine di cambiare le opinioni di altre persone “ … e poi la pratica della tua organizzazione.

Non usare parole come “prova” o le persone con cui stai discutendo potrebbero ridere in faccia.

Risposta

Potresti voler vedere il guru della settimana n. 84 . Si tratta solo di oggetti divini (monoliti) e di come sono cattivi.

Estratto:

(Maggiore) Isola funzionalità potenzialmente indipendente allinterno di una classe […] (Minor) Può scoraggiare lestensione della classe con nuove funzionalità […]

Rispondi

Non so se il tuo team è veramente interessato alla prova accademica che “gli oggetti di Dio sono sbagliati”.

Da un punto di vista psicologico il tuo approccio di refactoring può essere frainteso come un attacco alla competenza del team alla pari: “il team ha fatto un pessimo lavoro” sebbene il programma funzioni come previsto.

Quello che vuoi veramente fare è affrontare gli effetti collaterali negativi del “codice spagetti” e degli “oggetti di Dio”: costi enormi per aggiungere nuove funzionalità a causa dellaumento dei bug causati da effetti collaterali.

Essere molto potrebbe essere più utile porre domande specifiche invece di fornire risposte: 

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

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *