Cómo aprender a leer el código

Ayuda tener un proyecto en mente.

La programación es la resolución de problemas. Necesita un problema primero para ser resuelto.

Cuando resuelve un problema, enumera los pasos para resolverlo línea por línea. Eso es un programa.

Debes repetir algunos pasos o debes esperar a que se alcance una meta. (Está ahorrando para comprar un automóvil, por ejemplo, y no puede comprarlo hasta que haya ganado lo suficiente para un depósito). Un programa simple muestra “tiempo para comprar un automóvil” cuando el valor alcanza el valor mínimo de depósito.

La dificultad es interpretar líneas de código con formatos especiales o sintaxis especiales para el lenguaje que está leyendo. Algunas cosas se definen en otras partes del código o en archivos separados (o bibliotecas).

Los métodos de codificación más nuevos intentan ocultar los detalles para que pueda ver la lista general de pasos que realiza el programa. Si desea imprimir, agrega un botón de impresora y la aplicación de la biblioteca sabe cómo usar su impresora.

Cuando esté leyendo un código escrito por un programador profesional, habrá secciones de texto llamadas “comentarios”. Este es un texto que explica en inglés simple lo que hace o logra la sección de código.

Me gusta BASIC porque puedes escribir programas simples o complejos con tu Excel o Word. Aprenda a automatizar su Excel como hacer un truco especial que Transpose no puede hacer. (Copie solo ciertas filas de Excel a otra hoja según un criterio).

Trataré de usar una terminología de lenguaje neutral, ya que no mencionaste ningún idioma específico que desees para dominar la lectura. Me gustaría señalar que las habilidades que desarrolle para leer el código en un idioma serán generalmente transferibles al código de lectura en otros idiomas.

1. Encuentre una pequeña aplicación de código abierto (por debajo de 5–10 KLOC) escrita en un idioma en el que desee adquirir dominio. Algunas de las utilidades de Unix son buenas candidatas para esto si le interesa C.
2. Comience a leerlo, comenzando con la rutina “principal” (el nombre de la rutina depende del idioma)
3. Para una primera lectura, no mire las subrutinas, solo la función principal, que a menudo es trivial.
4. Una vez que esté familiarizado con la rutina principal, aborde la primera subrutina llamada. Tenga en cuenta que solo encontrar la fuente de esa subrutina es una habilidad importante. Puede seleccionar los directorios de origen o usar un buen IDE con buenas funciones de navegación (que a menudo requieren compilar primero el código).

1. Caso especial para un lenguaje orientado a objetos: cuando encuentre una subrutina que es una llamada a un método, estudie todo el objeto, no solo el método aislado. El objetivo es comprender qué hace el objeto y cómo lo hace.

1. Examine cómo cambian los datos (variables) a medida que pasa por encima de las llamadas de subrutina, comenzando de nuevo y entrando en las llamadas si no comprende los cambios.
2. Establezca puntos de interrupción en lugares del código que no entendió completamente en su lectura en los Pasos 4–6 y examine cómo funcionan en detalle.

Repita el proceso anterior con algunas aplicaciones pequeñas más para mejorar su competencia, tal vez trabajando con bases de código más grandes.

Esta es una de las tareas más difíciles en la programación porque realmente no estás leyendo el código, sino las intenciones y la mentalidad de la persona que lo escribió. A veces parece entender el código en sí, pero puede preguntarse, ¿por qué hizo eso? En algún momento puede preguntarse, ¿entendió el programador lo que estaban haciendo o soy yo? ¿Cómo te decides?

Esa es la razón por la cual, en la vida real, la mayoría de los programadores prefieren trabajar en proyectos nuevos en lugar de solucionar el código de otra persona.

Al leer el código de otro programador, enfrenta cuatro desafíos:

