Buona correzione vs Risoluzione rapida [duplicato]

0

Partiamo da questo principio: la qualità è una funzione che non puoi aggiungere a un progetto nel bel mezzo del processo di sviluppo.

Questo è lo scenario: due settimane per andare a vivere con il mio progetto e, uno degli sviluppatori ha aggiunto un metodo specifico utilizzato solo per un'applicazione web al nostro framework (il nostro framework è un rimbalzo di classi java utilizzate per estrarre contenuti da MongoDB , Alfresco, mySql ed è utilizzato dalle applicazioni Web). Sono il caposquadra e gli ho detto di generalizzare il metodo per mantenere il framework in modo da essere riusabile, ma ha detto "no, preferisco non farlo perché ci sono molti bug che devono essere corretti". Il manager è d'accordo con lui e ovviamente non lo sono.

È meglio fare uno sforzo extra per mantenere un framework libero da qualsiasi implementazione specifica (probabilmente usato solo da un'applicazione web) o semplicemente aggiungere i metodi perché funziona?

Quindi, la mia domanda è: è corretto scrivere codice che funziona solo o è meglio scrivere codice che funzioni ma non fa schifo (cioè aggiungere valore incorporato, metodi specifici, classi extra, aggiungere una colonna al database, ecc. )? Come è possibile giustificare il tempo extra (per essere onesti, questo tipo di correzione richiede 10 minuti in più per scrivere un buon codice generico) per la gestione? Come è possibile sostenere che è il modo giusto di scrivere codice per giovani sviluppatori e PM? in generale, una buona correzione o una soluzione rapida?

Ah, 10 minuti dopo aver ricevuto l'e-mail da PM, mi ha chiesto perché in un URL dell'applicazione 2 c'era il nome dell'applicazione 1 durante il login?

Mi piace citare Jeff Atwood: "Non lasciare" finestre non funzionanti "(cattive progettazioni, decisioni sbagliate o codice scadente) non riparate. Correggi ognuna appena viene scoperta."

Estratto da: Hyperink. "How-To-Stop-Succhiare-and-be-Impressionante, invece." iBook.

    
posta Andrea Girardi 11.11.2013 - 11:54
fonte

1 risposta

5

Le risposte a molte di queste domande iniziano "Tutti gli altri sono uguali ...".

Se hai due settimane di tempo per la spedizione, il tuo manager avrà molte chiamate impegnative tra il rilascio di funzionalità buggy, l'applicazione tempestiva di patch ai bug o l'adesione all'ideale di un framework applicativo pulito e ben sviluppato e possibilmente consegnando in ritardo o oltre il budget. In fin dei conti ciò che conta è che i clienti siano felici e paghino, quindi penso che devi fidarti del suo giudizio. Quello che potrebbe sembrare 10 minuti di lavoro extra da rispettare per il design potrebbe non essere solo di 10 minuti per un giovane; quello che potrebbe sembrare che tu sia un grande codice riutilizzabile potrebbe sembrare essere placcatura d'oro per il cliente. La citazione di Jeff Attwood va benissimo, ma se hai finestre rotte più di quanto tu abbia tempo di sistemare, devi dare la priorità a quelle che la pioggia sta attraversando ...

Ovviamente quando ha la visione opposta a te, devi quindi essere quello che parla per rivisitare tutte le soluzioni rapide e garantire il test di regressione una volta che le scadenze immediate sono passate.

    
risposta data 11.11.2013 - 12:13
fonte