Red de conocimiento informático - Conocimiento informático - Cómo leer el programa (cita) para obtener respuestas

Cómo leer el programa (cita) para obtener respuestas

Capítulo 1: Introducción 1. Desarrolle un hábito y, a menudo, dedique tiempo a leer código de alta calidad escrito por otros.

3. Preste atención y preste atención a los requisitos especiales no funcionales en el código, que pueden conducir a estilos de implementación específicos.

4. Cuando trabaje en código existente, coordine según sea necesario con el autor o mantenedor para evitar la duplicación de esfuerzos o resentimiento.

5. Piense en los beneficios que obtiene del software de código abierto como un préstamo y busque formas de retribuir a la comunidad de código abierto siempre que sea posible.

7. Cuando busque ERRORES, analice el código desde la manifestación del problema hasta la causa raíz del mismo. No seguir caminos irrelevantes (extraviarse)

8. Debemos aprovechar al máximo el programador, las advertencias dadas por el compilador o la salida del código simbólico, el rastreador de llamadas al sistema y la consulta estructurada de la base de datos. Utilice el mecanismo de registro del idioma, las herramientas de volcado de paquetes y los programas de detección de mensajes de Windows para determinar la ubicación del ERROR.

9. Para sistemas grandes y bien organizados, sólo necesita un conocimiento mínimo de su funcionalidad completa para poder realizar cambios.

10. Al agregar una nueva funcionalidad al sistema, la primera tarea es encontrar código que implemente características similares y usarlo como plantilla para la funcionalidad a implementar.

11. Desde la descripción funcional de la característica hasta la implementación del código, puede buscar el código según la cadena del mensaje o mediante palabras clave.

12. Al portar código o modificar interfaces, puede localizar directamente el alcance del problema a través del compilador, lo que reduce la carga de trabajo de lectura de código.

13. Cuando refactorizas, comienzas con un sistema que funciona y quieres asegurarte de que el sistema funcione correctamente al final. Un conjunto adecuado de casos de prueba puede ayudarle a cumplir esta restricción.

14. Al leer el código para buscar oportunidades de refactorización, comience con la arquitectura del sistema y luego perfeccione gradualmente para lograr los máximos beneficios.

15. La reutilización del código es una idea atractiva pero difícil de comprender; reduzca sus expectativas y evite decepciones.

16. Si desea que el código importante sea difícil de entender y separar, intente buscar un paquete más granular o incluso otro código.

17. Al revisar un sistema de software, tenga en cuenta que el sistema se compone de muchas partes, no solo de ejecución de declaraciones. También preste atención a analizar lo siguiente: estructuras de archivos y directorios, procesos de compilación y configuración, interfaz de usuario y documentación del sistema.

18. Utilice las revisiones de software como una oportunidad para aprender, enseñar, echar una mano y recibir ayuda.

Capítulo 2: Elementos básicos de programación

