Las consecuencias de la sobreingeniería en el diseño de software

disenosoftware

disenosoftware

la sobreingeniería en el diseño de software es la consecuencia de desarrollar intentando dar solución a funcionalidades futuras. Pasa en las mejores familias. ¿A quién no le ha ocurrido esto alguna vez? A mí personalmente, unas cuantas.

La experiencia nos dice que los requisitos de un proyecto suelen cambiar y esa es una realidad que hemos de asumir desde el inicio del desarrollo. Los cambios realizados durante la fase de desarrollo implican modificar, adaptar o incluso desechar partes del código implementado. Por lo tanto, desarrollar teniendo en cuenta tanto el espacio, contexto concreto, como el tiempo, pensar demasiado en el futuro no parece una buena idea.

Imaginemos que estamos desarrollando un componente propio para nuestra aplicación, una librería open source o un plugin para nuestro framework favorito. En estos casos, solemos implementar funcionalidad extra porque creemos que nos será útil más adelante. Todo un clásico en el mundo software.

El resultado final es la acumulación de fragmentos de código que nunca van a ser usados. Estamos engordando el número de líneas y dificultando la legibilidad. Esto es nefasto a nivel individual y mucho más a nivel de equipo.

Recapitulando, estas son las consecuencias de aplicar sobreingeniería en nuestro diseño de software:

  1. Mayor coste de tiempo (en su implementación) y en consecuencia, de presupuesto.
  2. Aumento de la complejidad del código haciéndolo menos legible y menos mantenible.
  3. Peor rendimiento de la aplicación (dependiendo de la complejidad añadida).
  4. Aumento del riesgo a tener nuevos bugs ya que hay funcionalidad que nunca se prueba.

Suena bastante mal, ¿verdad? ¿Cómo podemos protegernos de los cambios sin caer en las garras de la sobreingeniería? Te recomendamos leer Como desarrollar código a prueba de cambio