Come posso dimostrare o smentire gli "oggetti di Dio" sbagliati?

Riepilogo del problema:

Per farla breve, ho ereditato una base di codice e un team di sviluppo che non posso sostituire e l'uso di God Objects è un grosso problema. Andando avanti, voglio che ri-fattorizziamo le cose, ma sto ricevendo respingimenti dai team che vogliono fare tutto con God Objects "perché è più facile" e questo significa che non mi sarà permesso di ricodificare. Ho respinto citando i miei anni di esperienza nello sviluppo, che sono il nuovo capo che è stato assunto per conoscere queste cose, ecc., E così anche le società offshore di terze parti hanno rappresentato il rappresentante delle vendite, 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é ritengo che a lungo termine sarà più economico (e personalmente sento che ciò è preoccupato per la terza parte) per l'azienda.

Il mio problema è di livello tecnico, so che è buono a lungo termine ma ho problemi con il termine ultra breve e 6 mesi, e mentre è qualcosa che "conosco" non posso provarlo con riferimenti e risorse citate al di fuori di una persona (Robert C. Martin, alias Zio Bob), poiché è quello che mi viene chiesto di fare poiché mi è stato detto di avere dati da una persona e solo una persona (Robert C Martin) non è abbastanza brava da discutere .

Domanda:

Quali sono alcune risorse che posso citare direttamente (titolo, anno pubblicato, numero di pagina, citazione) da noti esperti del settore che affermano esplicitamente che questo uso di "Dio" Oggetti / Classi / Sistemi è cattivo (o buono, dal momento che stiamo cercando per la soluzione tecnicamente più valida)?

Ricerca che ho già fatto:

1. Ho un numero di libri qui e ho cercato nei loro indici l'uso delle parole "oggetto dio" e "classe 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 l'indice di fronte a me) ma l'ho trovato nei due libri sottostanti, ma voglio di più Posso usare.
2. Ho controllato la pagina di Wikipedia per "God Object" ed è attualmente uno stub con pochi collegamenti di riferimento, quindi anche se sono personalmente d'accordo con ciò che dice, non ha molto che posso usare in un ambiente in cui l'esperienza personale non è considerata valida. Il libro citato è anche considerato troppo vecchio per essere valido dalle persone con cui sto discutendo di questi punti tecnici poiché l'argomento che stanno sostenendo è che "una volta si pensava che fosse cattivo ma nessuno poteva provarlo, e ora il software moderno dice" dio "gli oggetti sono buoni da usare". Personalmente credo che questa affermazione sia errata, ma voglio dimostrare la verità, qualunque essa sia.
3. In "Agile Principles, Patterns and Practices in C #" di Robert C Martin (ISBN: 0-13-185725-8, copertina rigida) dove a pagina 266 si afferma "Tutti sanno che le classi divine sono una cattiva idea. Non vogliamo concentrare tutta l'intelligenza di un sistema in un singolo oggetto o in una singola funzione. Uno degli obiettivi di OOD è il partizionamento e la distribuzione del comportamento in molte classi e molte funzioni. " - E poi continua a dire che a volte è meglio usare God Classes a volte (citando i microcontroller come esempio).
4. Nella pagina 136 (e solo questa pagina) "Clean Code: A Handbook of Agile Software Artigianato" parla della "classe di Dio" e la definisce come un esempio lampante della violazione delle "classi dovrebbe essere piccola" usa per promuovere il principio di responsabilità singola "a partire da pagina 138.

Il problema che ho è che tutti i miei riferimenti e citazioni provengono dalla stessa persona (Robert C. Martin) e provengono dalla stessa persona / fonte. Mi è stato detto che, poiché ha solo una visione, il mio desiderio di non usare "God Classes" non è valido e non è accettato come best practice standard nel settore del software. È vero? Sto sbagliando qualcosa dal punto di vista tecnico, cercando di seguire l'insegnamento di zio Bob?

Dio Oggetti e programmazione orientata agli oggetti:

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

Conclusione:

Sono in perdita su cosa cercare per ottenere i migliori risultati aggiuntivi da citare, dal momento che stanno avanzando un reclamo tecnico e voglio conoscere la verità ed essere in grado di dimostrarlo con citazioni come un vero ingegnere / scienziato, anche se Sono di parte contro gli oggetti divini a causa della mia esperienza personale con il codice che li ha usati. Qualsiasi assistenza o citazioni sarebbe molto apprezzata.

