Quali sono le tecniche per mantenere alta la qualità del codice quando cambiano i requisiti?

What are the techniques for keeping the code quality high when requirements change?

Hai provato lo sviluppo basato sui test? È esattamente per questo scopo. Quando hai finito con una funzionalità con TDD, non hai solo la funzione, ma anche tutti i test automatici che coprono quella funzionalità. Con l'arrivo di nuove funzionalità o modifiche, è possibile eseguire questi test e assicurarsi che non si sia rotto nulla. Ciò ti aiuterà a migliorare in modo sicuro la struttura del codice, prima e dopo l'implementazione delle modifiche.

Che mi porta al secondo punto:

PS: Please don't confuse this with refactoring, which is meant to change the code, while keeping the behavior the same. In my case when the requirements to the code change, it's obviously not refactoring and involves changing the behavior.

Come hai detto tu stesso, il problema che stai affrontando è che la qualità del codice degrada dopo ogni modifica, quindi alla fine il codebase richiederà il refactoring, altrimenti potresti raggiungere un punto fermo nella produttività. Non c'è modo di sfuggirlo.

Tuttavia, forse intendevi semplicemente che non vuoi risposte come "Basta refactoring del codice", che è giusto. Ma questo è esattamente ciò che la tua domanda sta chiedendo qui.

Inoltre, una risposta a questa domanda non potrebbe essere completa senza una citazione di Kent Beck:

When faced with a hard change, first make it easy (warning, this may be hard), then make the easy change.

Per aggiungere un po 'di contesto, quando Kent Beck dice "prima rendi [il cambiamento] facile", sta parlando di rifattorizzare l'attuale base di codice per renderlo più accogliente ai nuovi requisiti che ora dobbiamo implementare .

Whenever I write a piece of functionality from scratch, it's a good and robust code.

Pensiamo tutti che a questo punto. Raramente abbiamo ragione.

But often times my assumptions about how the code should work evolve over time. After I reflect those changes in the code, the whole system suddenly loses its quality.

Bene, no. Non ha mai avuto qualità. Se fosse successo, saresti stato in grado di cambiare facilmente le tue ipotesi. La qualità è più che soddisfacente per le esigenze di oggi.

It seems to me that the best approach is to drop the old code and write a new one from scratch with new assumptions in mind. But from obvious constraints in time I wanna learn how to keep the code quality high while heavily changing it.

Se semplicemente non riesci a scrivere un codice flessibile, allora una riscrittura è la migliore. Certamente migliore del codice mezzo mutato che sta ancora cercando di soddisfare i requisiti che non esistono più.

Question: Are there any techniques or books that could help me develop this skill?

Dal punto di vista dello sviluppo questo è agile. La cascata non reagisce bene a molti cambiamenti non pianificati ed emergenti. In questo momento agile è il meglio che abbiamo per questo.

Da un punto di vista della codifica il principio migliore per questo è la singola responsabilità. Ogni modulo dovrebbe avere solo una, preferibilmente unica, ragione per cambiare. Prendi le tue decisioni in un unico posto. Non diffondeteli. Seguitelo dall'inizio e il cambiamento non sarà così traumatico.

I see how code review is a good tool to uncover issues in code and I agree. But I'm interested in preventing those issues from happening in the first place and developing the skill to do that on my own without involving other team members.

La revisione del codice serve principalmente a verificare che il tuo codice sia leggibile. Sicuramente vale la pena, ma non garantirà tutto. Altri potrebbero verificare la tua progettazione e implementazione, ma non appoggiarti a ciò.

PS: Please don't confuse this with refactoring, which is meant to change the code, while keeping the behavior the same. In my case when the requirements to the code change, it's obviously not refactoring and involves changing the behavior.

È vero. Modifiche al refactoring. Hai bisogno di trasformazioni per soddisfare nuove esigenze. Indovina un po? Refactoring consente di modificare i vecchi progetti che non prevedevano la necessità di adeguare i cambiamenti a quelli che lo fanno. Una volta che sei pronto per scrivere nuovi test unitari che riflettono le tue nuove esigenze e possono farle passare.

Non consigliamo libri qui, ma questa risposta contiene abbastanza parole che dovresti riuscire a trovare ora.

Bugs, presence of unnecessary code, that was needed before and isn't need after the change, code reduncancy, bad abstractions, etc. All kinds of bad things.

Seguendo la tua descrizione della qualità del codice , mi sembra ragionevole introdurre il programma statico analisi nel ciclo di vita del progetto. Non c'è bisogno di menzionare che i test sono un must (unitario, Integrazione, funzionale, end-to-end, ...).

