Paradigmi di programmazione e sviluppatore della manutenzione [chiuso]

9

Stavo leggendo, Facts and Fallacies of Software Engineering, che ha una sezione di manutenzione. Da allora, sono uno sviluppatore della manutenzione da anni, sono stati presentati fatti molto interessanti. Eccone tre.

Fatto 41: la manutenzione in genere consuma dal 40 all'80 percento (in media, il 60 percento) dei costi del software. Pertanto, è probabilmente la fase più importante del ciclo di vita del software.
Fatto 42: il miglioramento è responsabile di circa il 60 percento dei costi di manutenzione del software. La correzione degli errori è all'incirca del 17 percento. Pertanto, la manutenzione del software consiste principalmente nell'aggiungere nuove funzionalità al vecchio software, non nel risolverlo.
Fatto 45: un migliore sviluppo dell'ingegneria del software porta a più manutenzione, non a meno.

Questo era controintuitivo, risulta che un buon software ha più manutenzione, perché è facile da cambiare. Quindi, rimane in uso più a lungo, portando a, sì, ulteriori cambiamenti.

Quale paradigma (come funzionale, orientato agli oggetti, procedurale) ha la migliore manutenibilità e c'è qualche ricerca a sostegno di questo?

maintenance maintainability

— KaizenSoze
fonte

Possiedo una copia di Fatti e Fallacie, e per ogni fatto (e fallacia), ci sono citazioni per varie pubblicazioni che lo supportano. Non ne ho una copia a portata di mano, ma alcune di queste citazioni discutono l'effetto del paradigma sulla manutenzione?

— Thomas Owens

Il libro è stato scritto nel 2003, molte delle conclusioni sono ancora rilevanti oggi. Ero curioso di sapere se le persone avevano nuovi studi su particolari paradigmi. La manutenzione sembra una parte trascurata della discussione.

— KaizenSoze,

Se uno qualsiasi degli studi o delle pubblicazioni citati in Fatti e Fallacie riguardasse la manutenibilità di un particolare paradigma, un'opzione sarebbe quella di cercare nei database IEEE o ACM per altri articoli e documenti che citano quel documento. Se non hai accesso ai database IEEE o ACM, posso guardare la mia copia del libro quando torno a casa e vedere se posso fare una simile ricerca. Sfortunatamente, sarei solo in grado di procurarti nomi di altri documenti e non i documenti stessi.

— Thomas Owens

12

Penso che scoprirai che paradigmi come funzionali, OO e procedurali probabilmente non coronano in modo significativo la manutenibilità del software.

Ciò che potresti trovare è quanto segue in modo molto più chiaro con la manutenibilità del software:

Livello di raccolta dei requisiti e ingegneria dei requisiti
Buone pratiche di sviluppo: (accoppiamento lento, alta coesione, test unitari, YAGNI ...)
Ingegneri del software qualificati e qualificati (valgono 10 volte tanto quanto un idiota)
Team di QA tecnico qualificato e organizzato
Buona gestione del progetto guidata da responsabili di progetto competenti (ancora più difficile da trovare rispetto agli abili sviluppatori di software IMHO)
Buoni proprietari di prodotti o gestori di applicazioni, forte leadership, buona direzione a lungo termine, buon feedback ai team di progetto, visione generale.

— albero_acero
fonte

+1 Voglio aggiungere una buona documentazione all'elenco

— treecoder il

+1 Aggiungi il processo "Value Focused" all'elenco. Il processo definisce e guida ciò che è stato fatto e non fatto. Ciò che il processo misura è importante e ciò che il processo non misura non è importante. Soprattutto quando i ragazzi delle risorse umane iniziano a riempire i posti di "idioti".

— Mattnz,

2

Questo era controintuitivo, risulta che un buon software ha più manutenzione, perché è facile da cambiare. Quindi, rimane in uso più a lungo, portando a, sì, ulteriori cambiamenti.

Sembra che tu stia visualizzando questo dalla quantità di manutenzione e non dalla percentuale di costo. Un buon software con più funzionalità aggiunte è solo una quantità maggiore di software. Se la percentuale di manutenzione è fissa (perché era un buon software e supponiamo che le funzionalità aggiuntive siano state aggiunte come un buon software), l'importo aumenterà. È solo un pezzo di torta più grande con lo stesso numero di fette.

Sulla base di ciò che stai chiedendo, è importante che il software "buono" sia stato scritto in: codice funzionale, OOP o procedurale. Dare a qualcuno una sega a guida laser risparmia sul legno se la persona non sa come misurare?

— Jeffo
fonte