language agnostic - Costo de desarrollo de programación procedural vs. OOP?
language-agnostic procedural-programming (9)
Vengo de un fondo OO bastante fuerte, los beneficios de OOD & OOP son algo natural para mí, pero recientemente me encontré en una tienda de desarrollo vinculada a los hábitos de programación de procedimientos. El lenguaje de implementación tiene algunas características de OOP, no se usan de manera óptima.
Actualización: todos parecen tener una opinión sobre este tema, al igual que yo, pero la pregunta era:
¿Han habido buenos estudios comparativos que contrasten el costo del desarrollo de software usando lenguajes de programación procedural versus lenguajes orientados a objetos?
Algunos comentaristas han señalado la dudosa naturaleza de tratar de comparar las manzanas con las naranjas, y estoy de acuerdo en que sería muy difícil medir con precisión, aunque quizás no del todo imposible.
Buena idea. Una comparación cara a cara. Escriba la aplicación X en un estilo de procedimiento y en un estilo OO y mida algo. Costo para desarrollar Retorno de la inversión.
¿Qué significa escribir la misma aplicación en dos estilos? Sería una aplicación diferente, ¿no? La gente de procedimiento se negaría a que la gente de OO hiciera trampas cuando usaban herencia o mensajería o encapsulación.
No puede haber tal comparación. No hay ninguna base para comparar dos "versiones" de una aplicación. Es como preguntar si las manzanas o las naranjas son más rentables para ser fruta.
Habiendo dicho eso, debes enfocarte en cosas que otras personas realmente pueden ver.
Es hora de construir algo que funcione.
Tasa de errores y problemas.
Si su enfoque es mejor, tendrá éxito y las personas querrán saber por qué.
Cuando explicas que OO te lleva a tu éxito ... bueno ... has ganado la discusión.
La clave es el tiempo. ¿Cuánto tiempo le lleva a la empresa cambiar el diseño para agregar nuevas características o corregir las existentes? Cualquier estudio que hagas debe enfocarse en esa área.
Mi empresa tenía un diseño orientado a eventos y orientado a procedimientos para un software CAM a mediados de los años 90 creado utilizando VB3. Se tardó mucho tiempo en adaptar el software a nuevas máquinas. Un largo tiempo para probar los efectos de las correcciones de errores y las nuevas funciones.
Con VB6, pude graficar el diseño actual y un nuevo diseño que solucionó el problema de prueba y adaptación. El jefe no técnico captó lo que estaba intentando hacer de inmediato.
La clave es explicar por qué OOP beneficiará al proyecto. Use cosas como Refactoring by Fowler y Design Patterns para mostrar cómo un nuevo diseño reducirá el tiempo para hacer cosas. También incluye cómo llegar del punto A al punto B. Refactorizar ayudará a mostrar cómo puede tener etapas intermedias de trabajo que pueden enviarse.
La mayoría de estas preguntas se confunden con el problema de que la productividad del programador individual varía en un orden de magnitud o más; si tiene un programador OO que es uno de los gruop en productividad xy un programador "procedural" que es un programador 10x, el programador de procedimientos es susceptible de ganar incluso si OO es más rápido en algún sentido.
También existe el problema de que la productividad de codificación suele ser solo del 10 al 20 por ciento del esfuerzo total en un proyecto realista, por lo que una mayor productividad no tiene mucho impacto; incluso ese hipotético programador 10x, o un programador infinitamente rápido, no puede reducir el esfuerzo general en más de 10-20 por ciento.
Puede echar un vistazo al artículo de Fred Brooks "No Silver Bullet" .
OO u oferta de procedimiento a una manera diferente de desarrollar y ambos pueden ser costosos si se manejan mal.
Si suponemos que los trabajos son realizados por la mejor persona en ambos casos, creo que el resultado puede ser igual en términos de costo.
Creo que la diferencia de costos dependerá de cómo será la fase de mantenimiento en la que tendrá que agregar funciones y modificar las características actuales. El proyecto de procedimiento es más difícil de realizar las pruebas automáticas, está menos sujeto a poder expandirse sin afectar a otras partes y es más difícil entender el concepto parte por parte (porque la parte cohesiva no está agrupada).
Por lo tanto, creo que el costo de OO será menor a largo plazo en comparación con el procedimiento.
Creo que S.Lott se estaba refiriendo al fenómeno del "experimento irrepetible", es decir, no puede escribir la aplicación X de forma procesal, luego rebobinar el tiempo y escribirla OO para ver cuál es la diferencia.
podrías escribir la misma aplicación dos veces de dos maneras diferentes, pero
- aprenderías algo sobre la aplicación haciéndolo de la primera manera que te ayudaría de la segunda manera, y
- puede ser mejor en OO que en procedimientos, o viceversa, según su experiencia y la naturaleza de la aplicación y las herramientas elegidas
entonces realmente no hay una base directa para la comparación
los estudios empíricos son igualmente inútiles, por razones similares: diferentes aplicaciones, diferentes equipos, etc.
los cambios de paradigma son difíciles, y un pequeño porcentaje de programadores nunca puede hacer la transición
Si eres libre de desarrollar tu camino , entonces la solución es simple: desarrolla las cosas a tu manera, y cuando tus compañeros de trabajo notan que estás codificando círculos alrededor de ellos y tu código no se rompe casi con frecuencia, etc., y te preguntan cómo lo haces, luego enséñales OOP (junto con TDD y cualquier otra buena práctica que puedas usar)
si no, bueno, podría ser hora de pulir el currículum ... ;-)
Dudo que encuentres un estudio definitivo. Como varias personas han mencionado, este no es un experimento reproducible. Encontrará evidencia anecdótica, mucha información. Algunas personas pueden encontrar algunos estudios estadísticos, pero los examinaría cuidadosamente. No estoy al tanto de ninguno realmente bueno.
También haré otro punto, no hay algo exclusivamente orientado a objetos o puramente procesal en el mundo real. Muchos, si no la mayoría, de los métodos de objetos se escriben con código de procedimiento. Al mismo tiempo, muchos programas de procedimientos usan metodologías OO, como la encapsulación (también llamada abstracción por parte de algunos).
No me malinterpreten, OO y los programas de procedimiento se ven y son diferentes, pero es una cuestión de gris oscuro frente a gris claro en lugar de blanco y negro.
No creo que encuentres un estudio como ese. Al menos debes definir lo que quieres decir con "costo". Debido a que el diseño de OOP es de alguna manera más lento, a corto plazo el desarrollo es quizás más rápido con la programación de procedimientos. A muy corto plazo, quizás la codificación de espagueti sea aún más rápida.
Pero cuando el proyecto comienza a crecer las cosas son opuestas, porque el diseño OOP se presenta mejor para administrar la complejidad del código.
Entonces, en un proyecto pequeño, el diseño de procedimientos PUEDE ser más económico, porque es más rápido y no tiene inconvenientes. Pero en un gran proyecto, obtendrás palo muy rápido usando solo un paradigma simple como la programación de procedimientos
Después de hurgar con google, encontré este documento aquí . Los términos de búsqueda que utilicé están orientados a objetos de Productividad.
Los párrafos iniciales continúan diciendo
La introducción de tecnología orientada a objetos no parece obstaculizar la productividad general en nuevos grandes proyectos comerciales, pero tampoco parece mejorarla en las dos primeras generaciones de productos. En la práctica, la influencia rectora puede ser el flujo de trabajo del negocio y no la metodología.
Creo que encontrará que la Programación Orientada a Objetos es mejor en circunstancias específicas, pero neutral para todo lo demás. Lo que vendió a mis jefes en la conversión de la aplicación CAD / CAM de mi empresa a un marco orientado a objetos es que mostré con precisión las áreas exactas en las que ayudaría. La atención no se centró en la metodología en su conjunto, sino en cómo nos ayudará a vender algún problema específico que tuvimos. Para nosotros teníamos un marco extensible para agregar más formas, informes y controladores de máquina, y el uso de colecciones para eliminar la limitación de memoria del diseño anterior.
Este artículo no dice nada sobre OOP vs Procedural. Pero creo que podría usar métricas similares de su empresa para una discusión.
Lo encuentro interesante ya que mi compañía está comenzando a explorar la iniciativa ROWE . En nuestra primera sesión, fue evidente que actualmente no capturamos suficientes métricas en los resultados.
Entonces debe enfocarse en 1) ¿El mantenimiento de los procesos actuales impide el desarrollo futuro? 2) ¿Cómo van a afectar los diferentes métodos al # 1?