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.