Barrapunto

Quizá es demasiado para un novato, pero yo recomiendo leer el código de Active MQ [apache.org], que es la implementación de JMS [sun.com] de la fundación Apache [apache.org]. Podrías empezar leyendo por encima la especificación de JMS, despues le echas un vistazo a lis interfaces que se definen en javax.jms y luego te lees la implementación que han escrito en org.apache.activemq.

Recomiendo leer la implementación "de fuera a dentro", es decir, empezando por las clases que implementan los interfaces de la librerí para luego ir profundizando.

¡Suerte!

Pero salió algo parecido en Slashdot: Tools for understanding code? [slashdot.org]

Te recomiendo empezar por tu propio código: usa módulos open source en tus aplicaciones, tracea su funcionamiento usando un debugger y su código fuente, etc. Esto te permite ver qué hace el código "en vivo", mientras lo vas leyendo.

Otra posibilidad es leer el código fuente de las librerías de un lenguaje, p. ej. Java o Python, que suele estar claramente documentado e implementado: ayuda mucho ver una buena implementación de una lista enlazada, una tabla hash y otras estructuras típicas de la programación.

Leer aburre. Creo que la mejor forma de leer un código es teniendo que modificarlo, para así entender mejor lo que hace.

Por lo menos a mí me sucede así que soy de atención dispersa. Empieza por algo que te interese modificar, aunque sea una chorrada. El primer proyecto medio grande que leí era un juego [thangorodrim.net]. Meterle mis modificaciones fue mi manera de leerlo, y leyéndolo aprendí más que en dos asignaturas de la carrera.

Me parece una mala idea intentar aprender a programar leyendo código ajeno.

Por un lado, intentar entender cómo pensó otro programador es complicadísimo, y por otro lado, te tentará a copiar en lugar de crear y nunca te acostumbrarás a crear tus propios programas.

Para mi lo idel es leer un buen manual, donde figuren las funciones más usuales y sus parámetros, seguidas de un ejemplo. Normalmente te bastará con ver el ejemplo para entender para qué sirve.

Una vez hayas dado una leída general para enterarte de qué hay disponible, lo que yo te aconsejaría es que te sientes a hacer algo concreto. Ahí irás viendo las necesidades y como ya has leído el manual, tendrás una idea de qué funciones pueden existir para solucionar tal o cual problema. Entonces es el momento de buscar en el manual y, si te hace falta, dar una leída más en profundidad a la descripción de esa función en particular.

Y un consejo importante: no se trata de aprender a programar en C o en Java o en Python: se trata de aprender a programar. O sea, esa manera de pensar y de ingeniárselas para resolver algo. El lenguaje te dará más o menos herramientas pero la programación en sí es la misma.

Para empezar, leer codigo no es ni sencillo ni divertido, asi que si vas a hacerlo (y es muy bueno hacerlo), usa el mismo principio que para empezar/colaborar en un proyecto: que te interese por la razon que sea, no por obligacion.

Lo segundo ya lo ha dicho McPolu antes, empezar de fuera hacia dentro. Empieza por la funcionalidad a alto nivel, mira que parte del programa implementa esa funcionalidad, vete mirando funcion a funcion cada una de las llamadas para ver que hace, si algo no te interesa, dejalo de momento y continua por algo que te llame mas la atencion... seguramente llegara un momento en que para entender una parte necesites saber que pasa en la anterior, es en ese momento cuando puedes ver el codigo que te has saltado.

Dependiendo del lenguaje o la plataforma, te sera de mucha ayuda ver el codigo en ejecucion, a veces, mientras lo ves en funcionamiento, entiendes decisiones que sobre el papel son dudosas, nada como ver en vivo como vienen los problemas y como los ha solucionado alguien para aprender. Para esto, un buen debugger es necesario.

El cuarto cnsejo es que modifiques el codigo, preguntate que pasaria si en vez de hacer A, haces B, que efecto tiene eso en el funcionamiento del programa... e intentalo, a ver que ocurre.

