DRY è il nemico della gestione dei progetti software?

Uno dei principi più basilari e ampiamente accettati dello sviluppo software è DRY (non ripeterti). È anche chiaro che la maggior parte dei progetti software richiede un qualche tipo di gestione.

Ora quali sono le attività che sono facili da gestire (stima, pianificazione, controllo)? Compiti giusti e ripetitivi, esattamente i compiti che dovrebbero essere evitati secondo DRY.

Quindi, dal punto di vista della gestione del progetto, è bello risolvere un'attività copiando 100 volte il codice esistente e apportando alcuni adattamenti minori a ciascuna copia, come richiesto. In ogni momento, sai esattamente quanto lavoro hai svolto e quanto è rimasto. Tutti i manager ti adoreranno.

Se invece applichi il principio DRY e cerchi di trovare un'astrazione che elimini più o meno il codice duplicato, le cose sono diverse. Di solito ci sono molte possibilità, devi prendere decisioni, fare ricerche, essere creativo. Potresti trovare una soluzione migliore in tempi più brevi, ma potresti anche fallire. Il più delle volte, non puoi davvero dire quanto lavoro è rimasto. Sei il peggior incubo di un project manager.

Certo che sto esagerando, ma c'è ovviamente un dilemma. Le mie domande sono: quali sono i criteri per decidere se uno sviluppatore sta esagerando a SECCO? Come possiamo trovare un buon compromesso? O c'è un modo per superare completamente questo dilemma, non solo trovando un compromesso?

Nota: questa domanda si basa sulla stessa idea della mia precedente, quantità di lavoro di routine nello sviluppo del software e sui suoi effetti sulla stima , ma penso che chiarisca il mio punto, quindi mi dispiace per avermi ripetuto :).

Sembra che tu presuma che l'obiettivo principale della gestione del progetto sia produrre stime esatte. Questo non è il caso. L'obiettivo primario della gestione dei progetti è lo stesso degli sviluppatori: offrire valore al proprietario del prodotto.

Un prodotto che utilizza molti processi manuali lenti piuttosto che l'automazione potrebbe in teoria essere più facile da stimare (anche se ne dubito), ma non fornisce un rapporto qualità-prezzo al cliente, quindi è semplicemente una cattiva gestione del progetto. Non c'è nessun dilemma.

È noto che la stima dei progetti software è difficile e sono stati scritti numerosi libri e sono stati sviluppati vari processi per gestirlo.

Se l' unico obiettivo del PM fosse produrre stime esatte, sarebbe facile. Riempi le stime con 10X e lascia che gli sviluppatori giochino per il resto se finiscono presto. Questo sarebbe effettivamente meglio del tuo suggerimento di utilizzare il copia-incolla diworkwork per ridurre il tempo, poiché i giochi non ridurranno la manutenibilità del prodotto.

Ma in realtà, il proprietario del prodotto desidera preventivi utili e un prodotto di qualità consegnato nel modo più rapido ed economico possibile. Questi sono gli effettivi vincoli che un PM dovrà percorrere.

In ogni caso, contesto il tuo presupposto che il lavoro manuale ripetitivo sia più prevedibile che automatizzato. Tutta l'esperienza mostra che il lavoro manuale ripetitivo è più soggetto a errori. E se viene rilevato un bug nel codice incollato? Improvvisamente, il costo della correzione di un bug si moltiplica per la quantità di ripetizione, il che fa esplodere l'incertezza.

Hai ragione: copia e incolla funziona alla grande, e DRY non ha senso quando il tuo compito è quello di produrre un programma per il quale il modello o la copia copiati non dovranno essere mantenuti o evoluti in futuro. Quando questi due componenti software hanno un ciclo di vita completamente diverso, accoppiandoli insieme refactoring del codice comune in una lib comune che è essa stessa sotto forte sviluppo può effettivamente avere effetti imprevedibili per lo sforzo. D'altra parte, quando si copiano sezioni di codice all'interno di un programma o di un sistema di programma, tutte queste parti avranno generalmente lo stesso ciclo di vita. Illustrerò di seguito cosa significa DRY e project management.

