¿Cuál es la mejor manera de familiarizarse con una base de código grande? [cerrado]

https://stackoverflow.com/questions/215076

03-07-2019
|

Pregunta

Unirse a un equipo existente con una base de código grande ya existente puede ser desalentador. ¿Cuál es el mejor enfoque?

Amplio; intente obtener una descripción general de cómo todo se vincula, desde el código
Estrecho; céntrese en pequeñas secciones de código a la vez, entendiendo cómo funcionan completamente
Elija una característica para desarrollar y aprender a medida que avanza
Intente obtener información de los diagramas de clase y uml, si está disponible (y actualizado)
¿Algo más enteramente?

Estoy trabajando en lo que actualmente es una aplicación C ++ de aproximadamente 20k líneas & amp; biblioteca (Edit: pequeño en el gran esquema de las cosas!). En la industria, imagino que recibiría una introducción de un programador experimentado. Sin embargo, si este no es el caso, ¿qué puede hacer para comenzar a agregar valor lo más rápido posible?

-
Resumen de respuestas:

Paso a través del código en modo de depuración para ver cómo funciona
Empareje con alguien más familiarizado con el código base que usted, tomando turnos para ser la persona que codifica y la persona que mira / discute. Gire a los socios entre los miembros del equipo para que el conocimiento se difunda.
Escribir pruebas unitarias. Comience con una afirmación de cómo cree que funcionará el código. Si resulta como esperaba, probablemente haya entendido el código. Si no, tienes un rompecabezas que resolver y / o una consulta que hacer. (Gracias Donal, esta es una gran respuesta)
Ir a través de las pruebas unitarias existentes para el código funcional, de una manera similar a la anterior
Lea UML, diagramas de clase generados por Doxygen y otra documentación para obtener una idea general del código.
Realice pequeñas ediciones o correcciones de errores, luego aumente gradualmente
Mantenga las notas, y no salte y comience a desarrollar; Es más valioso dedicar tiempo a comprender que a generar código desordenado o inapropiado.

esta publicación es un duplicado parcial de la mejor manera de familiarizarte con una base de código heredada

Solución

Si es posible, comience con una pequeña tarea, depure el código que rodea su problema. Pasar por el código en el modo de depuración es la forma más fácil de aprender cómo funciona algo.

Otros consejos

Otra opción es escribir pruebas para las características que le interesan. Configurar el arnés de prueba es una buena manera de establecer qué dependencias tiene el sistema y dónde reside su estado. Cada prueba comienza con una afirmación acerca de cómo cree que debería funcionar el sistema. Si resulta que funciona de esa manera, ha logrado algo y tiene un código de muestra de trabajo para reproducirlo. Si no funciona de esa manera, tienes que resolver un problema y seguir una línea de consulta.

Una cosa que generalmente sugiero a las personas que aún no se ha mencionado es que es importante convertirse en un usuario competente de la base de código existente antes de poder ser un desarrollador. Cuando nuevos desarrolladores entran en nuestro gran proyecto de software, sugiero que pasen tiempo convirtiéndose en usuarios expertos antes de comenzar a trabajar en el código.

Tal vez eso sea obvio, pero he visto a muchas personas intentar saltar al código demasiado rápido porque están ansiosos por comenzar a progresar.

Esto depende bastante de qué tipo de aprendiz y qué tipo de programador eres, pero:

Amplio primero: necesitas una idea de alcance y tamaño. Esto podría incluir la eliminación de documentos / uml si son buenos. Si se trata de un proyecto a largo plazo y va a necesitar una comprensión completa de todo, podría leer los documentos correctamente. Nuevamente, si son buenos.
Estrecho: elige algo manejable y trata de entenderlo. Obtener un " sabor " para el código.
Escoge una función, posiblemente una diferente a la que acabas de ver si te sientes confiado, y comienza a hacer pequeños cambios.
Iterar: evalúe qué tan bien han ido las cosas y vea si podría beneficiarse de repetir un paso temprano con más profundidad.

Emparejamiento con rotación estricta.