Un sitio por donde podrias empezar a mirar codigo es Krugle [krugle.org], un buscador de codigo en proyectos libres. La ventaja es que puedes ir directamente a areas que te interesen sin necesidad de navegar por miles de lineas de codigo.

El tiempo que te tires leyendo código lo retabilizarás muchísimo más si lees patrones de diseño, buenas prácticas de programación, textos sobre acoplamiento, complejidad ciclomática, etc. Algunas metodologías como XP también tienen reflexiones interesantes sobre código.

Mis primeros profesores de programación en la Universidad fueron bastante pésimos. Al final terminé aprendiendo C porque me enganché al Angband, un roguelike.

Primero me dedicaba a traducirlo (las cadenas estaban hardcodeadas), y después quise agregar mis propias razas.

Como los vampiros y trolls no soportan la luz del sol, tuve que bucear por el código para poder controlar si estabas en la superficie durante el día. Es más, también fue necesario que esas razas aparecieran en el juego 12h más tarde, para que se frieran en el primer turno (se empezaba en la superficie). Como al final necesitabas volver al pueblo, tuve que implementar un comando para consultar la hora (haciendo conversiones de días, horas, minutos y segundos respecto a los turnos).

Además, no pegaba mucho que un vampiro pudiera beneficiarse de las "bendiciones", así que se hicieron versiones alternativas de los hechizos para personajes malignos (bendecir, protección contra el mal, etc).

Más tarde, los personajes buenos se podían hacer malos si mataban muchos inocentes. También ciudades subterráneas que aparecían de vez en cuando y que eran iguales en todas las partidas (la semilla aleatoria era el número de nivel).

En fin, que enganchando una cosa con otra aprendí un huevo. Puedo decir sin pudor que dicho juego fue mi profesor de programación (y uno de los mejores). Y, sobre todo, lo que me divertí haciéndolo.

Perdonad la batallita. Respecto a la pregunta, la clave estuvo en elegir un tema que me gustaba, y en el que los cambios eran bastante tangibles. También es un tipo de programa que tiene unas estructuras muy comprensibles para la imaginación, y más este tipo de juego. No es de extrañar que este tipos de juegos, los roguelikes, sean los más proclives a los forks eternos, y existan trillones de variantes.

Y la técnica usada fue el buscador de Windows (sí, entonces el 95 era el sistema que usaba), para buscar texto en los archivos y adivinar dónde se tocaba.

Otras veces he intentado meterme en proyectos, como en el gimp, pero los conceptos me han resultado más áridos y abstractos, y me he aburrido antes de llegar a meterme de lleno.

No nos dices qué lenguaje te interesa, y así es difícil dar detalles. También sería conveniente conocer el campo que más te interesa, que no es lo mismo la programación gráfica que el desarrollo web.

Empieza a leer en el método main() :-D

Si te interesa PHP te recomiendo que hagas alguna aplicación que te interese y en lugar de hacer todo a mano, te agarres classes de http://www.phpclasses.org/ [phpclasses.org]. Esto tiene varias ventajas:

1.- Las clases de esa pagina, también están hechas en PHP, por lo que siempre podrás meterte a entender y modificar el funcionamiento de las mismas sin el overhead de aprender otro lenguaje (como Phyton con librerias de C y de además precompiladas).

2.- Casi siempre son pequeñas y realizan funciones muy especificas, por lo que no será difícil entenderlas.

3.- Son modulares y orientadas a objetos, así que de entrada aprenderás buenas practicas de programación, posteriormente te quedará la costumbre de hacer todo modular.

La primer herramienta de código abierto a la que tuve que meterle el diente fue Snort [snort.org]. Lo que hicimos fue:
1. Leer la documentación de usuario (que no necesariamente las de desarrollador también). Aunque parezca obvio no todos lo hacen
2. Empezar a depurar desde el hilo principal
3. Documentar en diagramas de secuencia, estados o flujo según aplique. De esta forma te servirá de referencia y lo podrás publicar para ayudar a otros
Probablemente sólo te sirva para aplicaciones de escritorio o "locales", y no para web, pero es un inicio.

