¿Cómo leer miles de líneas de código sin ninguna documentación? [cerrado]

Anteriormente estaba buscando un buen control TimeLine para un proyecto WPF. Encontré una respuesta aquí que me dirige a este proyecto CodePlex .

Ahora quiero cambiar el código para satisfacer mis necesidades culturales. ¡Pero hay algunos desajustes!

Mi pregunta es:

¿Cómo interactúas con miles de líneas de código?

EDITAR:

¡Cualquier atajo será genial!

Agrega comentarios al código fuente cuando lo ha entendido lo suficiente como para poder hacerlo. Refactorice estos comentarios vigorosamente a medida que entienda más y más.

1. Paso a través del código
2. Renombrar según sea necesario
3. Refactorizar según sea necesario
4. Repite hasta que entiendas completamente

... y el código te lo agradecerá. ;-)

Realice una sola acción, depure (una y otra vez) el código para encontrar cómo se lleva a cabo esa acción. ¡Escriba lo mismo en un lenguaje simple para obtener una mejor comprensión!

Algo que Joel Spolsky escribió cuando estaba en su blog (no puedo encontrar el artículo ahora) realmente me quedó grabado en relación con esto:

Dijo que el código no es un lenguaje humano natural, pero que como programadores, fácilmente podemos pensar que sí lo es y que deberíamos poder leerlo como tal. En consecuencia, muchos de nosotros miramos el nuevo código y esperamos poder simplemente "leerlo" y entenderlo de inmediato, como si fuera un bloque de texto en inglés.

Así que creo que la clave es básicamente ser lento, metódico y científico. Y como han dicho otros, comente (e incluso refactorice) a medida que avanza. No caigas en la mentalidad de "Debería mirarlo y entenderlo de inmediato".

Ah, y sí, todavía caigo en esta trampa a veces. "Haz lo que digo, no lo que hago", y todo eso. :)

SE-Radio entrevistó a Dave Thomas sobre este mismo tema

Este episodio de podcast tiene muchos consejos y técnicas para ingresar a la 'cultura' del proyecto y comprender cómo vivían los habitantes originales.

Tuve que hacer esto recientemente con un proyecto de más de 100,000 LOC. Mi primera idea fue que es más fácil ver patrones de gráficos de 100 o incluso 1000 nodos que de 100,000 líneas de texto.

