Paradigmas de programación y el desarrollador de mantenimiento [cerrado]

9

Estaba leyendo, Facts and Falacies of Software Engineering, que tiene una sección de mantenimiento. Desde entonces, he sido desarrollador de mantenimiento durante años, me presentaron hechos muy interesantes. Aquí hay tres.

Hecho 41: El mantenimiento generalmente consume del 40 al 80 por ciento (promedio, 60 por ciento) de los costos de software. Por lo tanto, es probablemente la fase más importante del ciclo de vida del software.
Hecho 42: La mejora es responsable de aproximadamente el 60 por ciento de los costos de mantenimiento del software. La corrección de errores es aproximadamente del 17 por ciento. Por lo tanto, el mantenimiento del software se trata principalmente de agregar nuevas capacidades al software antiguo, no de repararlo.
Hecho 45: Un mejor desarrollo de ingeniería de software lleva a más mantenimiento, no menos.

Este era contrario a la intuición, resulta que un buen software tiene más mantenimiento, porque es fácil de cambiar. Por lo tanto, permanece en uso por más tiempo, lo que lleva a, sí, más cambios.

¿Qué paradigma (como funcional, orientado a objetos, de procedimiento) tiene la mejor capacidad de mantenimiento, y ¿hay alguna investigación que respalde esto?

maintenance maintainability

— KaizenSoze
fuente

Tengo una copia de Facts and Falacies, y para cada hecho (y falacia), hay citas de varias publicaciones que lo respaldan. No tengo una copia a mano, pero ¿alguna de esas citas discute el efecto del paradigma en el mantenimiento?

— Thomas Owens

El libro fue escrito en 2003, muchas de las conclusiones siguen siendo relevantes hoy en día. Tenía curiosidad si la gente tenía nuevos estudios sobre paradigmas particulares. El mantenimiento parece una parte olvidada de la discusión.

— KaizenSoze

Si alguno de los estudios o publicaciones citados en Facts and Falacies trata sobre la capacidad de mantenimiento de un paradigma particular, una opción sería buscar en las bases de datos IEEE o ACM otros artículos y documentos que citan ese documento. Si no tiene acceso a las bases de datos IEEE o ACM, puedo mirar mi copia del libro cuando llegue a casa y ver si puedo hacer esa búsqueda. Desafortunadamente, solo podría obtener los nombres de otros documentos y no los documentos en sí.

— Thomas Owens

12

Creo que encontrará que los paradigmas como funcional, OO y procesal probablemente no se correlacionan con el mantenimiento del software de una manera significativa.

Lo que puede encontrar los siguientes ejemplos es mucho más claro con el mantenimiento del software:

Nivel de recopilación de requisitos e ingeniería de requisitos
Buenas prácticas de desarrollo: (acoplamiento flojo, alta cohesión, pruebas unitarias, YAGNI ...)
Ingenieros de software calificados y calificados (valen 10 veces más que un imbécil)
Equipo de control de calidad técnico calificado y organizado
Buena gestión de proyectos dirigida por gerentes de proyectos competentes (aún más difícil de encontrar que los desarrolladores de software calificados en mi humilde opinión)
Buenos propietarios de productos o gerentes de aplicaciones, liderazgo sólido, buena dirección a largo plazo, buenos comentarios para los equipos del proyecto, visión general.

— árbol de arce
fuente

+1 Quiero agregar buena documentación a la lista

— treecoder

+1 Agregue el proceso "Valor centrado" a la lista. El proceso define e impulsa lo que se hace y no se hace. Lo que el proceso mide es importante, y lo que el proceso no mide no es importante. Especialmente cierto cuando los chicos de Recursos Humanos comienzan a llenar los asientos con "imbéciles".

— mattnz

2

Este era contrario a la intuición, resulta que un buen software tiene más mantenimiento, porque es fácil de cambiar. Por lo tanto, permanece en uso por más tiempo, lo que lleva a, sí, más cambios.

Parece que está viendo esto por la cantidad de mantenimiento y no por el porcentaje del costo. Un buen software que tiene más funciones agregadas es solo una mayor cantidad de software. Si el porcentaje de mantenimiento es fijo (porque era un buen software y asumimos que las características adicionales se agregaron como un buen software), la cantidad aumentará. Es solo un pedazo de pastel más grande con el mismo número de rebanadas.

Según lo que solicite, es importante si el software "bueno" se escribió en: código funcional, OOP o de procedimiento. ¿Darle a alguien una sierra eléctrica guiada por láser ahorrará en madera si la persona no sabe cómo medir?

— JeffO
fuente