En un par de meses, un colega se mudará a un nuevo proyecto y yo heredaré uno de sus proyectos. Para prepararme, ya he ordenado a Michael Feathers ' Trabajar de manera efectiva con el código heredado .
Pero estos libros, así como la mayoría de las preguntas sobre el código heredado que encontré hasta ahora, se refieren al caso de heredar el código tal como está. Pero en este caso, realmente tengo acceso al desarrollador original y tenemos algo de tiempo para una entrega ordenada.
Algunos antecedentes sobre el código que heredaré:
- Está funcionando: No hay errores conocidos, pero a medida que aumentan los requisitos de rendimiento, algunas optimizaciones serán necesarias en un futuro no muy lejano.
- Sin documentar: Hay prácticamente cero documentación a nivel de método y clase. Sin embargo, lo que se supone que debe hacer el código en un nivel superior está bien entendido, porque he estado escribiendo en contra de su API (como una caja negra) durante años.
- Solo pruebas de integración de nivel superior: Solo hay pruebas de integración que prueban la interacción adecuada con otros componentes a través de la API (de nuevo, caja negra).
- Nivel muy bajo, optimizado para la velocidad: Debido a que este código es fundamental para todo un sistema de aplicaciones, muchos de ellos se han optimizado varias veces a lo largo de los años y son de muy bajo nivel (una parte tiene su propio administrador de memoria para ciertas estructuras / registros).
- Simultáneamente y sin bloqueo: Aunque estoy muy familiarizado con la programación simultánea y sin bloqueo y en realidad he contribuido con algunas piezas a este código, esto agrega otra capa de complejidad.
- Base de código grande: Este proyecto en particular tiene más de diez mil líneas de código, por lo que no hay forma de que se me explique todo.
- Escrito en Delphi: Voy a poner esto en práctica, aunque no creo que el lenguaje sea pertinente a la pregunta, ya que creo que este tipo de problema es agnóstico.
Me preguntaba cómo sería mejor pasar el tiempo hasta su partida. Aquí hay un par de ideas:
- Obtenga todo para construir en mi máquina: A pesar de que todo debe estar incluido en el control de código fuente, quien no se ha olvidado de registrar un archivo de vez en cuando, por lo que este debe ser el primer orden de negocio.
- Más pruebas: Aunque me gustaría realizar más pruebas unitarias de nivel de clase para que cuando haga los cambios, cualquier error que presente pueda detectarse desde el principio, el código tal como está ahora no es verificable (enorme clases, métodos largos, demasiadas dependencias mutuas).
- Qué documentar: creo que, para empezar, sería mejor enfocar la documentación en aquellas áreas del código que de otra forma sería difícil de entender, por ejemplo. Debido a su naturaleza de bajo nivel / altamente optimizada. Me temo que hay un par de cosas allí que pueden parecer desagradables y que necesitan refactorización / reescritura, pero en realidad son optimizaciones que han estado ahí por una buena razón que podría pasar por alto (véase Joel Spolsky, Cosas que nunca debes hacer, Parte I )
- Cómo documentar: creo que algunos diagramas de clase de la arquitectura y diagramas de secuencia de funciones críticas acompañados de cierta prosa serían los mejores.
- A quién documentar: Me preguntaba qué sería mejor, que escribiera la documentación o que me la explicara, para poder escribirla. Me temo que las cosas que son obvias para él, pero no para mí, no estarían cubiertas adecuadamente.
- Refactorización usando programación de pares: Esto podría no ser posible debido a limitaciones de tiempo, pero tal vez podría refactorizar parte de su código para hacerlo más fácil de mantener mientras todavía estaba allí para proporcionar información sobre por qué las cosas son como son.
Por favor comenta y agrega a esto. Ya que no hay tiempo suficiente para hacer todo esto, estoy particularmente interesado en cómo priorizaría.
Actualización: Al finalizar el proyecto de traspaso, he ampliado esta lista con mis propias experiencias en esta respuesta a continuación .