Si te acaban de presentar un nuevo proyecto, ¿qué es lo primero que buscas para tener una idea de cómo funciona?
¿Buscas el diseño primero? Si hay un diseño, ¿qué buscas en él? Diagramas de clase o diagramas de implementación o diagramas de secuencia o algo más?
¿O vas directamente por el código? Si es así, ¿cómo entiendes cómo interactúan las diferentes capas?
Respuestas:
Empiezo con el código. Los documentos de diseño separados, si los hay, tienen más probabilidades de estar equivocados o mal concebidos que no. Entonces, empiezo tratando de rastrear un flujo simple a través del código; si es una aplicación web, podría ser una solicitud o una secuencia de solicitudes, por ejemplo. Una vez que he hecho eso, tengo una especie de esqueleto para entender mejor. Entonces, podría volver y leer diseños u otra documentación, pero en ese momento, tengo algo concreto con lo que relacionarlos y validarlos, para poder detectar información duff. O podría seguir leyendo el código, o probar casos, etc.
Yo comenzaría en un nivel superior. Si hay documentación para el usuario - manual o guía del usuario. De lo contrario, eche un vistazo a las especificaciones de requisitos para tener una idea de lo que se supone que debe hacer el software. Prefiero mirar el diseño e intentar mapearlo en los archivos de código. Esperemos que estos estén estructurados en carpetas de alguna manera sensata. Luego elegiría parte del diseño e iría a los archivos para seguir el flujo del código sin atascarme demasiado en los pequeños detalles.
Comienzo configurando un sistema de desarrolladores. Yo uso el procedimiento documentado. Esto le permite al gato salir de la bolsa acerca de cuánto está sincronizada la documentación con la realidad.
También me dice cuáles son las dependencias. Esto importa
Ahora que tengo una configuración de desarrolladores (y marco el documento de configuración con correcciones a medida que avanzo) construyo una versión. Termino haciendo preguntas durante toda esta fase.
Ahora que está construido, hago el ejercicio introductorio del manual del usuario. Esto me dice aproximadamente qué hace realmente el sistema.
Ahora tengo una pista parcial sobre el sistema, leí los documentos de diseño, que ahora creo en proporción a lo equivocados que han sido los documentos hasta ahora.
Una vez que llegue a la documentación de comportamiento real, puedo comenzar a buscar en el código y ver qué hay realmente allí. Nunca se alinean, pero ahora sé cuánto creer.
Luego miro la salida IDE para los comentarios de "todo" y "arreglo". Cosas como "arreglar en la versión 2.0" también son sugerencias.
Por lo tanto, se trata de aprender la veracidad y, como señalan las personas, los documentos de diseño por separado rara vez están actualizados o son correctos, pero le dice lo que la gente estaba pensando en un momento dado. Y, por supuesto, esas personas probablemente no estén disponibles para interrogar.
Prefiero comenzar con el diseño para obtener una visión general del proyecto e intentar comprender algunas de sus características y / o estructura clave antes de profundizar en los detalles.
Siempre el diseño. Con el código, vale la pena seguir los pasos de configuración del desarrollador (verificar la fuente, construir el proyecto, hacer los cambios de configuración necesarios), pero no tiene sentido tratar de aprender la estructura de una aplicación a partir de su código. Eso solo le dice cuál es la estructura, no por qué es la estructura o lo que los otros desarrolladores piensan que los aspectos más destacados y malos son de la arquitectura. Aquellos que aprende de los diagramas de pizarra y chats con los desarrolladores.
Para un software complejo, lo abordaría más o menos como si fuera un nuevo proyecto de desarrollo. Comience con las grandes ideas: visión, contexto, alcance, partes interesadas. Lea la documentación del usuario y obtenga una idea de cómo se usa. Obtenga capacitación para el usuario con el software si es posible (o aplicable). Luego, comience a analizar los requisitos y la documentación de diseño para tener una idea de cómo funciona a un alto nivel. Hable con los diseñadores si todavía están cerca. Mire la arquitectura del sistema desde diferentes perspectivas. A partir de ahí, comience a profundizar en la funcionalidad principal y ver un código, volviendo a los requisitos y el diseño según sea necesario. Mientras observa el código, ejecute el software para verlo en acción. Mientras tanto, compile documentación resumida para futuras referencias: usted es dueño de Cliffs Notes. Bifurca hasta que tengas una idea bastante buena de cómo funciona y cómo encaja todo, pero concéntrate en las partes con las que trabajarás. A estas alturas ya tiene una comprensión completa de todo el sistema, o al menos de las partes que le son aplicables.
Por supuesto, en el mundo real, es posible que no tenga tiempo para pasar por todo esto antes de comenzar a ensuciarse las manos, especialmente en los proyectos más grandes. Pero así es como lo haría si fuera por mí.
Debe trabajar de ida y vuelta entre el código y los documentos de diseño.
Puede comenzar con el código o el diseño, y realmente no importa. Lea el código hasta que esté bien y verdaderamente confundido, luego consulte los documentos de diseño. O lea los documentos de diseño para obtener una imagen de alto nivel y luego mire el código para ver cómo se ve. Repita casi indefinidamente siempre que esté trabajando con el código.
Tenga en cuenta que los documentos de diseño casi siempre están desactualizados e incorrectos de muchas maneras. Sin embargo, siempre que tenga en cuenta estos puntos, los documentos desactualizados aún lo ayudarán a comprender la mente del autor en algún momento del pasado. Muchos de los problemas e inquietudes de alto nivel seguirán siendo válidos, y es muy probable que pueda comprender más rápidamente cómo llegó el código a donde está, incluso si tiene una imagen anticuada del lugar donde el autor pensó originalmente que Vamos.
Mientras trabaja en el código y el diseño, cree sus propios documentos que describan su comprensión del código hoy. Tal vez estos documentos sean un simple boceto o dos, tal vez sean escritos en una wiki, tal vez sean otra cosa. No los complique demasiado: no hay documentos de palabras de 30 páginas. Simplemente apunte sus ideas, lo que aclarará en gran medida su propio pensamiento.
Depende del tipo de aplicación. Si es una aplicación centrada en datos, generalmente comienzo con el diseño de la base de datos. Si tiene una interfaz de usuario que puede ejecutar (o buenos diseños de pantalla), también puede darle una buena idea de lo que hace la aplicación muy rápidamente (estoy hablando de unas pocas horas aquí como máximo). Después de eso, empiezo a cavar en el código y tendrá más sentido porque sé lo que está haciendo la aplicación.
Comienzo con la documentación de diseño. En particular, la especificación, que indica la intención de lo que se está mirando.
Si es posible, luego miro las notas de diseño y la documentación para obtener una idea general de cómo se ha hecho, el proceso de pensamiento, el estilo y la naturaleza de las personas involucradas.
Si es posible, entonces hablo con las personas que trabajaron en él, ¿qué hace? ¿Cómo? ¿Por qué? ¿Dónde están enterrados los cuerpos?
Hay una tendencia entre los desarrolladores a saltar al código: "Déjame mostrarte este código". Esto está bien para ellos, pero tiende a secuestrar mis necesidades, que es entender el alto nivel que da contexto a las cosas de bajo nivel.
Utiliza grandes cantidades de poder cerebral para mirar pequeños fragmentos de código, fuera de contexto completo y comprender cualquier cosa significativa. Entonces, si es posible, hacer que los desarrolladores hablen sobre el PRINCIPIO, la estructura, las unidades, los módulos, lo que sea que conduzca a una apreciación de la tarea.
Solo entonces vale la pena intentar ingresar al código.
En el gran esquema de cosas, mirar el código es como mirar una página llena de 0 y 1. Hay significado, pero lleva mucho tiempo resolverlo. Obtener una idea de dónde mirar y qué partes son significativas ayuda a reducir el espacio de búsqueda.
Todo lo dicho: cuando no hay doco, no hay personas y solo el código, entonces no hay nada más que mirar el código.
En ese caso, normalmente no trato de entenderlo con una lectura lenta y profunda, hago un pase rápido, leyendo rápidamente todo. A veces esto es solo abrir archivos y sentarse presionando la tecla de página hacia abajo. Puede obtener una apreciación increíble de una imagen general con solo hacer esto. (Y en algunos casos, incluso volcado en cadena los archivos ejecutables y los rastreo, buscando firmas y patrones. Esto ha sido increíblemente fructífero en los últimos 20 años).
Comienzo con las pruebas. Si las pruebas unitarias y las pruebas de integración están bien escritas, describen los casos de uso. Si no están bien escritos, o no están escritos en absoluto (lamentablemente, este es en gran medida el caso), comienzo con puntos de entrada en el código y los comparo con el diseño.
Luego escribiré pruebas para cada caso de uso, descubierto por el árbol que encontrará después de investigar los puntos de entrada, para sondear el código y usar las utilidades de cobertura de código para ver lo que me falta. Estas pruebas me dicen exactamente cómo funciona el código.
Siempre trato de agregar valor a algo que miro; escribir pruebas, limpiar código, refactorizar funciones grandes (más de 20 líneas).
Me parece que la creación de documentación por sí sola no agrega ningún valor real al código, ya que nunca interactúa con el código.
bueno, ¿qué es "el diseño"? un LÉAME? un diagrama uml? puede hacer un documento de diseño hasta la mitad (y la mayoría lo hace), no puede codificar hasta la mitad
cualquier diseño simplemente será una opinión , mientras que el código es el hecho
solo me referiré a documentos secundarios cuando no pueda entender el razonamiento del código
leer código es una habilidad esencial para un desarrollador. es mejor que lo aprendas ahora, de todos modos no verás mucha documentación útil durante tu carrera
Luego miro el archivo README, TODO y Changelog del desarrollador. Si no entiendo por qué se escribió el software, cómo se escribió y hacia dónde va ... No lo uso.
Diseñe primero, luego codifique, de arriba hacia abajo si lo desea, para que entienda el contexto en todos los niveles en los que tengo que trabajar.
Pero si tengo que hacer un cambio muy específico, como arreglar un informe o un cálculo, simplemente voy y miro el código.
Más específicamente, mi enfoque de "diseño primero" es este:
Comienzo con el modelo de dominio si hay uno, si no hay ninguno construyo al menos uno básico (un buen punto de partida es el modelo de datos). Define el "glosario" de la aplicación y la relación entre los objetos (clases).
Representa "qué objetos son manejados" por la aplicación.
Luego busco el modelo de caso de uso para averiguar "qué procesos se realizan" por la aplicación, aunque prefiero un mapa de procesos si es el que muestra secuencias de procesos.
Después de eso, debería tener una buena imagen de la aplicación y luego puedo comenzar a diseñar el cambio.
Por cierto, la respuesta anterior está en el contexto de las aplicaciones comerciales.
El código no miente. Sin duda, es una buena idea obtener una visión general del proyecto primero para comprender lo que hace. Sin embargo, si su tarea es obtener una comprensión detallada de cómo funciona el proyecto, mirar el código, al menos para mí, es como mirar un rompecabezas pieza por pieza, excepto que con cada clase que mire, está agregando otro pieza del rompecabezas Si el código está bien estructurado, puede ver un patrón que se forma a partir de los nombres de las clases sin siquiera investigar qué hace la clase. En muchos casos, puede obtener pistas y pistas del código que lo ayudarán aún más.
Finalmente, obtienes lo que es una idea irreconocible de lo que hace el programa, un rompecabezas completo. La documentación puede ser incompleta o inexacta, pero el código nunca miente. Todo esto puede hacerlo sin descubrir qué hace cada método individual. No todos pueden aprender sobre un proyecto de esta manera, pero si lo haces a menudo, te resulta más fácil, sin mencionar que puedes obtener la esencia de una aplicación de tamaño mediano en un par de horas de estudio. Aunque supongo que todo se reduce a preferencias.
Después de ver el código del módulo / punto de aplicación más crítico: al ver el código, puedo verificar la bondad del diseño.
Ejemplo:
Debe trabajar en la gestión de aplicaciones de una aplicación web sobre informes financieros.
Después de leer el código sobre el mensaje, la aplicación de inicio y finalización (para probable bloqueo en db), el proceso maestro de creación de datos de lo que se debe informar, etc., etc. (por ejemplo, en el almacenamiento de gas, el proceso maestro trata sobre el cálculo del stock de gas en el área de almacenamiento de los clientes con suministro e inyección; el proceso secundario es la facturación de estos datos calculados previamente)
Ni código ni diseño. Me gusta hablar con las partes interesadas y los usuarios finales y descubrir cómo funciona desde su perspectiva. Una vez que puedo crear una imagen en mi mente a partir de ellos, miro rápidamente el diseño técnico y luego el código.
Primero iré con el diseño y luego codificaré simultáneamente. Es muy importante porque cada proyecto es diferente. Debe presentar un plan y un alto nivel de flujo de trabajo del proceso de la A a la Z antes de poder comenzar a trabajar en los códigos al mismo tiempo. Todas las decisiones tomadas deben documentarse para que otros equipos (o usted mismo) que estén desarrollando los códigos conozcan la última actualización y lo que se ha confirmado.
Si hay un buen documento de diseño de alto nivel, lo usaré. Tiene que ser conciso y actualizado. Si es demasiado detallado o desactualizado, me dirigiré al código.
Por supuesto, depende del proyecto, ¿no? Un proyecto extremadamente complejo o con muchas facetas quizás se aborde mejor a través de la documentación (si la documentación es lo suficientemente sólida).
En mi opinión, un solo módulo simple o una aplicación simple casi siempre se aborda mejor a nivel de código.
¡No hay una respuesta correcta para cada situación!