algún fragmento pequeño de algo de lo que conozcas su funcionamiento, y que esté en el idioma que necesites.

no es necesario que sea extremadamente pequeño, ni conozcas su funcionamiento hasta el último detalle ya de antemano, ni esté exactamente en el idioma que necesites. pero cuanto más próximo estés a esas condiciones, más placentero será todo.

un modulillo de 1000 lineas de apache, una extensión de firefox que haga algo poco espectacular, algún pequeño driver ... seguro que se te ocurren ejemplos mejores.

¿Empezar por el principio? Personalmente yo empiezo por leer la API y enterarme de que clases y métodos usaré. Con esa referencia se puede empezar a navegar por todo el resto del código (que me lleva a clases que usaré del segundo nivel en adelante). Si estás leyendo una aplicación, empieza por el método o procedimiento main().

Si no sabes por donde empezar es porque no has programado suficiente.

A mi me interesa algo parecido, y tengo especial interés en Bases de Datos, y cuestiones relativas a temas científicos: Astronomía, Física, etc,...

Aqui tienes Ejemplos para varios lenguajes de programación [wikibooks.org]
De nada ;-)

.. leeras un monton de codigo que no entenderas, sin documentación y con unos plazos cortitos. Asi aprendes seguro.

1. Sí, es buena idea. Muy buena.
2. Creo que el código de Vim era interesante.
3. Pero en cualquier caso y como ya te han dicho, busca algo que te interese.
4. Y sobre todo algo que te sirva modificar.

Como dicen por ahí, mejor aprender algoritmia, tecnología de la programación, patrones de diseño, ingeniería del software...

Leer buen código puede servir para sacar algunas ideas, pero leer un mal código puede ser perder el tiempo, o hasta contraproducente.

Digo esto porque el toda empresa, en todo proyecto, ya sea código abierto o cerrado, hay auténticos sacrilegios a las buenas prácticas en programación. El que sea GNU o de la fundación apache no tiene que garantizar que el código sea bueno.

Yo me he encontrado barbaridades del calibre de hacer a=a/0; para lanzar una excepción (¿para qué coño existe el "throw"?), y te hablo de proyectos medianamente grandes de empresas bastante importantes.

... porque hay cada porquería por ahí escrita como para caerse de culo (me incluyo entre los autores de estas porquerías).

Incluso en proyectos y paquetes de software "importantes" te encuentras código enmarañado y diseños cuestionables.

Se me viene a la cabeza Wordpress ...

Antes de mirar código de otros ¿no sería mejor escoger qué lenguaje y para que va enfocado?

Aunque las reglas básicas se hacen casi siempre igual dentro de un mismo paradigma de lenguaje, no siempre hacer las cosas "bien" es lo mejor.

Ejemplo, no es lo mismo programar para un microcontrolador con 8k de "espacio" y 256bits de RAM, que para una aplicación web o para el kernel.

El tema está más bien en que luego, en el proyecto que te encuentres intentes seguir la "estructura" del código que ya hay. Aunque parezca mentira, salvo en códigos muy churrusqueros, acaba siendo la mejor forma para comunicarte con el resto de desarrolladores del proyecto.

Bueno eso y mantener los comentarios de tu código actualizado.

En dos palabras: Bell Labs.

El código de plan9 es una obra de arte, el de inferno tampoco está mal (aunque sea Limbo) y el del UNIX original no tiene desperdicio. Se trata de código muy claro, elegante y sencillo.

Si quieres aprender, lo mejor es aprender de los grandes maestros...

Está claro; para empezar a enterarse de algo, deberíamos empezar por la documentación. Porque todo el mundo documenta sus aplicaciones en documentos de desarrollo aparte, y no sólo mediante comentarios dentro del código, ¿verdad?