Come posso vendere a SECCO? [chiuso]

1

Dove lavoro abbiamo circa 10 progetti VS in una soluzione identica per funzionalità (con alcune regole diverse in alcuni metodi) e che condividono molti metodi esatti. Condividono lo stesso spazio dei nomi e le classi vengono chiamate con if else's singolarmente.

Credo che sarebbe meglio e più sintetico avere un'interfaccia e una classe astratta con metodi protetti comuni a tutti i bambini.

I metodi che accettano una di queste classi possono quindi prendere un'interfaccia invece di avere 10 metodi diversi che ne prendono uno ed eseguono lo stesso metodo su ogni classe.

I metodi pubblici hanno tutti la stessa firma e restituiscono la stessa cosa.

Le future implementazioni della classe avranno una chiara guida su come implementarla (oltre a copiare e modificare una versione precedente) ed è più gestibile. La ragione per cui la sto considerando è che sto aggiungendo una versione extra e insoddisfatta dell'idea di copiare e incollare un sacco di confusione e di cambiare tutti i bit che ho bisogno di cambiare (solo in 2-3 lunghi metodi di ~ 20 metodi)

Ho difficoltà a esprimere le mie ragioni sul perché dovrei essere autorizzato a fare queste modifiche (probabilmente non ci vorrebbe più di un giorno e non cambierà la logica, quindi è necessario un test minimo). So intuitivamente che è meglio, ma non è abbastanza buono!

Come posso spiegare allo sviluppatore principale quando DRY è una buona cosa? Oppure ha ragione che dovremmo continuare a copiare e incollare le cose perché "abbiamo ereditato il codice in questo modo"?

    
posta Anon343224user 18.01.2016 - 00:34
fonte

3 risposte

4

DRY è uno dei miei principi preferiti e spesso ho un problema simile al tuo. Come convinco i miei colleghi (che sono spesso molto convinti) che il modo in cui il codice è ora potrebbe essere migliorato?

Nella mia esperienza personale, se per me significa molto, "lo faccio solo" nel mio tempo libero in un ramo. Quando ne sono felice, lo faccio parlare con il mio collega e mostra che cosa intendo piuttosto che parlarne. Ai miei colleghi spesso non piace parlare di fare cose perché "fare è troppo lavoro". Se mostro loro qualcosa che è già stato fatto, si prendono un po 'più gentilmente:).

Questo anche la domanda ti sembra vicina, quindi probabilmente vale la pena leggerla.

    
risposta data 18.01.2016 - 02:50
fonte
3

Sembra che tu stia usando l'ereditarietà per condividere il comportamento tra le classi. Devi favorire "composizione oggetto" su "ereditarietà di classe" . Questo non è semplice e il contesto è importante, ma dovresti riflettere se hai bisogno della tua classe astratta.

Per quanto riguarda l'interfaccia, sembra una buona idea, ramificazioni spesso indicano che il codice potrebbe essere progettato in modo migliore. Lo farei comunque come refactoring di Boy Scout . Fondamentalmente, lascia il codice più ordinato di quello che hai trovato, ma mantieni il refactoring nel contesto del compito che ti ha portato a quel codice. La prossima volta che visiti quel metodo di ramificazione potresti creare un'interfaccia, fare qualche ridenominazione banale e inviarla ai tuoi colleghi per la revisione del codice. Il tuo cambiamento e le sue giustificazioni saranno molto più concrete a quel punto.

Non cercare di risolvere il mondo in una sola volta e non provare a impostare lo standard per "Implementazioni future" tutto in una volta. Il miglioramento dovrebbe essere nei piccoli morsi, ma continuo.

    
risposta data 18.01.2016 - 01:21
fonte
2

Inizia dicendo (ricordando) che il costo per mantenere il software è esponenziale con le sue dimensioni (fonte questo libro ) .

Quindi i tuoi argomenti sembrano solidi. Evita di scontrarti con la loro resistenza al cambiamento (perché è molto probabile) e guidali gentilmente verso una versione DRY.

    
risposta data 18.01.2016 - 05:43
fonte

Leggi altre domande sui tag