Come implementare il codice in modo da ridurre la possibilità di reinterpretazioni complete

Question

Ho avuto un pezzo di lavoro buttato fuori a causa di una modifica di piccola specifica che risultava non essere stata specificata correttamente. Se fosse stato fatto proprio all'inizio del progetto, la maggior parte di questo lavoro è would have never have been needed in the first place.

Quali sono alcuni buoni consigli/principi di progettazione che impediscono che queste cose accadano?

O per ridurre la quantità di rielaborazione al codice necessario per implementare richieste di funzionalità o modifiche di progettazione a metà dell'implementazione?

Answer 1

Modularize. Crea piccoli blocchi di codice che facciano bene il loro lavoro. Tuttavia, questo è solo l'inizio. Solitamente è una grande combinazione di fattori che contribuiscono al codice così male da richiedere una rielaborazione completa. Tutto da requisiti altamente instabili, design scadente, mancanza di proprietà del codice, l'elenco potrebbe continuare all'infinito.

Aggiungendo a ciò che altri hanno educato: COMUNICAZIONE.
Comunicazione tra voi e il cliente, voi e la gestione, voi e gli altri sviluppatori, voi e il vostro dipartimento di QA, la comunicazione tra tutti è la chiave. Assicurati che il management capisca i tempi ragionevoli e si assicuri che tu e il cliente comprendiate esattamente che cosa è il vostro edificio.

Answer 2

Prenditi del tempo per tenere aperta la comunicazione con il cliente per il quale costruisci il prodotto. Fai delle pietre miliari e imposta un orario per mostrare il progetto al cliente in ogni momento fondamentale. Anche se il cliente è completamente deluso da una pietra miliare quando lo mostri, puoi grattare ciò che hai e ricominciare dall'ultimo traguardo. Ciò richiede anche che il tuo lavoro sia costruito in blocchi che funzionano indipendentemente l'uno dall'altro come ha affermato Csunwold.

Punti ...

1. mantenere aperta la comunicazione
2. essere aperto e onesto con il progresso del prodotto
3. essere disposti a cambiare ogni giorno per vedere le esigenze del business dei clienti e le specifiche per il cambio prodotto .

Answer 3

Come ha detto csunwold, la modularizzazione del codice è molto importante. Scrivilo in modo che se un pezzo si inclina agli errori, non fa saltare il resto del sistema. In questo modo, puoi eseguire il debug di una singola sezione buggy pur essendo in grado di fare affidamento sul resto.

Oltre a ciò, la documentazione è fondamentale. Se il tuo codice è chiaramente e chiaramente annotato, rielaborarlo in futuro sarà infinitamente più facile per te o per chiunque stia eseguendo il debug.

Anche l'utilizzo del controllo del codice sorgente può essere utile. Se trovi che una parte di codice non funziona correttamente, c'è sempre l'opportunità di tornare a una precedente e solida iterazione.

Answer 4

Sebbene non si applichi direttamente al tuo esempio, quando scrivo codice cerco di tenere d'occhio i modi in cui posso vedere il software evolvere in futuro.

Fondamentalmente cerco di anticipare dove il software andrà, ma criticamente, resisto alla tentazione di implementare qualsiasi delle cose che posso immaginare accadendo. Tutto quello che sto cercando è di far sì che le API e le interfacce supportino possibili futuri senza implementare quelle funzionalità, nella speranza che questi "possibili scenari" mi aiutino a trovare un'interfaccia migliore e più a prova di futuro.

Non sempre funziona naturalmente.

Answer 5

I requisiti software cambiano, e non c'è molto che si possa fare a questo proposito tranne che per un'interazione più frequente con i clienti.

Si può, tuttavia, creare codice più robusto di fronte al cambiamento. Non ti salverà dal lancio di codice che soddisfa un requisito che nessuno ha più bisogno, ma può ridurre l'impatto di tali cambiamenti.

Ad esempio, ogni volta che ciò si applica, utilizzare le interfacce anziché le classi (o l'equivalente nella propria lingua) ed evitare di aggiungere operazioni all'interfaccia, a meno che non si sia assolutamente certi di averne bisogno. Costruendo i tuoi programmi in questo modo è meno probabile che tu possa fare affidamento sulla conoscenza di un'implementazione specifica, e hai meno probabilità di implementare cose che non ti serviranno.

Un altro vantaggio di questo approccio è che è possibile scambiare facilmente un'implementazione con un'altra. Ad esempio, a volte vale la pena di scrivere il più stupido (in termini di efficienza) ma il più veloce per scrivere e testare l'implementazione per il tuo prototipo e sostituirlo con qualcosa di più intelligente alla fine quando il prototipo è la base del prodotto e le prestazioni effettivamente questioni. Trovo che questo sia un modo molto efficace per evitare ottimizzazioni premature e quindi buttare via cose.

Answer 6

• iterate piccola

• iterate spesso

• prova tra le iterazioni

• ottenere un prodotto di lavoro semplice al più presto in modo il cliente può dare un contributo.

Fondamentalmente assumere cose andranno buttati fuori, quindi il codice in modo appropriato, e non si ottiene abbastanza lontano in qualcosa che averlo essere buttato fuori costa un sacco di tempo.

Answer 7

modularità è la risposta, come è stato detto. ma può essere una risposta difficile da usare nella pratica. suggerisco concentrandosi su:

• piccole biblioteche che fanno cose predefinite ben
• minime dipendenze tra i moduli

interfacce di scrittura prima è un buon modo per raggiungere entrambi questi (con interfacce utilizzate per la dipendenze). test di scrittura successivo, contro le interfacce, prima che il codice venga scritto, spesso evidenzia scelte di progettazione che non sono modulari.

Non so se l'app è intensiva in UI; ciò può rendere più difficile la modularità. di solito vale la pena, ma se non si assume che in seguito sarà gettato via e seguirà il principio dell'iceberg, quel 90% del lavoro non è legato all'interfaccia utente e quindi più semplice da mantenere modulare.

infine, consiglio "il programmatore pragmatico" di andrew hunt and dave thomas pieno di consigli. il mio preferito è DRY - "non ripeterti" - qualsiasi codice che dice la stessa cosa due volte.

Answer 8

G'day,

Guardando attraverso le altre risposte qui ho notato che tutti sono menzionare che cosa fare per il vostro prossimo progetto.

Una cosa che sembra mancare però è avere un wash-up per scoprire perché le specifiche. era fuori sincrono con i requisiti effettivi richiesti dal cliente.

Sono solo preoccupato che se non lo fai, non importa quale approccio tu stia adottando per implementare il tuo prossimo progetto, se hai ancora quel disallineamento tra i requisiti reali e le specifiche. per il tuo prossimo progetto, sarai di nuovo nella stessa situazione.

Potrebbe essere qualcosa di semplice come una cattiva comunicazione o forse un requisito del cliente insinuarsi.

Ma almeno se si conosce la causa e si può provare a ridurre al minimo le possibilità che accada di nuovo.

Non bussare a ciò che altre risposte stanno dicendo e ci sono alcune cose fantastiche lì, ma per favore, apprendi da quello che è successo in modo che non sei condannato a ripeterlo.

HTH

applausi,

Answer 9

A volte una riscrittura è la soluzione migliore!
Se si sta scrivendo un software per una fotocamera, si potrebbe presumere che la prossima versione realizzerà anche video, o video stereo o scansione laser 3D e includerà tutti i ganci per tutte queste funzionalità, oppure si potrebbe scrivere un'architettura astronauta così versatile e estensibile che potrebbe far fronte alla prossima macchina fotografica, inclusi i motori a reazione, ma costerà tanto in denaro, risorse e prestazioni che potreste essere stati migliori nel non farlo.

Una riscrittura completa per nuove funzionalità in un nuovo ruolo non è sempre una cattiva idea.