Así que pasé 45 minutos y escribí un programa corto de Python (<100LOC) para analizar lo que necesitaba de él y dibujar las relaciones de objeto. Me genera Graphviz fuente, que es un muy fácil de lenguaje para generar. (No hay nada especial sobre Python aquí: Ruby o C # o Common Lisp o lo que sea que pueda hacerlo igual de bien).

En otros proyectos, he visto a personas usar Graphviz para dependencias de módulos, gráficos de llamadas, historial de versiones, todo tipo de cosas. La mejor herramienta de visualización de programas jamás vista.

(Tal vez sea porque tomé compiladores , pero me parece extraño que cuando un programador se enfrenta a un problema, la respuesta parece ser siempre "¡escribir un programa!", Excepto cuando el problema involucra el código fuente de un programa.: - )

Paso a paso en el depurador mientras se ejecuta, es casi la única forma de entender una nueva base de código grande.

Comprenda que realmente no hay atajos para hacer grokking en plenitud. (Y si tiene problemas con esa frase, su educación ha sido MUY descuidada. Es de "Stranger In a Strange Land", de Robert A. Heinlein).

Léalo, una página a la vez, una rutina a la vez. Añadir comentarios. Dibuja imágenes de las principales estructuras de datos. Reconocer algoritmos. Recurrir a conocimientos previos.

Resista la tentación de poner en marcha el depurador. La ventana del depurador es demasiado pequeña: ves una línea a la vez, pero realmente no ves dónde has estado ni a dónde vas.

Hagas lo que hagas, escribe tanto como puedas a medida que avanzas para que nadie termine en la misma posición que tú.

necesitas usar pistas. obtenga una pista de lo que debe buscar y utilice ampliamente la funcionalidad de búsqueda de su entorno o IDE que puede llevarlo a la sección deseada del código en la que necesita realizar cambios.

leer 14 mil líneas de código java no tiene ningún sentido. La funcionalidad de búsqueda es su salvavidas

Diferentes personas tienen diferentes estilos de aprendizaje, así que YMMV. Lo primero que hago en esta situación es leer todo el código base al menos una vez. Eso me da una idea general de dónde está todo. Luego elijo una sección para examinar con más detalle. Las estructuras de datos serían un buen lugar para comenzar. Una vez que tengo una idea general de lo que está sucediendo, hago lo mismo con otra parte del código que interactúa con la primera. Después de suficientes iteraciones, tengo una buena idea de cómo funciona el código.

La mejor manera, como con toda la programación, no solo grandes fragmentos de código no comentado, es dividirlo en pedazos. Esto es algo que debe hacer en su cabeza, así como visualmente en el código. Esto puede significar agregar grandes comentarios en negrita o saltos de línea múltiples. Esto ayuda mientras te desplazas para ver las piezas. Intenta encontrar los fragmentos lógicos de código.

Por supuesto, a medida que entiendes las partes, coméntalas por lo que sabes en ese momento, posiblemente poniendo notas sobre algo que no entiendes.

También recomendaría no tratar de entender toda la pieza desde el principio. En su lugar, trate de comprender las piezas que necesita saber ahora y trabaje en el resto más tarde.

Comenzaría usando Leo Editor en modo @shadow con el uso activo de nodos clonados . Esto permite agregar notas y comentarios para cada sección de código en estudio sin cambiar el código , y las anotaciones siempre estarán en contexto, al lado del código del que está hablando. Aquí hay un ejemplo de flujo de trabajo de los documentos:

Por ejemplo, cuando reparo un error en Leo, creo un nodo ordinario para representar el error. Este nodo de error es mi vista de todos los datos en el código fuente de Leo que se relacionan con el error. Cuando descubro el código relacionado con el error, clono sus nodos y los muevo debajo del nodo de error. También agregaré nodos ordinarios como hijos del nodo de error. Estos nodos contienen el informe de error original, descripciones de cómo solucioné el error, datos de prueba o cualquier otra nota que desee conservar.

Una vez que he creado el nodo de error, me concentro solo en ese nodo y sus hijos. Puedo examinar el nodo de error y sus hijos sin tener que saltar el contorno. Todo lo que necesito está en un solo lugar. Cuando llego a arreglar el error, puedo hacerlo cambiando los clones. Nuevamente, no tengo que saltar el contorno. No importa cuán grande o complejo sea todo el esquema: solo estoy tratando con el nodo de error y sus hijos. Este enfoque extremadamente estrecho hace que sea mucho más fácil corregir errores.

Dibuje diagramas de la fuente: las relaciones de datos, las relaciones funcionales, las relaciones de objeto. Determine la agregación, el flujo de datos y el flujo de código. Las imágenes son mucho mejores que los comentarios para esto, y se pueden mantener separadas del código.

Antes de refactorizar algo, escribe pruebas. Muchas pruebas. Pruebas muy específicas de pequeños bloques de código que son al menos invocables, ya que dependerá de cómo se escriba su desorden heredado.

Para empezar, la ventaja de escribir pruebas es que debe tener algún tipo de comprensión del código antes de poder probarlo, por lo que, con suerte, cada prueba que escriba tendrá un poco de conocimiento. También puede comentar mucho las pruebas con sus suposiciones junto con las afirmaciones.

Al hacer la prueba primero, no corre el riesgo de alterar algo en el código que tiene efectos secundarios que no puede conocer. También tendrás una red de seguridad cuando vengas a refactorizar el código.

Utilizo herramientas como doxygen, para generar un diagrama de clase general, que agrega mi comprensión de lo que hace cada una de las clases.

Luego tomo algunos errores fáciles de la cola de errores (antes de que mi gerente me asigne uno difícil: P), luego ejecuto esa funcionalidad en el depurador e intento generar un flujo de datos aproximado o un modelo de flujo de código.

Por ejemplo, la funcionalidad de exportación en algún software: así que trato de entender cómo se leen los datos de origen, desde qué parte del código (interfaz base) puedo evaluar si los datos se leen correctamente usando mi clase y diagramas de flujo de código, de qué clases son responsables qué tipo de exportaciones, etc. Creo que la mitad de la comprensión se realiza, una vez que tenga los diagramas de clase y los diagramas de flujo.

Acérquese a un defecto trivial, por ejemplo, una excepción NullPointerException. Al principio, evite cualquier cosa relacionada con la concurrencia, cualquier cosa que, por su naturaleza, implique comprender gran parte del código a la vez.

Una vez que haya solucionado algunos errores, probablemente tendrá una muy buena idea. Funciona para mí, en cualquier caso.

Básicamente, la acción para escribir un código limpio debe comenzar desde el diseño. Si estamos codificando en el lenguaje OOP, crea un UML, compártelo con tus compañeros y convencerte de que el diseño no es ambiguo. En cualquier caso, los desarrolladores deberíamos convencernos de que el diseño resuelve el problema y no los ambigüedades.

Cuando se trata de codificación, debemos asegurarnos de que el diseño se convierta en código, es decir, una entidad a una clase o estructura, una operación para funcionar, etc.

Y revisé un documento técnico http://queue.acm.org/detail.cfm?id=2063168 que habla sobre el estilo de codificación o cómo podemos usar el espacio, la sangría, la variación de fuentes como la mayoría de los IDE podemos usar para escribir MUCHO Código CLEANER donde los humanos podemos entender tanto como las máquinas. Hace más hincapié en escribir código sin comentarios para que nuestro código aparezca como párrafos en sí.