Si es posible, al pasar por la documentación / base de código, intente emplear el emparejamiento con una rotación estricta. Lo que significa que dos de ustedes se sientan juntos por un período de tiempo fijo (por ejemplo, una sesión de 2 horas), luego cambian de pareja, una persona continuará trabajando en esa tarea mientras la otra se mueve a otra tarea con otro compañero.

En parejas, ambos obtendrán un conocimiento, que luego se puede enviar a otros miembros del equipo cuando se produce la rotación. Lo bueno de esto también es que cuando se reúne un nuevo par, el que trabajó en la tarea (en este caso, investigando el código) puede resumir y explicar los conceptos de una manera más fácil de entender. A medida que el tiempo avanza, todos deben estar en un nivel de comprensión similar y, con suerte, evitar el " Oh, solo John sabe un poco del código " síndrome.

Por lo que puedo decir sobre su situación, tiene un buen número para esto (3 pares), sin embargo, si está distribuido o no está trabajando en la misma escala de tiempo, es poco probable que sea posible.

Yo sugeriría ejecutar Doxygen en él para obtener un diagrama de clase actualizado, y luego ampliarlo por un tiempo. Esto le brinda una imagen rápida que puede usar a medida que se acerca al código.

Estoy de acuerdo en que depende completamente de qué tipo de aprendiz eres. Dicho esto, he estado en dos compañías que tenían bases de códigos muy grandes para empezar. Normalmente, trabajo así:

Si es posible, antes de ver cualquiera de los códigos funcionales, realizo pruebas unitarias que ya están escritas. Estos generalmente pueden ayudar bastante. Si no están disponibles, hago lo siguiente.

Primero, ignoro en gran medida la implementación y veo solo los archivos de encabezado, o solo las interfaces de clase. Intento hacerme una idea de cuál es el propósito de cada clase. Segundo, profundizo un poco en la implementación, comenzando con lo que parece ser el área de mayor importancia. Esto es difícil de calibrar, por lo que de vez en cuando empiezo en la parte superior y avanzo hacia abajo en la lista de archivos. A esto lo llamo aprendizaje de amplitud. Después de este paso inicial, por lo general analizo en profundidad el resto del código. La primera imagen de amplitud inicial ayuda a consolidar / arreglar cualquier idea que obtuve del nivel de la interfaz, y luego la mirada profunda me muestra los patrones que se han utilizado para implementar el sistema, así como las diferentes ideas de diseño. Por profundidad, quiero decir que básicamente recorres el programa usando el depurador, entras en cada función para ver cómo funciona, y así sucesivamente. Obviamente, esto no es posible con sistemas realmente grandes, pero 20k LOC no son tantos. :)

Trabaje con otro programador que esté más familiarizado con el sistema para desarrollar una nueva función o para corregir un error. Este es el método que he visto funcionar mejor.

Creo que necesitas unir esto a una tarea en particular. Cuando tenga tiempo en sus manos, opte por el enfoque que desee.

Cuando tengas que hacer algo, concéntrate y hazlo.

Haz que el equipo te ponga en la corrección de errores durante dos semanas (si tienes dos semanas). Estarán encantados de conseguir que alguien se responsabilice de eso, y para el final del período habrá pasado tanto tiempo resolviendo problemas con la biblioteca que probablemente lo sepa bastante bien.

Si tiene pruebas unitarias (apuesto a que no las tiene). Comience poco a poco y asegúrese de que las pruebas de la unidad no fallan. Si te fijas en todo el código base al mismo tiempo, tus ojos se pondrán vidriosos y te sentirás abrumado.

Si no hay pruebas de unidad, debe centrarse en la función que desea. Ejecute la aplicación y observe los resultados de las cosas que su función debería afectar. Luego comience a buscar en el código tratando de averiguar cómo la aplicación crea las cosas que desea cambiar. Finalmente, cámbielo y verifique que los resultados salen como usted desea.

Usted mencionó que es una aplicación y una biblioteca. Primero cambia la aplicación y sigue usando la biblioteca como usuario. Luego, después de aprender la biblioteca, será más fácil cambiarla.

Desde un enfoque de arriba hacia abajo, la aplicación probablemente tenga un bucle principal o una interfaz gráfica de usuario principal que controla toda la acción. Vale la pena entender el flujo de control principal de la aplicación. Vale la pena leer el código para tener una visión general del flujo principal de la aplicación. Si es una aplicación GUI, cree un documento que muestre qué pantallas hay y cómo pasar de una pantalla a otra. Si se trata de una aplicación de línea de comandos, cómo se realiza el procesamiento.

Incluso en las empresas no es raro tener este enfoque. A menudo nadie entiende completamente cómo funciona una aplicación. Y la gente no tiene tiempo para mostrarte. Prefieren preguntas específicas sobre cosas específicas, así que tienes que profundizar y experimentar por tu cuenta. Luego, una vez que obtenga su pregunta específica, puede intentar aislar la fuente de conocimiento de esa parte de la aplicación y formularla.

Comience por comprender el 'dominio de problemas' (¿es un sistema de nómina? inventario? control en tiempo real o lo que sea). Si no entiende la jerga que usan los usuarios, nunca entenderá el código.

Luego mira el modelo de objeto; es posible que ya haya un diagrama o que tenga que aplicar ingeniería inversa a uno (ya sea manualmente o usando una herramienta como lo sugiere Doug). En esta etapa, también podría investigar la base de datos (si corresponde), si debería seguir el modelo de objetos, pero puede que no, y es importante saberlo.

Eche un vistazo al historial de cambios o la base de datos de errores, si hay un área que aparece mucho, analice ese bit primero. Esto no significa que esté mal escrito, sino que es el bit que todos usan.

Por último, conserve algunas notas (prefiero un wiki).

Los tipos existentes pueden usarlo para comprobar la salud de tus suposiciones y ayudarte.
Tendrá que volver a consultarla más tarde.
El próximo chico nuevo en el equipo realmente te lo agradecerá.

Tuve una situación similar. Yo diría que vas así:

Si se trata de una aplicación de base de datos, comience desde la base de datos e intente entender cada tabla, sus campos y luego su relación con las otras tablas.
Una vez que esté bien con la tienda subyacente, ascienda a la capa ORM. Esos cuadros deben tener algún tipo de representación en código.
Una vez hecho esto, continúe con cómo y de dónde provienen estos objetos. ¿Interfaz? ¿Qué interfaz? ¿Alguna validación? ¿Qué preprocesamiento tiene lugar en ellos antes de que vayan al almacén de datos?

Esto te familiarizaría mejor con el sistema. Recuerde que tratar de escribir o entender las pruebas unitarias solo es posible cuando sabe muy bien qué se está probando y por qué solo se debe probar en solo de esa manera.

Y en el caso de una aplicación grande que no esté orientada hacia bases de datos, recomendaría otro enfoque:

¿Cuál es el objetivo principal del sistema?
¿Cuáles son los componentes principales del sistema para resolver este problema?
¿Qué interacciones tiene cada uno de los componentes entre ellos? Haz una gráfica que represente las dependencias de los componentes. Pregunta a alguien que ya esté trabajando en ello. Estos componentes deben estar intercambiando algo entre sí, así que intente descifrarlos también (como IO podría devolver el objeto File a la GUI y me gusta)
Una vez que esté cómodo con esto, sumérjase en el componente que es menos dependiente entre otros. Ahora estudie cómo ese componente se divide en clases y cómo interactúan entre sí. De esta manera, tienes un solo componente en total
Mover al siguiente componente menos dependiente
Al final, vaya al componente central que normalmente tendría dependencias en muchos de los otros componentes que ya ha abordado
Mientras observa el componente central, es posible que se refiera a los componentes que examinó anteriormente, ¡así que no se preocupe, siga trabajando duro!

Para la primera estrategia: Tomemos el ejemplo de este sitio de stackoverflow, por ejemplo. Examine el almacén de datos, qué se almacena, cómo se almacena, qué representaciones tienen esos elementos en el código, cómo se presentan en la interfaz de usuario. ¿De dónde vienen y qué procesamiento tienen lugar una vez que regresan al almacén de datos?

Para el segundo Tomemos el ejemplo de un procesador de textos, por ejemplo. ¿Qué componentes hay? IO, UI, Page y como. ¿Cómo estos están interactuando entre sí? Avanza a medida que aprendes más.

Relájate. El código escrito es la mentalidad de una persona, congeló la lógica y el estilo de pensamiento y llevaría tiempo leer esa mente.

Primero, si tiene miembros del equipo disponibles que tengan experiencia con el código, debe hacer arreglos para que hagan una descripción general del código con usted. Cada miembro del equipo debe proporcionarle información sobre su área de especialización. Por lo general, es valioso que varias personas expliquen las cosas, porque algunas explicarán mejor que otras y otras comprenderán mejor que otras.

Luego, debes comenzar a leer el código por un tiempo sin ninguna presión (un par de días o una semana, si tu jefe te lo proporciona). A menudo, es útil compilar / construir el proyecto por sí mismo y poder ejecutar el proyecto en modo de depuración para que pueda recorrer el código. Luego, empiece a mojarse los pies, corrija los bichos pequeños y haga pequeñas mejoras. Esperamos que pronto esté listo para un proyecto de tamaño mediano, y más tarde, un gran proyecto. Continúa apoyándote en tus compañeros de equipo a medida que avanzas, a menudo puedes encontrar uno en particular que esté dispuesto a guiarte.

No seas demasiado duro contigo mismo si luchas, eso es normal. Puede llevar mucho tiempo, quizás años, entender una base de código grande. En realidad, a menudo ocurre que incluso después de años todavía hay algunas partes del código que aún son un poco aterradoras y opacas. Cuando tienes tiempo de inactividad entre proyectos, puedes profundizar en esas áreas y, a menudo, encontrarás que, después de algunos intentos, puedes resolver incluso esas partes.

¡Buena suerte!

Es posible que desee considerar consultar las herramientas de ingeniería inversa de código fuente . Hay dos herramientas que conozco:

SWAG Kit (solo Linux) enlace
Bauhaus académico commercial

Ambas herramientas ofrecen conjuntos de características similares que incluyen análisis estático que produce gráficos de las relaciones entre los módulos en el software.

Esto consiste principalmente en gráficos de llamadas y decencias de tipo / clase. Ver esta información debería darle una buena idea de cómo las partes del código se relacionan entre sí. Con esta información, puede profundizar en la fuente real de las partes en las que está más interesado y que necesita comprender / modificar primero.

Encuentro que simplemente saltar al código puede ser un poco abrumador. Trate de leer tanta documentación sobre el diseño como sea posible. Esperamos que esto explique el propósito y la estructura de cada componente. Es mejor si un desarrollador existente puede llevarlo a cabo, pero eso no siempre es posible.

Una vez que se sienta cómodo con la estructura de alto nivel del código, intente solucionar uno o dos errores. Esto te ayudará a familiarizarte con el código real.

Me gustan todas las respuestas que dicen que debes usar una herramienta como Doxygen para obtener un diagrama de clase y, primero, tratar de entender el panorama general. Estoy totalmente de acuerdo con esto.

Dicho esto, esto depende en gran medida de qué tan bien factorizado esté el código para comenzar. Si es un lío gigantesco, será difícil de aprender. Si está limpio y organizado correctamente, no debería ser tan malo.

Consulte esta respuesta sobre cómo usar las herramientas de cobertura de prueba para ubicar el código para una característica de interés, sin saber dónde está esa característica o cómo se distribuye en muchos módulos.

(marketing descarado por delante)

Debería consultar nWire . Es un complemento de Eclipse para navegar y visualizar grandes bases de código. Muchos de nuestros clientes lo utilizan para introducir nuevos desarrolladores al imprimir visualizaciones de los flujos principales.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow