Anteriormente estaba buscando un buen control de la línea de tiempo para un proyecto WPF. Encontré una respuesta en 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 esas miles de líneas de código?
EDITAR:
¡Cualquier acceso directo será genial!
Usted agrega comentarios al código fuente cuando lo ha entendido lo suficiente como para poder hacerlo. Refactorice estos comentarios vigorosamente a medida que comprende cada vez más.
... 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 realiza esa acción. ¡Escriba lo mismo en un lenguaje sencillo para obtener una mejor comprensión!
Algo que Joel Spolsky escribió cuando estaba en su blog (no puedo encontrar el artículo ahora) realmente se quedó conmigo al respecto:
Dijo que el código no es un lenguaje humano natural, pero como programadores, fácilmente nos convencemos de que 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 otros han dicho, coméntalo (e incluso refactoriza) a medida que avanzas. No caiga 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.
Hace poco tuve que hacer esto 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 los objetos. Generé la fuente Graphviz , que es un lenguaje muy fácil para generar. (No hay nada especial acerca de Python aquí: Ruby o C # o Common Lisp o lo que sea que pueda hacerlo igual de bien).
En otros proyectos, he visto personas que usan Graphviz para dependencias de módulos, gráficos de llamadas, historial de versiones, todo tipo de cosas. La mejor meta-herramienta de visualización de programas de todos los tiempos.
(Tal vez sea porque yo hice 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. :-)
Recorrerlo en el depurador mientras se ejecuta, es casi la única forma de entender una nueva base de código grande.
Comprende que realmente no hay atajos para quejarse en plenitud. (Y si tiene problemas con esa frase, su educación ha sido muy descuidada. Es de "Extraño en una tierra extraña", por Robert A. Heinlein).
Léalo, una página a la vez, una rutina a la vez. Añadir comentarios. Haz dibujos de las principales estructuras de datos. Reconocer algoritmos. Aprovechar el conocimiento previo.
Resiste la tentación de activar el depurador. La ventana gráfica del depurador es demasiado pequeña: ve una línea a la vez, pero realmente no ve dónde ha estado ni a dónde va.
Hagas lo que hagas, escribe todo lo que puedas mientras avanzas para que nadie termine en la misma posición que tienes.
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 al que necesita hacer cambios.
leer 14 mil líneas de código java no tiene ningún sentido. La funcionalidad de búsqueda es tu salvador
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á pasando, hago lo mismo con otra parte del código que interactúa con la primera. Después de suficientes iteraciones, tengo un buen sentido de cómo funciona el código.
La mejor manera, como con toda la programación, no solo con grandes porciones de código sin comentarios, es dividirla en partes. 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 múltiples saltos de línea. Esto ayuda mientras te desplazas para ver las piezas. Trate de encontrar los fragmentos lógicos del código.
Por supuesto, a medida que entienda los bits, coméntelos por lo que sabe en ese momento, posiblemente agregando notas sobre algo que no entiende.
También recomendaría no tratar de entender toda la pieza desde el principio. En su lugar, intente comprender las piezas que necesita saber en este momento y trabaje en el resto más adelante.
Comenzaría utilizando el Editor Leo en @ shadow mode con el uso activo de nodos clonados . Esto permite agregar notas y comentarios para cada sección del código en estudio sin cambiar el código , y las anotaciones siempre estarán en contexto, junto al código al que se refiere. Aquí hay un ejemplo de flujo de trabajo de los documentos:
Por ejemplo, cuando soluciono un error en Leo, Creo un nodo ordinario para representar el bicho. Este nodo de error es mi vista de Todos los datos en el código fuente de Leo que se relaciona con el error. Como descubro codigo relacionado con el error, clono sus Nodos y moverlos debajo del error. nodo. También agregaré nodos ordinarios como hijos del nodo bug. Estos nodos contiene el informe de error original, descripciones de cómo solucioné el error, datos de prueba, o cualquier otra nota que pueda quiero mantener.
Una vez que haya creado el nodo de error, concentrarse solo en ese nodo y su niños. Puedo examinar el nodo de error y sus hijos sin necesidad de Salta alrededor del contorno. Todo lo que yo La necesidad está en un solo lugar. Cuando llegue alrededor de arreglar realmente el error I Puede hacerlo cambiando los clones. De nuevo, no tengo que saltar. el contorno. No importa lo grande que sea o complejo todo el esquema es: soy sólo se ocupa del nodo de error y su niños. 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 cualquier cosa escribe pruebas. Muchas pruebas. Pruebas muy específicas para pequeños bloques de código que son, al menos, invocables, ya que dependerá de cómo se escribe el desorden heredado.
Para empezar, la ventaja de escribir pruebas es que necesita tener algún tipo de comprensión del código antes de poder probarlo, por lo que cada prueba que escriba será un poco de conocimiento adquirido. También puede comentar en gran medida las pruebas con sus suposiciones junto con las aseveraciones.
Al hacerlo, primero prueba, no corres el riesgo de alterar algo en el código que tiene efectos en cadena que no puedes 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, y luego comprendo qué hace cada una de las clases.
Luego tomo un error fácil de la cola de errores (antes de que mi administrador 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 dónde puedo evaluar el código (interfaz base) para que los datos se lean correctamente utilizando mis diagramas de flujo de clase y código, qué clases son responsables de qué tipo de exportaciones, etc. Creo que la mitad del entendimiento se realiza, una vez que tenga los diagramas de clase y los diagramas de flujo.
Enfoque un defecto trivial, por ejemplo, una NullPointerException. Al principio, evite todo lo relacionado con la concurrencia, todo lo que por su naturaleza implicará comprender una gran cantidad de código a la vez.
Una vez que hayas corregido algunos errores, probablemente tendrás una 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 lenguaje OOP, creamos un UML, compartimos con compañeros y nos convencemos 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 ambiguos.
Cuando se trata de codificación, debemos asegurarnos de que el diseño se convierta en código, es decir, una Entidad en una clase o estructura, una operación para funcionar, etc.
Y revisé un documento técnico enlace que habla sobre el estilo de codificación o cómo podemos usar el espacio. , sangría, variación de fuente, como la mayoría de los IDE, podemos usar para escribir código MUCHO LIMPIO donde los humanos podamos entender tanto como las máquinas. Se enfatiza más en escribir código libre de comentarios para que nuestro código aparezca como párrafos en sí mismos.
Lea otras preguntas en las etiquetas project-management source-code