Trabajando en el código de otra persona [cerrado]

Tengo apenas un año de experiencia en codificación. Después de comenzar a trabajar, la mayoría de las veces estaría trabajando en el código de otra persona, ya sea agregando nuevas funciones sobre las existentes o modificando las funciones existentes. El tipo que ha escrito el código real ya no funciona en mi empresa. Me está costando entender su código y hacer mis tareas. Cada vez que intenté modificar el código, de alguna manera me metí con las funciones de trabajo. ¿Qué debo tener en cuenta al trabajar sobre el código de otra persona?

¿El código tiene pruebas unitarias? Si no, fuertemente sugiero que comience la adición de ellos. De esta manera, puede escribir nuevas características / correcciones de errores como pruebas fallidas y luego modificar el código que pasa la prueba. Cuantos más construyas, más confianza tendrás de que tu código agregado no ha roto otra cosa.

Escribir pruebas unitarias para el código que no comprende completamente le ayudará a comprender dicho código. Por supuesto, se deben agregar pruebas funcionales si aún no existen. Mi impresión fue que esos ya existían en la pregunta OP. Si me equivoco en ese punto, estas pruebas funcionales deberían ser su primer paso.

Eagle76dk hace un gran punto acerca de conseguir a su gerente a bordo para hacer este trabajo; más detalles en la publicación de Eagle76dk.

Además, a medida que escribe estas pruebas, le animo a que intente escribir las pruebas para que verifiquen el comportamiento comercial que el método haya intentado lograr, no el comportamiento del código. Además, no asuma en absoluto que los comportamientos comerciales que ve en el código son los correctos: si tiene a alguien que podría decirle qué debería hacer la aplicación, en muchos casos es más valioso de lo que el código podría decirle.

Además de otra respuesta que menciona las pruebas unitarias, te sugiero que te asegures de que todo esté en control de versiones para que puedas revertir tus cambios fácilmente. Y haciendo pequeños cambios para hacer que el código sea más fácil de mantener.

En mi opinión, la forma más rápida de aprender el código de otra persona (especialmente cuando los cambios desencadenan un comportamiento inesperado como usted describe) es recorrer el código utilizando un depurador .

Comience con un paso por lo que parece ser el bucle principal / métodos principales del programa. Use las funciones de entrar y salir para ver qué hacen los diferentes métodos. Esto le enseñará la estructura general del código.

Después de eso, divide y vencerás avanzando y aprendiendo las diferentes partes del programa en un nivel más profundo. En la mayoría de los depuradores puede estudiar variables y sus valores actuales . Estudie cómo cambian y cuándo.

Establezca puntos de interrupción en los métodos que desencadenan comportamientos que le preocupan. Por ejemplo, si está intentando cambiar un texto en el programa, y ​​el texto sigue volviendo al valor original, establezca puntos de interrupción en todos los lugares donde se cambia el texto o intente mover todos estos cambios a un solo método. Use la pila de llamadas para ver desde dónde se llama este método, etc.

Si cambiar una línea de código provoca cambios inesperados en otros lugares, coloque un punto de interrupción en esa línea y vea qué sucede allí, por ejemplo, verificando los valores de las variables actuales en el alcance, usando step into o la pila de llamadas para ver desde dónde llegó la llamada.

Al hacer esto mucho, comenzará a aprender la estructura del código sorprendentemente rápido. Comencé como lo hiciste en mis primeros trabajos de programación, con un montón de código que se había escrito hace muchos años y que muchas personas habían cambiado a lo largo de muchos años. El código no era mío solo desde allí donde otras personas trabajaban en él al mismo tiempo. No pude reescribirlo todo en ese punto. Escribir pruebas para todo ese código me hubiera llevado meses o años. El depurador realmente me salvó, no sé cómo habría aprendido el código sin él ...

Lo primero a tener en cuenta es que se dedica más tiempo a leer código que a escribir código. Dedique tiempo a comprender cómo trabajaba el otro tipo: su estilo y enfoque de los problemas.

Trata de adoptar el estilo existente tanto como sea posible; de ​​lo contrario, el chico después de ti tendrá el doble de ajustes que hacer.

Tratar con el código de otra persona es la norma, no la excepción, debe ser experto en descubrir cómo el otro chico habría resuelto un problema o implementado una función. Una vez que haya hecho eso, le resultará más fácil lidiar con su código.

