Codice di prova futuro

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

• Le prove future sono non che aggiungono elementi.
• Le prove future assicurano che puoi facilmente aggiungere codice / funzionalità senza rompere le funzionalità esistenti.

Questo significa che scrivere codice "a prova di futuro", significa garantire che il codice sia scritto in un modo accoppiato, sufficientemente astratto, ma anche codice che non nasconda completamente i livelli di astrazione, quindi c'è sempre un modo per andare livelli di astrazione più bassi, se necessario.

Scrivere codice a prova di futuro è un'arte di per sé ed è strettamente associato alle pratiche SOLID per il controllo delle versioni dei componenti, la separazione delle preoccupazioni, la stratificazione e l'astrattezza delle funzionalità. Le prove future non hanno nulla da fare con l'aggiunta di funzionalità in anticipo, ma assicurandoti di poter aggiungere funzionalità in futuro in modo non violento , attraverso il buon design di esistenti codice / librerie.

My 2c

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

Rendi il codice robusto contro situazioni inaspettate che consentono un ripristino agevole o veloce, ma non scrivere codice per possibili usi futuri.

Un buon modo per garantire che, è di utilizzare la progettazione e lo sviluppo di test guidato. I casi di test sono derivati dalla specifica e dai casi d'uso. Tutto il codice deve superare un test. Il codice non necessario non dovrebbe essere scritto. Facendolo in questo modo è semplice determinare se è necessario o meno.

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

• Per me, la verifica futura del codice è scritta in un modo che sarà in grado di interagire con le tecnologie in evoluzione. Ciò comporta la modularizzazione del codice, in modo che ogni parte della tua applicazione possa interagire indipendentemente dalla lingua e dalla tecnologia dell'applicazione nel suo complesso. Un buon esempio di questo sarebbe usare XML o JSON per passare i dati tra diverse parti dell'applicazione. Tuttavia la tecnologia evolve, è molto probabile che sarà sempre in grado di leggere XML e JSON.

• Simile a quanto sopra, l'esposizione di una parte della tua applicazione tramite un'API SOAP o REST ottiene risultati simili. A prescindere dalle tecnologie che si evolvono, non sarà necessario riscrivere ogni parte dell'applicazione perché le nuove tecnologie saranno ancora in grado di comunicare con i vecchi.

• Sul punto di scrivere il codice nel caso sia necessario , penso che sia molto pericoloso in quanto il codice probabilmente non avrà test o pochi.

Quindi, con tutti i mezzi, rendere il codice a prova di futuro (la NASA invia ancora astronavi usando Fortran), ma non scrivere il codice "nel caso in cui".

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

Il codice dovrebbe essere facilmente modificabile / estensibile. Non aggiungere codice che non sia immediatamente necessario, perché ciò fornisce un senso di sicurezza molto falso e spreca risorse di sviluppo / test in un mondo in cui i requisiti cambiano.

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

In primo luogo, pensa che in futuro qualcuno proverà ad aggiungere una funzione al codice, o tenterà di riutilizzare il tuo codice da qualche altra parte. Potrebbero anche provare a correggere una funzionalità nel codice. Ovviamente avere un buon codice pulito è un punto di partenza richiesto, ma ci sono anche alcune tecniche specifiche che possono essere fatte.

Programmazione difensiva : consente di eseguire il controllo degli input oltre a ciò che effettivamente richiede l'applicazione corrente. Ogni volta che chiami API, assicurati di verificare 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 dei ritorni API cambierà da quello che è ora.

Elliminate Undefined Behavior : un sacco di codice ha un comportamento che si evolve dal nulla. Alcune combinazioni di input portano a determinati output che nessuno ha realmente inteso, ma solo così accade. Ora inevitabilmente qualcuno si baserà su quel comportamento, ma nessuno lo saprà dato che non è definito. Chiunque tenti di cambiare il comportamento in futuro, inavvertitamente romperà le cose. Utilizza ora i controlli di sicurezza e prova a rimuovere / bloccare tutti gli usi non definiti del codice.

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

Isolamento e segregazione : l'incapsulamento e la corretta modularizzazione sono un buon principio di progettazione, ma è necessario andare oltre. Troverete spesso che è necessario 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 continuato da parte degli autori. In questi casi impiega più tempo per mettere uno strato tra te e questo codice. Taglia l'API verso ciò che ti serve in modo che l'accoppiamento sia molto basso per consentire una sostituzione più facile in futuro.

Il codice buono, pulito e ben organizzato è a prova di futuro, nel senso che rende le modifiche e le aggiunte più facili da implementare correttamente.

"Future Proof" nel migliore dei casi significa "design senza accoppiamento". 80% delle volte le persone significano "flessibile" quando dicono "prova futura". A volte lo dicono per cercare di sembrare fantastici. Ma almeno stanno consegnando qualcosa in tempo che funzioni.

"Future Proof" nel peggiore dei casi non ha senso. Il 20% delle volte, è una scusa per sprecare tempo a ricercare tecnologie alternative invece di offrire semplicemente qualcosa. Non stanno consegnando nulla (o quello che stanno consegnando è troppo complesso per il problema in questione.)

Ci sono due casi limite.

1. Previsione infallibile. In realtà può prevedere con precisione il futuro. In questo caso, si prega di applicare questa potente previsione per una dimostrazione futura del codice. Meglio, applicare l'inesauribile previsione per prevedere le tendenze del mercato e ritirarsi presto e interrompere la codifica.

2. Uno è "guidare" il futuro. Cioè, uno ha una nuova tecnologia pronta per la distribuzione in futuro che richiederà una riscrittura della cosa che viene consegnata in questo momento. È strano che uno non stia schierando questa bella cosa futura prima.

   Dobbiamo consegnare il progetto "A", sapendo che il progetto "B" porterà a un'immediata riscrittura di "A". Solo in questo caso, potremmo essere in grado di fornire la prova futura "A".

YAGNI = Non ne hai bisogno .

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

Vedi anche: Placcatura in oro .

Ignorare il titolo della domanda e attaccare il punto principale su "mettere qualcosa 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 non sia necessario.
2. Potresti non aver mai bisogno della funzione, quindi hai perso tempo.
3. Non sai quali saranno i requisiti per la funzione 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 che è pieno di codice generico per clienti diversi o pieno di funzionalità gonfie di cose che non ti servono, sai quanto tempo e sforzi supplementari ci vogliono per mantenere o estendere la funzionalità a causa di quello. Quindi evita a tutti i costi.