Casi todos los programadores avanzados dicen que es muy útil leer el código de otros profesionales. Por lo general, aconsejan código abierto.
¿Lo lees o no? Si lo hace, ¿con qué frecuencia y cuál es el procedimiento para leer el código? Además, es un poco difícil para los novatos lidiar con SVN: un montón de archivos. ¿Cual es la solución?
Respuestas:
¿Lo lees o no?
Sí.
Si lo haces, con qué frecuencia
Diario. Constantemente. Trabajo con numerosos proyectos de código abierto (principalmente relacionados con Python) y debo leer el código fuente porque es la documentación más precisa.
¿Y cuál es el procedimiento para leer el código?
Um. Abrir y leer.
Además, es un poco difícil para los novatos lidiar con SVN: un montón de archivos. ¿Cual es la solución?
Abrir y leer. Entonces lee más.
No es fácil. Nada lo hace fácil. No hay camino real para entender. Se necesita trabajo.
Hay varias capas en el enigma que tienes. Primero, comience en el nivel alto, una vista de pájaro, por así decirlo. Una vez que revise un proyecto, habrá un montón de archivos en una estructura de directorio. Eso es lo mismo si está buscando código abierto o código cerrado (el código fuente es el código fuente después de todo). Entonces comience con esto:
Se necesita práctica, pero definitivamente es factible. Cuanto más sepa sobre las bibliotecas y los marcos que usa la aplicación, más sabrá cómo debe organizarse el código y dónde buscar respuestas a preguntas específicas. Algunos códigos son un poco más difíciles de seguir, especialmente si son bastante indirectos. Por eso necesitas el lápiz y el papel. Finalmente, una bombilla se apaga en tu cabeza y lo consigues. Eso es cuando leer el resto del código tiene mucho más sentido.
No es leer como lees una novela, sino más bien cómo lees un libro de referencia. Una buena manera es elegir un error recientemente corregido de un mensaje de verificación, hacer una diferencia de lo que cambió y leer las partes relevantes hasta que comprenda tanto el problema como la solución. Las vulnerabilidades de seguridad bien publicitadas son errores divertidos para elegir porque hay mucha discusión sobre ellos en los foros. Luego, escoge uno de los errores de "fruta baja" del rastreador de errores y lee hasta que entiendas cómo solucionarlo tú mismo. La mayoría de los profesionales de lectura de códigos son incidentales en el curso de la corrección de errores o la adición de funciones.
Por lo general, los mejores ejemplos de código apenas se notan. Los comprenderá instantáneamente sin leerlos más de una vez. Hacen que parezca que es extremadamente fácil de escribir, a pesar de que un código tan bueno generalmente pasa por muchos borradores. Produce la sensación paradójica de que, por supuesto, el código dado es la forma obvia de hacerlo, aunque no es la primera forma en que pensaba.
Cuando encuentre un código como ese, intente comprender el conocimiento que se generó al escribirlo y los principios de diseño involucrados, de modo que cuando se encuentre en una situación similar en el futuro, con suerte pueda aplicar los mismos principios.
Un truco que uso con bastante frecuencia cuando leo alguna función complicada, el segmento de código es comenzar a refactorizarlo en algo más legible sin cambiar la lógica.
¿Cómo es difícil lidiar con "un montón de archivos"? No es diferente de cuando escribe su propio código, excepto que no tiene conocimiento previo de su organización a menos que esté documentado.
Si usted, como programador reclamado, no puede entender la estructura del proyecto a partir de "un grupo de archivos", ya sea un proyecto extremadamente mal organizado, o si es un programador inepto (o, en casos extremos, ambos).
Comience a leer, trate de encontrar algunos puntos de entrada o clases / métodos dinámicos esenciales y construya una comprensión de cómo todo se une a partir de ahí. No será instantáneo, llevará tiempo, pero se puede hacer incluso si no hay documentación en absoluto.
Lo mejor que puede esperar al leer el código de otro proyecto, ya sea una API o una pieza de software, es que las variables, las funciones y los nombres de macro no se abrevian de manera ambigua o se nombran para que pueda descubrir su intención.
Pero aparte de eso, se necesita una cantidad decente de conocimiento distribuido en el lenguaje, las técnicas de programación y también sobre el propósito del código en sí mismo para poder sumergirse en un código complejo.
Actualmente estoy tratando de ver cómo Lua hace algo de su magia, pero estoy llegando al punto anterior donde muchos de los identificadores se nombran vagamente y se abrevian al punto donde no puedo entender qué línea está intentando hacer lo que sé tiene que hacerse en algún punto del código de función ... Las variables de una sola letra frecuentes y los nombres de macro / función abreviados me están haciendo pensar.
Después de mirar el "Primero, comience en el nivel alto, una vista de pájaro" como sugirió @Berin Loritsch, puede buscar pruebas de unidad y / o pruebas de integración, si las hay.
Las pruebas unitarias son interesantes para ver cómo funcionan los (api) detalles.
Las pruebas de integración generalmente ofrecen una buena visión general de los procesos de negocio