¿Cómo visualizar el diseño de un motor de física?

Estoy haciendo un motor de física y se está volviendo bastante difícil hacer un seguimiento de todo. A menudo, cuando vuelvo a mi código después de un descanso, simplemente no recuerdo por qué eso no funciona. La mayoría de los problemas no son simples errores de programación, sino defectos de diseño en mi motor de física. Es por eso que debería terminar de diseñarlo antes de programarlo.

Sin embargo, necesito una forma de escribir en papel todo el diseño de mi motor de física. De lo contrario, lo olvidaré mañana y me perderé de nuevo. Un diagrama de clase UML no es apropiado para el diseño de un motor de física. Realmente no me importan las clases sino el proceso. No veo el diagrama de proceso de negocio como realmente útil porque modelar un solo paso (marco) de mi proceso no me ayudará a comprender el comportamiento final de mi motor en muchos pasos.

Entonces, ¿qué tipo de diagrama debo usar para ayudarme a realizar un seguimiento del proceso? ¿Qué tipo de diagrama usan los profesionales para hacer un motor de física?

Las listas de tareas son cosas maravillosas.

No estoy hablando de // #TODO: bla, bla, comentarios. Me refiero a obtener un cuaderno honesto con Dios.

Nunca se sabe cuándo recordará algo importante que hacer. Un cuaderno se sentará en silencio y le permitirá pensar sin quejarse de cómo su escritura no se compilará. Algunas de mis mejores ideas ocurren en el baño (sí, tengo un cuaderno a prueba de agua, pero no tienes que ir tan lejos).

Puede obtener los de bolsillo que están cosidos (no pegados) para que no se desmoronen en su bolsillo. ¿No logró obtener una elegante con un marcador incorporado? Cinta, tijeras, cinta y nadie lo sabrá jamás.

Cuando una idea golpea, simplemente anótala. Dibuja pequeños cuadros al lado de cada idea y puedes marcarla fácilmente como hecha. Pon un cuadro en la parte superior de la página y sabrás cuando la página esté lista.

¿Qué acceso secuencial no es lo suficientemente bueno para ti? Sí, también hacen carpetas de bolsillo. Todo esto puede parecer un poco demasiado, pero es mejor que ahogarse en las notas o intentar capturar todo en Jira.

No dejes las cosas medio implementadas

Mantenga sus mejoras pequeñas y alcanzables. No comiences nada que no se pueda terminar de una vez. Si es demasiado grande para eso, divídalo en pasos más pequeños. Siempre deje el código que compila y pasa sus pruebas. Ah, y no dejes pasar las pruebas que nunca has visto fallar. Hacer una prueba tanto aprobada como reprobada es cómo se prueba la prueba.

Deja de pensar que necesitas todo el diseño en papel

Lo que debe hacer es capturar su plan en evolución. No sabes cómo se verán las cosas cuando termines, así que deja de fingir que lo haces. Capture lo que haya descubierto lo mejor que pueda. Usa una servilleta y un crayón si es necesario. Pocas personas entienden el 90% de UML de todos modos. Use cualquier forma que pueda para mostrar lo que necesita mostrar. Me concentro en mostrar mis interfaces y qué sabe sobre qué.

Escribe notas cuando dejes de codificar

En el momento en que quite los dedos de las teclas es la última vez que comprenderá lo que ha hecho (y lo que ha planeado) tan bien como lo hace ahora. Capture esa comprensión lo mejor que pueda en algunas notas. Si todo lo que tiene son comentarios, entonces todavía está atado a la computadora y es probable que deje un charco en la silla. Una vez más, tener una computadora portátil es algo increíble.

De esta manera, puede aterrizar su cerebro con gracia, salvar su vejiga y despegar nuevamente más tarde sin recurrir a la cafeína y el rechinar de dientes.

"Todo debe construirse de arriba hacia abajo, excepto por primera vez", dicen.

Comenzaría desde el nivel más bajo (por ejemplo, matemática vectorial básica), y me aseguré de entenderlo bien y que tiene una buena cobertura de prueba. Luego, construiría una capa más además de eso, permitiendo más operaciones abstractas (por ejemplo, grupos / entidades, detección de colisiones, mecánica de colisiones). De nuevo, lo cubriría con pruebas; Me ayudaría a pensar en los casos de uso real de estas abstracciones en el motor.

A menos que comprenda muy bien todo el motor (por ejemplo, cuando vuelve a implementar un motor existente conocido), generalmente es bueno tener estas capas; le permite pensar en una capa en particular en términos de la capa anterior, y generalmente no es mucho más profunda. Puede experimentar y construir una capa con nuevas abstracciones útiles; lo que resulta práctico en realidad a menudo se desvía de las ideas iniciales.

Esperemos que cada capa sea lo suficientemente pequeña como para que no necesite un diagrama complicado, o sea fácil encontrar una útil.

Nunca he encontrado un diagrama de código complejo que fuera útil. Sin embargo, los diagramas de interacción y ciclo de vida son útiles. Muy a menudo, un diagrama como ese está limitado a 1-2 capas y, por lo tanto, es simple.

