"Troppo orientato agli oggetti"

Vengo da un forte background OO e recentemente ho iniziato a lavorare in un'organizzazione che, sebbene il codice sia scritto in Java, ha molta meno enfasi sul buon design OO rispetto a quello a cui sono abituato. Mi è stato detto che presento "troppa astrazione" e che dovrei invece codificare come è sempre stato fatto, che è uno stile procedurale in Java.

TDD non è anche molto praticato qui, ma voglio avere un codice verificabile. Seppellire la logica aziendale in metodi statici privati ​​in grandi "classi di Dio" (che sembra essere la norma per questa squadra) non è molto verificabile.

Faccio fatica a comunicare chiaramente la mia motivazione ai miei collaboratori. Qualcuno ha qualche consiglio su come posso convincere i miei colleghi che l'uso di OO e TDD porta a un codice più facilmente gestibile?

Questa domanda sul debito tecnico è collegata alla mia domanda. Tuttavia, sto cercando di evitare di incorrere in primo luogo nel debito, invece di ripagarlo dopo il fatto che è quello che copre l'altra domanda.

Non ti sei lamentato del fatto che non è possibile mantenerlo, ma non di tuo gradimento. Se si tratta di una scelta di stile deliberata, potrebbe trattarsi solo di differenze creative inconciliabili e dovresti adattare il tuo stile per adattarlo o trovare un posto adatto al tuo stile preferito.

Le persone possono e devono sempre scrivere codice modulare, efficiente, ben astratto, relativamente privo di bug in uno stile procedurale. Java è una strana scelta di linguaggio per un tale negozio, ma posso vederlo accadere se fattori esterni decidessero la lingua, come ad esempio la necessità di sviluppare per Android.

Tutti sono un genio. Ma se giudichi un pesce dalla sua capacità di arrampicarsi su un albero, vivrà tutta la sua vita credendo che sia stupido. - Albert Einstein

Se stata una scelta deliberata, non puoi davvero giudicarli dal modo in cui aderiscono ai buoni principi di progettazione orientati agli oggetti, dovresti giudicare da quanto bene aderiscono ai buoni principi di progettazione procedurale e anche riformattare di conseguenza. Java non ti consente di scrivere codice al di fuori di una classe, quindi la semplice presenza di uno non significa che intendessero un modulo orientato agli oggetti.

D'altra parte, se il codice è un disastro in entrambi i paradigmi, probabilmente dovresti semplicemente tagliare le tue perdite.

Leggendo la tua domanda, mi sono ricordato di un consiglio del libro Pragmatic Programmer.

Uno dei suoi suggerimenti è Be a Catalyst for Change:

Potresti trovarti in una situazione in cui sai esattamente cosa deve fare e come farlo. L'intero sistema appare appena sotto i tuoi occhi: sai che è giusto. Ma chiedi il permesso per affrontare tutto e ti ritroverai con ritardi e sguardi vuoti. Le persone formeranno commissioni, i budget dovranno essere approvati e le cose si complicheranno. Ognuno custodirà le proprie risorse. A volte questo si chiama "stanchezza all'avvio".

È ora di cucinare Stone Soup. Scopri cosa puoi ragionevolmente chiedere. Sviluppalo bene. Una volta che lo hai, mostra alla gente e lasciali meravigliare. Quindi dì "certo, sarebbe meglio se aggiungessimo ..." Fingere che non sia importante. Siediti e attendi che inizino a chiederti di aggiungere la funzionalità che originariamente volevi. Le persone trovano più facile unirsi a un successo continuo. Mostra loro un assaggio del futuro e li farai radunare.

Quindi, penso che se inizi a fare un buon lavoro con le tue conoscenze OO e TDD, presto inizieranno a cercare e chiedere del tuo lavoro.

Per vendere nuovi modi di lavorare, devi mostrare evidenti vantaggi. Scrivere più livelli di astrazione, senza un chiaro vantaggio ma un vago: "può essere utile per il futuro" non funzionerà.

Crea fabbriche in cui le fabbriche producono più di un tipo di oggetto. Usa l'iniezione delle dipendenze, dove mostra immediatamente i benefici. Crea interfacce che verranno implementate da più di una classe.

Quello che vedo troppo spesso in "OO vero" è che vengono utilizzate tecniche avanzate per risolvere problemi davvero semplici in un modo troppo complesso.

Come si può dimostrare il vantaggio di una fabbrica se solo lo sarà mai lo stesso oggetto? Trova un problema nel tuo codice che beneficia di tecniche avanzate e mostra il tuo punto e il lavoro da lì.

Le guerre si vincono una battaglia alla volta.

Puoi convincerli solo assumendo un piccolo pezzo di codice e implementando TDD e migliori pratiche OO su di esso per realizzare i vantaggi. Li hai portati nella terra promessa, non solo mostrandoti delle belle cartoline postali.

Certamente, penso che oggi ci siano casi di sovraastrazione in uso in molte basi di codice. Inserisci solo ciò di cui hai bisogno e questo include anche le astrazioni.