Leyes del código fuente y el desarrollo de software

Leo en Juixe TechKnow una lista muy acertada de “leyes” que el autor considera imprescindibles a la hora de escribir código fuente. Les dejo a continuación mi humilde traducción de cada uno de los puntos tratados en el post original, con unos pocos agregados y modificaciones:

  • Las líneas de código comentado no son comentarios – Usa control de versiones, no lleves un registro de los cambios del código comentándolo. El código comentado es código esquizofrénico.
  • Deja que tu reputación te preceda – Si trabajas en proyectos de código abierto, blogueas y mantienes una buena red de contactos, conseguirás más ofertas que aquellos que sólo envían currículums por mail para buscar trabajo.
  • No des excusas por tu código, déjalo hablar por si mismo – Te pagan para encontrar soluciones usando código, no busques excusas para el mismo. “Funcionó en mi máquina” no es una solución, el cliente no usará tu computadora para correr la aplicación.
  • No tomes las críticas a tu código como algo personal - No se trata de tí, sino de una característica de negocios y de la performance de toda la aplicación.
  • Tu código es el legado de tu carrera - Aquellos que mantengan tu código una vez que lo hayas dejado, te maldecirán o te agradecerán.
  • Escribir código no es lo mismo que programar - Escribir código no es igual a desarrollar software; lo primero requiere pensar y ser creativo mientras que en el segundo caso esto no siempre es necesario.
  • Escribir código implica aprender - La ley de Moore establece que la tecnología se “duplica” cada 18 meses, hay que mantenterse actualizado. Si no aprendes nada es que estás haciendo algo mal. Cada proyecto es una oportunidad para aprender.
  • Escribir código es comunicar - Muchos leerán el código que escribiste. Usa buenas prácticas así como patrones de diseño conocidos. Esfuérzate por la simplicidad antes que por impresionar, tu código debe comunicar clara y consistentemente su propósito.
  • Las herramientas no hacen al desarrollador - Conoce a fondo tus herramientas y úsalas con su máximo poder, pero no permitas que se conviertan en tus muletas. Trabajar con diferentes IDEs no debería detenerte sólo porque no encuentras el asistente de generación de código que necesitas.
  • No confíes en tu código - Confiar en tus habilidades al codificar no remplaza la necesidad de realizar tests. No confíes en tu código. No confíes en tus suposiciones. No confíes en los usuarios.
  • El código no está escrito en latín - El código no muere una vez terminada la aplicación, tiene que ser refactorizado, modificado y reusado. El código tiene que evolucionar. Tu mayor fortaleza no radica en escribir montañas de nuevas líneas de código, sino en mantener, refactorizar y reagrupar código existente según las exigencias y las especificaciones de la aplicación.
  • Respetar la API – Tu API es un contrato del que otros dependerán. Mantén la API limpia y explícita. Mientras menos métodos expongas, menos testeo, mantenimiento y documentación serán necesarios.
  • El código significa cosas diferentes para diferentes personas - En última instancia, para los usuarios finales el código simplemente es la habilidad de poder hacer lo que ellos esperan.

Agrego un par de “mi cosecha”:

  • No te cases con un lenguaje o tecnología – Hoy en día existen muchísimos lenguajes, frameworks y soluciones disponibles para diferentes finalidades. A la hora de desarrollar una nueva aplicación, es mucho mejor elegir el lenguaje o la tecnología apropiada para ella, antes que intentar adaptar lo único que conoces al propósito del proyecto.
  • No mates mosquitos con bombas H – Esto es un corolario del anterior punto. Nunca sobredimensiones las necesidades de una aplicación sólo porque no sabes cómo utilizar la herramienta adecuada, en vez de eso, aprovecha la oportunidad de aprender. De esta forma no sólo harás un mejor desarrollo, sino que también se incrementarán tus conocimientos.

Aclaro que varios puntos fueron levemente modificados e incluso uno fue completamente removido, ya que no me pareció relevante incluirlo. Estoy seguro de que los incluídos son suficientes y están traducidos de forma clara y concisa, si piensas al contrario, ¡házmelo saber!

Vía: Juixe TechKnow | Laws of Source Code and Software Development

Tags: , ,

This entry was posted on Friday, May 8th, 2009 at 6:33 am and is filed under Programación. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Leave a Reply