1. Comprender el gran esquema del software que se lee. ¿Por qué está organizado de la manera en que lo organizaron? ¿Por qué seleccionaron esta solución en lugar de eso? Si un fragmento de código no tiene sentido, ¿es porque realmente no tiene sentido o no entiendo lo que está pasando?
2. Tus propios prejuicios. ¿Qué codifican de esta manera?
3. La mente colectiva. ¿Qué pasa si el software que se analiza es producto de varias mentes y no saben cómo comunicarse muy bien entre ellas?
4. ¿Puedes identificar las revisiones de archivos que se usaron para compilar esta versión en particular? En algunas tiendas ni siquiera tienen un sistema de control de versiones. Este es uno de los aspectos más descuidados del desarrollo de software. Es como si tuvieras un almacén lleno de autopartes y te piden que ensambles un automóvil con innumerables prototipos de piezas, pero no te dicen cuál va en tu modelo.
5. Finalmente, a algunos programadores les encanta escribir software de una manera tan complicada que incluso los confunde, y mucho menos a un extraño. Esto se llama “seguridad laboral”. Lo hacen deliberadamente complicado para garantizar que no sean despedidos.

Son otros aspectos que a menudo se descuidan, como la documentación, la falta de estandarización al escribir el código, la falta de procesos de control de calidad. ¿Quién quiere perder el tiempo documentando cuando todo lo que queremos hacer es código, código, código?

Me he encontrado muchas veces donde el software acaba de salir de las manos del desarrollador. Luego, renuncian y dejan a otros tipos, como usted, rascándose la cabeza con una basura inmanejable.

Pero, esto tiene una gracia redentora. Si lo intentas sinceramente, realmente te conviertes en un mejor programador. Es difícil, pero en general, no imposible.

¿Qué problema estamos tratando de resolver aquí? Para estudiar un algoritmo, es más eficiente leer sobre el diseño (s) del algoritmo en lugar de mirar una implementación particular del mismo (el código).
Para un programa particular (o sistema de programas) es mejor entender primero el diseño. Mire los archivos que se crean y las tablas internas que se mantienen. El año pasado, heredé un conjunto de programas escritos por un miembro del equipo: el código en sí era adecuado pero tenía algunos defectos de diseño fatales que el miembro del equipo había creado.
No es posible “codificar” una falla de diseño fatal. Lo descubrí mirando uno de los archivos utilizados por el programa y descubrí que crearía claves de registro duplicadas, lo que sería un problema. Estoy en el proceso de rediseñar los programas. Sí, he tenido que “leer el código” en pequeños fragmentos, solo para descubrir implementaciones y defectos más incorrectos. Ese descubrimiento se produjo al ejecutar varios casos de prueba y observar la salida inesperada o el informe de errores.
Leer el código no es como leer un periódico. El análisis del diseño y la implementación debe realizarse en paralelo. Nunca asumas que lo que tienes es robusto y está formado correctamente. Es necesaria una visión escéptica y crítica. Desarrollar hábitos de saber qué buscar es la estrategia.

Aprende a escribirlo primero, eso sin duda te enseñará cómo leerlo también.

Comience simple, elija C # por ejemplo. Hay toneladas de cosas en línea. Puede crear juegos simples basados ​​en consola al principio. Es realmente muy divertido. Las cosas pequeñas más tarde conducen a las más grandes, comienza a acumularse y, más temprano que tarde, te darás cuenta de que no solo puedes leer el código, sino que incluso puedes entender el código en idiomas nunca antes vistos.

El juego de codificación se basa en ciertas reglas, comprenda los patrones detrás de ellas y se sorprenderá de lo que vendrá

1. Aprende a codificar y familiarízate con él
2. Aprende algunos patrones populares
3. Encuentre algunas herramientas (ctags, cscope, GNU Global, fuente de información)
4. Lea el documento o gen uno usted mismo (doxygen) para conocer aproximadamente el algoritmo y la arquitectura
5. Leer el código y Leer y leer

Ver: ¿Cómo aprendo a codificar? No creo que haya una forma más rápida de entender la lectura del código que aprender a producirlo.

Una vez que haya aprendido a producir código, leerlo (en cualquier idioma) será mucho más fácil. También lo recordará mejor si aprende con ejercicios (haciendo cosas).

deberías aprender el idioma en el que escribiste el código.

Aprende a programar primero. No solo lea el código, intente interpretarlo.