Mantenerlo semplice ora o programmare pensando al futuro?

Attualmente sto codificando una nuova applicazione per la mia azienda che è piuttosto coinvolta. Per rispettare la scadenza, la funzionalità è stata leggermente attenuata in modo da poter avere qualcosa pronto per il lancio.

Mi è stato affidato il compito di mettere in funzione la versione 1 entro la fine del mese. Sono a metà dello sviluppo e sono arrivato al punto ora che c'è una fine in vista.

Ieri ho trascorso un po 'di tempo a trovare una soluzione molto semplice e facile per uno dei requisiti e sono abbastanza orgoglioso di come è venuto fuori. Stamattina è stato spedito il documento versione 2, e c'è un requisito che richiede che il codice che ho scritto ieri sia sventrato o gravemente modificato. Richiederebbe molto lavoro in futuro se lo lascio così com'è. Ora posso dedicare un giorno in più per rendere più robusta la mia attuale soluzione in modo che la funzione v2 possa essere aggiunta con molto meno sforzo, ma ciò mi metterà un po 'indietro per la codifica aggiuntiva che richiederebbe.

Non so se farò v2. Potrei essere io o potrebbe essere un collega di lavoro o addirittura un tirocinante.

Se fossi nei miei panni, passeresti il ​​tempo ora per renderlo più facile in futuro, o lasceresti la tua soluzione e ti occuperesti quando sarà il momento?

Se la scadenza è Scolpita nella pietra, basta finire quello che devi rispettare. Assicurati di gonfiare le stime per v2 per adattarle alle modifiche del codice per il nuovo requisito. Assicurati inoltre di documentare brevemente ciò che pensi che sarà necessario modificare per le nuove funzionalità di v2 in modo che un collega possa raccoglierlo se ti viene assegnato un altro.

Se c'è abbastanza flessibilità nella scadenza (1 giorno, a giudicare dal suono, quindi punta a un'estensione di 2,5 giorni), certo, vai avanti e codifica per il futuro noto!

Evita di cadere in preda (presto) al secondo effetto di sistema . Ecco alcune buone tecniche da applicare:

1. Sicuramente evita la de-railing della versione 1 solo per quello che vedi in arrivo nella versione 2. La pianificazione in anticipo va bene, ma il creatore delle specifiche della v2 dovrebbe essere responsabile del fallimento della v2, non della v1.
2. (Se possibile) vedi se puoi fare in modo che il creatore rielabori i requisiti per la versione 2 che non richiedono le modifiche più grandi ora e quindi pianificale in un secondo momento, forse per la v3.
3. Mantieni YAGNI a mente , ma cerca di programmare l'estensibilità in mente - evita numeri magici, valori hardcoded, scrivi buoni test unitari o contratti di codice, ecc. L'applicazione di buone tecniche in anticipo renderà il refactoring e le modifiche al codice meno dolorose lungo la strada.

La maggior parte dei progetti software che crescono come città hanno successo nel lungo periodo. La pianificazione evolutiva solo in un futuro limitato consente al software di essere rilasciato in tempo e con le funzionalità richieste al momento del rilascio - e non di più. Vedi questo estratto da Carl Sagan:

La disposizione [di una città] potrebbe essere più efficiente se tutti i sistemi civici fossero costruiti in parallelo e sostituiti periodicamente (motivo per cui disastri disastrosi - le grandi conflagrazioni di Londra e Chicago, per esempio - a volte sono un aiuto nella pianificazione della città). Ma il lento accrescimento di nuove funzioni consente alla città di lavorare più o meno continuamente attraverso i secoli.

• Carl Sagan, Cosmos : http://www.eridanus.info/genesis.html

Non aggiungere il codice oggi per il requisito del mese prossimo. Oggi dovresti scrivere il codice più pulito possibile per i requisiti che hai. Sono scettico sul fatto che un giorno di lavoro ora salverà più giorni dopo. Ho sentito affermazioni del genere e non riesco a ricordare un singolo caso in cui era vero. Potresti essere in grado di convincermi mostrando un po 'di codice, ma la mia esperienza mi dice che è improbabile.

Lascia così com'è.

Gli sviluppatori in realtà APPREZZANO un progetto legacy che fa quello che dovrebbe fare e non di più.

Ciò che oggi può sembrare una buona idea per "mettere in scena" la base di codice per soddisfare un requisito "futuro", con ogni probabilità fungerà da ostacolo alla comprensione del codice in futuro. A nessuno piace occuparsi di funzionalità parzialmente implementate e vestigia di requisiti fantasma dimenticati. Non sto dicendo che sarà così, ma le cose spesso vanno in questo modo nonostante le migliori intenzioni.

Buone risposte. Vorrei solo aggiungere - quello che faccio in un caso come questo è prendere una buona diff in modo da poter catturare ciò che ho fatto e riporlo in un luogo sicuro. Quindi se l'opportunità verrà di nuovo nella prossima versione, sarà facile.

In generale, un buon sviluppatore anticipa i requisiti futuri, ma quando si profila una scadenza, è tempo di rispondere ai bug in ciò che hai già e non "scuotere la barca".

Dipende. C'è una buona regola vecchio stile: trattare gli altri come se volessero essere trattati da soli. Cosa faresti se fosse il tuo progetto e conoscessi tutte le priorità?

Se v2 è sicuramente richiesto e la scadenza è solo un desiderio piuttosto che una necessità, non creare debiti tecnici e riparare le vele quando il tempo è bello. Anche se qualcun altro farà v2 apprezzeranno la lungimiranza.

In caso di dubbi sulla necessità di v2, attenersi a YAGNI. Inoltre, se sei dall'altra parte dello spettro e hai uno di quei clienti che ti spammano costantemente con le loro idee prima che si formino, controlla le tue e-mail solo 2 o 3 volte al giorno e non affrettarti con l'azione, rimarrai sorpreso quanti "problemi" e richieste diventano irrilevanti prima ancora di leggerli.