Seriamente, ci sono molti di questi programmi là fuori: ad esempio, l'industria dei videogiochi produce molti programmi che devono essere mantenuti per un breve periodo di alcuni mesi o un anno al massimo, e quando quel tempo è finito, copia-incolla il vecchio codice di un gioco precedente in cui è stato superato il periodo di manutenzione, nella base di codici di un nuovo gioco va benissimo e potrebbe accelerare le cose.

Sfortunatamente, il ciclo di vita della maggior parte dei programmi che ho dovuto affrontare negli ultimi anni è molto diverso da quello. Il 98% dei requisiti o richieste di correzione di bug che mi sono arrivati ​​erano richieste di modificaper i programmi esistenti. E ogni volta che devi cambiare qualcosa in un software esistente, la "gestione del progetto" o la pianificazione funzionano meglio quando i tuoi sforzi di test e debugging sono piuttosto bassi - il che non sarà il caso se cambi qualcosa in un posto, ma a causa della copia logica aziendale superata che dimentichi facilmente che devi cambiare anche una dozzina di altre posizioni nella base di codice. E anche se riesci a trovare tutti quei posti, il tempo per cambiarli tutti (e testare le modifiche) è probabilmente molto più alto come se avessi un solo posto dove cambiare. Quindi anche tu potresti fare una stima accurata per il cambiamento, avendo i costi una dozzina di volte più alti di quanto deve essere può facilmente scontrarsi con il budget del progetto.

TLDR - ogni volta che si sviluppa un programma in cui non è necessaria o responsabilità per la correzione di errori e la manutenzione dell'originale o della copia, sentirsi liberi di copiare. Ma se tu, il tuo team o la tua azienda sei o potresti diventare responsabile, applica DRY ogni volta che puoi.

Esempio

Come addendum, lasciami spiegare cosa significa "correzione e correzione di bug" e come ciò porta a imprevedibilità nella pianificazione, specialmente all'interno di un prodotto, da un esempio reale. In realtà ho visto accadere questo genere di cose nella realtà, probabilmente non con 100 istanze, ma i problemi possono anche iniziare quando hai solo un'istanza duplicata.

Il compito: creare 100 report diversi per un'applicazione, ogni report sembra molto simile, alcune differenze di requisiti tra i report, alcune logiche diverse, ma tutto sommato, non molte differenze.

Lo sviluppatore che ottiene questa attività crea la prima (diciamo che impiega 3 giorni), dopo che alcune modifiche o correzioni di bug minori dovute al controllo qualità e all'ispezione del cliente è terminata, sembra funzionare correttamente. Quindi ha iniziato a creare il rapporto successivo copiando e incollando tutto, quindi il successivo, e per ogni nuovo rapporto ha bisogno di circa 1 giorno in media. Molto prevedibile, a prima vista ...

Ora, dopo che i 100 report sono "pronti", il programma passa alla produzione reale e si verificano alcuni problemi che sono stati trascurati durante il QA. Forse ci sono problemi di prestazioni, forse i rapporti si bloccano su base regolare, forse altre cose non funzionano come previsto. Ora, quando era stato applicato il principio DRY, il 90% di questi problemi poteva essere risolto cambiando la base di codice in un unico posto. Ma a causa dell'approccio copia-incolla, il problema deve essere risolto 100 volte anziché una volta. E a causa delle modifiche già applicate da un report all'altro, lo sviluppatore non può copiare e incollare rapidamente la correzione per il primo report nell'altro 99. Deve esaminare tutti i 100 report, leggerli, tradurre la modifica nella modifica segnalare, testarlo e forse eseguire il debug di ciascuno di essi singolarmente. Per il Primo Ministro, questo inizia a diventare davvero difficile - può ovviamente prendersi il tempo per una correzione di bug "regolare" (diciamo, 3 ore) e moltiplicarlo per 100, ma in realtà, questa è probabilmente una stima sbagliata, alcune delle correzioni potrebbero essere più facile da realizzare rispetto ad altri, altri potrebbero essere più difficili. E anche se questa stima è corretta, avere il debug costa 100 volte più alto del necessario e costerà alla tua azienda un sacco di soldi.