19. Al analizar un programa por primera vez, main es un buen punto de partida. 20. Las secuencias en cascada if-else if-...-else se pueden ver como A. estructura de elección que consta de opciones mutuamente excluyentes 21. A veces, para comprender lo que hace un programa en un determinado aspecto, puede ser más apropiado ejecutarlo que leer el código fuente 22. Al analizar un programa importante, es mejor. primero identifique el componente importante 23. Comprender las convenciones de nomenclatura locales y utilizarlas para adivinar el propósito funcional de variables y funciones 24. Al modificar el código basándose en conjeturas, debe diseñar un proceso que verifique la hipótesis inicial. compilador Realizar inspecciones | introducir afirmaciones | o ejecutar casos de prueba apropiados 25. Comprender una determinada parte del código puede ayudarle a comprender el resto del código 26. Para resolver el código difícil, comience con la parte fácil. de Adquiera el hábito de leer documentación relacionada con elementos de la biblioteca; esto mejorará su capacidad para leer y escribir código 28. Existen muchas estrategias alternativas para la lectura de código: análisis ascendente y descendente aplicando heurísticas y verificando comentarios. documentación externa, todos estos métodos deben probarse dependiendo de las necesidades del problema 29. Los bucles del formulario for (i=0; i>n puede entenderse como a/k, k=2n .47. 48. Trate la expresión de control de cada estructura de control como una afirmación del código que contiene. 49. Las declaraciones return, goto, break y continue, así como las excepciones, afectarán la estructura. flujo de ejecución. Dado que estas declaraciones generalmente terminan o reinician el ciclo en curso, su comportamiento debe razonarse por separado 50. Usar variables e invariantes de ciclos complejos, razonar sobre los ciclos. 51. Reorganizar el código usando transformaciones que preserven el significado para simplificar el razonamiento sobre el código. Capítulo 3: Tipos de datos C avanzados

52. Comprender las funciones que cumplen las construcciones de lenguaje específicas. Después de eso, podrá comprender mejor el código que las utiliza. 53. Identificar y clasificar las razones para usar punteros. 54. En los programas C, los punteros se utilizan generalmente para construir estructuras de datos encadenadas | estructuras de datos asignadas dinámicamente | implementar llamadas de referencia | acceder e iterar elementos de datos | representar funciones de referencia | | y acceder directamente a la memoria del sistema 55. Los parámetros pasados ​​por referencia se pueden utilizar para devolver el resultado de una función o para evitar la copia de parámetros.

La sobrecarga 56. Un puntero que apunta a la dirección de un elemento de la matriz puede acceder al elemento ubicado en una posición de índice específica 57. El puntero al elemento de la matriz y el índice de la matriz correspondiente tienen la misma semántica para las operaciones en ambos. El uso de funciones globales o variables locales estáticas no es reentrante en la mayoría de los casos 59. Los punteros de caracteres son diferentes de las matrices de caracteres 60. Todas las razones para identificar y clasificar estructuras de aplicaciones u objetos ***. elementos de datos para que puedan usarse en su conjunto para devolver múltiples elementos de datos de funciones | construir estructuras de datos encadenados | mapear datos en dispositivos de hardware y medios de almacenamiento | implementar tipos de datos abstractos y programar de manera orientada a objetos | 62. *** Los usuarios en programas C se utilizan principalmente para optimizar la utilización del espacio de almacenamiento | implementar polimorfismo y acceder a diferentes expresiones internas de datos 63. Un puntero, después de ser inicializado para apuntar al espacio de almacenamiento de N elementos. se puede utilizar como una matriz de N elementos 64. Los bloques internos asignados dinámicamente se pueden liberar en el sitio de soldadura, al final del programa o mediante la recolección de basura. El bloque de memoria asignado en la pila se libera cuando la función que asignó. sale. 65. Los programas en C utilizan declaraciones typedef para promover la abstracción y mejorar la legibilidad del código, evitando así problemas de portabilidad y simulando el comportamiento de declaración de clases de C++ y Java. 66. La declaración typedef puede entenderse como una definición de variable: el nombre de la clase. variable es el nombre del tipo; el tipo de la variable es el tipo correspondiente al nombre. Capítulo 4: Estructura de datos C

67. Comprender las operaciones de estructura de datos explícitas basadas en el tipo de datos abstracto subyacente. En lenguaje C, los tipos de matrices integrados generalmente se usan para implementar vectores y la implementación subyacente ya no está abstraída. 69. Las matrices de N elementos se pueden secuenciar para (i = 0; i

Almacenado en una matriz, vinculado a una lista vinculada o vinculado a través de los bordes del gráfico 92. Los bordes en los gráficos generalmente se representan implícitamente a través de punteros o explícitamente como estructuras independientes 93. Los bordes en los gráficos a menudo se almacenan. Es una asignación dinámica. matriz o lista enlazada en ambos casos, los bordes están anclados a los nodos del gráfico 94. En un gráfico no dirigido, todos los nodos deben considerarse equivalentes al expresar datos, de manera similar a. Además, el código que realiza tareas de procesamiento no debe distinguir. bordes en función de su orientación 95. En un gráfico desconectado, el código transversal debe poder conectar subgrafos aislados 96. Al procesar un gráfico que contiene ciclos, el código transversal debe evitar ingresar bucles al procesar gráficos. otros tipos de estructuras independientes pueden estar ocultas. Capítulo 5: Flujo de control avanzado

98. Utilice algoritmos y estructuras de datos definidos recursivamente. A menudo se implementa utilizando definiciones de funciones recursivas. 99. Al razonar sobre funciones recursivas, comience con un punto de referencia. prueba de retraso y verifica cómo cada llamada recursiva se acerca gradualmente al código de ejemplo de referencia no recursivo 100. Los lenguajes simples a menudo usan una serie de pasos que siguen el análisis sintáctico de funciones con estructuras gramaticales 101. Al razonar sobre funciones mutuamente recursivas. , se basará en la definición recursiva del concepto subyacente 102. Una llamada recursiva de cola es equivalente a un bucle que regresa al comienzo de la función 103. Cambie la cláusula throws de la definición del método Eliminando el método del. clase y luego ejecuta el compilador Java para compilar el código fuente de la clase, puede encontrar fácilmente aquellos métodos que implícitamente pueden generar excepciones 104. El código que se ejecuta en computadoras multiprocesador a menudo se organiza en torno a procesos o subprocesos .105. El modelo paralelo se utiliza para distribuir el trabajo entre múltiples procesadores, o crear un grupo de tareas y luego distribuir una gran cantidad de tareas estandarizadas que deben procesarse 106. El modelo paralelo de administrador/trabajador basado en subprocesos generalmente consumirá mucho tiempo. o bloquear operaciones en subtareas de los trabajadores, manteniendo así la capacidad de respuesta de la tarea central 107. El modelo paralelo de administrador/trabajador basado en procesos se usa generalmente para reutilizar programas existentes u organizar y separar procesos de grano grueso con interfaces bien definidas Módulo del sistema. 108. En el procesamiento paralelo basado en canalizaciones, cada tarea recibe algunas entradas, realiza algún procesamiento en ellas y pasa la salida generada a la siguiente tarea para un procesamiento diferente. 109. Las condiciones de carrera son difíciles de alcanzar. El código relacionado a menudo propaga las condiciones de carrera. múltiples funciones o módulos; por lo tanto, es difícil aislar los problemas causados ​​por las condiciones de carrera 110. Tenga cuidado con el código de manipulación de la estructura de datos y las llamadas a la biblioteca que aparecen en los controladores de señales. 111. Al leer código que contiene macros, tenga en cuenta que. las macros no son funciones ni declaraciones 112. Las macros en los bloques do... while(0) son equivalentes a las declaraciones en los bloques de control 113. Las macros pueden acceder a todas las variables locales visibles en su punto de uso. valor de los parámetros 115. El empalme de etiquetas basado en macros puede crear nuevas etiquetas Capítulo 6: Manejo de proyectos grandes

116 Puede analizar la organización de un proyecto explorando el árbol de código fuente del proyecto: el jerárquico. Estructura de directorios que contiene el código fuente del proyecto. El árbol del código fuente a menudo puede reflejar la estructura de la arquitectura y los procesos de software del proyecto. 117. El árbol del código fuente de la aplicación A menudo refleja la estructura de implementación de la aplicación. 118. No se deje intimidar por el código fuente grande. colecciones; generalmente están mejor organizadas que los proyectos especializados más pequeños 119. Cuando se acerque por primera vez a un proyecto grande, tómese su tiempo para familiarizarse con la estructura del árbol de directorios del proyecto 120. El código fuente del proyecto es mucho más que el. instrucciones en lenguaje informático que se pueden compilar para obtener un programa ejecutable; el árbol de código fuente de un proyecto generalmente también incluye especificaciones | scripts de prueba | Ejemplos de compilación | información sobre procesos y licencias 121. El proceso de compilación de proyectos grandes generalmente se describe de forma declarativa con la ayuda de dependencias. Las dependencias están representadas por programas de herramientas, como make y sus derivados, convertidos en acciones de compilación específicas. , los archivos de producción a menudo se generan dinámicamente mediante pasos de configuración; antes de analizar los archivos de producción, se debe realizar la configuración específica del proyecto 123. Al inspeccionar cada paso de un proceso de compilación a gran escala, puede utilizar el modificador -n de make. programa para ensayo 124. El sistema de control de revisiones proporciona una manera de obtener la última versión del código fuente del repositorio 125. Puede utilizar los comandos relevantes.

, muestra las palabras clave de identificación de revisión en el archivo ejecutable, haciendo coincidir así el archivo ejecutable con su código fuente 126. Utilice el número dentro del sistema de seguimiento de errores que aparece en el registro de revisión para encontrar la información relevante en la base de datos del sistema de seguimiento de errores. el problema 127. Puede utilizar el repositorio de versiones de un sistema de control de revisiones para descubrir cómo se implementó un cambio específico 128. Las herramientas de compilación personalizadas se utilizan en muchos aspectos del proceso de desarrollo de software, incluida la configuración | Prueba y documentación 129. El resultado de depuración del programa puede ayudarnos a comprender partes clave del flujo de control del programa y los elementos de datos 130. La ubicación de la declaración de seguimiento es generalmente una parte importante de la operación del algoritmo. utilizado para comprobar el algoritmo Pasos de la operación | Parámetros recibidos por la función | Flujo de control del programa | Propiedades del hardware subyacente y resultados de los casos de prueba 132. Puede utilizar afirmaciones que prueben el algoritmo para confirmar su comprensión de la operación. del algoritmo, o usarlo como punto de partida para el razonamiento .133 Las afirmaciones sobre los parámetros y resultados de la función a menudo registran las condiciones previas y posteriores de la función 134. Podemos usar afirmaciones que prueban la función completa como especificaciones para cada una. función dada 135. Los casos de prueba pueden ser parcialmente en lugar de especificaciones de función. 136 Las secuencias de código fuente se pueden ensayar utilizando los datos de entrada de los casos de prueba. Capítulo 7: Especificaciones y convenciones de codificación

137. método de organización seguido por una base de código determinada Luego, puede explorar su código fuente de manera más eficiente 138. Al leer el código, primero asegúrese de que la configuración de las pestañas de su editor o hermoso programa de impresión sea consistente con las especificaciones de estilo que sigue el código. 139. Puede utilizar bloques de código para sangrar y comprender rápidamente la estructura general del código. 140. Se debe prestar suficiente atención de inmediato a los códigos que están organizados de manera inconsistente. 141. Al analizar el código, preste especial atención a las secuencias de código marcadas como XXX. , FIXME y TODO: pueden ocurrir errores al acecho 142. Las constantes se nombran con letras mayúsculas y las palabras están separadas por guiones bajos 143. En los programas que siguen los estándares de codificación de Java, el nombre del paquete siempre comienza con un dominio de nivel superior. nombre (por ejemplo, org, com), los nombres de clases y los nombres de interfaces comienzan con una letra mayúscula, y los nombres de métodos y variables comienzan con una letra minúscula 144. La marca de tipo de prefijo húngaro antes del nombre de control de la interfaz de usuario puede ayudarnos a determinar su nombre. 145. Las diferentes especificaciones de programación tienen diferentes efectos sobre la portabilidad. Hay diferentes opiniones sobre la composición de la estructura. 146. Al revisar la portabilidad del código, o al utilizar un estándar de codificación determinado como guía, tenga cuidado de comprender la definición y limitaciones de los requisitos de portabilidad del estándar. 147. Si la función GUI se implementa utilizando las estructuras de programación correspondientes, la revisión del código puede verificar fácilmente si las especificaciones de una interfaz de usuario determinada se adoptan correctamente. 148. Después de comprender cómo se realiza el proceso de compilación del proyecto. está organizado y automatizado, podemos leer rápidamente las reglas de compilación correspondientes a la comprensión 149. Al examinar el proceso de lanzamiento de un sistema, los requisitos del formato de lanzamiento correspondiente a menudo se pueden utilizar como base. Capítulo 8: Documentación

<. p> 150. Al leer el código, debe hacer todo lo posible para utilizar cualquier documentación que pueda obtener. 151. Leer una hora de código le proporcionará tanta información como leer un minuto de documentación. 152. Utilice el documento de especificaciones del sistema para. Comprenda el entorno operativo del código que lee 153. La especificación de requisitos de software es Puntos de referencia para leer y evaluar el código 154. La especificación de diseño del sistema se puede utilizar como hoja de ruta para comprender la estructura del código. código 155. El documento de especificación de prueba nos proporciona datos que se pueden utilizar para obtener una vista previa del código 156. Cuando se trabaja con un sistema desconocido, las descripciones funcionales y las guías de usuario pueden proporcionar información general importante para comprender mejor el contexto en el que se encuentra el código. 157. Del manual de referencia del usuario, podemos obtener rápidamente conocimientos básicos sobre la apariencia y la lógica de la aplicación, detalles del formato de archivo de la interfaz del código y mensajes de error 158. Utilice el. documentación para obtener rápidamente una descripción general del sistema y comprender el código que proporciona características específicas. 159. La documentación a menudo puede reflejar e insinuar la estructura subyacente del sistema 160. La documentación ayuda a comprender algoritmos y estructuras de datos complejos. de algoritmos puede hacer comprensible un código opaco (oscuro, difícil de entender).

Para entender 162. La documentación a menudo puede aclarar el significado de los identificadores en el código fuente 163. La documentación puede proporcionar la base teórica detrás de los requisitos no funcionales 164. La documentación también puede explicar la interfaz de programación interna 165. Porque la documentación rara vez es así. El código real del programa se prueba y observa como tal, por lo que a menudo puede contener errores, documentación incompleta o desactualizada. La documentación también proporciona casos de prueba, así como ejemplos de aplicaciones del mundo real. La documentación a menudo también incluye problemas de implementación conocidos. o error 168. Las deficiencias conocidas en el entorno generalmente están documentadas en el código fuente 169. Los cambios en la documentación pueden resaltar esos puntos de falla 170. Los cambios duplicados o conflictivos en el mismo código fuente a menudo indican un problema fundamental. al mantenedor que lo solucione con una serie de parches 171. Correcciones similares aplicadas a diferentes partes del código fuente a menudo indican un error o descuido común que también puede existir en otros lugares 172. La documentación a menudo proporciona información inapropiada que confunde nuestra comprensión de la fuente. 173. Tenga cuidado con las características no documentadas: clasifique cada instancia como justificada | negligente o dañina, y decida en consecuencia si el código debe corregirse o documentarse.174 A veces, cuando la documentación describe un sistema, no lo hace en términos de lo completo. implementación, sino en términos de cómo debería verse el sistema o cómo se implementará en el futuro.175 En la documentación del código fuente, la palabra gork generalmente significa "comprensión".176. Si las palabras desconocidas o utilizadas inusualmente dificultan la comprensión del sistema. código, intente buscarlos en el glosario de documentación (si existe) | New Hacker's Dictionary [Ray96] | o en un motor de búsqueda web 177. Siempre mire la documentación de manera crítica, prestando atención a fuentes no tradicionales, como comentarios. | publicaciones | casos de prueba | listas de correo | registros de revisión | bases de datos de seguimiento de problemas | el código fuente en sí | al mismo nivel que el código, la documentación a menudo puede engañar al lector, o simplemente ser incorrecta 179. Para aquellos con códigos defectuosos, podemos inferir su verdadera intención a partir de él 180. Al leer la documentación de un sistema grande, debemos. primero familiarícese con la estructura general y las convenciones del documento 181. Cuando trabaje con documentos grandes, puede utilizar herramientas o convertir la salida de texto a un dispositivo de salida de alta calidad, como una impresora láser, para mejorar la eficiencia de lectura. Capítulo 9: Arquitectura del sistema

182. Un sistema puede (y esto es cierto en los sistemas principales) producir múltiples tipos de texto al mismo tiempo. Examinar el mismo sistema de diferentes maneras. partes del sistema | o usar diferentes niveles de descomposición pueden revelar diferentes tipos de arquitectura 183. Aplicaciones colaborativas o que requieren acceso colaborativo *** Los procesos semiautónomos que comparten información o recursos generalmente usan una arquitectura de repositorio centralizado. repositorios centralizados para almacenar pares clave/valor no estructurados y servir como centros de comunicación entre una gran cantidad de componentes de código diferentes 185. Cuando el proceso de procesamiento se puede modelar, diseñar e implementar como una serie de transformaciones de datos, el flujo de datos (o canalización). filtro) se utiliza a menudo 186. En el entorno de procesamiento automático de datos por lotes, la arquitectura de flujo de datos se utiliza a menudo, especialmente en plataformas que proporcionan un amplio soporte para herramientas de datos 187. Una señal clara de una arquitectura de flujo de datos es que el. El programa utiliza archivos temporales o canalizaciones para comunicarse entre diferentes procesos 188. Usar diagramas para construir Modelar la relación entre clases en una arquitectura orientada a objetos 189. El código fuente se puede ingresar en una herramienta de modelado y la arquitectura del sistema se puede deducir a la inversa. 190. Los sistemas con una gran cantidad de subsistemas en el mismo nivel a menudo se organizan según una arquitectura jerárquica 191. La arquitectura en capas generalmente se implementa apilando componentes de software con interfaces estandarizadas 192. Cada capa del sistema puede tratar la capa debajo de ella. como una entidad abstracta y (siempre que la capa cumpla con su especificación de requisitos) no le importa cómo se usa la capa superior. It.193 La interfaz de la capa puede ser una familia de funciones complementarias que admita un concepto específico o una. Serie de funciones intercambiables que admiten diferentes implementaciones subyacentes de la misma interfaz abstracta 194. Los sistemas implementados en lenguaje C a menudo utilizan matrices, operaciones de multiplexación de interfaces de capa de expresión 195.

Un sistema implementado en un lenguaje de elefante, que utiliza llamadas a métodos virtuales para expresar directamente operaciones multiplexadas en interfaces de capas 196. El sistema se puede organizar en varios ejes de coordenadas utilizando diferentes modelos de descomposición jerárquica únicos. 197. Utilizando tecnología de corte de programas, Dependencias entre datos. y el control en un programa puede centralizarse 198. En un sistema concurrente, un único componente del sistema actúa como un administrador centralizado, responsable de iniciar/detener y coordinar la ejecución de otros procesos y tareas del sistema .199. sobre lo mejor de muchos enfoques diferentes. Cuando se trata de tales sistemas, no se busca en vano un diagrama arquitectónico que lo abarque todo; los diferentes estilos arquitectónicos deben ubicarse e identificarse como entidades separadas pero relacionadas. 200. Diagramas de transición de estados. a menudo ayudan a aclarar las acciones de las máquinas de estados 201. Cuando se trata de grandes cantidades de código, es extremadamente importante comprender el mecanismo de dividir el código en unidades separadas 202. En la mayoría de los casos, la física del módulo A es un límite. un solo archivo | múltiples archivos organizados en un directorio o una colección de archivos con un prefijo unificado 203. Un módulo en C consta de un archivo de encabezado que proporciona la interfaz pública del módulo y un archivo fuente que proporciona la implementación correspondiente. El constructor se usa a menudo para asignar recursos relacionados con el objeto e inicializar el estado del objeto. La función generalmente se usa para liberar los recursos ocupados por el objeto durante su vida útil 205. Los métodos de objeto a menudo usan campos de clase para almacenar datos que controlan. el funcionamiento de todos los métodos (como una tabla de búsqueda o un diccionario) o mantener información de estado sobre cómo opera la clase (por ejemplo, asignar un contador a un identificador para cada objeto 206. En una clase bien diseñada, todos los campos deben declararse). Los métodos privados y accesibles con acceso público brindan acceso a ellos 207. Cuando encuentre una declaración de amigo, deténgase y analícela para ver las razones de diseño para omitir la encapsulación de clases 208. Los operadores se pueden usar con moderación para mejorar la usabilidad de una clase específica. clase, pero es inapropiado utilizar la sobrecarga de operadores para implementar una clase como una entidad de clase con toda la funcionalidad relacionada con los tipos aritméticos incorporados 209. Las implementaciones genéricas no se implementan durante la compilación mediante sustitución de macros o funcionalidad admitida por el lenguaje (como. como plantillas de C++ y paquete Ada Generic) se implementa durante el tiempo de ejecución mediante el uso de punteros a elementos de datos y punteros a funciones o polimorfismo de objetos 210. Los tipos de datos abstractos se utilizan a menudo para encapsular esquemas de organización de datos comunes (como árboles | listas o pilas). ), u ocultar los detalles de implementación de los tipos de datos a los usuarios 211. El propósito del uso de bibliotecas es variado: reutilizar el código fuente o el código objeto, organizar colecciones de módulos, organizar y optimizar el proceso de compilación o implementar varias aplicaciones. bajo demanda. 212. Los sistemas grandes | distribuidos a menudo se implementan como muchos procesos cooperativos 213. Para los repositorios de datos basados ​​en texto, la estructura se puede descifrar explorando los datos almacenados en ellos. consultando tablas en el diccionario de datos o utilizando comandos SQL específicos de la base de datos, como show table 215. Después de identificar los elementos arquitectónicos reutilizados, puede buscar sus descripciones originales para comprender la forma correcta de utilizar este marco y el posible uso indebido. 216. Para analizar en detalle una aplicación construida sobre un marco, la mejor ruta de acción es comenzar estudiando el marco en sí. 217. En el asistente de lectura generado, no tengas grandes expectativas en lo que respecta al código. Te decepcionarás 218. Después de aprender algunos patrones de diseño básicos, descubrirás que la forma en que ves la arquitectura del código cambiará: tu visión y vocabulario se ampliarán para incluir Identifica y describe muchas formas comunes. nombrarlos explícitamente. Esto se debe a que la reutilización del diseño arquitectónico a menudo precede a la formación de patrones 220. Intente seguir el patrón subyacente para comprender la arquitectura, incluso si el patrón no se menciona explícitamente en el código. arquitectura, construida alrededor de una máquina de estados cuyo funcionamiento depende del estado actual de las instrucciones del programa intérprete y del estado del programa.222 En la mayoría de los casos, la arquitectura de referencia solo especifica una estructura conceptual para el dominio de la aplicación, y la implementación específica no tiene. para seguir esta estructura. Capítulo 10: Herramientas de lectura de código

