Paradigmes de programmation et développeur de maintenance [fermé]

9

Je lisais, Facts and Fallacies of Software Engineering, qui a une section de maintenance. Depuis, je suis développeur de maintenance depuis des années maintenant, j'ai présenté des faits très intéressants. En voici trois.

Fait 41: La maintenance consomme généralement 40 à 80% (en moyenne, 60%) des coûts des logiciels. Par conséquent, c'est probablement la phase de cycle de vie la plus importante du logiciel.
Fait 42: L'amélioration est responsable d'environ 60% des coûts de maintenance des logiciels. La correction d'erreur est d'environ 17%. Par conséquent, la maintenance logicielle consiste principalement à ajouter de nouvelles fonctionnalités aux anciens logiciels, et non à les réparer.
Fait 45: Un meilleur développement de l'ingénierie logicielle entraîne plus de maintenance, pas moins.

Celui-ci était contre-intuitif, il s'avère qu'un bon logiciel a plus de maintenance, car il est facile à changer. Par conséquent, il reste en service plus longtemps, ce qui entraîne, oui, plus de changements.

Quel paradigme (tel que fonctionnel, orienté objet, procédural) a la meilleure maintenabilité, et existe-t-il des recherches à l'appui?

maintenance maintainability

— KaizenSoze
source

Je possède une copie de Facts and Fallacies, et pour chaque fait (et erreur), il existe des citations pour diverses publications qui le soutiennent. Je n'ai pas de copie à portée de main, mais l'une de ces citations discute-t-elle de l'effet du paradigme sur la maintenance?

— Thomas Owens

Le livre a été écrit en 2003, la plupart des conclusions sont toujours d'actualité. J'étais curieux de savoir si les gens avaient de nouvelles études sur des paradigmes particuliers. L'entretien semble être une partie négligée de la discussion.

— KaizenSoze

Si l'une des études ou publications citées dans Facts and Fallacies concerne la maintenabilité d'un paradigme particulier, une option serait de rechercher dans les bases de données IEEE ou ACM d'autres articles et articles qui citent cet article. Si vous n'avez pas accès aux bases de données IEEE ou ACM, je peux regarder ma copie du livre à mon retour et voir si je peux faire une telle recherche. Malheureusement, je ne pourrais vous obtenir que les noms d'autres papiers et non les papiers eux-mêmes.

— Thomas Owens

12

Je pense que vous constaterez que les paradigmes tels que fonctionnel, OO et procédural ne correspondent probablement pas à la maintenabilité du logiciel de manière significative.

Ce que vous pourriez trouver les corellations suivantes beaucoup plus clairement avec la maintenabilité du logiciel:

Niveau de collecte des exigences et d'ingénierie des exigences
Bonnes pratiques de développement: (couplage lâche, haute cohésion, tests unitaires, YAGNI ...)
Ingénieurs logiciels qualifiés et qualifiés (ils valent 10 fois plus qu'un crétin)
Équipe d'AQ technique qualifiée et organisée
Bonne gestion de projet dirigée par des chefs de projet compétents (Encore plus difficile à trouver que les développeurs de logiciels qualifiés à mon humble avis)
Bons propriétaires de produits ou gestionnaires d'applications, leadership solide, bonne direction à long terme, bons retours aux équipes de projet, vision globale.

— maple_shaft
source

+1 Je veux ajouter une bonne documentation à la liste

— treecoder

+1 Ajouter le processus «axé sur la valeur» à la liste. Le processus définit et pilote ce qui est fait et ce qui n'est pas fait. Ce que le processus mesure est important et ce que le processus ne mesure pas est sans importance. Cela est particulièrement vrai lorsque les gars des RH commencent à remplir les sièges de "crétins".

— mattnz

2

Celui-ci était contre-intuitif, il s'avère qu'un bon logiciel a plus de maintenance, car il est facile à changer. Par conséquent, il reste en service plus longtemps, ce qui entraîne, oui, plus de changements.

Vous semblez voir cela à partir du montant de la maintenance et non du pourcentage des coûts. Un bon logiciel qui a plus de fonctionnalités ajoutées est juste une plus grande quantité de logiciels. Si le pourcentage de maintenance est fixe (car il s'agissait d'un bon logiciel et nous supposons que les fonctionnalités supplémentaires ont été ajoutées en tant que bon logiciel), le montant augmentera. C'est juste un plus gros morceau de tarte avec le même nombre de tranches.

Selon ce que vous demandez, il importe que le "bon" logiciel soit écrit en: code fonctionnel, POO ou procédural. Est-ce que donner à quelqu'un une scie électrique guidée au laser permettra d'économiser du bois si la personne ne sait pas mesurer?

— JeffO
source