Lo stesso accadrà la prossima volta in cui il cliente chiederà di cambiare il colore dell'emblema della sua azienda in tutti quei rapporti, di rendere configurabile la dimensione della pagina o di qualche altro nuovo requisito che influisca su tutti i rapporti in modo simile. Quindi, in tal caso, è possibile effettuare una stima dei costi e fatturare al cliente 100 volte il prezzo che dovrebbe pagare quando il codice fosse stato ASCIUTTO. Tuttavia, provalo alcune volte e il cliente annullerà il progetto perché probabilmente non sarà disposto a pagare i tuoi esorbitanti costi di evoluzione. E forse a quel punto qualcuno farà la domanda sul perché ciò sia accaduto e indicherà con il dito la persona che ha preso la decisione per questa programmazione copia-incolla.

Il mio punto è: quando produci software per gli altri, hai sempre almeno per un breve periodo di tempo la responsabilità di far funzionare la cosa, correggere bug, adattare il programma ai mutevoli requisiti ecc. Anche in un progetto green-field, questi le parti possono rapidamente aggiungere molto di più rispetto allo sforzo di sviluppo inizialmente previsto. E soprattutto quando tutto il tuo codice incollato è all'interno di un prodotto, il periodo di responsabilità è uguale per tutte le parti, il che è abbastanza diverso dalla situazione in cui hai incollato del codice precedente da un progetto morto che non è più sotto manutenzione attiva.

Quindi, dal punto di vista della gestione del progetto, è bello risolvere un'attività copiando 100 volte il codice esistente e apportando alcuni adattamenti minori a ciascuna copia, come richiesto. In ogni momento, sai esattamente quanto lavoro hai svolto e quanto è rimasto. Tutti i manager ti adoreranno.

L'asserzione di base non è corretta.

La cosa che rende il software diverso dalle altre professioni è che stai facendo qualcosa di nuovo ogni giorno. Dopo tutto, nessun cliente sta andando a pagare voi per costruire qualcosa che qualcun altro ha già fatto. Ai project manager potrebbe piacere la prevedibilità, ma ai loro capi piace il valore . Se stai semplicemente incollando il codice con lievi variazioni, non stai fornendo molto valore per l'azienda.

Alla fine la società realizzerà di poter fare lo stesso lavoro in una frazione del tempo assumendo un buon programmatore. E se non lo fanno, lo faranno i loro concorrenti.

La programmazione taglia e incolla alla fine porta a software abbandonato. Ero un appaltatore di un sistema per ordinare servizi di telefonia mobile da una grande compagnia telefonica. Il sistema è stato tagliato e incollato alla nausea perché tutti i test erano manuali e non volevano cambiare alcun codice funzionante. Il più piccolo miglioramento potrebbe comportare una nuova copia di centinaia di righe di codice. Inizialmente l'applicazione era stata scritta per gestire account con un massimo di dodici righe fisiche. Ovviamente questa limitazione è stata fatta in centinaia di posizioni nel codice. Dopo circa quattro anni gli affari hanno chiesto al team cosa ci sarebbe voluto per gestire account più grandi. Hanno stimato circa $ 18 milioni. A quel punto il progetto è stato consegnato a un team offshore per una manutenzione minima. La squadra esistente è stata licenziata.

Le organizzazioni che la pensano in questo modo vengono schiacciate dalle aziende con una tecnologia migliore.

Una massima spesso dimenticata che si applica qui è la regola di 3 . Questo afferma che è OK copiare il codice una volta, ma oltre a ciò dovrebbe essere sostituito da un codice generico.

