2010-08-27 13 views
10

Soy un recién graduado universitario que acaba de comenzar mi trabajo. En mi período de aumento, necesito aprender mucho código de producto. Hay algunos documentos de diseño pero no ayudan mucho.¿Cómo entiendes una gran parte del código?

¿Puede proporcionarnos algunas técnicas generales para navegar y comprender un gran código de producto (específicamente C++)?

+2

duplicado: http://stackoverflow.com/questions/2783612/listing-c-c-functions-code-analysis-in-unix/2783652#2783652 –

+1

wiki de la comunidad? – Anon

+2

@gbrandt el enlace se trata de obtener maneras de enumerar las funciones de C/C++. Ciertamente no es un dup. – OTZ

Respuesta

10

Ejecútelo a través de doxygen. Esto generará la documentación html que será útil incluso si el código no tiene los comentarios correctos de estilo doxygen.

Otro buen consejo es consultar las pruebas unitarias, si las hay. Si no hay pruebas unitarias, una buena forma de entender el código es escribir sus propias pruebas unitarias. El esfuerzo para hacer esto se pagará por sí mismo muchas veces.

8

utilizan todos los medios a su disposición (de ninguna prioridad especial):

  1. uso del producto en sí y comprender lo lo hace
  2. Talk a los desarrolladores que mantienen o han trabajado con él previamente
  3. de depuración a través de él y ver cómo los flujos de datos y cómo interactúan las clases ("al hacer clic en este botón, lo que sucede exactamente, ¿quién es responsable?")
  4. mirada a la arquitectura, UML, diagramas de clases o
  5. Uno de mis favoritos: crear sus propios diagramas de jerarquías de clases, interacciones de clase, flujo de control general, componentes de alto nivel, interacciones proceso/DLL, duración de los objetos y administración
  6. Si no están totalmente fuera de fecha, leer las especificaciones de desarrollo/pruebas/usuario (va bien con # 1)
  7. leer la documentación sobre el mismo

encima de todo: ser tenaz y persistente. Si no participa en el trabajo, no espere comprenderlo. Si no entiende algo, cave y cave hasta que lo haga. El software no es magia, es un trabajo sólo difícil :)

+1

Buena lista. Sin embargo, creo que los tienes en el orden de prioridad. La mayoría de las veces en un proyecto viejo y grande, cualquier documentación no tiene valor. –

+0

Yo agregaría que si trabaja en el paso (5), comparta sus diagramas con el equipo. La mayoría de los equipos (los míos incluidos) dan la bienvenida a la contribución. Su esfuerzo puede ayudar a complementar el conjunto de documentación que ya carece. –

5

Algunas personas le dirán que empiece con las estructuras de datos, pero en un sistema grande, incluso eso no es terriblemente útil la mayor parte del tiempo. Puedo pensar en cuatro puntos principales:

  • Tómese su tiempo. A menudo, es más como una serie completa de cambios de gestalt que una comprensión lineal única y gradual. Sé paciente.

  • No importa cuán grande sea, usted debería ser capaz de poner un punto de interrupción y caminar en un depurador. Incluso en un sistema grande, complicado y de múltiples subprocesos, debe poder caminar y ver qué está sucediendo.

  • Pida errores y empiece a arreglarlos, sin importar cuán disparatados parezcan. Es como dejarse caer en un país extranjero; Recogerás el idioma eventualmente.

  • Encuentra un mentor. Una guía de la selva es invaluable.

+2

+1: corregir errores es una gran función de forzado para aprender una base de código. A menos que el error sea realmente trivial, tendrás que aprender alguna parte del código para poder solucionarlo. –

+1

Las correcciones de errores son lo que siempre pido hacer si tengo la tarea de aprender cualquier software nuevo. De esta forma no solo entenderás lo que está haciendo, sino cómo (y, a veces, mejor que tus colegas si no logran descifrar el error). –

1

Creo que ya ha habido algunas buenas respuestas. Mi 2c vale ...

No estoy seguro de qué clase es tan grande (10 KLOC, 1000 KLOC, 10000 KLOC, etc.), pero uno esperaría que esto se descomponga de alguna manera y no sea un solo programa monolítico. Tal vez su administración tenga alguna guía sobre en qué 'módulos' es más probable que esté pasando tiempo en este momento. Con suerte, esto puede ayudar a analizar el alcance del problema.

En primer lugar, antes de intentar comprender el código, intente comprender el producto. ¿Qué hace? Entonces, ¿cómo lo hace? ¿Con qué interactúa? Entonces, ¿cómo interactúa? etc ...

Al llegar al código, intente primero comprender el diseño de alto nivel y la filosofía, y trabaje en la amplitud antes de la profundidad. Estoy de acuerdo con que algunos de los anteriores reparen algunos errores, pero también sugiero que continúen manejando el alto nivel, incluso si necesitan entrar en detalles para solucionar algunos errores.

También estoy de acuerdo con lo anterior en términos de generar algunos diagramas para usted si no puede encontrar ninguno ya existente. Y luego compártelos, ¿quizás una wiki de equipo/producto? Tengo curiosidad de por qué el doco existente no ayuda mucho. Normalmente, esto se debe a que este tipo de doco se generó a partir de los conceptos iniciales y el producto ya no tiene ninguna similitud, pero si este no es el caso, entonces, ¿qué se puede aportar a este problema? ¡Uno asume que en el lugar donde se encuentra hoy alguien más estará en el orden suficiente, y usted está en una posición ideal para saber qué doco esencial falta!

Si el producto es realmente "enorme", debe aceptar que nunca podrá guardarlo en su cabeza, así que lo mejor que puede hacer es estar lo suficientemente familiar como para saber por dónde empezar a buscar (vuelve a entender el producto, y acercándose a la amplitud del código primero).

Cuestiones relacionadas