Me pregunto cuál sería una buena definición de término "sobre-ingeniería" aplicada al desarrollo de software. La expresión parece usarse mucho durante las discusiones de diseño de software a menudo junto con "excesivo a prueba de futuro" y sería bueno definir una definición más precisa.¿Qué es la "sobre-ingeniería" aplicada al software?
Creo que la mejor respuesta a su pregunta se pueden encontrar en this other qestion
Hay esta discusión en Joel on Software que comienza con,
creación de extensas jerarquías de clases para un problema futuro imaginado que no lo hace todavía existir, es una especie de exceso de ingeniería, y por lo tanto, es malo.
Y, entra en una discusión con ejemplos.
Aquí hay otro sobre la sobre-ingeniería de frameworks: http : //discuss.joelonsoftware.com/default.asp? joel.3.219431.12 –
Mi definición aproximada sería 'que proporcionan una funcionalidad que isnt necesario para cumplir con la especificación de requisitos'
¿Qué hay de los requisitos no expresados? A menudo no están en la especificación, sin embargo deben cumplirse para ofrecer una solución robusta. –
Si no lo dicen, ¿cómo sabes cuándo los has satisfecho? – PaulJWilliams
sobre la ingeniería a menudo comienza en la etapa de requisitos. Recuerdo un proyecto SSADM que generó alrededor de 5000 páginas de documentos de requisitos antes de que se escribiera una sola línea de código. –
creo que son los mismos que Gold plating y recibir golpes de la Golden hammer :)
Básicamente, usted puede sentarse y pasó demasiado tiempo tratando de hacer un diseño perfecto, sin escribir ningún código para ver cómo funciona. Cualquier método ágil le dirá que no haga todo el diseño por adelantado, y que simplemente cree fragmentos de diseño, impleméntelo, reitere sobre él, rediseñe, vuelva a comenzar, etc. ...
En los casos donde hemos considerado las cosas por ingeniería, siempre ha estado describiendo un software que ha sido diseñado para ser tan genérico que pierde de vista la tarea principal para la que inicialmente fue diseñado y, por lo tanto, se ha vuelto no solo difícil de usar, sino también poco inteligente .
Quoting from here: "... Implementar las cosas cuando en realidad los necesita, no cuando simplemente prever que los necesite."
Solo por favor no desarrolle software para reactores nucleares con esta filosofía en mente;) – 0scar
Punto tomado, pero discutiría la semántica aquí y diría que usted * realmente * necesita casi todas las salvaguardas posibles cuando se trata de software que podría afectar la seguridad o salud – JosephStyons
La respuesta ágil a esta pregunta es: cada pieza de código que no contribuye a la funcionalidad solicitada.
Para mí, la sobreingeniería incluye todo lo que no necesita y que no necesita saber que va a necesitar. Si te encuentras diciendo que una característica podría ser agradable si los requisitos cambian de cierta manera, entonces podrías estar sobre-ingeniería. Básicamente, la sobreingeniería está violando YAGNI.
La belleza de la programación ágil es que es difícil sobre-diseñar si lo haces bien.
Pero puede terminar con una suite de pruebas masivamente desarrollada :) (patos para cubrir) –
Si escribe un manifiesto que defina lo que es "correcto" y lo que está "mal" y luego lo siga, entonces sí, probablemente sea bastante difícil hacerlo algo mal". – 0scar
@ 0scar: ese es el punto con Agile: usted define lo que es correcto. :) –
Over-Engeneering significa la arquitectura y el diseño de la aplicación con más componentes de los que realmente debería tener según la lista de requisitos.
Hay una gran diferencia entre la sobre-ingeniería y la creación de una aplicación extensible, que se puede actualizar a medida que cambian los requisitos. Si puedo pensar en un ejemplo, editaré la publicación.
Si pasa tanto tiempo pensando en las posibles ramificaciones de un problema que termina interfiriendo con la solución del problema en sí, es posible que esté sobre-ingeniería.
Existe un delicado equilibrio entre las "mejores prácticas de ingeniería" y la "aplicabilidad en el mundo real". En algún momento, debe decidir que, aunque una solución en particular no sea tan "pura" desde el punto de vista de la ingeniería como podría ser, hará el trabajo.
Por ejemplo:
Si está diseñando un sistema de gestión de usuarios para el uso de una sola vez a una reunión de secundaria, es probable que no es necesario añadir soporte para nombres muy largos, o conjuntos de caracteres cobardes. Establecer una longitud máxima razonable y hacer un poco de desinfección básica debería ser suficiente. Por otro lado, si está creando un sistema que se implementará para cientos de eventos similares, es posible que desee dedicar más tiempo al problema.
Todo se trata del nivel de esfuerzo adecuado para la tarea en cuestión.
Me temo que una definición precisa probablemente no sea posible ya que depende en gran medida del contexto. Por ejemplo, es mucho más fácil sobre-diseñar un sitio web que muestra ponis brillantes que un sistema de control de planta de energía nuclear. Las redundancias, la comprobación de errores excesivos, las instalaciones de registro altamente instrumentadas son una ingeniería excesiva para una aplicación de ponys brillantes, pero no para un sistema de control de una planta de energía nuclear. Creo que lo mejor que puede hacer es tener una idea de cuándo está aplicando demasiada sobrecarga a sus funciones para el propósito de la aplicación.
Tenga en cuenta que yo distinguiría entre dorado y sobre-ingeniería. En mi opinión, el dorado está creando características que no se pidieron y nunca se usarán. La sobreingeniería se trata más de la cantidad de "seguridad" que incorpora en la aplicación, ya sea mediante la codificación de verificaciones en torno al código o mediante el uso de un diseño excesivo para una tarea sencilla.
Para mí es cualquier cosa que agregue más grasa al código. Carne sería cualquier código que haga el trabajo de acuerdo con la especificación y la grasa sería cualquier código que inflaría el código de una manera que simplemente agrega más complejidad. El programador podría haber estado esperando una futura expansión de la funcionalidad; pero aún así es gordo.!
Contrariamente a la mayoría de las respuestas, no creo que la "funcionalidad actualmente innecesaria" sea una sobre-ingeniería; o es la forma menos problemática.
como usted ha dicho, el peor tipo de sobre-ingeniería generalmente se comete en nombre del futuro-impermeabilización y extensibilidad - y logra exactamente lo contrario:
La verdad es que el diseño que se adapta más fácilmente a los requisitos nuevos y cambiantes (y por lo tanto es el más resistente al futuro y extensible) es el diseño lo más simple posible.
Interesante pensó que la sobre-ingeniería puede ocurrir cuando uno trata de encontrar un problema técnicamente interesante en lugar de simplemente implementar algo aburrido. Algo de lo que tener cuidado, supongo. –
¡Me gusta el último párrafo! –
Over-engineering es simplemente crear un producto con mayor funcionalidad, calidad, generalidad, extensibilidad, documentación o cualquier otro aspecto que el requerido.
Por supuesto, es posible que tenga requisitos fuera de un proyecto específico; por ejemplo, si prevé futuras aplicaciones similares, entonces puede tener requisitos adicionales de extensibilidad, dependiendo del costo, que agregue a los requisitos específicos del proyecto .
Contrario a la creencia popular, la sobreingeniería es realmente un fenómeno que aparece cuando los ingenieros se vuelven "arrogantes" y piensan que entienden al usuario.
hice un simple diagrama para ilustrar esto:
Parece un cáncer. – Calmarius
Bonita ilustración. ¿Qué usaste para armar eso si pudiera preguntar? – TheLegendaryCopyCoder
Esto se relaciona con mi opinión de programación controvertido de "The simplest approach is always the best approach".
Cuando su diseño realmente hace las cosas más complejas en lugar de simplificar las cosas, es demasiado ingenioso.
Más sobre esto en:
Negación # 1: Soy un BA gran imagen. No conozco ningún código. Leo este sitio todo el tiempo. Esta es mi primera publicación.
Divertido Mi jefe me acaba de decir que diseñé un nuevo producto de software que planeamos para tutoría (gente de recursos humanos del mercado objetivo). Así que vine aquí a buscar el término.
Quieren obtener algo en el lugar para vender ahora, redirigiendo las herramientas existentes. No puedo evitar quedarme sentado y pensar, menos suscripciones, menor retención, si no permite algo de la flexibilidad de la que hablamos. Y principalmente, tienen una interfaz de usuario muy visual que un mono podría usar.
Dijo que podíamos planificar fases futuras para mejorar el producto, especialmente la interfaz de usuario. Tenemos clientes actuales que esperan "mejoras futuras" que todavía no estamos haciendo. Sin embargo, lo necesitan, realmente lo necesitan.
Estoy en el proceso de renunciar, así que no retrocedí.
Pero mi definición sería ............. asegurándome de que solo hace lo mínimo posible, lo más barato posible, y aún así ser aceptable para lo que dices que es. Más allá de eso está la ingeniería excesiva.
Descargo de responsabilidad # 2: Este sitio me ayudó a aterrizar en mi próximo trabajo implementando un software más configurable.
Probablemente deba aplicar la etiqueta 'subjetiva' a esto. –
no relacionado con la programación – abmv
@abmv No estoy de acuerdo en absoluto. Las preguntas sobre el proceso de Desarrollo de software son completamente legítimas. – Pwninstein