legacy - para - seo imagenes wordpress

¿Cuál es la mejor manera de familiarizarse con una gran base de código? (19)

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

Ancho; intenta obtener una visión general de cómo todo se une, desde el código
Estrecho; centrarse en pequeñas secciones de código a la vez, entendiendo cómo funcionan completamente
Elija una característica para desarrollar y aprender sobre la marcha
Intenta obtener información de los diagramas de clases y uml, si está disponible (y al día)
¿Algo más completamente?

Estoy trabajando en lo que actualmente es una aplicación de C ++ de aproximadamente 20k líneas y biblioteca (Editar: ¡pequeño en el gran esquema de cosas!). En la industria, imagino que obtendrías 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 por el código en modo de depuración para ver cómo funciona
Haga una pareja con alguien más familiarizado con el código base que usted, turnándose para ser la persona que codifica y la persona que mira / discute. Rotar socios entre los miembros del equipo para que el conocimiento se extienda.
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 acertijo para resolver o una consulta para hacer. (Gracias Donal, esta es una gran respuesta)
Revise las pruebas de unidad existentes para el código funcional, de manera similar a la anterior
Lea UML, diagramas de clase generados por Doxygen y otra documentación para obtener una amplia sensación del código.
Haga pequeñas ediciones o correcciones de errores, y luego gradualmente acumule
Mantenga notas y no salte y comience a desarrollar; es más valioso pasar el tiempo comprendiendo que generar código desordenado o inapropiado.

esta publicación es un duplicado parcial de the-best-way-to-familiarize-yourself-with-an-inherited-codebase

(marketing descarado por delante)

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

Comience con una pequeña tarea si es posible, depure el código alrededor de su problema. Recorrer el código en modo de depuración es la forma más fácil de aprender cómo funciona algo.

Comience por comprender el "dominio del problema" (¿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 objetos; Es posible que ya exista un diagrama o que tenga que realizar una ingeniería inversa (ya sea manualmente o utilizando una herramienta como lo sugirió Doug). En esta etapa, también podría investigar la base de datos (si corresponde), si debe seguir el modelo de objetos, pero puede que no, y eso es importante de saber.

Eche un vistazo al historial de cambios o a la base de datos de errores, si hay un área que aparece mucho, investigue ese bit primero. Esto no quiere decir que esté mal escrito, pero que es lo que todos usan.

Por último, mantenga algunas notas (prefiero una wiki).

Los tipos existentes pueden usarlo para verificar tus suposiciones y ayudarte.
Tendrá que volver a consultarlo más tarde.
El próximo nuevo miembro del equipo realmente te lo agradecerá.

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

Creo que debes relacionar esto con una tarea en particular. Cuando tenga tiempo en sus manos, elija el enfoque que le apetezca.

Cuando tenga que hacer algo, concéntrese en un objetivo específico y hágalo.

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

Luego, debe comenzar a leer el código por un tiempo sin ninguna presión (un par de días o una semana si su jefe lo proporcionará). A menudo es útil compilar / construir el proyecto usted mismo y poder ejecutar el proyecto en modo de depuración para que pueda recorrer el código. Luego, comience a mojarse los pies, arreglando pequeños insectos y realizando pequeñas mejoras. Esperemos que pronto esté listo para un proyecto de tamaño mediano, y más tarde, un gran proyecto. Continúe apoyándose en sus compañeros de equipo sobre la marcha: a menudo puede encontrar uno en particular que esté dispuesto a guiarlo.

No seas tan duro contigo mismo si luchas, eso es normal. Puede llevar mucho tiempo, tal vez años, comprender una gran base de código. En realidad, a menudo sucede que, incluso después de años, todavía hay algunas partes del código que todavía son un poco aterradoras y opacas. Cuando obtienes un tiempo de inactividad entre proyectos, puedes profundizar en esas áreas y, a menudo, después de algunos intentos, puedes descubrir incluso esas partes.

¡Buena suerte!

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

Una vez que te sientas cómodo con la estructura de alto nivel del código, intenta corregir un error o dos. esto te ayudará a familiarizarte con el código real.

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

SWAG Kit (solo Linux) link
Bauhaus academic commercial

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

Esto consiste principalmente en gráficos de llamadas y decencia 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 que le interesan y que necesita comprender / modificar primero.

Esto depende bastante del tipo de aprendiz y del tipo de programador que sea, pero:

En primer lugar, es necesario tener una idea del alcance y el tamaño. Esto puede incluir skimming docs / uml si son buenos. Si se trata de un proyecto a largo plazo y vas a necesitar una comprensión completa de todo, podría leer los documentos correctamente. Nuevamente, si están bien.
Estrecho: elija algo manejable e intente comprenderlo. Obtener un "sabor" para el código.
Elija una característica, posiblemente una diferente a la que acaba de ver si se siente seguro, y comience a hacer algunos pequeños cambios.
Iteramos: evalúe qué tan bien han ido las cosas y vea si puede beneficiarse al repetir un paso temprano con más profundidad.

Estoy de acuerdo en que depende completamente del tipo de alumno que sea. Habiendo dicho eso, he estado en dos compañías que tenían bases de código muy grandes para empezar. Por lo general, trabajo así:

Si es posible, antes de mirar cualquier código funcional, realizo pruebas unitarias que ya están escritas. Estos generalmente pueden ayudar bastante. Si no están disponibles, entonces hago lo siguiente.

En primer lugar, ignoro en gran medida la implementación y solo miro los archivos de encabezado, o solo las interfaces de clase. Intento tener una idea de cuál es el propósito de cada clase. En segundo lugar, profundizo un nivel en la implementación comenzando por lo que parece ser el área de mayor importancia. Esto es difícil de medir, así que de vez en cuando simplemente empiezo en la parte superior y sigo hacia abajo en la lista de archivos. Yo llamo a este aprendizaje de amplitud inicial. Después de este paso inicial, por lo general voy en profundidad a través del resto del código. La apariencia inicial de amplitud ayuda a solidificar / corregir cualquier idea que obtuve desde el nivel de interfaz, y luego el aspecto de profundidad me muestra los patrones que se han utilizado para implementar el sistema, así como las diferentes ideas de diseño. Primero, en profundidad, quiero decir que básicamente recorre el programa utilizando el depurador, ingresando 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 es mucho. :)

Haga que el equipo lo solucione durante dos semanas (si tiene dos semanas). Estarán encantados de que alguien se haga cargo de eso, y para el final del período habrás pasado tanto tiempo resolviendo problemas con la biblioteca que probablemente lo sepas bastante bien.

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

Dicho esto, esto depende en gran medida de cuán bien factorizado es 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.

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

Si tiene pruebas unitarias (apuesto a que no). Comience poco a poco y asegúrese de que las pruebas de la unidad no fallen. Si miras toda la base de código de inmediato, tus ojos se nublarán y te sentirás abrumado.

Si no hay pruebas de unidad, debe centrarse en la función que desee. Ejecute la aplicación y observe los resultados de las cosas que su característica debería afectar. Luego, comience a revisar el código tratando de descubrir cómo la aplicación crea las cosas que desea cambiar. Finalmente cámbialo y verifica que los resultados salgan de la forma que quieras.

Usted mencionó que es una aplicación y una biblioteca. Primero cambie la aplicación y quédese usando la biblioteca como usuario. Luego, después de que aprendas 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 GUI principal que controle 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 obtener una descripción general del flujo principal de la aplicación. Si se trata de una aplicación GUI, cree un documento que muestre qué pantallas hay y cómo pasar de una pantalla a otra. Si es una aplicación de línea de comandos, cómo se realiza el procesamiento.

Incluso en las empresas no es inusual 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, por lo que debes cavar y experimentar por tu cuenta. Luego, una vez que obtenga su pregunta específica, puede tratar de aislar la fuente de conocimiento para esa parte de la aplicación y preguntarla.

Sugeriría ejecutar Doxygen en él para obtener un diagrama de clase actualizado, y luego abrirlo por un tiempo. Esto le brinda una visión general rápida que puede utilizar a medida que se acerca y se ensucia con el código.

Trabaje con otro programador que esté más familiarizado con el sistema para desarrollar una nueva característica o arreglar un error. Este es el método que he visto funcionar mejor.

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

Si se trata de una aplicación basada en una base de datos, comience desde la base de datos y trate de dar sentido a cada tabla, sus campos y luego su relación con las otras tablas.
Una vez que esté bien con la tienda subyacente, suba a la capa ORM. Esas tablas deben tener algún tipo de representación en el código.
Una vez hecho esto, pase a cómo y de dónde provienen estos objetos. ¿Interfaz? que interfaz? Cualquier validación? ¿Qué preprocesamiento se lleva a cabo antes de ir al almacén de datos?

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

Y en el caso de una gran aplicación que no está dirigida a bases de datos, recomendaría otro enfoque:

¿Cuál es el objetivo principal del sistema?
¿Cuáles son los principales componentes del sistema para resolver este problema?
¿Qué interacciones tiene cada componente entre ellos? Haz un gráfico que represente las dependencias de los componentes. Pídale a alguien que ya esté trabajando en eso. Estos componentes deben estar intercambiando algo entre ellos, así que intente descubrirlos también (como IO podría estar devolviendo el objeto File a GUI y como)
Una vez que se sienta 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 forma tienes un solo componente en total
Pase al siguiente componente menos dependiente
Para el final, diríjase al componente principal 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: tome el ejemplo de este sitio , por ejemplo. Examine el almacén de datos, qué se está almacenando, cómo se almacena, qué representaciones tienen esos artículos en el código, cómo y dónde se presentan en la interfaz de usuario. De dónde proceden y qué procesamiento se realiza una vez que vuelven al almacén de datos.

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

Estar relajado. El código escrito es la forma de pensar de alguien, congela la lógica y el estilo de pensamiento y llevaría tiempo leer esa mente.

Una cosa que normalmente sugiero a las personas que aún no se han mencionado es que es importante convertirse en un usuario competente de la base de códigos existente antes de poder ser un desarrollador. Cuando los nuevos desarrolladores entran en nuestro gran proyecto de software, les sugiero que dediquen tiempo a convertirse en usuarios expertos antes de sumergirse en intentar trabajar en el código.

Tal vez eso sea obvio, pero he visto a mucha gente tratar de saltar al código demasiado rápido porque están ansiosos por comenzar a avanzar.

Emparejamiento con rotación estricta.

Si es posible, mientras revisa la documentación / base de código, intente emparejar con una rotación estricta. Es decir, dos de ustedes se sientan juntos durante 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 que la otra se mueve a otra tarea con otra pareja.

En parejas, ambos obtendrán un conocimiento, que luego se puede alimentar a otros miembros del equipo cuando ocurre la rotación. Lo bueno de esto también es que cuando se combina un nuevo par, el que trabajó en la tarea (en este caso, investigar el código) puede resumir y explicar los conceptos de una manera más fácil de entender. A medida que pase el tiempo, todos deberían tener un nivel similar de comprensión y, con un poco de suerte, evitar el síndrome "Ah, solo John conoce ese fragmento del código".

Por lo que puedo decir sobre su escenario, tiene un buen número para esto (3 pares), sin embargo, si se distribuye o no trabaja en la misma escala de tiempo, es poco probable que sea posible.