Costo della manutenzione in base ai paradigmi

Question

Costo della manutenzione in base ai paradigmi

#1 da (3 voti)
#2 da (0 voti)
#3 da (0 voti)

6

Esistono dati su quali paradigmi consentono il codice che è più facile / meno costoso da mantenere? Certamente, indipendentemente dal paradigma scelto, un buon design è meno costoso da mantenere che cattivo, ma probabilmente ci dovrebbero essere grosse differenze provenienti solo dalla scelta del paradigma.

La programmazione non strutturata, ad esempio, genera codice molto disordinato (codice spaghetti) che è costoso da mantenere.

Nella programmazione orientata agli oggetti, i dettagli di implementazione sono nascosti e quindi dovrebbe essere abbastanza economico cambiarli.

Nella programmazione funzionale, non ci sono effetti collaterali, quindi c'è meno rischio di introdurre bug durante la manutenzione, che dovrebbe essere più economico.

Esistono dati su quali paradigmi sono i più efficienti in termini di costi quando si scende alla manutenzione? Se non esistono tali dati, qual è la tua opinione sulla domanda?

maintenance paradigms

posta Anto 10.04.2011 - 21:31

fonte

3 risposte

Leggi altre domande sui tag maintenance paradigms

Modelli e pratiche di programmazione in Python? [chiuso] Inizia a comprendere un progetto esistente per programmatore principiante

score 3 · Answer 1

Gli esseri umani possono gestire così tanta complessità in un dato momento.

Vuoi un paradigma che riduce o nasconde la complessità per te.

Minore complessità significa maggiore manutenibilità.
Una minore complessità significa meno sforzi di comunicazione.

I migliori paradigmi in termini di manutenibilità sono quelli che:

nascondi la complessità in modo da non averlo sempre in faccia.
ti consente di aggiungere funzionalità senza modificare quelle esistenti.

IMHO Vorrei andare con una miscela di quanto segue:

architettura a livelli (non necessariamente n-tier, basta non fondere la logica di business con la logica di presentazione)
usa OOP nella logica aziendale. So che l'incapsulamento e il riutilizzo del codice possono essere ottenuti usando non-OOP, ma con OOP avete schemi ben documentati. Puoi stare sulle spalle dei giganti.
sviluppare un'API in modo che i programmatori sviluppino app basate su tale API.
rendere agnostica la presentazione dell'API business logic
prova la persona che sviluppa il livello della logica di business non è la stessa che sviluppa il livello di presentazione.

Non so se tutti questi sono "paradigmi", ma penso che questo approccio sarebbe un buon equilibrio tra manutenzione e flessibilità a costi contenuti.

score 0 · Answer 2

Non sono a conoscenza di alcun dato esistente, ma sto solo entrando in campo quindi sto solo vedendo degli studi, ecc., ma ho anche dato un'occhiata a una varietà di metodologie di programmazione, quindi mi interessa molto, ed ecco la mia opinione su questo:

Qualsiasi paradigma ragionevole , fatto bene, ti darà buoni risultati di manutenzione. La programmazione non strutturata è non sensibile.

Il problema più grosso non è in realtà il tuo paradigma (che si tratti di programmazione o sviluppo) che introduce un sacco di costi, sono gli odori del codice. Ci sono molti frutti a bassa quota, che si tratti di rinominare le variabili, accorciare le funzioni, ecc., Che forniranno un ritorno sulla manutenzione molto maggiore rispetto alla scelta di una metodologia diversa.

score 0 · Answer 3

Da questo articolo, sembra che la programmazione funzionale e la programmazione orientata agli oggetti offrano una buona leggibilità e siano mantenibili codice. La programmazione imperativa segna un basso livello di manutenibilità in quanto diventa difficile riutilizzare sezioni di programmi di grandi dimensioni. La programmazione strutturata soffre di scarsa manutenzione essendo difficile apportare revisioni una volta che il programma è stato scritto.

FWIW, dalla mia esperienza, ho odiato lavorare su programmi che sono stati scritti con un approccio rigido e dall'alto verso il basso. Soprattutto quando non c'erano gli sviluppatori originali.