¿Cuáles son buenas técnicas para mantener su lugar en el código?

Entiendo el uso de marcadores para recordar un solo punto en su código. Sin embargo, ¿cómo se hace un seguimiento del flujo del código que están investigando? Por ejemplo: múltiples marcadores y el orden en que se hicieron.

Ejemplo:

1. Informe de error: "Las colisiones no funcionan en las esquinas de las paredes"

   1. La reproducción del error lo atribuye a ciertos polígonos que no colisionan.
   2. El código de colisión fue escrito por un desarrollador no disponible. Entonces la investigación es algo así como:

Durante la investigación, especialmente cuando se revisan elementos que no son de código, como Google, se puede esperar razonablemente que pierdan su lugar en el código ( ¿Ya he visto esta ruta de código? O ¿Qué ruta de código estaba investigando? Hay varios que conducen a esta función , etc.). Lo mismo ocurre con las interrupciones inevitables (Jefe: necesito [Informe largo sin sentido] AHORA , etc.)

Sería útil tener un recurso de técnicas o herramientas para proporcionar una manera de realizar un seguimiento de su lugar en el código.

Editar : El ejemplo anterior se entiende como una ilustración potencial, no como un problema real que necesita respuesta.

Otra forma de formular esta pregunta es:

Cuando aprende un nuevo sistema, ¿cómo realiza un seguimiento de dónde está en el aprendizaje del código? No se trata de entender por qué el código hace lo que hace (que es para lo que deberían ser los comentarios), sino cómo lo hace (que solo se aprende leyendo el código, no comentarios).

La interfaz de burbujas intenta resolver este problema mostrando un montón de bits de código a la vez. (Estás atrapado con tu navegador para buscar en Google). Se ve increíble pero no lo he probado. Esta versión de la idea es una implementación de Visual Studio para Visual Studio Ultimate.

Además de todas las excelentes tecnologías mencionadas, he descubierto que el papel A3 antiguo es una excelente ayuda en estos temas. Escriba sus ideas y organícelas al estilo de un mapa mental.

Tanto mi editor como mi depurador pueden saltar a la definición de una función y tener un botón "atrás" multinivel como un navegador web para volver a donde estaba antes. Eso suele ser suficiente para que yo pueda realizar un seguimiento de un flujo de depuración complejo. También ayuda tener un control de fuente que le permite comprometerse mucho . Eso me da un mensaje de confirmación que explica por qué estoy intentando algo, así como una forma rápida de retroceder el cambio si no funciona. Aparte de eso, una pizarra blanca simple para enumerar los prospectos potenciales y explorados llena los vacíos restantes para mí.

Múltiples formas en que hago un seguimiento:

• Anotarla . ¿Tienes una reunión en dos minutos? Escriba lo que estaba haciendo y dónde. Siempre tengo papel y lápiz a mi lado para escribir cosas mientras codifico.
• Marcadores . Tengo 10 marcadores numerados que puedo establecer.
• Stacktrace . Puede ver fácilmente toda la jerarquía de código por la que pasó. Mi editor también me permite copiar el seguimiento de la pila y guardarlo. La próxima vez que abra mi editor, puedo cargar el stacktrace para una navegación rápida.
• Editor de navegación . Ir al miembro base, ir al heredero, buscar usos, ir a la referencia, ...

Utilizo la solución simple: nunca cierre nada hasta que termine la tarea. Eso significa que, por lo general, una de las aproximadamente 50 ventanas / pestañas abiertas tiene algo que me recordará lo que estaba pensando cuando vuelva a ello.

Obtenga una herramienta de desarrollo real / IDE, lo que sea que le guste. Vi, Emacs, Eclipse o lo que sea (la elección es tan grande como los argumentos sobre cuál es el mejor, pero ese es otro problema), y aprende a usarlo correctamente . no, como muchos lo hacen, úselo como el Bloc de notas con resaltado de sintaxis. Aprenda a usar teclas de acceso rápido y no confíe en el mouse para realizar acciones comunes (es demasiado lento). Una pantalla grande (1920x1200 mínimo) es benéfica.

Mi herramienta de desarrollo ha nombrado (los nombres más lentos pero útiles los hacen persistentes) y sin nombre (Rápido para insertar y eliminar) marcadores, navegación hacia adelante y hacia atrás y búsqueda de referencia, todo en uno, todo y desarrollador (personal y de grupo) notas adjuntas a un línea particular de código fuente. Hace todos los idiomas bajo el sol, sin tener que instalar otro complemento.

Trabajo en una base de código que consta de una docena o más de 1 millón de módulos SLOC más, utilizando media docena de idiomas. Obviamente, no trabajo en todos ellos a la vez, sino que me concentro en pequeñas partes de uno o dos, pero puedo navegar con algunas acciones a cualquier punto del código que sea relevante para lo que estoy haciendo.

Con Visual Studio, en una sesión de depuración, puede usar la ventana 'Pila de llamadas' (puede habilitarla en Debug / Windows / Call Stacko con el acceso directo Ctrl+Alt+c) para rastrear el flujo de código.

Me sorprende que nadie haya mencionado las muchas herramientas que pueden crear diagramas de gráficos de llamadas. He encontrado que el doxygen es de gran ayuda. Ni siquiera tiene que comprometerse a utilizar doxygen en todo su programa, solo puede etiquetar las funciones que le interesan rastrear.

Yo uso el modo org para emacs, que es una herramienta súper-esquemática. Con él, puedo escribir un esquema que imite la pila de llamadas del código e incluir enlaces directos al código fuente en sí (a través de org-store-link). Puede incluir texto explicativo, enlaces a páginas web, etc. (por ejemplo, cuando busca números mágicos en Google)

No es perfecto Por ejemplo, la estructura de esquema no tiene ninguna noción de volver a subir un nivel, por lo que es difícil rastrear una ruta de ejecución, en lugar de solo una pila. Pero es lo mejor que he encontrado en los diagramas en papel.