No se apresure a asumir que el código del otro tipo apesta.

Pero siempre sospeche.

Pero sí, lleva tiempo entender el código de otro desarrollador. Cuanto más una función u objeto sea utilizado por múltiples partes del sistema, más cuidadoso deberá ser. Si puede resolver el problema más cerca del síntoma, eso a veces puede ser útil. Por ejemplo, normalice los datos entrantes de otro objeto en el lado del objeto problemático de la cerca después de que se entreguen los datos pero antes de que suceda cualquier otra cosa.

Es una mala señal cuando cambiar una cosa rompe otra inesperadamente. Si tiene otros desarrolladores más experimentados en los que pueda confiar para obtener ayuda, le recomiendo que analicen las cosas que le causan problemas. Por lo menos, puede recoger algunas cosas mirándolas depurar.

En un mundo ideal, todo el código escrito por un desarrollador dado estará bien documentado, bien estructurado y probado de manera comprensible, tanto con herramientas automáticas como pruebas unitarias y guiones de casos de uso que un usuario ejecuta para verificar que obtenga el resultado esperado.

Sin embargo, lo primero que aprenderá es que no vivimos en un mundo ideal.

Muchos desarrolladores no documentan su código correctamente, si es que mezclan la lógica empresarial con código no relacionado, y la única prueba que hacen es una ejecución rápida de lo que esperan que sea el caso de uso normal.

Cuando trabaje con un código como este, lo primero que debe hacer es establecer lo que debe hacer. Si hay comentarios, pueden darte pistas, pero no cuentes con eso. Según mi experiencia, muchos codificadores no son buenos para explicarse e incluso si dejan comentarios, pueden no tener sentido. Sin embargo, a menos que sea el único codificador de la empresa, alguien seguramente debe tener al menos una idea básica de para qué sirve el código y qué debe hacer. ¡Pregunta por ahí!

Si tiene pruebas unitarias, le harán la vida mucho más fácil. Si no lo hace, entonces parte del aprendizaje de la base de código puede implicar escribir pruebas unitarias para el código que ya existe. Normalmente, esto no se considera una buena práctica porque si escribe pruebas unitarias para ajustar el código existente, terminará con pruebas unitarias que piensan que el código funciona como está (se escribirán para asumir que el comportamiento que en realidad es un error es correcto), pero al menos te da una línea de base. Si luego descubre que algún comportamiento que pensó que era correcto, de hecho, es incorrecto, puede cambiar la prueba unitaria para comprobar cuál es el resultado esperado en lugar del resultado que el código da ahora. Una vez que tiene una prueba unitaria, puede hacer cambios y evaluar qué efectos secundarios tiene cualquier cambio que realice.

Finalmente, el mejor recurso que tiene cuando trata con un fragmento de código no documentado es preguntar a los usuarios finales. Es posible que no sepan nada sobre el código, pero saben lo que quieren que haga la aplicación. La recopilación de requisitos es la primera etapa de cualquier proyecto, y hablar con los posibles usuarios del sistema a desarrollar es siempre una parte importante de eso. Solo piense en ello como en la etapa de captura de requisitos para un nuevo proyecto que ya se ha construido.

Tenga en cuenta que incluso un código bien escrito y bien documentado puede ser difícil de entender para un extraño. El código es esencialmente una expresión de cómo pensaba la persona que lo escribió en ese momento, y cada uno tiene su propio proceso de pensamiento único. Tendrás que aprender a ser un poco paciente y ser un detective. Poder entrar en el proceso de pensamiento de otra persona es difícil, pero es una habilidad esencial para un programador que realiza el mantenimiento del código existente. Como la mayoría de la codificación (alrededor del 70%) está relacionada con el mantenimiento del código existente, es una habilidad importante para aprender.

Ah, y ahora que has visto el dolor que puede causar un código mal documentado, no probado y desordenado, no lo harás con el próximo desarrollador pobre que aparezca, ¿verdad? :) Aprenda de los errores de su predecesor, comente bien su código, asegúrese de que cada módulo tenga una responsabilidad claramente definida a la que se adhiera, y asegúrese de tener un conjunto completo de pruebas unitarias que escriba primero (para metodologías TDD) o al menos junto con el código que se está desarrollando.