3 potrebbe sembrare un numero arbitrario ma uno scenario comune è quello in cui i dati e la logica sono duplicati in un'applicazione e in un database. Un esempio spesso citato è dove c'è una tabella di ricerca nel database e un lato client di enumerazione. La differenza nei paradigmi non consente che questo sia facilmente memorizzato in un unico posto e quindi le informazioni appaiono spesso in entrambi i posti.

Mentre è bello avere un codice DRY, ci possono essere momenti in cui la logica aziendale detta un'eccezione e quindi è necessario creare due o più bit di codice dall'origine che in precedenza era generica.

Quindi che si fa? Codice per lo status quo (dopo tutto, YAGNI ). Mentre il codice dovrebbe essere scritto per facilitare le modifiche, scrivere un'intera serie di campane e fischietti per qualcosa che potrebbe non essere necessario è solo bruciare soldi.

Nella tua domanda, elenchi solo tre funzioni di gestione del progetto: stima, pianificazione e controllo. La gestione del progetto riguarda il raggiungimento degli obiettivi entro i limiti del progetto. I metodi utilizzati per raggiungere gli obiettivi nei limiti di un progetto sono diversi per i progetti software rispetto a molti altri tipi di progetti. Ad esempio, si desidera che i processi di produzione siano altamente ripetibili e ben compresi. Tuttavia, lo sviluppo del software è principalmente un lavoro di conoscenza- è non routinario e richiede pensiero piuttosto che seguire rigide istruzioni e procedure. Le tecniche utilizzate per avviare, pianificare, eseguire, monitorare e controllare e chiudere un progetto software dovranno tenere conto del tipo di lavoro che deve essere fatto su un progetto software - in particolare, lavoro non di routine che non può essere fatto alle istruzioni e procedure specifiche.

Penso che l'altro problema sia che stai prendendo DRY, un concetto che si riferisce alla ripetizione delle informazioni e cerchi di applicarle alla gestione delle attività. DRY dice semplicemente che dovresti avere una sola rappresentazione autorevole di informazioni. I project manager dovrebbero abbracciarlo, poiché significa che tutti sapranno dove andare per le informazioni, comunicare i cambiamenti sarà facile e i cambiamenti potranno essere controllati e gestiti bene. DRY, attraverso pezzi riutilizzabili, aiuta a contenere i costi a lungo termine, aiuta a mantenere i programmi a lungo termine e a migliorare la qualità: tre pezzi nel triangolo di gestione del progetto . Ci vuole un certo investimento di tempo e denaro speso per rendere le cose ESSENZIALI efficaci, ma il compito del project manager è quello di fare un compromesso di tempo, costi, pianificazione e qualità.

La scrittura di nuovo codice è solo una piccola parte dell'attività

Il tuo suggerimento semplificherebbe la stima della parte di scrittura iniziale del nuovo codice. Tuttavia, per portare effettivamente qualcosa di nuovo (non importa se si tratta di un sistema nuovo di zecca, un'aggiunta di funzionalità o un cambiamento di funzionalità) farlo non è sufficiente ed è solo una minoranza di lavoro - le stime viste in letteratura dicono che in pratica questo parte è qualcosa come il 20% -40% del lavoro totale.

Quindi la maggior parte del lavoro (che include l'adattamento del tuo sviluppo iniziale a ciò che era effettivamente necessario, l'integrazione, i test, la riscrittura, i test) non diventa più facile da stimare; viceversa, evitando intenzionalmente DRY ha appena reso quella parte molto più grande, più difficile e con stime più variabili - quell'errore o necessità di cambiamento che richiede la modifica di tutte le parti clonate potrebbe non accadere, ma se lo fa, allora le tue stime saranno totalmente sbagliati.

Non si ottengono stime migliori migliorando la qualità della stima di una piccola parte del lavoro ma peggiorando la maggior parte del lavoro; quindi non è davvero un compromesso, ma una situazione perdente in cui si ottiene una produttività peggiore ma anche stime peggiori.

DRY è utile ma è anche sopravvalutato. Alcune persone possono andare troppo lontano. Ciò che molti sviluppatori non riescono a capire è che ogni volta che si implementa DRY per utilizzare lo stesso metodo per due (leggermente) scopi diversi, si sta introducendo una sorta di accoppiamento molto stretto tra i diversi usi. Ora ogni volta che si modifica il codice per il primo caso d'uso, è necessario verificare anche se regredisce nel secondo caso d'uso. Se si tratta di casi d'uso ampiamente indipendenti, è molto discutibile se debbano essere strettamente accoppiati - probabilmente non dovrebbero esserlo.

L'uso eccessivo di DRY può anche portare a metodi divini che esplodono in complessità per gestire tutti i diversi casi d'uso in cui sono posti, quando metodi atomici generalmente più piccoli che replicano un po 'di codice sarebbero molto più mantenibili.

Tuttavia, suggerirei che la domanda non è realmente pertinente a livello di gestione del progetto. Un project manager non vorrà davvero preoccuparsi di questo livello di dettagli di implementazione. Se lo sono, probabilmente è una micro-gestione. Davvero ... come vengono implementate le cose è più responsabilità dello sviluppatore e responsabile tecnico. Il project management è più interessato a ciò che viene fatto e quando .

MODIFICA: per commento, concordo tuttavia sul fatto che, nel rendere più semplice la stima dei tempi di sviluppo, evitare la DEUMINAZIONE a volte può ridurre la quantità di incertezza. Ma credo che questa sia una questione insignificante in relazione alle domande più urgenti di (1) per quanto tempo fino al soddisfacimento dei requisiti aziendali, (2) quale debito tecnico viene preso in considerazione nel processo e (3) rischi per il costo totale di la proprietà delle scelte architettoniche fatte - se andare in SECCO o meno in molti casi è una scelta progettuale che dovrebbe essere basata più sul rischio / rendimento di quei fattori, piuttosto che sul rendere un po 'più facile fornire ai project manager informazioni più accurate .

Penso che tu stia fraintendendo DRY.

Facciamo un esempio:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

public Class B
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }

    public int Add(int x, int y)
    {
        return x + y;
    }
}

vs.

public Class C : A
{
    public int Add(int x, int y)
    {
        return x + y;
    }
}

Sostituendo la classe B con C abbiamo seguito il principio DRY e ridotto la duplicazione del codice. Ma non abbiamo aumentato le incognite o il rischio per il progetto (a meno che tu non abbia mai fatto l'eredità prima).

Penso che cosa intendi quando parli di DRY è qualcosa di più simile a un'attività di progettazione. Vale a dire:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

!!! Nuovo requisito! Alcuni clienti devono essere in grado di moltiplicare i doppi !!

// Use class B for new clients!!
public Class B
{
    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

vs.

public Class A // Version 2
{
    public int Multiply(int x, int y)
    {
        return Multiply(x as double, y as double);
    }

    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

Qui (supponendo che funzioni) abbiamo progettato una soluzione in grado di gestire sia il vecchio che il nuovo requisito, essenzialmente cercando di creare un modello matematico del problema della vita reale o delle regole aziendali. Nella vita reale il sistema che stiamo modellando sarà ovviamente molto più complicato, il nostro modello non si adatterà esattamente e i casi limite e i risultati inaspettati richiederanno tempo per trovare e correggere.

Quindi, dovremmo prendere B o A versione 2 in questo caso?

• B sarà più specifico dell'effettiva modifica richiesta con meno effetti collaterali e sarà più facile da stimare e più rapido da fare.

• Una versione 2 comporterà una riduzione del codice complessivo e sarà la soluzione più elegante

Ancora una volta dirò che dipende dalla qualità delle specifiche e dei requisiti.

Se disponiamo di specifiche molto chiare che coprono i casi limite e la compatibilità con le versioni precedenti, allora possiamo essere sicuri di comprendere il sistema abbastanza bene da riformattare il modello senza produrre bug.

Se abbiamo una richiesta di emergenza per un singolo cliente in cui l'unico requisito è che il comportamento cambi per quel cliente senza considerare l'intero sistema; quindi 'migliorare' il modello refactoring A comporta un rischio sostanziale. Sia di rompere gli altri clienti o di superare la scadenza a causa del tempo extra sconosciuto necessario per progettare e testare la soluzione.

Paragrafo per paragrafo

Uno dei principi più basilari e ampiamente accettati dello sviluppo software è DRY (non ripeterti). È anche chiaro che la maggior parte dei progetti software richiede un qualche tipo di gestione.

Corretta.

Ora quali sono le attività che sono facili da gestire (stima, pianificazione, controllo)? Compiti giusti e ripetitivi, esattamente i compiti che dovrebbero essere evitati secondo DRY.

Le attività ripetitive dovrebbero essere automatizzate, obbligatorie . Sono noiosi, soggetti a errori, se fatti a mano.

Quindi, dal punto di vista della gestione del progetto, è bello risolvere un'attività copiando 100 volte il codice esistente e apportando alcuni adattamenti minori a ciascuna copia, come richiesto. In ogni momento, sai esattamente quanto lavoro hai svolto e quanto è rimasto. Tutti i manager ti adoreranno.

Penso che tu possa cambiare la parola "adattamento" con "configurazione". Considera di avere un bug in questo pezzo di codice che dovrebbe essere copiato. Un bug che appare in condizioni specifiche. Se non è stato risolto nella fonte originale ed è stato copiato, ci saranno molti posti da correggere. Questo può essere negativo, ma poi qualcuno deve:

• per prima cosa correggi il codice nel sorgente originale;
• ripari il codice in ogni altro posto;
• assicurati che quelli fossero tutti i posti. Quando dici che questo deve essere fatto al manager, probabilmente odierà qualcuno.

Se invece applichi il principio DRY e cerchi di trovare un'astrazione che elimini più o meno il codice duplicato, le cose sono diverse. Di solito ci sono molte possibilità, devi prendere decisioni, fare ricerche, essere creativo. Potresti trovare una soluzione migliore in tempi più brevi, ma potresti anche fallire. Il più delle volte, non puoi davvero dire quanto lavoro è rimasto. Sei il peggior incubo di un project manager.

La rimozione di duplicati porta a un singolo punto di errore. Se qualcosa non riesce puoi essere abbastanza sicuro di dove questo accada. I motivi SOLID e Design sono lì per aiutarti a risolvere esattamente quel problema. Scadenze troppo brevi tendono a provocare una "codifica" dello stile procedurale. Più tempo investito in un progetto per creare qualcosa di riutilizzabile significa che dovrebbe esserci una quantità minima di tempo trascorso nel progetto successivo quando la funzione verrà riutilizzata, ma dovrebbe essere configurabile in primo luogo.

Certo che sto esagerando, ma c'è ovviamente un dilemma. Le mie domande sono: quali sono i criteri per decidere se uno sviluppatore sta esagerando a SECCO? Come possiamo trovare un buon compromesso? O c'è un modo per superare completamente questo dilemma, non solo trovando un compromesso?

Molte persone hanno indicato che qui non c'è nessun dilemma. Sì e no.

Se hai qualcosa di altamente sperimentale che non hai mai fatto prima, non c'è nessun dilemma. Altrimenti se hai qualcosa che deve essere fatto di nuovo, come il nuovo sistema di prenotazione hai già delle astrazioni, dipende solo da ciò di cui hai bisogno.

Penso che il dilemma sia: dovremmo implementare qualcosa in una funzione, se è improbabile che venga richiesto. Implementare qualcosa quando richiesto. Nessuno ha bisogno di una grande infrastruttura che non verrà utilizzata.

non si tratta affatto di progettare per il futuro riutilizzo o del principio YAGNI. Si tratta di ripetere il codice nel pacchetto di lavoro corrente.

Si tratta assolutamente di design. Forse non riutilizzare di per sé, ma comunque progettare.

Quali sono i criteri per decidere se uno sviluppatore sta esagerando a SECCO?

Esperienza e ambiente / situazione esistente. Per un dato problema otterrai un forte senso del Principio del Prado mentre provi maggiori gradi di ASCIUGATURA. Poi all'improvviso vengono in gioco considerazioni sulla gestione. Tempo, obiettivi, cliente, gestione del codice a lungo termine (qualcuno ha detto debito tecnico ), ecc. Informeranno il tuo piano di attacco.

Come possiamo trovare un buon compromesso?

Uh ... design? Il refactoring è design, beh dovrebbe essere. L'ambito del DRYing può facilmente espandersi come una super nova dal loop, al metodo, alle classi. Ci sono stato, l'ho fatto. Ma non puoi davvero saperlo fino a quando non studi il problema: questo è design.

Come può non essere un problema di progettazione? È necessario considerare il problema in modo più ampio rispetto al codice duplicato immediato a portata di mano. Questa è un'attività di progettazione che si tratti di codice esistente o di un foglio bianco; che si tratti del "metodo extract" o della creazione di nuove classi e moduli.

Epilogo

... la domanda sottoposta e le sue risposte non coprono l'aspetto della gestione del progetto.

Gestione tipica, ignorando i tempi di progettazione. Idealmente, avremmo progettato la ripetitività superflua ridondante prima della codifica. Invece, il management pensa che lo sviluppo (e correzioni di bug) sia un singolo evento olimpico - la codifica - quando in realtà è un decathlon. E misurano a 1/1000 di secondo perché pensano che sia tutto analogico.

Se invece applichi il principio DRY e cerchi di trovare un'astrazione che elimini più o meno il codice duplicato, le cose sono diverse.

Ho avuto questa esperienza: "Ho trascorso due giorni a scrivere questa riga (di un modulo GUI) e due ore a scrivere il resto del modulo." Voglio dire che mi sono preso il tempo di identificare le classi riutilizzabili - DRY è un effetto collaterale naturale - la riga del modulo GUI e in quella altre. Una volta eseguito il debug, questi sono stati utilizzati, individualmente e nella composizione, in tutto il modulo che ora ha codificato molto velocemente e i test sono stati eccezionalmente rapidi nonostante la complessità di costruzione. E ha anche superato test formali con una percentuale di bug sorprendentemente bassa.

Il più delle volte, non puoi davvero dire quanto lavoro è rimasto. Sei il peggior incubo di un project manager.

Neanche io lo sapevo, ma credevo che lo sforzo di progettazione iniziale avrebbe dato i suoi frutti. Lo diciamo tutti, ma la direzione in particolare non se ne fida. La direzione avrebbe pensato che stavo scherzando. "Due giorni e non hai nemmeno il 2% di esso ancora codificato!"

In un caso siamo rimasti fedeli alle nostre pistole quando il management ha detto "stai spendendo troppo tempo nel design, vai avanti". E i colleghi che dicono "sono troppe classi". Bene, un sotto-progetto molto meno complesso avrebbe dovuto durare circa 1 mese (pensavo fosse OK ipotesi) ma ci sono voluti 5 mesi. Di questi 3 mesi sono stati testati / riparati perché era un simile POS. "Ma non abbiamo avuto il tempo di progettare!". Lo hanno effettivamente detto.

Le mie domande sono: quali sono i criteri per decidere se uno sviluppatore sta esagerando a SECCO? Come possiamo trovare un buon compromesso? O c'è un modo per superare completamente questo dilemma, non solo trovando un compromesso?

Mostra alla direzione come funziona. Cattura alcuni dati. Confronta con altri lavori, in particolare quello dei tuoi colleghi che svolgono il lavoro precipitoso. Quel mucchio di insuccessi sembra sempre perdere la gara, rimanere bloccati nei test e poi dopo il rilascio è tornato più volte per correggere altri bug.