Codice per prove future

Dove lavoro gli sviluppatori mi dicono sempre che "L'ho aggiunto per ogni evenienza" o "Penso che sia una buona idea farlo perché probabilmente lo vorranno un giorno". Penso che sia fantastico essere proattivi nel cercare di anticipare i cambiamenti futuri, ma non posso fare a meno di pensare che sia inutile e rischia di scrivere codice che potrebbe non essere mai necessario e quindi improduttivo (penso anche che alcuni sviluppatori vogliano solo provare qualcosa nuovo per il gusto di farlo). Gli argomenti per la correzione futura non sono validi se si scrive semplicemente codice organizzato pulito e valido?

Bene, prima di tutto, ci sono alcune cose che necessitano di chiarimenti:

• Le prove future non aggiungono roba.
• Le prove future stanno assicurando di poter aggiungere facilmente codice / funzionalità senza interrompere le funzionalità esistenti.

Ciò significa che la scrittura di codice "a prova di futuro" garantisce che il codice sia scritto in modo accoppiato libero, sufficientemente astratto, ma anche codice che non nasconda completamente i livelli di astrazione, quindi c'è sempre un modo per andare ai livelli di astrazione più bassi se necessario.

La scrittura di codice a prova di futuro è un'arte da sola ed è strettamente accoppiata con le pratiche SOLID per il controllo delle versioni dei componenti, la separazione delle preoccupazioni, la stratificazione e l'astrattezza della funzionalità. Future proofing ha nulla a che vedere con l'aggiunta di funzionalità prima del tempo, ma a fare in modo è possibile aggiungere funzionalità in futuro in un non rottura maniera, attraverso la buona progettazione di codice / librerie esistenti.

Il mio 2c

Non scrivere codice che non verrà utilizzato per molto tempo. Sarà inutile in quanto molto probabilmente non si adatta alle esigenze in quel momento (che per definizione non conosci ancora).

Rendi il codice robusto contro situazioni di problemi imprevisti che consentano un ripristino agevole o fail-fast, ma non scrivere codice per possibili usi futuri.

Un buon modo per garantire ciò è utilizzare la progettazione e lo sviluppo test-driven. I casi di test sono derivati ​​dalle specifiche e dai casi d'uso. Tutto il codice deve effettuare un test test. Il codice non necessario non deve essere scritto. In questo modo è semplice determinare se è necessario o meno.

È importante rendersi conto che rendere il codice a prova di futuro e scrivere codice nel caso sia necessario in futuro sono due cose molto diverse. Il primo è fondamentale per una buona applicazione, il minore di solito non è una buona pratica di codifica.

• Per me, il codice a prova di futuro, lo sta scrivendo in modo tale da poter interagire con le tecnologie in evoluzione. Ciò comporta la modularizzazione del codice, in modo che ogni parte dell'applicazione possa interagire indipendentemente dal linguaggio e dalla tecnologia dell'applicazione nel suo insieme. Un buon esempio di ciò sarebbe l'utilizzo di XML o JSON per passare i dati tra diverse parti dell'applicazione. Comunque la tecnologia evolva, è molto probabile che sarà sempre in grado di leggere XML e JSON.

• Simile a quanto sopra, esponendo una parte dell'applicazione tramite un'API SOAP o REST si ottiene una cosa simile. Qualunque siano le tecnologie che evolvono, non dovrai necessariamente riscrivere ogni parte dell'applicazione perché le nuove tecnologie saranno ancora in grado di comunicare con le vecchie.

• Sul punto di scrivere il codice nel caso sia necessario , penso che sia molto pericoloso in quanto è probabile che il codice abbia pochi o nessun test.

Quindi, sicuramente, rendi il codice a prova di futuro (la NASA invia comunque navi spaziali usando Fortran), ma non scrivere il codice "per ogni evenienza".

Pensa a quante volte hai abilitato un pezzo di codice in un ambiente di produzione e ho pensato "Grazie a Dio l'ho scritto 2 anni fa!".

Il codice dovrebbe essere facilmente modificabile / estendibile. Non aggiungere codice che non è immediatamente necessario, poiché ciò fornisce un falso senso di sicurezza e spreca risorse di sviluppo / test in un mondo di requisiti in evoluzione.

Molte altre risposte affrontano tipi di problemi di progettazione più ampi, o sono piuttosto astratti. Se pensi in termini di ciò che accadrà in futuro, puoi definire alcune tecniche chiare per aiutare il codice a prova di futuro .

Pensa principalmente che in futuro qualcuno proverà ad aggiungere una funzione al codice o tenterà di riutilizzare il tuo codice altrove. Potrebbero anche tentare di correggere una funzione nel codice. Ovviamente solo avere un buon codice pulito è un punto di partenza richiesto, ma ci sono anche alcune tecniche specifiche che possono essere fatte.