Tenga en cuenta que la capacidad de leer código que no ha escrito es una habilidad muy valiosa, probablemente más valiosa que escribir código. Desafortunadamente, esto es muy subestimado y poco enseñado en las escuelas.

Lo que estoy tratando de decir es que es normal que no siempre se entienda el código al leerlo la primera vez (al igual que es normal que no se escriba el código perfecto la primera vez). Si acepta que lleva tiempo obtener un código extranjero, no le importará hacer un esfuerzo adicional. Un pequeño resumen:

• Las pruebas unitarias serían ideales, pero no siempre realistas; especialmente si trabajas en una organización grande con mucha burocracia.

• Aprenda a usar su sistema de control de versiones correctamente; nunca romperás lo existente (no realmente nunca , pero es una buena red de seguridad).

• No asumas que es malo simplemente porque no lo entiendes al instante. No asumas que es bueno simplemente porque funciona. Lo importante es que comprenda el estilo de código del mantenedor anterior y adapte sus líneas agregadas a su estilo. El mantenedor que viene después de ti te lo agradecerá.

• En algunas empresas, desafortunadamente, la dificultad de leer el código puede subestimarse. Esto es común en grandes corporaciones con procesos rígidos. A menudo (implícitamente) prefieren que inserte un código que funciona rápidamente en lugar de tomarse su tiempo para escribir algo limpio. Dejaré que usted decida cuál es su equipo en este punto.

• Finalmente, nunca olvides que leer código es una habilidad . Cuanto más lo hagas, mejor lo lograrás. Otra forma de decir esto es que la única forma de ser bueno es practicarlo muchas veces. Como se mencionó anteriormente, leer código es y será una parte mucho mayor de su trabajo que escribir.

A juzgar por sus problemas con la ruptura inadvertida de cosas, voy a suponer que el código no está cubierto por pruebas automáticas. El Paso # 0 sería ordenar y leer Trabajar efectivamente con código heredado de Michael Feathers. Es simplemente invaluable.

Los pasos básicos que sugeriría:

• Cubra el código con pruebas que cubran la funcionalidad actual.
• Refactorizar hasta que sea comprensible.
• Escriba una prueba para la funcionalidad nueva o modificada.
• Implemente la nueva funcionalidad.
• Refactorizar hasta satisfacción.

Deliberadamente omito especificar el sabor de las pruebas (unidad, integración, ...), solo obtengo algún tipo de cobertura de prueba automatizada.

(y sí, siga el estilo de codificación en términos de diseño y denominación)

Como se mencionó anteriormente: bienvenido al mundo real. Solo puedo estar de acuerdo con las respuestas anteriores. Solo desearé extender la respuesta con mi experiencia laboral sobre estimaciones de tiempo.

Una buena sugerencia es dejarle claro a su jefe, tomará tiempo aprender cómo piensan los otros desarrolladores. Por lo general, experimentará que la solución actual a menudo depende de la edad y la experiencia del desarrollador.

Si tiene suerte, la tarea en cuestión debe analizarse y comprender la documentación lo ayudará mucho (pero este no suele ser el caso).

Mi experiencia es que al modificar el código de otros, trate de no cambiar el código que no involucra su tarea actual. Es posible que conozca una solución mejor o podría escribirse de una manera más intuitiva, pero cambiarla a menudo genera problemas como:

• La tarea llevará más tiempo y tu jefe no la entenderá.
• El código que cambie debe probarse y cuesta. La solución actual ha sido probada y aprobada.
• Será difícil ver qué cambios resuelven la tarea actual y cuáles son correcciones "justas".

Pero no dude en decirle a su jefe, si ve algo que cree que debería ser diferente (solo muestra que puede pensar).

Finalmente, asegúrese de tener suficiente tiempo para hacer la solución. Una solución más rápida viene con experiencia. Pero rara vez hay una solución rápida, ya que esta es la razón principal / principal de los errores y el código que no se puede mantener.

Piense en ello como realizar una operación en una persona.

Busca en el interior el problema que necesita solucionar y nota que la mayoría de las arterias, etc., no están configuradas de la manera en que lo haría, por lo que las corta y corta hasta que se vean bien y luego soluciona el problema.

Sorprendentemente, su paciente muere casi de inmediato.

