Modularità contro Semplicità di una singola classe

Una cosa che mi viene in mente è qualcosa che ho appena letto in il libro di Robert Martin : hai imparato schemi di progettazione e hai imparato dei principi solidi. Ma tutte queste cose non dovrebbero essere applicate ciecamente a qualsiasi codice, solo perché le conosci. Invece, dovrebbero essere applicati quando l'alternativa sarebbe più complicata di non applicarli.

È un libro piuttosto buono e ti guida attraverso una serie di esempi di sviluppo iterativo e di test drive. In tutto il libro c'è un messaggio unificante che dice, mantieni il codice semplice, non introdurre livelli e pattern di astrazione extra. Invece, aggiungi in modo incrementale le funzionalità e converge verso modelli conosciuti quando questa risulta essere la soluzione più semplice.

In base al tuo post, potrebbe sembrare che alcuni dei tuoi software avrebbero potuto essere considerati come sovradimensionati. Allo stesso tempo, non so quale sia il livello di abilità per il resto della tua squadra. E sfortunatamente, posso facilmente immaginare che altre persone si confondano quando vedono 2 classi e un'interfaccia anche se tu avessi assolutamente ragione nel suggerirle.

Nella mia esperienza, ci sono sicuramente alcuni programmatori che credono ancora che l'obiettivo del nostro lavoro sia quello di unire insieme le chiamate API usando un numero qualsiasi di istruzioni di controllo necessarie. E quando hai bisogno di estendere il codice, hai semplicemente bisogno di più dichiarazioni di controllo. E ciò che rende un buon programmatore è quello che può navigare con il metodo a 600 linee e riuscire a renderlo 700 linee introducendo solo 2 bug. E se è questo ciò in cui credono, sarà molto difficile convincerli altrimenti, Dio sa che ci ho provato.

Non ho una buona risposta per questo tipo di situazione. Il mio unico consiglio sarebbe quello di ottenere il supporto del capo tecnico del progetto, o un altro sviluppatore senior che altri guardano. Avere alcune discussioni e riflessioni sul codice passato e vedere se è possibile identificare ciò che è stato fatto in passato che ha funzionato e che non ha funzionato. Una volta che li hai a bordo con te, ottieni il supporto del management in modo che le persone giuste abbiano la capacità di garantire che un certo livello di design lo faccia nel prodotto.

Se non hai quel supporto, suppongo che potresti a) cercare un lavoro / gruppo diverso o b) creare una bolla di codice buono intorno a te e provare a lavorare in isolamento:)

Ricorda che applichiamo pattern e SOLID non perché ne leggiamo, ma perché è il codice PIÙ SEMPLICE che possiamo scrivere. Quindi, se pratichi questa roba, dovresti essere in grado di codificare più velocemente e produrre un codice di qualità superiore rispetto ai tuoi compagni di squadra. Alla fine altri, compresa la tua gestione, lo noteranno. Se ti ritrovi a produrre "progetti adeguati" ma i tuoi compiti ti portano continuamente il doppio del tempo altrimenti potrebbero mancare qualcosa (un buon design potrebbe richiedere più tempo in anticipo, ma dovresti aspettarti di vedere un rimborso in brevissimo tempo futuro).

Economia: questo è ciò che DEVI fare e COMUNICARE. Diciamo che lo fanno nel modo che vogliono. E poi abbiamo il tuo modo. Quali sono i vantaggi?

Puoi "abbattere" i benefici? (Continuate a chiedere così-cosa fino a quando non si colpisce il beneficio finale). Ora, puoi quantificare i benefici e convertirlo in un valore in dollari? (se ne vale la pena, dovrebbe essere quantificabile - se sei confuso raccogli "Come misurare tutto" di Doug Hubbard:)

Ora, prendi le differenze con la gestione. Mostra loro come quello che hai fatto li ha aiutati a stare bene, usando l'economia (è tutto ciò che vorranno vedere / sentire a questo punto a causa della tua situazione). Usa i numeri: costi risparmiati / guadagnati, entrate stimate, risparmi futuri, efficienze operative ecc., Qualunque cosa tu pensi sia / sia stata il beneficio del tuo design. Crea un caso aziendale semplice e mostralo a loro. Rendilo credibile per favore.

I tuoi manager / capi dovrebbero vederlo facilmente e essere più fiduciosi piuttosto che "affermazioni tecnicamente migliori". Se loro non possono essere nella società sbagliata - non possono capire l'economia aziendale !!

(Puoi dare un'occhiata all'eccellente libro di Steve Tockey - "Massimizzare il ritorno sul software" - si tratta di mostrare gli aspetti economici di qualsiasi cosa tecnica)

Buona fortuna!

È solo entropia.

Se mantieni i tuoi oggetti - o almeno la loro vista esterna, i metodi, le proprietà, ecc. - il più piccolo e il più semplice possibile, non c'è limite a ciò che puoi fare ea ciò che puoi mantenere e migliorare. Sistemi di capacità e complessità quasi infinite diventano possibili. Ma può richiedere lavoro extra e autodisciplina per attenersi a questo giorno per giorno.

Considera una tabella di visualizzazione (Classe DT). Vuoi sapere quale riga è selezionata. Se tutte le classi sono piccole, è necessario utilizzare uno dei pochi metodi di DT per ottenere un oggetto Row. Quindi dovrai usare i pochi metodi di una riga per ottenere un oggetto Selection. Un metodo di selezione ti dirà infine quale riga è selezionata. Il tuo tipico sviluppatore vorrà aggiungere un metodo DT, "getSelectedRow". È facile da aggiungere. Risparmia tempo in uso. Può essere individuato in documention molto più rapidamente. Tutto sommato è un'idea vincente e non puoi discuterne. Non ci sono difetti.

Naturalmente, una volta che DT ha 500 metodi, ecc., trovare un metodo può diventare davvero difficile. Quando ha 1000+ può essere impossibile. Ma è impossibile spiegarlo alle persone. Per prima cosa aggiungeranno solo un nuovo metodo / proprietà / qualunque. Quando ce ne sono troppi, non hanno idea di cosa sia sbagliato, quindi non lo risolveranno nemmeno se pagherebbero il costo - cosa che non faranno. Penso che ad alcune persone piaccia questa situazione perché hanno memorizzato tutti i 500, e non ci sarà molta competizione per il loro lavoro: sono una delle poche persone in grado di utilizzare la classe in modo efficace.

Ogni tanto qualcuno fa qualcosa di giusto e viene prodotto un ottimo software. Ma la solita tendenza è quella di seppellire la semplicità che rende possibile la complessità utile sotto tutti i tipi di miglioramenti che, individualmente, rendono la vita più facile e, collettivamente, rendono un sistema inspiegabile e inamovibile. Ho visto, sia nelle piccole aziende che nelle immense aziende IT di base, la continua necessità di rottamare vecchi sistemi e di costruirne di completamente nuovi perché non si poteva fare altro sui vecchi. Ho visto entrambi i singoli programmatori che dovevano ottenere nuovi posti di lavoro perché non potevano più dare un senso al loro vecchio codice e alle principali società di software che dovevano produrre sistemi nuovi di zecca perché non potevano più lavorare sui loro vecchi.

Penso che tutto ciò che puoi fare sia: tieni pulito il tuo codice. Prova a vendere le tue idee a uno o due degli altri programmatori. Hope management nota che il tuo materiale ha meno bug, viene prodotto più velocemente (a lungo termine) ed è migliorabile. E se il management diventa troppo ignaro di ciò che stai realizzando, trova un altro lavoro e spera che funzioni meglio.