Por el contrario, la “complejidad accidental” crece de aquellas cosas que pensamos que debemos construir para mitigar la complejidad esencial. Estas fueron diseñadas para tratar la complejidad esencial de controlar el tráfico de miles de aviones, pero la solución en si misma introduce su propia complejidad. De hecho, el sistema de control del tráfico aéreo usado hoy en día es tan complejo que actualizarlo es difícil, si no imposible. La mayoría del tráfico aéreo mundial está dirigido por tecnología de más de 30 años de antigüedad.
Muchos frameworks y vendedores de soluciones son los síntomas de la complejidad accidental de la enfermedad (nacieron para solventar la mayoría de malos diseños implementados para distintas problemáticas). Los frameworks que resuelven problemas específicos son útiles. Los frameworks sobre-diseñados añaden más complejidad de lo que arreglan.
Los desarrolladores se sienten atraídos hacia la complejidad como las polillas a las llamas, frecuentemente con el mismo resultado. Resolver problemas es divertido, y los desarrolladores resuelven problemas. A quien no le gustaría resolver rápidamente un problema increíblemente complejo? En el software a gran escala, sin embargo, eliminar la complejidad accidental, manteniendo la solución en su complejidad esencial, es un reto.
Como hacer esto? Prefiriendo frameworks derivados de código de trabajo en vez de aquellos moldeados desde una torre de marfil. Mirando el porcentaje de código que se tiene en una solución que maneja el problema de negocio vs el código que sirve la frontera entre la aplicación y los usuarios. Mirando con cuidado las soluciones proporcionadas por los proveedores. Esto no tiene que ser inherentemente malo, pero los vendedores frecuentemente agregan complejidad accidental. Asegúrese que la solución ataca el problema.
Es tarea del arquitecto resolver los problemas inherentes a la complejidad esencial sin introducir complejidad accidental.
Autor Neal Ford
Versión original : Simply essential complexity; diminish accidental complexity
| Ícaro, hijo del aquitecto Dédalo, aplico de forma errónea la solución diseñada por su padre, para escapar del encarcelamiento al que fueron sometidos, con un resultado nefásto. Los frameworks/tecnologías más famosos y extendidos, no siempre son los más adecuados a la solución de un problema, ya que pueden añadir "complejidad accidental". El uso de cualquiera de ellos, mucho menos garantiza estar excentos de fallos de implementación, y lo más grave, de su correcta utilización. |  Cuadro de Jacob Peter Gowy |
Emmerson.
- FIN -
No comments:
Post a Comment