Las aplicaciones heredadas son iguales. Ya tienen una forma de trabajar: debe comprender los diversos componentes del software y cómo se relacionan entre sí y luego hacer su cambio para que funcione de la misma manera. No es tan emocionante como dejar volar tu creatividad, pero puedes hacerlo en proyectos personales.

Le pediría a un ingeniero sénior que se siente con usted durante aproximadamente una hora todos los lunes y le explique un aspecto diferente del sistema. Tome notas de lo que dice y envíelos por correo electrónico a él y a su gerente para ver si su gerente tiene algo que agregar. Debería acelerar rápidamente de esta manera.

En cuanto a cómo no romper las cosas, en primer lugar, asegúrese de comprender lo que hace el sistema. Pruebe antes - haga su cambio - pruebe después. No hay fórmulas mágicas; a medida que ganes experiencia, mejorarás, ¡o te despedirán, supongo!

Una cosa que realmente no he visto aquí: no trabajes en una isla.

A menos que usted sea el único programador en su equipo, es probable que haya alguien que tenga más experiencia que usted, y posiblemente muchas personas en las que pueda apoyarse.

Hacer preguntas. Muchos de ellos.

No se preocupe por "molestar" a otra persona (dentro de lo razonable): prefiero que alguien me interrumpa por una o dos preguntas durante un ciclo normal de desarrollo, que tener que apagar un incendio en un entorno de producción más adelante.

Cuando esté listo para registrar algo, revíselo con su mentor (es). Deben poder decirle no solo si algo romperá algo más, sino más importante, por qué. La revisión del código también hará que el mentor sea un mejor programador, dándole una visión del sistema que de otro modo no verían con tanta frecuencia.

Recuerde: no solo está aprendiendo el sistema como cualquier nuevo empleado necesitaría, sino que también está aprendiendo cómo convertirse en un programador.

Y cinco años después, alienta al próximo New Guy a que te use como mentor.

Cuando se trata de depurar código, recuerde: siempre hay una razón . Cuando ha estado tratando de encontrar y corregir el mismo error estúpido durante unos días y no está haciendo ningún progreso, es tentador comenzar a pensar en uno o más de:

• Simplemente no soy lo suficientemente inteligente como para descubrir cómo funciona este código

• El tipo que escribió este código no tenía idea de lo que estaba haciendo.

• La magia está involucrada: magia muy negra

Esas son todas formas de rendirse. El antídoto es recordar siempre que las computadoras son deterministas: siempre hay una razón para lo que hacen. El código puede oler a marea baja en una fábrica de conservas de pescado y parecerse a un tazón gigante de linguini, pero al ser implacablemente racional y tener una mente abierta, lo resolverá .

Ya sea que escriba pruebas unitarias siempre que sea posible o escriba pequeñas aplicaciones que involucren el código que está modificando, deberá observar, comprender y luego documentar la lógica.

Si el código funciona principalmente, suena como lo hace, entonces conservaría el estilo del formato de código para ese módulo, ya sea su estilo o no. Mantiene las cosas uniformes. Sin embargo, los buenos comentarios nunca pasan de moda.

Aconsejo un sistema de prueba y una plataforma de prueba, donde puede modificar y probar este código, sin interrumpir la producción.

Si puede eliminar elementos del código en una biblioteca, lo haría, a menos que esté trabajando en una biblioteca.

Con el tiempo, una vez que comprenda la lógica, puede volver a escribir y probar.

Este consejo está determinado por el idioma que está utilizando, la capacidad de obtener un banco de pruebas y otras limitaciones que tenga.

Intente utilizar algunas herramientas de análisis de código para encontrar el código no utilizado que se puede eliminar, para que al menos no tenga que preocuparse por este código.

Se ha señalado anteriormente que debe comprender el propósito del sistema, no solo los detalles del código. Un programador con suficiente experiencia para escribir un sistema de entrada de pedidos generalmente se siente cómodo con la parte de 'avanzar', que implica seleccionar productos, formatear una factura y procesar el pago. Cuando se atascan es cuando el usuario decide 'no, no importa' y comienza a cancelar las transacciones, o cuando cometen un error en el procesamiento del pago y presionan el botón 'atrás'. En ese momento, muchos programadores se desconciertan porque ven que el código "aparece de la nada" y no pueden entender por qué está allí.

En resumen, debe comprender no solo el "flujo normal", sino todo el retroceso que es necesario si alguien comete un error o cambia de opinión. Esto empeora aún más con las anulaciones del supervisor, donde algunos códigos solo se pueden ejecutar con ciertos privilegios de cuenta.