223. Las herramientas de vocabulario pueden encontrar patrones de manera eficiente en un archivo de código grande o en varios archivos. 224. Utilice el editor de programas y expresiones regulares para encontrar comandos.

comando, explore archivos de código fuente enormes 225. Busque archivos de código fuente en modo de solo lectura 226. Utilice la expresión regular ^nombre de función para encontrar la definición de la función 227. Utilice la clase de caracteres de expresión regular para encontrar el nombre siguiente. Variables específicas de patrón 228. Utilice la clase de carácter negativo de la expresión regular para evitar coincidencias no positivas. 229. Utilice la expresión regular símbolo-1. *símbolo-2 para buscar símbolos que aparecen en la misma línea. el editor La función de etiquetas del editor puede encontrar rápidamente la definición de entidades 231. Puede usar herramientas de creación de etiquetas específicas para aumentar la función de navegación del editor 232. Use la vista de esquema del editor para obtener una vista panorámica. de la estructura del código fuente. 233. Utilice su editor para detectar coincidencias de paréntesis | corchetes y llaves en el código fuente. 234. Utilice grep para encontrar patrones de código en varios archivos. símbolos 236. Cuando no pueda expresar exactamente lo que está buscando, utilice las raíces de las palabras clave para buscar en el código fuente del programa. 237. Utilice grep para filtrar la salida generada por otras herramientas para aislar los elementos que está buscando. para. 238. Cambie la salida Pipe de grep a otras herramientas para automatizar tareas de procesamiento complejas. 239. Reutilice los resultados de las búsquedas de código editando la salida de grep. 240. Filtre las falsas seleccionando líneas de salida que no coincidan con los patrones de ruido (. grep -v) salida grep.241. Utilice fgrep para buscar una lista de cadenas en el código fuente.242 Cuando busque comentarios o código escrito en un lenguaje donde los identificadores no distingan entre mayúsculas y minúsculas, utilice la coincidencia de patrones que no distinga entre mayúsculas y minúsculas. -i). Con el modificador de línea de comando grep -n, puede crear una lista de verificación de archivos y números de línea que coincidan con una expresión regular determinada. 244. Puede usar diff para comparar las diferencias entre diferentes versiones de un archivo o. 245. Después de ejecutar el comando diff. Cuando use diff, puede usar diff -b para hacer que el algoritmo de comparación de archivos ignore los espacios finales, -w para ignorar las diferencias en todos los espacios en blanco y -i para hacer que la comparación de archivos sea caso-. insensible 246. No se preocupe por crear su propia herramienta de lectura de código. Tenga miedo 247. Al crear su propia herramienta de lectura de código: aproveche al máximo las capacidades que ofrecen los lenguajes modernos de creación rápida de prototipos y mejore su uso; una variedad de heurísticas que explotan la estructura del vocabulario del código; permiten algo de ruido o silencio en la salida (salida irrelevante o salida faltante); usar otras herramientas para preprocesar la entrada o postprocesar la salida. : Especifique los niveles apropiados de advertencias del compilador y evalúe cuidadosamente el 249 generado. Utilice el preprocesador de C para clasificar los programas que abusan de las funciones del preprocesador 250. Para comprender a fondo cómo el compilador maneja un bloque de código específico, debe observar el generado. Código simbólico (ensamblaje) 251. A través del análisis Los símbolos en los archivos de objetos correspondientes pueden proporcionar una comprensión clara de la entrada y salida del archivo fuente 252. Utilice un navegador de código fuente para explorar grandes colecciones de códigos y tipos de objetos. Resista la tentación de embellecer el código externo para cumplir con sus estándares de codificación. Tentación; Los cambios de diseño innecesarios pueden crear código diferente y obstaculizar la organización del trabajo. 254. Los hermosos programas de impresión y el color de la sintaxis del editor pueden hacer que el código fuente de un programa sea más legible. El programa cdecl puede convertir declaraciones de tipo C y C++ difíciles de entender y traducirlas al inglés simple (y viceversa). La ejecución real del programa a menudo conduce a una comprensión más profunda de las acciones del programa. y los programas de seguimiento de paquetes pueden mejorar la comprensión de las acciones del programa 258. Los perfiladores de ejecución pueden identificar el código que necesita optimización, verificar la cobertura de los datos de entrada y analizar el comportamiento de los algoritmos 259. Al examinar líneas de código que nunca se han ejecutado. puede encontrar debilidades en la cobertura de la prueba y corregir los datos de la prueba en consecuencia. 260. Para explorar cada detalle del comportamiento dinámico de un programa, debe ejecutarlo en un depurador 261. Imprima el código que le resulte difícil de entender. artículo 262. Puedes dibujar diagramas para representar el comportamiento del código. 263. Intenta presentar el código que estás leyendo a otra persona. Hacerlo generalmente mejorará tu comprensión del código.

4. Para comprender algoritmos complejos o estructuras de datos inteligentes, elija un entorno tranquilo y luego