Come fa un codice sviluppatore in previsione del cambiamento? [chiuso]

Due cose molto essenziali da capire sono:

• Non puoi mai prevedere ogni modifica che un cliente può chiedere. Ho avuto un cliente che ha deciso di passare un progetto di due mesi da PHP a ASP.NET una settimana prima del rilascio ed era convinto che questo sarebbe stato un cambiamento facile.

• Qualsiasi modifica avrà un costo. Non importa se stai usando Agile o se hai un design pulito ed estensibile, il costo sarà ancora lì.

Detto questo, ci sono più tecniche che portano a cambiamenti meno costosi. Come già notato da Jörg W Mittag, questo è praticamente solo "buon design", ma se vuoi qualcosa di più specifico, ecco alcuni suggerimenti:

1. Evita la duplicazione del codice a tutti i costi. Dovendo fare un cambio in questa classe, poi in questa, e infine ci-state attenti, il codice non è esattamente lo stesso delle prime due posizioni - aumenterebbe il costo.

   Il problema principale qui è che su progetti di grandi dimensioni, gli sviluppatori non possono sapere quali pezzi sono stati già scritti e potrebbero svilupparsi da soli in una posizione diversa nella base di codice. L'architettura pulita e la documentazione adeguata aiutano, ma non fanno sparire il problema.

