Todos sabemos que es simple, ¿no?Al evaluar un diseño, ¿cómo evalúa la complejidad?
He visto la complejidad medida como el número de interacciones entre sistemas, y creo que es un muy buen lugar para comenzar. Sin embargo, aparte de la sensación visceral, ¿qué otros métodos (preferiblemente más objetivos) pueden usarse para determinar el nivel de complejidad de un diseño o pieza de software en particular?
¿Cuáles son SUS reglas o heurísticas preferidas?
Si su aplicación está construida, puede medirla en términos de tiempo (cuánto tiempo llevará ejecutar una tarea en particular) o cálculos (cuánto código se ejecuta cada vez que se ejecuta la tarea).
Si solo tiene diseños, puede ver cuántos componentes de su diseño son necesarios para ejecutar una tarea determinada o ejecutar una tarea promedio. Por ejemplo, si usa MVC como su patrón de diseño, entonces tiene al menos 3 componentes tocados para la mayoría de las tareas, pero dependiendo de la implementación del diseño, puede terminar con docenas de componentes (un caché además del 3 capas, por ejemplo).
Éstos son los míos:
1) ¿Es difícil de explicar a alguien que entiende el problema, pero no ha pensado en la solución? Si explico el problema a alguien en el pasillo (que probablemente ya entiende el problema si están en la sala) y puede explicar la solución, entonces no es demasiado complicado. Si demora más de una hora, es probable que la solución esté sobreinyectada.
2) ¿Qué tan profundo debe andar en las funciones anidadas? Si tengo un objeto que requiere una propiedad mantenida por un objeto sostenido por otro objeto, entonces es probable que lo que estoy tratando de hacer esté demasiado alejado del objeto mismo. Esas situaciones se vuelven problemáticas cuando se trata de hacer que los objetos sean seguros para la ejecución de subprocesos, ya que habrá muchos objetos de diferentes profundidades desde su posición actual hasta el bloqueo.
3) ¿Estás tratando de resolver problemas que ya se han resuelto antes? No todos los problemas son nuevos (y algunos argumentarían que ninguno realmente lo es). ¿Hay un patrón o grupo de patrones existente que pueda usar? Si no puedes, ¿por qué no? Está bien hacer sus propias soluciones nuevas, y estoy de acuerdo, pero a veces las personas ya han respondido el problema. No voy a volver a escribir STL (aunque lo intenté, en un punto), porque la solución ya existe y es buena.
Cuando asistí al taller de Modelización de sistemas complejos en el New England Complex Systems Institute (http://necsi.org/), una de las medidas que utilizaron fue la cantidad de estados del sistema.
Por ejemplo, si tiene dos nodos, que interactúan, A y B, y cada uno de éstos puede ser 0 o 1, sus posibles estados son:
A B
0 0
1 0
0 1
1 1
Así, un sistema de sólo el 1 interacción entre binario los componentes realmente pueden resultar en 4 estados diferentes. El punto es que la complejidad del sistema no necesariamente aumenta linealmente a medida que aumenta el número de interacciones.
La complejidad se puede estimar con el acoplamiento y cómo cohesivo son todos sus objetos. Si algo tiene demasiado acoplamiento o no es lo suficientemente cohesivo, entonces el diseño comenzará a ser más complejo.
buenas medidas pueden ser también el número de archivos, el número de lugares donde se almacena la configuración, el orden de compilación en algunos idiomas.
Ejemplos:
.- archivos de propiedades, configuración de base de datos, archivos XML para almacenar la información relacionada.
.- decenas de miles de clases con las interfaces y las asignaciones de bases de datos
.- un fichero de construcción extremadamente largo y complicado (build.xml, Makefile, otros ..
Hay métricas formales. Leer arriba en Cyclomatic Complexity, por ejemplo.
Editar.
también, busque en Function Points. Ellos le dan una medición cuantitativa de la complejidad del sistema que no se produce en el intestino.
complejidad ciclomática es un mteric calculado a partir del código fuente - usted no tiene el código fuente durante el diseño! –
@Steven A. Lowe: Sin embargo, tiene los mismos conceptos de sentencias if. Puede calificar fácilmente partes de su diseño con complejidad en función de las elecciones y decisiones descritas en las especificaciones o requisitos. –
Cyclomatic es mejor cuando tienes el código fuente. En el diseño, simplemente no es productivo intentar estimar el número de ciclos y la comparación. –
¿Finalmente algo LOC puede realmente ayudar a medir? :)
creo que la complejidad se ve mejor como el número de cosas que necesitan interactuar.
Un diseño complejo tendría n niveles mientras que un diseño simple tendría solo dos.
Complejidad es necesarios para solucionar problemas que la simplicidad no puede superar, por lo que no siempre será un problema.
Existe un problema en la definición de la complejidad en general ya que la complejidad generalmente tiene una tarea asociada. Algo puede ser complejo de entender, pero simple de ver (código muy lacónico, por ejemplo) El número de interacciones para que esta página web llegue desde el servidor a su computadora es muy compleja, pero la abstracción del protocolo http es muy simple.
Por lo tanto, tener una tarea en mente (por ejemplo, mantenimiento) antes de seleccionar una medida puede hacerla más útil. (es decir, agregar un archivo de configuración e iniciar sesión en una aplicación aumenta su complejidad objetiva [sí, solo un poco seguro], pero simplifica el mantenimiento).
No es la complejidad del código, pero el diseño, es difícil saber cuántos archivos al diseñar;) –