Si alguien escribe 10,000 líneas de código al año, y una aplicación tiene una 'vida' de diez años, entonces un programador responsable de recoger el trabajo de otra persona podría tener que entender 100,000 líneas de código. Dividir esto por 50 líneas por página es de 2000 páginas. Si el programa se escribe en un patrón de diseño, el programador encontrará que la comprensión de un "bloque" conduce a al menos una comprensión general de la mayoría del resto. Si no, entonces es necesario leer hasta la última línea.

Algunos programadores "solo hacen lo que se les dice" y escriben espaguetis. Nunca entienden el 'panorama general': simplemente arreglan los problemas cuando los usuarios se quejan. En tales circunstancias, es una buena idea comenzar a migrar todo lo que pueda a un patrón apropiado. Eventualmente esto puede significar recodificar cosas que no están 'rotas'. No se preocupe por eso, solo asegúrese de que mientras sea su proyecto sea progresivamente más sostenible.

Hay algunas respuestas realmente buenas aquí. Pero creo que también vale la pena mencionar cuánto puede ayudar la familiaridad con buenos patrones de diseño , leer el código existente (bien escrito) y escribir código legible.

Por supuesto, puede ser muy confuso cuando encuentra un SomethingFactorycódigo existente, que en realidad no sigue el patrón de fábrica . Pero tanto como lo permita su equipo y marco, puede ser beneficioso mantener tales casos al mínimo.

Los siguientes patrones de diseño (donde las necesidades del negocio lo permiten) también pueden reducir significativamente la duplicación de código, lo que a su vez reduce errores en futuras modificaciones.

Algunas buenas fuentes de patrones de diseño son

http://sourcemaking.com/design_patterns

http://www.oodesign.com/

y por supuesto el libro

http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

El seguimiento del flujo de control entre los métodos es muy importante para desarrollar un mapa mental de la lógica empresarial.

Nuestra solución se basa en el reconocimiento de que una de las pocas informaciones confiables disponibles al acercarse a un sistema heredado es el propio sistema en ejecución. Nuestro enfoque reifica los rastros de ejecución y utiliza programación lógica para expresar pruebas en ellos.

Generar un modelo de datos de flujo de trabajo es la mejor manera de analizar todas las rutas de código:

En la práctica, la revisión de código se vuelve difícil de manejar en los flujos de trabajo científicos heredados. El origen de tales flujos de trabajo significa que las prácticas de ingeniería de software pueden no haberse aplicado durante el desarrollo, lo que lleva a una base de código que se ofusca efectivamente. Si bien el análisis estático tiene técnicas bien desarrolladas para el análisis del flujo de datos, no admiten el comportamiento en los flujos de trabajo del mundo real. Por ejemplo, cuando se debe cargar un archivo de configuración para determinar cómo se deben procesar los datos, o cuando se utiliza la evaluación de código dinámico.

Y visualizar el flujo de trabajo es ideal:

Un motivo común, que se presta al desarrollo visual, es la presentación de un flujo de trabajo como un gráfico. Esto protege al usuario de la complejidad subyacente de los recursos y la ejecución.

Referencias

• Comprender los flujos de trabajo heredados a través del análisis de tiempo de ejecución (pdf)
• Pruebas lógicas basadas en trazas del sistema heredado orientado a objetos (pdf)
• console.trace () - API web | MDN
• Método de rastreo de llamadas a través de Proxies
• Cómo espiar tus métodos de rubí
• Fácil rastreo de llamadas a funciones anidadas en Python - sitio web de Eli Bendersky
• Método de registro de entrada / salida - Mebyon Kernow
• Rastreo: instrumentación para mostrar llamadas de función
• -Xtrace -
• GitHub - johnno1962 / SwiftTrace: invocaciones de métodos Trace Swift y Objective-C
• Debug :: Trace - Extensión de Perl para rastrear llamadas de subrutina - metacpan.org

Asegúrese de estar utilizando un programa que lo ayude a encontrar cosas en el archivo actual. Nada es peor que saber que lo que está buscando está en el archivo actual, pero se desplaza y se desplaza y no puede encontrarlo. Una vista de esquema en la herramienta que usa para editar el código realmente ayuda con ese problema.