Estoy tomando el código de alguien más. ¿Cuáles son algunas buenas maneras de aprender lo que el programador hizo lo más rápido posible? Lo he estado ejecutando, pasando por él y mirando la pila de llamadas. ¿Que más puedo hacer?Tomar el código de otra persona
Lo siento, me olvidé de mencionar, pero hay poca documentación y he estado tratando de solucionar problemas simples. ¡Gracias!
Por lo general, la mejor manera es comenzar a trabajar en el código que soluciona pequeños errores. El tiempo más verdadero que pasas con él es la única forma de aprender la base de código. No hay una forma mágica de aprender una base de código. Tomará semanas, meses o posiblemente años según la complejidad. Sin embargo, para la mayoría de los sistemas comerciales genéricos, un tiempo de aceleración es de aproximadamente 6 meses de conocimiento del código y 6 meses de conocimiento separado de la industria para comprenderlo realmente.
Establezca el registro para observar en qué secuencia están sucediendo las cosas.
leer aquí: Hired as a developer to maintain and update current code base, no docs!
dead link______ – sergiol
solucionar un problema simple en él.
Editar: Luego arregle los problemas más grandes, y comience a escribir la documentación y las pruebas unitarias, de las áreas que comprende. Construya en esas áreas, y un día puede comprender todo el sistema.
Aunque estoy de acuerdo, esto podría funcionar como una solución ... odio hacer bandaids. –
¿Documentación? ¿Lectura del código en sí, sin ejecutar en el depurador?
Aparte de eso, estás haciendo lo que yo haría.
Normalmente encuentro que si el código no es la documentación, entonces la documentación probablemente sea incorrecta ... Pero podría llevarlo de vuelta a lo que "debería" hacer el código. –
Eso es cierto, pero la documentación puede estar en un nivel más alto que el código, lo que al menos facilitaría la comprensión de cómo la Clase X se ajusta a la imagen más grande. – jprete
Me parece que no aprenderé el código completamente hasta que empiece a corregir errores/modificarlo. Si el programador original todavía está allí, entonces discutir los cambios antes de implementarlos ayudaría.
El registro es bueno para ver lo que hace el código.
Si tiene un sistema de control de versiones, puede ir y ver qué cambios le hace el programador a qué partes de código, navegue por el historial.
Encuentro útil a veces de alguna manera tratar de entender el estilo de código de los programadores, esto me ayuda a entender cómo podría pensar sobre un problema y resolverlo.
Comience las pruebas de unidad de escritura, ya que eso lo hará usar sus clases/métodos, y hará dos cosas, aprenda y encuentre errores o tenga las herramientas listas en caso de que aparezcan errores.
El problema con este enfoque es que primero tiene que saber (1) cómo funciona, (2) cómo se supone que debe funcionar, y (3) cuáles son los puntos de entrada. Es posible que aún no sepa lo suficiente de eso para escribir pruebas efectivas de unidades. : -/ –
Al escribir las pruebas unitarias, aprenderá. Tendrá que revisar el código y hacerse una idea de cómo se diseñan las clases. Si no hay documentación y tienes que resolverlo, también podrías escribir pruebas unitarias y hacer algo productivo mientras aprendes, y quizás corregir algunos errores en el proceso. –
será difícil escribir pruebas unitarias para una base de código que no fue diseñada para ser probada. Considere escribir pruebas de integración para ese asunto. –
Lo primero que haría es echar un vistazo al cuadro de diálogo más simple y su código, principalmente para analizar el estilo de codificación y ver cómo el desarrollador prefiere organizar el código.
Una vez que conozca el estilo de codificación, y aproximadamente donde todo va a existir en el archivo (o si las cosas se ponen al azar, incluso si es útil saberlo), será más fácil pasar por todo lo demás.
No hay nada fácil en cómo entender el código de otra persona rápidamente. Especialmente si está lleno de hacks y no hay documentación disponible.
Debe intentar comprender la estructura de clases y ejecutar el flujo normal del software con una ayuda de depurador.
No salte demasiadas secciones de código "oh, creo que sé lo que hace esta sección". No, tu no.Se sorprendería de la "innovación" que podemos encontrar en el código.
Si puede, hable con los usuarios del código de la otra persona (ya sea que los usuarios finales u otros desarrolladores tengan que trabajar con su código). Eso le dará una idea de la calidad del código de otras personas: ¿se publicó con solo unos pocos errores o tomó 6 meses de revisiones para hacerlo bien? ¿El desarrollador se preocupó por hacer una aplicación bien pulida o era un desastre? Eso debería darte una idea de si necesitas ajustar un poco el código o comenzar a reemplazar grandes cantidades de él.
Hay una diferencia sutil entre la interfaz de usuario y la calidad del código detrás de ella. Es muy parecido al revestimiento de vinilo. Una casa puede ser un naufragio absoluto debajo de todos esos hermosos revestimientos blancos, pero el cableado es un desastre, el marco está podrido y las tuberías tienen fugas. Pero maldita sea, es hermoso desde la calle. –
Eso es ciertamente posible. Pero encuentro que, en general, si el exterior se ve bien y se construyó con cuidado y atención al detalle, el marco probablemente se construyó de la misma manera suponiendo que la misma persona hiciera ambas cosas. Por supuesto, debe saber quién es el responsable de qué: no puede culpar a las personas que ponen el revestimiento por un cableado defectuoso. – TLiebe
Me gusta comenzar a agregar pruebas a los métodos del código, si no están ya allí. Averiguar cómo cubrir el código le da mucha información sobre los recorridos de codificación, cuál debe ser el resultado esperado, etc.
Todo lo demás ha dicho que es exacto para aprender lo que el codificador ha hecho.
Otra forma de verlo es aprender el programa en sí. Juega con la aplicación en profundidad como lo haría un usuario y entiende lo que hace el programa. Una vez que entienda completamente el sistema final, será mucho más fácil averiguar cómo y por qué fue escrito.
No estaría de más documentar lo que aprenda sobre clases, funciones, etc. también, para que el siguiente tipo (u otra persona que sea contratada para trabajar en las mismas cosas).
Además, cuando he hecho esto antes, he encontrado que es mejor usar el programa bastante antes de tratar de entender el código. Puede sonar obvio, pero más de lo que veas tendrá sentido después de eso. Las pruebas unitarias, como han sugerido otras personas, también pueden ayudar de la misma manera. (Útil cuando se siente lo suficientemente seguro como para refactorizar también.)
Una cosa que me ayuda a aprender sistemas más rápido es escribir la documentación yo mismo.
Creo saber lo que hace el código del juego, el problema fue escrito para resolver en un nivel alto es un buen comienzo. Con eso uno puede mentalmente, en un nivel alto, también tratar de imaginar cómo tal problema podría ser resuelto con la herramienta de tipo utilizada.
A partir de ese momento, examinar el código tendrá algún significado y ayudará a que sea posible seguir la idea del desarrollador original. Además, detectará rápidamente cuándo se está perdiendo.
También creo que el código debe documentarse, ya que mi experiencia la mayor parte del tiempo es una documentación fuera del código que muchas veces no está sincronizada con el código y podría ser engañosa. Así que algunos comentarios aquí y allá, encabezados de clase, comentario de método también deberían ser de ayuda.
Primera vez heredo el código de otra persona, tuve migraña después de dos días, era una pesadilla.
Así que diviértete.
El primer lugar donde empiezo es la base de datos.
En mi experiencia, entender el modelo de datos es clave para darle contexto al pasar por el código. (esto supone que el modelo de datos no es una tabla de entidad genérica de clave-valor genérica)
Si el modelo de datos es una tabla genérica de valores-clave, entonces usted sabe que tiene un problema allí mismo. – HLGEM
He pasado la mayor parte del último año trabajando en el código que heredé de otra persona. No había documentación y una gran cantidad de lo que el sistema debía hacer no estaba escrito en ninguna parte, sino en la cabeza del cliente. La clave para mí ha sido hacer tantas preguntas como pude y recopilar información de cada fuente disponible. Yo recomendaría compilar su propia documentación sobre la marcha.
Mucha gente podría decir que no reescribe el código, pero que a menudo puede ser la mejor manera si el código está mal comentado o codificado (no auto documentación). Para el código con el que luché, a menudo ha sido la mejor solución.
Otra cosa útil que tener es algún tipo de documento de estándares antes de comenzar. El documento de normas lo ayudará a descifrar el código o a poner el código a la altura de las especificaciones y hacerlo más fácil de entender.
Esto debería ser wiki comunitario. Esta es una pregunta subjetiva. – Joren
Diría que si has tenido que hacer todo esto; los problemas no son tan simples Buena suerte. –
Esta parece ser la norma en la que actualmente trabajo ... Estás en el camino correcto. En momentos como estos, nunca digo * Sí * a nada por adelantado, generalmente digo que lo intentaré. –