editorial - graphic design glossary
¿Qué es la "sobre-ingeniería" aplicada al software? (19)
Cuando su diseño en realidad hace que las cosas sean más complejas en lugar de simplificar las cosas, usted está sobreingeniería.
Más sobre esto en:
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.
Contrariamente a la mayoría de las respuestas, no creo que la "funcionalidad actualmente innecesaria" sea una sobreingeniería; o es la forma menos problemática.
Como dijiste, el peor tipo de sobreingeniería suele cometerse en nombre de la capacidad de futuro y la extensibilidad, y logra exactamente lo contrario:
- Las capas de abstracción vacías son, en el mejor de los casos, innecesarias y, en el peor, lo restringen a un uso limitado e ineficiente de la API subyacente.
- El código está plagado de "puntos de extensión" designados, como métodos protegidos o componentes adquiridos a través de fábricas abstractas, que no son exactamente lo que realmente necesita cuando tiene que ampliar la funcionalidad.
- Haciendo que todo sea configurable para "evitar la codificación rígida", con el efecto de que hay más (lógica compleja, propensa a fallos) lógica de aplicación en los archivos de configuración que en el código fuente.
- Sobre-genérico: en lugar de implementar la especificación funcional (técnicamente poco interesante), el desarrollador crea un "motor de reglas de negocio" (técnicamente interesante) que "ejecuta" las especificaciones por sí mismas según lo suministrado por los usuarios comerciales. El resultado neto es un intérprete para un lenguaje propietario (scripting o específico de dominio) que generalmente está horriblemente diseñado, no tiene soporte de herramientas y es tan difícil de usar que ningún usuario de negocios podría trabajar con él.
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 que es lo más simple posible.
Contrario a la creencia popular, la sobre-ingeniería es un fenómeno que aparece cuando los ingenieros se vuelven "arrogantes" y piensan que entienden al usuario.
Hice un diagrama simple para ilustrar esto:
Creo que las mejores respuestas a su pregunta se pueden encontrar en esta otra pregunta
Creo que son lo mismo que chapado en oro y ser golpeado por el martillo de oro :)
Básicamente, puede sentarse y pasar demasiado tiempo tratando de hacer un diseño perfecto, sin siquiera escribir algún código para ver cómo funciona. Cualquier método ágil te dirá que no hagas todo tu diseño desde el principio, y que solo generes trozos de diseño, lo implementes, lo reiteres, lo rediseñes, lo vuelvas a hacer, etc.
En los casos en que hemos considerado las cosas por ingeniería, siempre se ha descrito 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, no solo es difícil de usar. , pero carente de fondos, inteligente.
Esto se relaciona con mi controvertida opinión de programación de "El enfoque más simple es siempre el mejor enfoque" .
Exención de responsabilidad n. ° 1: soy una gran figura BA. No conozco ningún código. Leo este sitio todo el tiempo. Esta es mi primera publicación.
Es curioso. Mi jefe me acaba de decir que diseñé una nueva producción de software que planeamos para la tutoría (gente de recursos humanos del mercado objetivo). Así que vine aquí a buscar el término.
Quieren obtener algo 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 podríamos planificar fases futuras para mejorar el producto, especialmente la IU. 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 mi próximo trabajo implementando un software más configurable.
Hay una discusión en Joel sobre software que comienza con,
crear extensas jerarquías de clase para un problema futuro imaginado que aún no existe, es una especie de exceso de ingeniería, y por lo tanto, es malo.
Y entra en una discusión con ejemplos.
La belleza de la programación ágil es que es difícil sobreingeniería si lo haces bien.
La respuesta ágil a esta pregunta es: cada pieza de código que no contribuye a la funcionalidad solicitada.
La sobreingeniería consiste simplemente en crear un producto con mayor funcionalidad, calidad, generalidad, extensibilidad, documentación o cualquier otro aspecto que el requerido.
Por supuesto, puede tener requisitos fuera de un proyecto específico; por ejemplo, si prevé realizar aplicaciones similares en el futuro, entonces podría tener requisitos adicionales de extensibilidad, en función del costo, que agregue a los requisitos específicos del proyecto.
La sobreingeniería significa diseñar y diseñar la aplicación con más componentes de los que realmente debería tener según la lista de requisitos.
Existe 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.
Me temo que probablemente no sea posible una definición precisa 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 fueron solicitadas y nunca serán utilizadas. 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.
Mi definición aproximada sería ''Proporcionar funcionalidad que no es necesaria para cumplir con los requisitos espec''
Para mí es algo que añadiría 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.!
Si pasa tanto tiempo pensando en las posibles ramificaciones de un problema que termina interfiriendo con la solución del problema, es posible que esté sobre-ingeniería.
Hay un equilibrio fino entre "mejores prácticas de ingeniería" y "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 administración de usuarios para un solo uso en una reunión de la escuela secundaria, probablemente no necesite agregar soporte para nombres increíblemente largos o conjuntos de caracteres originales. 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.
Se trata del nivel de esfuerzo adecuado para la tarea en cuestión.
Citando desde aquí : "... Implementa cosas cuando realmente las necesites, nunca cuando solo preveas que las necesitas".