Le metriche fornite dall'analisi statica sono abbastanza buone in che descrive obiettivamente la qualità del codice nei termini che hai espresso.

A volte, l'analisi può insegnarti delle pratiche dubbiose che non conoscevi.

Ciò che l'analisi statica non può dire è: quanto è buono / cattivo il design , quanto è cattivo / buono il modello o quanto è efficiente o inefficiente il sistema . Almeno non gli strumenti che conosco.

Il processo può essere migliorato introducendo tecniche di programmazione come revisione tra pari o programmazione coppie .

Coinvolgere un altro sviluppatore (o due ...) fa molto meglio il processo di apprendimento. Il contrasto tra punti di vista, abilità e conoscenza può aiutare a migliorare quei punti che l'analisi statica non potrebbe.

But I'm interested in preventing those issues from happening in the first place and developing the skill to do that on my own without involving other team members

Riguardo alle tue abilità, prevenire è una questione di consapevolezza. Sviluppare abilità è una questione di tempo e pratica.

It seems to me that the best approach is to drop the old code and write a new one from scratch with new assumptions in mind. But from obvious constraints in time I wanna learn how to keep the code quality high while heavily changing it.

Non so se è migliore o solo desiderabile ma tendo a pensare allo stesso modo. Il tempo è un vincolo relativo. In alcuni casi l'obiettivo vale la pena di uno sforzo supplementare, in generale quando l'obiettivo è la pratica e l'auto-miglioramento.

Question: Are there any techniques or books that could help me develop this skill?

Assolutamente. Il numero uno, andare a prenotare per mantenere la qualità del codice mentre si cambia il design è Refactoring . Descrive un processo per prendere ciò che hai e cambiarlo in base alle tue esigenze mantenendo tutto il tempo in un sistema operativo. Combinando le metodologie di refactoring con il design guidato da test e un sistema di controllo delle versioni funzionante, ottieni una grande potenza sul codice.

Riscrivere da zero è una cosa che facevo spesso. Anche se molto allettante, ci sono molte ragioni per non farlo. Se inizi con il codice che hai, hai già un sistema funzionante, una struttura di test e una serie di test che ti consentono di conoscere lo stato del tuo codice in qualsiasi momento . Ricalcando il codice esistente, utilizzando passaggi di refactoring di piccole e grandi dimensioni, si scopre che non si è mai più di uno o due commit di tornare a uno stato funzionante. Questo ti dà una grande libertà di esplorare lo spazio della soluzione.

Sì, forse la maggior parte della scrittura sull'architettura del software riguarda davvero la scrittura di un codice che è adattabile alla luce del cambiamento dei requisiti.

Se ci pensate, la maggior parte dei principi di progettazione sono piuttosto irrilevanti se il codice non cambierà mai. Perché persino avere un codice leggibile se non lo guarderai mai più? Seguendo principi come SOLID si paga davvero solo quando si deve cambiare il codice.

Alcuni importanti principi a tal fine sono "separazione delle preoccupazioni" e "singola responsabilità". L'obiettivo è di separare il codice in unità in modo tale che una singola modifica dei requisiti richieda idealmente la modifica di una singola classe o modulo. Il rovescio della medaglia è il principio YAGNI, che dice che non dovresti cercare di prevedere e preparare le specifiche richieste di modifica che non sei sicuro accadrà.

Dovresti chiederti perché i tuoi requisiti cambiano così tanto spesso. E 'forse che non hai capito bene i requisiti in primo luogo e hai scritto il codice per sviluppare questa comprensione? In questo caso ha senso costruirne uno da buttare e poi ricostruirlo correttamente la seconda volta. Ma ancor più sensato è capire i requisiti prima di scrivere il codice. Pensa al problema aziendale da risolvere e quindi modellalo a livello concettuale. Chi sono gli utenti, quali sono i flussi che faranno attraverso il software, quali sono i tipi di oggetti che manipoleranno, quali azioni esistono su quegli oggetti, quali sono i flussi di dati nel sistema, ecc ... Si desidera trasmetti le tue idee agli utenti o alle persone che comprendono gli utenti, con prototipi e prototipi.

Con una corretta comprensione del problema del mondo reale che si sta risolvendo, trovo che raramente si debbano apportare enormi cambiamenti ai requisiti. Potrebbe essere necessario estenderli o modificare i punti più piccoli, ma i grandi cambiamenti non si verificheranno finché il problema rimane invariato.