Il caso di qualsiasi cambiamento di pratica viene fatto identificando i punti deboli creati dal progetto esistente. In particolare, è necessario identificare ciò che è più difficile di quanto dovrebbe essere a causa del design esistente, ciò che è fragile, ciò che sta rompendo ora, quali comportamenti non possono essere implementati in modo semplice come risultato diretto (o anche un po 'indiretto) di l'implementazione corrente o, in alcuni casi, il modo in cui le prestazioni subiscono, il tempo necessario per accelerare la velocità di un nuovo membro del team, ecc.

In secondo luogo, il codice di lavoro supera qualsiasi argomento sulla teoria o sulla buona progettazione. Questo è vero anche per codici errati, sfortunatamente. Quindi dovrai fornire un'alternativa migliore, il che significa che, come sostenitore di modelli e pratiche migliori, dovrai rifattorizzare per prendere in giro un design migliore. Trova un piano di stile stretto, tracciante-proiettile attraverso il design esistente e implementa una soluzione che, forse, per l'iterazione uno, mantenga attiva l'implementazione dell'oggetto dio, ma ne difenda l'implementazione effettiva con il nuovo design. Quindi scrivi del codice che sfrutta questo nuovo design e mostra ciò che vinci a causa di 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 abbastanza piccola da attaccare in sistemi scarsamente progettati, potrebbe richiedere più tempo di quello che vorresti fornire un valore iniziale e il payoff iniziale potrebbe non essere così impressionante per tutti, ma puoi anche lavorare sulla ricerca di alcuni sostenitori del tuo nuovo approccio se lo associ a membri del team che sono almeno leggermente comprensivi.

Lamenting the God Object funziona solo quando predichi al coro. È uno strumento per nominare un problema e funziona solo per risolverlo quando hai un pubblico ricettivo che è abbastanza anziano e motivato da fare qualcosa al riguardo. Riparare l'oggetto God vince l'argomento.

Dal momento che la tua preoccupazione immediata sembra essere il buy-in esecutivo, penso che sia meglio sostenere un caso secondo cui la sostituzione di questo codice deve essere un obiettivo strategico e legarli agli obiettivi aziendali di cui sei responsabile. Penso che tu possa sostenere che puoi fornire una qualche direzione tecnica lavorando prima su un picco tecnico su ciò che pensi che dovrebbe essere fatto per sostituirlo, coinvolgendo preferibilmente risorse di una o due persone tecniche che hanno riserve sul progetto attuale.

Penso che tu abbia trovato abbastanza risorse per giustificare la tua discussione; le persone in tali incontri presteranno attenzione solo al riassunto della tua ricerca e smetteranno di ascoltare dopo aver 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 dimostrando che qualcun altro ha torto o te stesso nel modo giusto. Questo è un problema sociale, non logico.

In un ruolo di leadership tecnologica, devi associare qualsiasi tua iniziativa agli obiettivi aziendali, quindi la cosa più importante per presentare il tuo caso ai dirigenti è ciò che il lavoro farà per tali obiettivi. Poiché sei anche considerato il "nuovo ragazzo", non puoi semplicemente aspettarti che le persone buttino via il loro lavoro o si aspettino di mettersi rapidamente in riga; devi creare un po 'di fiducia dimostrando che puoi offrire. Come preoccupazione a lungo termine, in un ruolo di leadership, devi anche imparare a focalizzarti sui risultati, ma non necessariamente essere attaccato ai dettagli del risultato. Ora sei lì per fornire una direzione strategica, rimuovere gli ostacoli tattici dai progressi della tua squadra e offrire tutoraggio alla tua squadra, non vincere battaglie di credibilità con i membri della tua squadra.

Prendere una decisione dall'alto in basso sarà raramente 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 all'interno della tua organizzazione piuttosto che intensificare una volta che senti che la situazione è fuori controllo.

Ma considerando dove ti trovi ora, direi che la soluzione migliore è quella di 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 lo zio Bob e altri. e che vorresti passare qualche giorno / settimana a dare l'esempio su un ristretto refactoring dell'aspetto bang-for-buck più elevato, per dimostrare come dovrebbe essere la tua visione del buon design. Tuttavia, dovrai allineare qualunque sia il tuo caso a specifici obiettivi aziendali al di là delle tue preferenze personali.

Innanzitutto, è necessario presentare che qualsiasi organizzazione misurabile deve adottare le migliori pratiche del settore. Dicendo che "funziona solo per noi!" non può essere misurato, né nel tempo né nelle risorse in quanto è semplicemente imprevedibile. L'ingegneria del software è una scienza tanto quanto qualsiasi altro campo scientifico e questi concetti sono stati studiati, ricercati, testati e documentati.

1. l' oggetto di Dio è un anti-modello che lo afferma

   Nell'ingegneria del software, un anti-pattern (o antipattern) è un pattern usato in operazioni sociali o aziendali o ingegneria del software che può essere comunemente usato ma è inefficace e / o controproducente nella pratica.

2. Nella conferenza di Google IO del 2009 , questo argomento è stato parzialmente spiegato quando è stato spiegato il modello MVP. Potrebbe non essere rilevante per l'Oggetto Dio, ma potrebbe darti delle munizioni.

3. Inoltre, l'uso di questo modello anti-violazione viola il principio della responsabilità singola nei progetti orientati agli oggetti, che afferma che:

   ogni classe dovrebbe avere un'unica responsabilità e tale responsabilità dovrebbe essere interamente incapsulata dalla classe. Tutti i suoi servizi dovrebbero essere strettamente allineati a tale responsabilità.

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

5. Non possiamo parlare del singolo principio di responsabilità senza parlare dell'accoppiamento di oggetti .

   [...] accoppiamento o dipendenza è il grado in cui ciascun modulo di programma si basa su ciascuno degli altri moduli.

   Laddove 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ù elevato di accoppiamento degli oggetti significa minore coesione e viceversa. Gli oggetti di Dio sono un buon esempio di accoppiamento stretto poiché sanno più di quanto dovrebbero, quindi li sovraccaricano di responsabilità, limitando così notevolmente la riusabilità del codice.

6. Quando si progetta un'applicazione complessa, la semplicità deve venire in mente. I grandi problemi devono essere scomposti in quelli più piccoli, che sono più facili da gestire, testare e documentare. Ciò è particolarmente vero in un paradigma orientato agli oggetti.

   Con questo argomento, torniamo indietro all'argomento anti-pattern, ma questo paradigma è tutto basato su modelli, rappresentazione di oggetti del mondo reale e, in definitiva, incapsulamento dei dati.

7. Hai ragione quando dici che queste "buone pratiche" sono più esistenti nelle classi. Tuttavia, ho esperienze di insegnamento al college (e alcune università) e ho visto questi principi insegnare solo nelle università, specialmente nelle facoltà di ingegneria. È triste Ma come ogni buona pratica, coloro che si sforzano di migliorare se stessi di solito imparano alcuni modelli di progettazione di base e alla fine capiscono come giungere tra accoppiamento e coesione.

   Ciò che di solito insegno agli studenti è che, potrebbe sembrare che occorrano maggiori sforzi per adottare buoni standard di programmazione, ma a lungo termine ripaga sempre . Un buon esempio potrebbe essere qualcuno che chiede a un programmatore di scrivere una funzione di ordinamento. Il programmatore ha due scelte; 1) scrivere una funzione di ordinamento rapido delle bolle (meno di 5 minuti) che non sarà sostenibile man mano che l'elenco degli elementi cresce, o 2) scrivere un algoritmo di ordinamento più complesso (ovvero ottimizzato) (ordinamento rapido, ecc.) Che si ridimensionerà meglio con elenchi più grandi.

