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"?
No hay comentarios:
Publicar un comentario