2. Il tuo sistema dovrebbe essere disaccoppiato il più possibile. Se un piccolo cambiamento nel modulo che visualizza fatture generate sullo schermo richiede la riscrittura di alcune classi nel modulo che gestisce la registrazione di nuovi utenti, c'è qualcosa di sbagliato nel disaccoppiamento.

   • Il disaccoppiamento può essere fatto attraverso le interfacce. Ciò significa che è possibile lavorare sulla logica sottostante mentre l'interfaccia rimane la stessa e le altre parti del sistema non sono interessate. Ad esempio, potresti avere un'interfaccia per un componente logger; quando il cliente chiede di passare da syslog a una coda messaggi basata su RabbitMQ, le modifiche sono vincolate alla classe che implementa l'interfaccia specificata e gli utenti di questa interfaccia non si preoccupano di dove vanno i log.

     Il problema principale qui è che le interfacce potrebbero perdere ". Ad esempio, si passa da syslog a RabbitMQ e si nota un nuovo tipo di eccezioni quando il servizio di accodamento messaggi non è raggiungibile. Le classi che utilizzano l'interfaccia di registrazione ora devono gestire questa eccezione aggiuntiva.

   • Un ulteriore disaccoppiamento può essere ottenuto con l'iniezione di dipendenza. Il vantaggio è che invece di lavorare sulla classe stessa, ne crei una nuova, testala separatamente, e quando sei pronto, scambia la vecchia classe con quella nuova, mantenendo la possibilità di tornare alla vecchia classe senza problemi (o modifica di una riga di codice singola o tramite configurazione).

   Il punto è che questo richiede più lavoro. Se usato troppo (ogni parte dell'applicazione viene iniettata), il design potrebbe diventare troppo complicato.

3. L'ambiente conta tanto quanto il design. Alcuni suggerimenti:

   • Il tuo codice dovrebbe essere mantenibile. Il codice degli spaghetti non è di per sé problematico, ma in particolare perché rende difficile modificare il codice di base.

   • Lo stile uniforme è importante, perché rende il codice più facile da leggere; il codice di difficile lettura è difficile da cambiare.

   • I test di regressione automatizzati rendono la manutenzione meno stressante. Un anno fa ho lavorato in un'azienda in cui il prodotto chiave aveva uno 0% di copertura del codice. Quando qualcuno ha dovuto apportare una modifica, l'ha fatto, e quindi se è successo qualcosa di brutto nella produzione, il programmatore è stato il colpevole. Questo è un eccellente esempio di come non anticipare i cambiamenti.

     Il problema è che anche i test dovrebbero essere mantenuti, quindi, invece di cambiare semplicemente il codice, si dovrebbero cambiare test e codice. Il tempo impiegato per cambiare i test non è nulla in confronto al tempo perso a causa della mancanza di test adeguati, ma i project manager inesperti potrebbero non capirlo.

   • Tutti i membri del team dovrebbero essere a conoscenza di tutte le parti del codice base (del prodotto, non dell'intera azienda).

Non sto sostenendo questo come la risposta, ma questa è una lista di tecniche che mi ha aiutato molto negli ultimi 20 anni.

Codice auto-documentale

Potresti essere tentato di aggiungere commenti ovunque per rendere il codice più facile da capire. Ma il semplice fatto è che molto spesso, se sono richiesti ampi commenti all'interno di un metodo, il codice non è abbastanza semplice e dovrebbe essere refactored.

KISS

I moduli o i metodi che fanno molto sono un odore di codice e dovrebbero essere refactored il più possibile per renderli più facili da leggere, capire e modificare.

YAGNI

Con il cambiamento in mente si è tentati di aggiungere un'intera serie di campane e fischietti che potrebbero risparmiare tempo dopo. Resistere all'impulso di fare questo. Il codice aggiuntivo richiede test, può contenere bug e rende più grande il tuo codice base.

Percorso di minor resistenza

Se ti trovi di fronte a un cambiamento e il cliente non sa esattamente quello che vuole, codifica i conosciuti e il wireframe o prendi in giro il resto. L'ultima cosa che vuoi fare è dire, codifica 4 opzioni quando solo 1 sarà mai conservato.

Mock

Come accennato in precedenza, se puoi prendere in giro dati o schermate anziché codificarli, ciò farà risparmiare tempo.

Elimina vacche sacre

Qualche sviluppatore che è stato in giro da un po 'ha lavorato su sistemi in cui vi è un pezzo di codice complesso di business critical che nessuno vuole toccare sotto pena di morte! Se il codice viene modificato, spesso si rompe, si comporta in modi imprevisti o il debito tecnico viene aggiunto al codice attorno ad esso.

Innanzitutto, assicurati di non creare nessuna vacca sacra. In secondo luogo, se esistono, eliminali in modo che siano più facilmente digeribili. I test unitari automatizzati possono essere di grande aiuto qui.

Ci sono molte metodologie date per rendere il tuo codice più adattabile e manutenibile, ma la maggior parte di loro ha i seguenti punti al centro:

• Mantieni i metodi piccoli: i tuoi metodi dovrebbero fare solo una cosa bene. Se provano a fare più di una cosa, quasi certamente falliranno nel fare almeno una di quelle cose in determinate circostanze, e sicuramente svilupperanno una logica interna verrucosa molto complessa. Per questo motivo si dovrebbe anche mantenere il numero di argomenti passati al minimo. Oltre a rendere il codice più semplice da comprendere (e quindi ad adattarsi), rende anche il riutilizzo molto più semplice. Se hai un metodo di 500 linee con 10 linee di logica da qualche parte all'interno che è necessario riutilizzare in una circostanza diversa, devi aggiungere un argomento flag e avvolgere quella logica (o la logica circostante) in istruzioni if, o copialo e incollalo da qualche altra parte. Se quella logica era tutta nel suo metodo a 10 linee, puoi semplicemente chiamarla.
• Mantieni le tue lezioni piccole e mirate. Proprio come con i metodi, le classi dovrebbero fare solo una cosa bene. Ad esempio sulla nostra piattaforma di e-commerce la classe di ordine contiene molta logica per la consegna dell'ordine. Di recente abbiamo dovuto aggiungere funzionalità per consentire la spedizione dei componenti di un singolo ordine da più posizioni (se parte dello stock si trovasse in una posizione e il resto in una posizione diversa). Poiché la consegna era così strettamente legata al concetto di un ordine, alla fine l'unica soluzione praticabile era quella di costruire una logica complessa per analizzare l'ordine e creare più ordini basati sull'originale, ciascuno mappato per la spedizione dalla posizione con lo stock, e kludge e aggirare le questioni relative al pagamento per quell'ordine, che sono anche incorporate nella classe dell'ordine. In breve, la nostra classe di ordine cerca di fare troppo e le sue responsabilità non sono chiare. Se avessimo classi di pagamento ordine separate e classi di consegna dell'ordine a cui sono stati delegati il pagamento e la consegna, il lavoro sarebbe stato molto più semplice e molto probabilmente si sarebbe trattato semplicemente di adattare la classe ordine per supportare più consegne per ordine.

Nel software, small è sempre bello, e se il tuo codice è troppo grande per adattarsi allo schermo senza scorrere, probabilmente è anche troppo grande per adattarsi alla tua comprensione.

^{Poiché MainMa ha già detto:} le modifiche che si verificano effettivamente sono imprevedibili. ^{(in quasi tutti i casi)}

Mantenere l'implementazione il più semplice possibile dal punto di vista tecnico POV e il più vicino possibile ai requisiti effettivi (cioè utilizzare gli identificatori parlanti), o, in altre parole

Il meglio che puoi fare per le modifiche future è aiutare a capire come funziona la tua soluzione.