Oh, eccomi, necro un'altra domanda vecchia, ma immagino che non hai vinto questa discussione ed ecco perché.

Sembra un problema di cultura

Sei il loro manager ma non puoi sostituirli e devi andare dai tuoi manager per convincerli a fare quello che credi che dovrebbero fare, che in questo caso presumo sia almeno sbarazzartene con il dio oggetti che si muovono in avanti. Mi sembra un classico caso di codice che rispecchia la cultura in cui è nato. In altre parole, l'oggetto dio è come funziona questa azienda. Vuoi apportare qualsiasi tipo di cambiamento significativo? Alla fine, andrai sempre nello stesso posto, poiché apparentemente tutte le decisioni devono essere cancellate in cima.

Essendo stato a conoscenza di molteplici tentativi falliti di pulizia del codice legacy e modifiche alla politica del codice, ora sono dell'opinione che non si possa combattere la cultura che ha reso il codice possibile in primo luogo quando quella cultura è ancora saldamente radicata o, almeno, combattendo la cultura è una dura salita in salita che è improbabile che qualcuno possa mai pagarmi abbastanza o darmi abbastanza potere per sentirmi come uno sforzo meritevole che probabilmente avrà successo di nuovo.

Prima che ci possa essere un cambiamento, devono essere motivati ​​a cambiare e sfortunatamente come programmatori che si fregano abbastanza da leggere Stack di tanto in tanto è difficile per noi capire che non tutti sono motivati ​​dalle stesse cose. Ho vinto molti argomenti razionali nelle mie esperienze, ma alla fine la società soffre di sviluppatori intellettualmente pigri per un motivo.

Forse le preoccupazioni degli affari sono state motivate a pensare solo a domani piuttosto che alla prossima settimana o tra cinque anni (uno scenario particolarmente frustrante quando sei figlio di immigrati da un paese che ha costruito una cripta sementi nell'Artico in caso di apocalisse). Forse hanno paura del cambiamento. Forse valorizzano l'anzianità eccessivamente al punto che la catena di comando è insignificante anche quando devono assumere dall'esterno per portare un leader o un manager del team di sviluppo perché riconoscono che nessuno nella loro squadra all-lifer è cresciuto abbastanza nel loro tempo lì (o perché detti lifers non vogliono il rischio associato alla responsabilità). Oppure, e l'ho visto, forse è il fenomeno molto reale e deprimente della mediocrità che si difende perché sa dentro di sé che può '

Come combatti i problemi che alla fine sono radicati nella paura o nelle metriche infrante per il successo? Te lo dico io, ci vuole molto di più di un team di sviluppo di qualità impegnato e tu ne hai avuto molto meno dal suono al momento della pubblicazione di questa Q.

Nel caso non impossibile che non si tratti di un problema di cultura intrattabile ...

Ora supponendo che le persone al vertice siano molto ricettive nei confronti del cambiamento e in realtà siano disposte a fidarsi di te per realizzarlo, devi solo punteggiare tutti i tuoi argomenti con denaro e opportunità perse.

Ogni volta che ci vuole più tempo per formare 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 da un'azienda con cui si desidera collaborare , costa denaro. Un sacco di soldi pazzeschi. Soprattutto, lascia una finestra aperta per un concorrente più piccolo e più agile in cui entrare, metterti in una posizione in cui tutto ciò che puoi fare è reagire troppo lentamente a loro, e alla fine strapparti tutto da te.

Basta riconoscere che una cultura particolarmente testarda e stupida manterrà lo status quo a tutti i costi, anche se l'attuale tetto fisico dell'azienda è effettivamente in fiamme a causa sua.

Potresti citare alcuni dei principi OOP più basilari come l'accoppiamento lento e l'alta coesione. Un "oggetto di Dio" suona come se accoppiasse classi non correlate e avesse una bassa coesione.

Potresti sempre chiedere allo stesso zio Bob.

Il fatto è che è così ovvio per le persone che hanno la sensazione che, una volta precisato, non debba essere referenziato da una moltitudine di autori. Ci deve essere solo una fonte.

Altri termini che potresti voler iniziare quando cerchi fonti sono:

• SOLIDO
• Legge di Demetra
• Big Ball of Mud

Tutti questi concetti espressi correlati che potrebbero produrre fonti di riferimento praticabili, anche se in realtà non lo nominano come tale.

Alla fine, però, sei il capo. Il motivo per farlo è perché lo dici tu, e anche se per essere considerato un buon manager dovresti davvero essere pronto a giustificare le tue decisioni; l'hai fatto, e se c'è ancora resistenza, il modo corretto di agire è che la tua squadra faccia quello che gli viene detto.

Come faccio a dimostrare o confutare che gli oggetti "dio" sono sbagliati?

Non puoi.

Questo tipo di congetture non è suscettibile di prove matematiche e le prove matematiche sono l'unico tipo di prova valida.

Anche se provi a sostituire la parola emotiva "sbagliato" con misure quantificabili degli effetti dell'uso di oggetti divini, scoprirai che:

1. le misure disponibili sono grezze,
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 collegati a tali misure.

E questo sta ignorando il problema di decidere quando un determinato oggetto è un oggetto "dio".

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

Quello che stai effettivamente facendo è discutere i pro e i contro degli oggetti "divini" al fine di cambiare le opinioni degli altri ... e poi la pratica della tua organizzazione.

Non usare parole come "prova" o le persone con cui stai discutendo rischiano di ridere in faccia.

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

Estratto:

(Maggiore) Isola funzionalità potenzialmente indipendenti all'interno di una classe [...] (Minore) Può scoraggiare l'estensione della classe con nuove funzionalità [...]

Non sono sicuro che la tua squadra sia davvero interessata a dimostrare accademicamente che "gli oggetti di Dio sono sbagliati".

Da un punto di vista psicologico il tuo approccio al refactoring può essere frainteso come l'attacco alla competenza della squadra alla volta: "la squadra ha fatto un brutto lavoro" sebbene il programma funzioni come previsto.

Quello che vuoi veramente fare è far fronte agli effetti collaterali negativi di "codice spagetti" e "oggetti di Dio": esplodere i costi per aggiungere nuove funzionalità a causa dei crescenti bug causati da effetti collaterali.

Essere più specifici e fare domande invece di fornire risposte può essere più utile:

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