Una delle misure del software gestibile è la sua accettazione delle modifiche in seguito da parte di sviluppatori diversi da quelli che l'hanno scritto. Ma quali caratteristiche ha il software quando è in produzione da un po 'e il cliente vuole che un nuovo sviluppatore aggiunga una funzionalità o risolva un bug? Quali attività, atteggiamenti, tecniche e / o pratiche contribuiscono a rendere il software "mantenibile" 6 mesi dopo?
Test automatico
Una suite completa di test automatici è forse la caratteristica più utile di una base di codice quando si tratta di consentire a qualcuno senza familiarità prima di apportare modifiche sostanziali.
Normalmente quando inserisci un nuovo code-base hai poca fiducia che le modifiche non avranno effetti indesiderati, quindi inizi in piccolo e, man mano che diventi più sicuro nella comprensione di come funziona il sistema, apporti modifiche più consistenti.
I test automatici possono davvero accelerare questo periodo di crescita della fiducia assicurandoti di avere la stessa comprensione di quale comportamento "corretto" sia e di non averne deviato.
Codice di autocertificazione
La documentazione esterna e la documentazione a livello di codice sono ottime, ma spesso si tratta di una soluzione a banda larga che è difficile da leggere.
Stabilisci la priorità di rendere il tuo codice più facile da leggere, quindi se ciò non bastasse, considera dove potrebbe essere utile la documentazione aggiuntiva.
Tipicamente una descrizione o una panoramica di sistema di alto livello per trovare quale codice iniziare a leggere è utile, ma anche nominare le tue directory e file in modo che le persone possano facilmente indovinare dove sono preferibili le cose.
Strumenti di sviluppo automatici affidabili e ambiente di sviluppo
Assicurati che il processo per iniziare a sviluppare sulla base di codice sia veloce, automatizzato e affidabile.
Questo si applica in particolare all'esecuzione dell'applicazione: non obbligarli ad aggiornare 10 percorsi diversi o fare clic su 20 diversi menu IDE solo per eseguirlo e assicurarsi che possano facilmente adattarsi all'ambiente di produzione.
Indipendentemente da quanto siano buone le istruzioni per la creazione o la distribuzione del progetto, l'automazione del più possibile per loro salverà la possibilità molto probabile che qualcuno di nuovo manchi un passaggio.
Oltre alle risposte esistenti, vorrei aggiungere:
Essere semplici, piccoli, ben definiti e limitati.
Motivazione:
Quando ognuna di queste descrizioni viene negata e applicata a un pezzo di software, implicherà una crescente difficoltà a comprenderne il codice sorgente.
Essere modulare e conforme a (1) LSP e (2) POLA.
Queste sono le condizioni necessarie (ma non sufficienti) per prevenire ciò che è noto come astrazioni leaky .
Le astrazioni di perdita sono inevitabili, ma le violazioni della modularità, LSP e POLA aumenteranno la quantità di dettagli che i programmatori di software devono destreggiarsi quando lavorano con il software, aumentando così il carico mentale.
Lo stile di codifica è familiare al programmatore.
Motivazione:
Questo riduce il carico di apprendimento sul programmatore.
Il codice è altamente navigabile.
Attività assegnata:
The customer would like to make a small change to a software feature. The customer describes the change request, using terminology and mental models which the customer has learned from the user interface. The software programmer must now figure out the different parts of source code that corresponds to what the user has described.
Criteri di valutazione:
The terminology, mental model, and organizations of software features are highly similar between the user interface and the application source code. Furthermore, the source code is organized according to well-established software application architecture principles, which speeds up the programmer's understanding and navigation to the relevant parts of source code.
Il software è tracciabile.
Attività assegnata:
A customer discovers a bug in the software that can be triggered when the user performs a sequence of steps on the user interface. Please investigate and fix the bug.
Criteri di valutazione:
For a software application to be traceable, a programmer must be able to trace out its execution when the user performs a sequence of steps. It is hopeful that once the execution has been traced out, a follow-up investigation on the execution path will provide clues for the root cause and a resolution to the bug.
Tipici modi per ottenere la tracciabilità:
Leggi altre domande sui tag maintainability