¿Mejores prácticas para gestionar la complejidad / visualizar componentes en su software?

Question

Estamos creando herramientas para extraer información de la web. Tenemos varias piezas, como

• Rastrear datos desde la web
• Extraer información basada en plantillas & amp; reglas de negocio
• Analizar resultados en la base de datos
• Aplicar normalización & amp; reglas de filtrado
• Etc, etc.

El problema es la resolución de problemas & amp; tener una buena "imagen de alto nivel" de lo que sucede en cada etapa.

¿Qué técnicas lo han ayudado a comprender y administrar procesos complejos?

• Use herramientas de flujo de trabajo como Windows Workflow Foundation
• Encapsula funciones separadas en herramientas de línea de comandos & amp; utilizar herramientas de secuencias de comandos para vincularlos juntos
• Escriba un lenguaje específico de dominio (DSL) para especificar en qué orden deberían suceder las cosas a un nivel superior.

Es curioso cómo maneja un sistema con muchos componentes interactivos. Nos gustaría documentar / comprender cómo funciona el sistema a un nivel más alto que el rastreo a través del código fuente.

Answer 1

El código dice lo que sucede en cada etapa. Usar un DSL sería una bendición, pero posiblemente no si tiene el costo de escribir su propio lenguaje de scripting y / o compilador.

La documentación de nivel superior no debe incluir detalles de lo que sucede en cada paso; debería proporcionar una visión general de los pasos y cómo se relacionan entre sí.

Buenos consejos:

• Visualice sus relaciones de esquema de base de datos.
• Use visio u otras herramientas (como la que mencionó, no la ha usado) para vistas generales del proceso (en mi opinión, pertenece a la especificación de su proyecto).
• Asegúrese de que su código esté correctamente estructurado / compartimentado / etc.
• Asegúrese de tener algún tipo de especificación de proyecto (o alguna otra documentación general que explique lo que hace el sistema en un nivel abstracto).

No recomendaría crear herramientas de línea de comandos a menos que realmente las use. No es necesario mantener herramientas que no usa. (Eso no es lo mismo que decir que no puede ser útil; pero la mayoría de lo que haces suena más como si perteneciera a una biblioteca en lugar de ejecutar procesos externos).

Answer 2

Utilizo el famoso Graphviz de AT & amp; T, es simple y funciona muy bien. Es la misma biblioteca que Doxygen usa también.

Además, si haces un pequeño esfuerzo, puedes obtener gráficos muy bonitos.

Olvidé mencionar que la forma en que lo uso es la siguiente (porque Graphviz analiza los scripts de Graphviz), uso un sistema alternativo para registrar eventos en formato Graphviz, por lo que simplemente analizo el archivo Logs y obtengo un buen gráfico.

Answer 3

Encuentro una matriz de estructura de dependencia una forma útil de analizar la estructura de una aplicación. Una herramienta como lattix podría ayudar.

Dependiendo de su plataforma y cadena de herramientas, hay muchos paquetes de análisis estático realmente útiles que podrían ayudarlo a documentar las relaciones entre subsistemas o componentes de su aplicación. Para la plataforma .NET, NDepend es un buen ejemplo. Sin embargo, hay muchos otros para otras plataformas.

Tener un buen diseño o modelo antes de construir el sistema es la mejor manera de comprender para el equipo cómo se debe estructurar la aplicación, pero las herramientas como las que mencioné pueden ayudar a hacer cumplir las reglas arquitectónicas y, a menudo, le brindarán información sobre el diseño que solo puede rastrear el código.

Answer 4

No usaría ninguna de las herramientas que mencionaste.

Necesita dibujar un diagrama de alto nivel (me gusta el lápiz y el papel).

Diseñaría un sistema que tenga diferentes módulos haciendo diferentes cosas, valdría la pena diseñar esto para que pueda tener muchas instancias de cada módulo ejecutándose en paralelo.

Pensaría en usar múltiples colas para

• URL para rastrear
• Páginas rastreadas de la web
• Información extraída basada en plantillas & amp; reglas de negocio
• Resultados analizados
• normalizado & amp; resultados filtrados

Tendría programas simples (probablemente de línea de comandos sin interfaz de usuario) que leerían los datos de las colas e insertarían datos en una o más colas (El rastreador alimentaría las " URL para rastrear " y " Páginas rastreadas de la web " ), puede usar:

• Un rastreador web
• Un extractor de datos
• Un analizador
• Un normalizador y filtrador

Estos encajarían entre las colas, y podría ejecutar muchas copias de estos en PC separadas, permitiendo que esto se escale.

La última cola podría enviarse a otro programa que realmente publique todo en una base de datos para uso real.

Answer 5

Mi empresa escribe especificaciones funcionales para cada componente principal. Cada especificación sigue un formato común y usa varios diagramas e imágenes según corresponda. Nuestras especificaciones tienen una parte funcional y una parte técnica. La parte funcional describe qué hace el componente a un alto nivel (por qué, qué objetivos resuelve, qué no hace, con qué interactúa, documentos externos relacionados, etc.). La parte técnica describe las clases más importantes en componentes y patrones de diseño de alto nivel.

Preferimos el texto porque es el más versátil y fácil de actualizar. Esto es un gran problema: no todos son expertos (o incluso decentes) en Visio o Dia, y eso puede ser un obstáculo para mantener los documentos actualizados. Escribimos las especificaciones en una wiki para que podamos vincular fácilmente entre cada especificación (así como rastrear los cambios) y permitir un recorrido no lineal a través del sistema.

Para un argumento de la autoridad, Joel recomienda Especificaciones funcionales aquí y aquí .

Answer 6

El diseño de arriba hacia abajo ayuda mucho. Un error que veo es hacer que el diseño de arriba hacia abajo sea sagrado. Su diseño de nivel superior debe revisarse y actualizarse como cualquier otra sección de código.

Answer 7

Es importante dividir estos componentes a lo largo de su ciclo de vida de desarrollo de software: tiempo de diseño, tiempo de desarrollo, pruebas, lanzamiento y tiempo de ejecución. Simplemente dibujar un diagrama no es suficiente.

He descubierto que adoptar una arquitectura de microkernel realmente puede ayudar a "dividir y conquistar". Esta complejidad. La esencia de la arquitectura de microkernel es:

• Procesos (cada componente se ejecuta en un espacio de memoria aislado)
• Subprocesos (cada componente se ejecuta en un subproceso separado)
• Comunicación (los componentes se comunican a través de un único canal simple de paso de mensajes)

He escrito un sistema de procesamiento por lotes bastante complejo que suena similar a su sistema usando:

Cada componente se asigna al ejecutable .NET Las vidas ejecutables se administran a través de Autosys (todo en la misma máquina) La comunicación se realiza a través de TIBCO Rendezvous

Si puede usar un kit de herramientas que proporcione cierta introspección en tiempo de ejecución, aún mejor. Por ejemplo, Autosys me permite ver qué procesos se están ejecutando, qué errores han ocurrido, mientras que TIBCO me permite inspeccionar las colas de mensajes en tiempo de ejecución.

Answer 8

Me gusta usar NDepend para realizar ingeniería inversa de bases de código complejas .NET. La herramienta viene con varias excelentes funciones de visualización como:

Gráfico de dependencia: ??

Matriz de dependencia: ??

Visualización de métrica de código a través de mapeo de árbol: ??