Programmazione difensiva : controlla l'input oltre ciò di cui hai effettivamente bisogno nell'applicazione corrente. Ogni volta che chiami le API assicurati di controllare che il loro input sia qualcosa che ti aspetteresti. In futuro le persone mescoleranno insieme nuove versioni di codice, quindi l'ambito degli errori e i ritorni API cambieranno da quello che è ora.

Elliminate Undefined Behaviour : un sacco di codice ha un comportamento che si evolve dal nulla. Alcune combinazioni di input portano a determinati output che nessuno intendeva veramente, ma succede proprio così. Ora inevitabilmente qualcuno farà affidamento su quel comportamento, ma nessuno lo saprà poiché non è definito. Chiunque tenti di modificare il comportamento in futuro, inavvertitamente romperà le cose. Utilizza subito i controlli di sicurezza e prova a rimuovere / bloccare tutti gli usi indefiniti del codice.

Suite di test automatizzata : sono sicuro che puoi trovare volumi scritti sulla necessità di test unitari. In riferimento alle prove future, tuttavia, questo è un punto critico nel consentire a qualcuno di riformattare il codice. Il refactoring è essenziale per mantenere un codice pulito, ma se manca una buona serie di test non è possibile effettuare il refactoring in modo sicuro.

Isolamento e segregazione : l'incapsulamento e la corretta modularizzazione sono un buon principio di progettazione, ma è necessario andare oltre. Scoprirai spesso che devi utilizzare una libreria, un'API o un prodotto, che potrebbe avere un futuro discutibile. Forse a causa di problemi di qualità, problemi di licenza o sviluppo continuo da parte degli autori. In questi casi, impiega più tempo a mettere un livello tra te e questo codice. Taglia l'API in base alle tue necessità, in modo che l'accoppiamento sia molto basso per consentire una sostituzione più semplice in futuro.

Un codice valido, pulito e ben organizzato è a prova di futuro, nel senso che semplifica l'implementazione corretta di modifiche e aggiunte.

"Future Proof" nel migliore dei casi significa "design debolmente accoppiato". L'80% delle volte le persone significano "flessibile" quando dicono "a prova di futuro". A volte lo dicono per cercare di sembrare cool. Ma almeno stanno consegnando qualcosa in tempo che funziona.

"Future Proof" nella peggiore delle ipotesi non ha senso. Il 20% delle volte è una scusa per perdere tempo a cercare tecnologie alternative invece di fornire semplicemente qualcosa. Non stanno consegnando nulla (o ciò che stanno offrendo è troppo complesso per il problema in questione.)

Esistono due casi limite.

1. Lungimiranza ineccepibile. Si può effettivamente prevedere con precisione il futuro. In questo caso, si prega di applicare questa potente previsione a prova di futuro del codice. Meglio, applicare la lungimirante lungimiranza per prevedere le tendenze del mercato, ritirarsi presto e interrompere la programmazione.

2. Uno è "guidare" il futuro. Cioè, si ha una nuova tecnologia pronta per l'implementazione in futuro che richiederà una riscrittura della cosa consegnata in questo momento. È strano che non si stia distribuendo prima questa cosa interessante del futuro.

   Dobbiamo consegnare il progetto "A", sapendo che il progetto "B" porterà a una riscrittura immediata di "A". Solo in questo caso, potremmo essere in grado di provare "A" in futuro.

YAGNI = Non ne avrai bisogno .

I tuoi istinti sono corretti: il loro codice è superfluo, aggiunge un onere di manutenzione e test e fa perdere tempo a cose che non hanno un valore commerciale concreto.

Vedi anche: Placcatura in oro .

Ignorando il titolo della domanda e mantenendo il punto principale sul "mettere le cose perché qualcuno potrebbe volerlo un giorno" ...

La risposta è no. Mai. Non scrivere un punto di codice che non ti serve oggi. Ecco perché:

1. Il programma ora è più complicato di quanto debba essere.
2. Potresti non aver mai bisogno della funzione, quindi hai perso tempo.
3. Non sai quali saranno i requisiti per la funzionalità se qualcuno lo chiederà in futuro. Quindi dovrai capirlo e modificarlo comunque.

Penso che il primo punto sia il più importante. Se hai mai lavorato con un sistema pieno di codice generico per diversi clienti, o pieno di funzionalità gonfiate con cose che non ti servono, allora sai quanto tempo e sforzo extra ci vogliono per mantenere o estendere le funzionalità a causa di quella. Quindi evita a tutti i costi.