Me pregunta mi amigo E que si le puedo dar algún consejo para seguir completando su formación en el campo de la programación. E es un informático que ha terminado hace poco sus estudios. Aparte de su formación académica, últimamente ha realizado varios cursos en los que ha conocido distintos paradigmas de desarrollo y diferentes tecnologías y lenguajes.
Hemos intercambiado varias ideas durante una fructífera conversación, y al final, como suele ser habitual, creo que el que supuestamente tenía que dar los consejos (yo) ha salido más enriquecido de la conversación que mi amigo, gracias a la cantidad de información e ideas que me ha dado él a mí.
Sin embargo, no quiero dejar que se pierda un consejo que, este sí,
le he dado yo a él y sobre el que le he insistido mucho, y que considero
muy importante. Lo voy a poner en letras
gordas porque me parece muy importante:
LEE CÓDIGO FUENTE ESCRITO POR OTRAS PERSONAS
Muchas
veces, debido a las limitaciones inherentes al tiempo disponible
(cursos) o al espacio (libros), cuando nos explican una técnica,
lenguaje o herramienta, los ejemplos que nos presentan son "de juguete".
Esos ejemplos suelen ser suficientes para ilustrar alguna
característica concreta que se quiere destacar, pero en la mayoría de
las ocasiones no son realistas. Si pusiéramos ese código en producción,
posiblemente nos despedirían al día siguiente (y de manera justificada, seguramente). Lo más probable es que
tropezáramos con muchos problemas, ya que en esos ejemplos "de clase" o
"de libro" no suelen incluirse cosas que sí se dan en el mundo real.
Por
ejemplo, el control de entradas de usuario. En la vida real, un
programa debe estar preparado por si en un cuadro de entrada de texto un
usuario teclea cualquier dato con basura o, peor aún, con intenciones
dañinas (como inyectar código SQL, provocar desbordamiento de
buffers...). Los controles necesarios o más habituales en ese tipo de
casos norlamente no se explican en los ejemplos de libro, ya que muchas
veces lo que se quiere es ir rápidamente al meollo de alguna otra
cuestión. Excepción hecha de aquellos temas del libro o curso en los que
se quiere ilustrar, precisamente, cómo "sanear" las entradas del
usuario antes de proceder a procesarlas.
Por todo ello, y ya que
tenemos la suerte de tener chorropocientillones de líneas de código de
casi cualquier lenguaje disponibles en Internet en cientos de proyectos
grandes, medianos o pequeños (que también los hay interesantes), ¿por
qué no sacarles partido?
LEE CÓDIGO DE OTROS.
Quizás sea mejor comenzar con
proyectos pequeños, pues te puedes hacer una idea global de todas las
partes del proyecto con una o dos horas de lectura del código, y
seguramente veas estilos y formas de hacer las cosas diferentes de tus
costumbres. No quiere decir que sean mejores, pero a lo mejor te dan
ideas que no se te hubieran ocurrido antes. A mí me ha pasado: viendo
cómo otros han organizado datos o han creado estructuras o han hecho una
clase o una función para llevar a cabo una tarea, me he inspirado para
hacer algo parecido en mi código, refactorizándolo para dejarlo más
eficiente, más legible, más mantenible o, simplemente, más bonito, lo
que también tiene implicaciones en cuanto a mantenibilidad, legibilidad
y, en última instancia, autosatisfacción (a ver si sólo los artistas van
a poder buscar la belleza).
No es necesario tener controlado
totalmente el hábito de leer proyectos pequeños para pasar a leer código
de proyectos más grandes. Un buen recurso son los proyectos de código
abierto (open source) más exitosos, donde su propio éxito es una
garantía de que encontraremos código escrito de manera profesional, y
seguramente bien estructurado y modularizado. Esa modularidad nos
permitirá dedicarnos a leer una parte pequeña de ese proyecto y
encontrarle utilidad "per se", sin tener que leer y mucho menos
comprender el proyecto entero. Así que, insisto: lee (trozos de) código
de proyectos grandes.
--
¿Y tú, has aprendido mucho leyendo código
fuente de proyectos reales, o todo lo que sabes se lo debes a los
ejemplos "de juguete"?