Lo que generalmente encuentro más valioso son las descripciones de interfaz y las garantías proporcionadas por cada nivel. Por ejemplo, el formato de las matemáticas vectoriales y lo que sucede en los errores numéricos; el formato de las descripciones de objetos más grandes (siempre convexo? siempre orientado en el sentido de las agujas del reloj ?, ¿cómo intersecar? etc.), los parámetros mecánicos de interacción (¿cómo avanza el tiempo? ¿cómo se maneja la masa? ¿se conserva siempre el impulso? ¿cómo se calculan las fuerzas?) interacciones correctas (¿cómo manejar la fricción? ¿deformación? ¿fragmentación? ¿La transformación de la energía mecánica en pérdidas de calor es algo?).

Cada capa debe ser lo suficientemente pequeña como para tener una cantidad observable de cosas que introduce y garantiza que proporciona. Esta descripción puede incluso redactarse sin que se escriba ningún código de implementación (todavía). Esto reduce la posibilidad de determinar que has hecho algo horriblemente mal en tres capas de profundidad; si lo hicieras, ya sería visible como máximo en dos capas de profundidad.

¡Haz diagramas de la arquitectura! Los diagramas de canalización de OpenGL FrustratedWithFormsDesigner publicados en los comentarios son un gran ejemplo para el flujo del programa , pero ese es solo un tipo de diagrama que puede ser útil.

Al diseñar diagramas, desea hacer que la comprensión del código sea simple e intuitiva; Esto puede abarcar tanto conceptos de alto nivel (como la línea superior de nodos en ese diagrama de canalización de OpenGL, diciendo algo) como detalles técnicos muy granulares (como un gráfico de llamada de función completa).

Idealmente, su documentación también debería hacer que el código sea fácil de entender para otras personas; Esto puede facilitar cosas como las revisiones de código o la colaboración de código abierto. Mire proyectos grandes para ver cómo logran esto: cuando trabaje con cientos de miles o millones de líneas de código, comprender cómo funciona el programa sin tener que leerlo es enormemente importante para realizar un seguimiento de la base de código o presentarlo a otros . El repositorio de Vim, con 1.3 millones de LOC, tiene bastante buena documentación de alto nivel (IMO) para esto en /src/README.txt . Introduce:

• Qué código en cada archivo hace
• Variables globales importantes y sus valores.
• Qué sucede en el bucle principal y qué funciones llama
• Qué sucede en cada uno de los modos y las funciones principales que los manejan
• Qué características de depuración nativas son

Si quiero contribuir con un parche, generalmente sé qué archivo necesito modificar para lograr mis objetivos sin excavar mucho.

Una de las mejores características de Vim /src/README.txtes lo fácil que es encontrarlo y lo completo que es; no es granular en ningún sentido, pero si hace clic en la srccarpeta en Github, se carga automáticamente y da instrucciones para encontrar otro código o documentación. Compare eso con el repositorio de Powershell, que busqué como ejemplo pero no pude encontrar ningún archivo o archivos equivalentes a los de Vim /src/README.txt. (¡Una mala señal para un proyecto con 988 mil LOC!)

Algunas cosas que puede querer diagramar o documentar incluyen:

• El flujo del programa conceptual (¿Qué hace el programa de lograr , y en qué orden?)
• Gráfico de llamada de función / flujo de programa implementado (¿Cómo logra el programa sus objetivos? ¿Qué funciones se llaman o se crean las clases?)
• ¿Qué código hay en qué archivos? ¿Cuál es el esquema organizacional y qué reglas tiene para determinar a dónde va una nueva función? Si tiene un esquema organizacional sólido, será fácil saber en qué archivo buscar una determinada función o clase, incluso sin un IDE o una característica similar a la de IDE "buscar en todo el proyecto".
• De manera relacionada, ¿qué archivos incluyen qué otros archivos (relacionados con un gráfico de llamada de función)?
• ¿Qué clases heredan de qué otras clases? ¿Cuál es el propósito de cada clase?

¿Cómo puedes hacer esos diagramas? A su nivel, y para los primeros borradores, el lápiz y el papel es probablemente el mejor / más rápido método. Cuando los diagramas y la documentación se vuelven más refinados, puede investigar:

• Dot / Graphviz, un conjunto de programas para generar gráficos a partir de .dotarchivos.
• LaTeX / TikZ, una herramienta muy compleja y detallada para generar gráficos o imágenes de cualquier tipo: puede ser demasiado pesado para sus necesidades, especialmente porque todo el posicionamiento de los nodos es manual, pero debe tenerse en cuenta, especialmente si planea escribir un papel o algo por el estilo más tarde.
• Para C, gson se egyptconecta gccy genera un .dotgráfico de llamadas. Se puede automatizar o incrustar en un makecomando, ¡lo cual es bueno!
• En relación con esto, GNU cflowpuede generar gráficos de llamadas de solo texto para C. Es posible que existan herramientas equivalentes para otros idiomas, aunque es posible que desee alejarse de las herramientas automatizadas en general; no crear el gráfico manualmente puede dificultar su comprensión del código o proporcionar una información inapropiada nivel de detalle complejo (saber qué funciones llamar printf()es usualmente bastante inútil).

Intenta usar un diagrama basado en redes de Petri. Es posible traducir el diagrama a programas de computadora de manera sistemática, y es posible integrar diagramas de alto nivel con diagramas de bajo nivel.

Referencias

Elementos netos y anotaciones: un lenguaje de programación visual de uso general (2016). Disponible en https://www.academia.edu/31341292/Net_Elements_and_Annotations_A_General-Purpose_Visual_Programming_Language .

Elementos netos y anotaciones para la programación de computadoras: computaciones e interacciones en PDF (2014). Disponible en https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .