Come tagliare la linea tra qualità e tempo? [duplicare]

Question

Come tagliare la linea tra qualità e tempo? [duplicare]

#1 da (4 voti)
#2 da (2 voti)
#3 da (2 voti)

-1

Da un lato, mi è stato insegnato da vari libri di ingegneria del software ([1] come esempio) che il mio lavoro di programmatore è quello di creare il miglior software possibile: grande design, flessibilità, facilità di manutenzione, ecc.

D'altra parte, anche se mi rendo conto che in realtà scrivo software per soldi e non per intrattenimento, anche se è molto bello scrivere un buon codice e pianificare in anticipo e refactoring dopo la scrittura e ... mi chiedo se è sempre meglio per il affari (dopotutto dovremmo essere responsabili). L'azienda beneficia sempre di un codice migliore? Forse sto sovrastimando qualcosa, e non è sempre utile?

Quindi come faccio a sapere quando fermarmi nel processo per ottenere il miglior codice possibile? Sono sicuro che l'esperienza è qualcosa che fa la differenza qui, ma credo che questa non possa essere l'unica risposta.

[1] Uncle Bob's in Clean Code dice a pagina 6 che:

They [managers] may defend the schedule and requirements with passion; but that’s their job. It’s your job to defend the code with equal passion.

code-quality productivity time-management

posta m3th0dman 20.10.2013 - 22:27

fonte

3 risposte

Leggi altre domande sui tag code-quality productivity time-management

Algoritmo per generare tutte le possibili immagini di una particolare dimensione in 256 colori Metodi di interfaccia non implementati [chiuso]

score 4 · Answer 1

Non c'è linea tra qualità e tempo. C'è il triangolo di gestione dei progetti :

Laqualitàèunafunzionediquestialtrifattori:tempo,costieambito.Nonimportaciòchevuoichesialaqualità,sehaiachefareconfixed-cost/fixed-scopeeconunariduzionedeitempidisponibili,laqualitàdiminuiscediconseguenza.

Forsequellodicuistaiparlandoèla"definizione di fatto" usata da molte diverse metodologie (specialmente quelle Agili). Spetta al tuo team aziendale e tecnologico concordare. Ad esempio, nel nostro team significa 80% di copertura del test unitario, 80% di copertura delle funzioni di test di accettazione, tutto il contenuto approvato e tradotto dai team di marketing e eventuali bug di regressione risolti o declassati dal product manager. Ci sono alcune altre cose, ma tu hai l'idea.

Non ci sarà mai alcuna barra per la "qualità del codice" perché significa cose diverse per persone diverse. La programmazione di coppie e la revisione del codice sono strumenti utili per mantenere la qualità del codice ragionevolmente alta - se altre persone del tuo team riescono a comprenderlo e mantenerlo senza sentirsi male allo stomaco, probabilmente è abbastanza buono.

Se vuoi istituire metriche come checkstyle o FXCop, analisi delle dipendenze, copertura del codice, CRAP, ecc., dipende da te e dal tuo team, puoi renderlo parte della tua definizione di fatto se vuoi. I proprietari delle tue attività vorranno probabilmente comprendere il valore di queste varie cose per te, perché le consideri importanti e perché devono essere fatte prima che una funzione sia rilasciabile. Se non puoi giustificarlo, non farlo.

score 2 · Answer 2

Bob Martin parla della tensione tra le parti con obiettivi in conflitto ,. Sta suggerendo che è tua responsabilità come Altoparlante per il Codice difenderlo e aumentare la sua qualità. Suppone che ci siano altri che sosterranno il bisogno o il desiderio dell'azienda di appesantire altri articoli ( ad es. , scadenze) più in alto di quanto non siate. Quando la tensione tra i desideri di tutte le parti è in equilibrio, il risultato sarà ottimale per il business. Quando il desiderio di una delle parti è troppo strong o troppo debole, il risultato sarà subottimale. Come programmatori, possiamo fornire un codice perfetto, ma così facendo, possiamo far sì che la nostra azienda non si adegui ai suoi tempi di mercato e lasci tutti i dipendenti della compagnia in disoccupazione. I manager possono raggiungere perfettamente le scadenze, ma nel fare ciò, potrebbero negarci il tempo e le risorse di cui abbiamo bisogno per produrre un codice di qualità accettabile, portando allo stesso risultato.

score 2 · Answer 3

So how should I know when to stop in the process to achieving the best possible code? I am sure that experience is something that makes a difference here, but I believe this cannot be the only answer.

Non è necessario ottenere il miglior codice possibile, ma scrivere un codice che sta diventando il migliore possibile e offre la minima resistenza possibile quando lo spingi in questa direzione.

Quando progetti il tuo programma, puoi verificare la qualità del design considerando i probabili scenari per l'evoluzione futura della funzionalità del tuo programma e capire quanto difficile o quanto facile questi sviluppi sarebbero in relazione con il tuo progetto.

EDIT - (Una risposta a @Aaronaught, che è troppo lungo per un commento.) Non volevo dire che considerando gli scenari probabili sia l'unico criterio per verificare la robustezza di un progetto. Ovviamente, devono essere soddisfatti casi d'uso e requisiti, prima di controllare qualcos'altro. Ma se li consideri solo, allora c'è un taglio netto tra qualità e tempo.

Il miglior programma possibile è internazionalizzato, può recuperare delicatamente dagli errori o fornire una diagnostica dettagliata, usa un toolkit GUI non così vecchio (se il cliente importa), ha un explorer di dati che ti aiuterà a individuare gli errori nell'input e così sopra. Ma anche se non abbiamo bisogno di costruire tutto dall'inizio, può essere utile prendere provvedimenti in modo che queste aggiunte prevedibili possano essere fatte facilmente.