Quali caratteristiche o caratteristiche rendono il codice mantenibile? [duplicare]

La manutenibilità non è una proprietà binaria, che sia mantenibile o meno. È un continuum. In parole povere, la manutenibilità è inversamente proporzionale alla quantità di tempo che impiega uno sviluppatore per apportare un cambiamento e il rischio che il cambiamento possa rompere qualcosa. Migliorare la leggibilità, l'accoppiamento o la coerenza contribuiscono tutti alla mantenibilità, poiché non ci vorrà molto tempo per apportare qualsiasi modifica. La manutenibilità è più facile da riconoscere per la sua assenza, come quando una cosa che pensavi dovesse impiegare un'ora per finire una settimana.

Gli standard di codifica aiutano a fare in modo che la base di codice sia coerente, quindi più facile da trovare rispetto a una base di codice che contiene più stili di codifica. Qualcosa che è più facile da capire è più facile da mantenere.

Per me, codice gestibile significa davvero codice che legge come un libro ed è ben documentato.

Il codice manutenibile è l'unità (e funzionale / integrazione se necessario) testata in modo tale che se viene apportato un cambiamento che introduce un effetto a catena, viene catturato rapidamente e in anticipo, prima che il codice sia addirittura archiviato.

Per me, il codice mantenibile non sfrutta le caratteristiche del linguaggio stravagante di cui è a conoscenza lo 0,1% della popolazione di programmazione (esempio semplice: utilizzando un XOR swap anziché una variabile temporanea solo perché l'autore pensa" è bello ".

Il codice manutenibile implementa anche i principi di architettura sonora: DRY , SOLID , ecc. Utilizza modelli e algoritmi di progettazione noti per risolvere i problemi appropriati.

La manutenibilità del codice è la sinergia realizzata quando applichiamo tutti quegli assiomi di codifica, regole empiriche, principi, ecc. È più arte che scienza. Nella misura in cui abbiamo cotto in una quantità appropriata di tutte queste cose, la base di codice è mantenibile. Il codice non è gestibile (sì / no, on / off, o / o) solo perché puoi modificarlo (o meno).

Tuttavia, il test dell'acidità della manutenibilità sta tentando di cambiare il codice. Nella misura in cui il codice resiste o non resiste, l'interazione con esso definisce la sua manutenibilità.

La manutenibilità ha "abilità". Compreso, ma non limitato a

• leggibilità
• comprensibilità
• mutevolezza
• testability
• affidabilità
• altri?

Come possiamo raggiungere queste abilità?

Attraverso l'applicazione di tutti quei principi e linee guida del software che hai mai o forse mai sentito nominare. Ad esempio:

• Buoni commenti
• variabile descrittiva, metodo, nomi di classe
• Limita i metodi a non più di una pagina di lunghezza
• Massimizza la coesione e minimizza l'accoppiamento
• incapsula ciò che rimane lo stesso
• incapsula ciò che cambia
• disposizione del codice / linee guida di formattazione applicate in modo coerente
• Solo un punto di ingresso e un solo punto di uscita.
• ... e molti, molti, altri ...

Per una buona manutenzione, è necessario considerare tutti, sempre, a tutti i livelli del codice e applicarli in un mix (non "il") appropriato. Inoltre, e non posso enfatizzare abbastanza, nessun principio funziona meglio (o molto bene, forse) da solo.

Cerca le tue strade per Damasco

Diversi anni fa due cose si sono incontrate. Una serie di programmi che erano letteralmente non mantenibili e la mia scoperta di Code Complete di Steve McConnell. Questo libro era la mia bibbia per riscrivere tutto quel codice peggio del fallimento e il confronto "prima e dopo" del codice era a dir poco rivelatore.

Trova le tue strade per Damasco. È un ambiente ricco di obiettivi.

Leggi Codice completo

Non posso esagerare su quanto sia buono questo libro per l'apprendimento dei principi fondamentali di sviluppo del software.

Il codice mantenibile è un codice che presenta un'elevata coesione e un basso accoppiamento. La coesione è una misura di quanto il codice sia correlato, leggibile e comprensibile. L'accoppiamento è una misura del modo in cui il codice è correlato, un accoppiamento basso significa che cambiare il modo in cui A fa qualcosa non dovrebbe influenzare B che usa A. Abbastanza un accoppiamento inferiore significa minore coesione, e viceversa, quindi uno sviluppatore deve trovare un equilibrio appropriato tra due.

La manutenibilità è di per sé una misura della facilità di modificare il codice, una maggiore manutenibilità significa meno tempo per apportare modifiche. Gli standard di codifica sono un modo per ottenere un'elevata manutenibilità e sono sviluppati a seguito di esperienze precedenti, non sono universali e dipendono dalle preferenze degli sviluppatori.

Porsi alcune domande.
(o, come qualcuno potrebbe dire, corriamo insieme attraverso alcuni scenari )

• Quanto sarà difficile per te capire cosa hai scritto?

  • La scorsa settimana?
  • Il mese scorso?
  • L'anno scorso?
  • 27 anni da oggi?

• Quanto sarà difficile per un collaboratore capire cosa hai scritto?

• Nello sfortunato evento, tutti i membri della tua squadra non sono disponibili, ma una correzione deve essere esaurita in poche ore e l'unico ragazzo disponibile per il lavoro è uno stagista estivo, quanto è probabile che ci riesca?

E poi:

• quanto sarà difficile applicare una correzione di sicurezza a un blocco casuale di codice?
• quanto sarà difficile modificare una incomprensione logica dei requisiti?
• quanto sarà difficile prendersi cura dell'usabilità / UX / problema estetico?
• quanto sarà difficile adattarsi al panorama legale in continua evoluzione?
• quanto sarà difficile spingere alcune nuove funzionalità commerciali?
• quanto sarà difficile trasferire tutto ciò su un'architettura diversa?

E il meglio di tutti:

• quanto sarà difficile adattare l'intero behemoth a una nuova serie di requisiti per un cliente con esigenze simili, ma ...?

Questo è più o meno ciò che riguarda la manutenzione. Quest'ultimo riguarda più la trasformazione dell'applicazione in un prodotto, forse, ma è un bisogno che è abbastanza tipico alzare, col tempo.

"Best practice":

• Commenti
• Documentazione
• I diagrammi
• rientro coerente
• Modelli di codifica

Tutti hanno lo scopo di far sopravvivere il tuo codice più a lungo.

I modelli di codifica, in particolare, aiutano la manutenzione rendendo la lettura del codice sempre meno di una scoperta, e sempre più di un "Oh sì, l'ho già visto, quindi la parte che sto cercando dovrebbe essere ... da queste parti ".

Dovrebbero, ovviamente, essere usati con cautela e non essere mai copypaste / abusati solo per il gusto di farlo.
Non è LEGO, è più una fonte di ispirazione.

Le probabilità sono che se non riesci a mettere in relazione l'utilizzo di alcuni pattern da parte di qualcuno con vantaggi in termini di manutenibilità, non li stanno utilizzando correttamente. Ma stai certo che, come metodo per confrontare soluzioni diverse e consentire tempi di risposta più rapidi in caso di manutenzione, sono teoricamente solidi.

Sono sorpreso che nessuno abbia menzionato le metriche di complessità di McCabe . Una metrica ad alta complessità è un vero odore di codice quando si tratta di manutenibilità. A volte è necessario che una routine sia "complessa", ma di solito indica un codice che sarà davvero difficile da mantenere.

Guardando in un altro modo, tutto il codice è mantenibile. Il fattore di differenziazione si riduce allo sforzo richiesto per mantenere il codice e la quantità di debito tecnico che il codice rappresenta in ogni dato stato.

Il codice ben fattorizzato richiede pochi sforzi da mantenere e, quando è necessario modificarlo, non imporrà un costo di risorse significativo. Codice difficile da leggere, troppo "intelligente" per il suo bene, scarsamente fattorizzato o che non rispecchia l'intenzione per cui è stato scritto, questi sono i tipi di codice che comportano costi più elevati da mantenere o da risolvere se il costo: vantaggio rende più opportuno evitare la manutenzione diretta. Il mancato mantenimento di un codice scadente aumenta notevolmente il debito tecnico e aumenta la probabilità che il codice possa essere considerato troppo costoso da mantenere.

Il codice di etichettatura come mantenibile e non controllabile può comportare perdite significative per la tua azienda e può causare lo stigma di fallimento del progetto che segue gli sviluppatori come un cattivo odore per anni. Cambiare la lingua per essere più sullo sforzo e meno sulla percezione della manutenibilità può essere più utile a lungo termine, contribuendo a concentrare gli sforzi sul problema prima che diventi molto difficile da gestire.

Quando lavoriamo con altri sviluppatori che hanno bisogno di assistenza per capire cosa significhi manutenibilità, chiederò loro: "Se l'applicazione si arresta alle 3:00 e vieni chiamato fuori dal letto per sistemarlo, è questo il codice che vorresti guarda allora? " Saresti sorpreso di come questo possa cambiare il punto di vista delle persone.

mantenere il codice significa prendere quel codice e apportarvi una modifica per correggere un bug o aggiungere una funzionalità

Il codice gestibile semplifica questo processo

rendere il codice gestibile significa renderlo più facile da comprendere (nomi di variabili descrittive, commenti e documentazione aiuteranno qui) e apportare modifiche ad esso è facile da fare (i pattern possono renderlo più semplice, ma dipende dalle reali necessità)

Ho definito la manutenibilità come: una misura dello sforzo richiesto per modificare la funzionalità del software applicativo. Una misura di "impegno" deve includere tempo, risorse ed esperienza.

In generale, qualsiasi gestore di sviluppo software ha familiarità con questa definizione di "sforzo" come si applica alla creazione di software. Il termine 'modifica della funzionalità' si applica sia a miglioramenti che a correzioni di bug. Si potrebbe anche dire che il codice gestibile è progettato per essere sfruttato.

Ci vuole un po 'di sforzo per creare software gestibile. Per quello che vale, di recente ho iniziato un blog sull'argomento.

link

Il mantenimento è - in una certa misura - soggettivo. Tuttavia, è il codice che viene scritto meno con l'ego dello scrittore in mente e più con il riconoscimento che a un certo punto, è probabile che qualcuno debba rivisitare questo codice e modificarlo per ragioni attualmente indefinite. Pochissime codebase rimangono statiche per anni.

Ciò che una persona considera manutenibile può essere molto diverso dal punto di vista di un altro per alcuni aspetti, ma alcune qualità che penso dovrebbe includere sono:

1. nessuna trappola nascosta per gli incauti in futuro
2. logica e logica dovrebbero essere documentate
3. dovrebbe essere conforme ad alcuni standard locali documentati

Abbiamo discussioni qui a proposito di documentazione e commenti di volta in volta.

Il codice di cui è facile seguire la logica e la logica dovrebbe essere, per la maggior parte, facile da aggiornare come richiesto con alcune avvertenze sulle considerazioni di progettazione originali (che dovrebbero essere ma non sono mai documentate adeguatamente).