Reglas de Programación – Eric S. Raymond
Publicado por Iván Gajate el 1 de febrero de 2009 en Desarrollo Web | 4 comentarios »
He encontrado este escrito traducido de Eric S. Raymond, que me ha encantado.
El artículo se lee muy bien, es muy ameno pese al tema del que trata y cuando se escribió (hace mas de 10 años), y cuenta el desarrollo de un proyecto de software desde su concepción, sacando algunas conclusiones durante el camino a las que irónicamente estoy llegando yo también en las últimas semanas 😀
Hay que leerse el artículo, pero copio aquí las lecciones con las que estoy más de acuerdo:
- Los buenos programadores saben qué escribir. Los mejores, que reescribir (y reutilizar).
- Contemple desecharlo; de todos modos tendrá que hacerlo.
Este me encanta, estoy en pleno proceso de “borrón y cuenta nueva”.
[…] no se entiende cabalmente un problema hasta que se implementa la primera solución. La siguiente vez quizás uno ya sepa lo suficiente para solucionarlo. Así que si quieres resolverlo, disponte a empezar de nuevo al menos una vez. - Cuando se pierde el interés en un programa, el último deber es heredarlo a un sucesor competente.
Que gráaandeeee (y utópico) - Libere rápido y a menudo, y escuche a sus clientes.
Pruebas, pruebas y mas pruebas. Con datos reales y desde el primer día. Es la única manera de que no haya sorpresas al final.
Lo que lleva de cabeza a la 8: - con muchas miradas, todos los errores saltarán a la vista.
[…] más usuarios detectan una mayor cantidad de errores. - Lo más grande, después de tener buenas ideas, es reconocer las buenas ideas de sus usuarios. Esto último es a veces lo mejor.
Siempre hay que pensar en el usuario. Si no, ¿para qué estamos haciendo un programa?. - Frecuentemente, las soluciones más innovadoras y espectaculares provienen de comprender que la concepción del problema era errónea.
Cuando usted se topa con un muro durante el desarrollo […] es, a menudo, la hora de preguntarse no si usted realmente tiene la respuesta correcta, sino si se está planteando la pregunta correcta. Quizás el problema requiere ser replanteado.
Y volvéeemos a la 3 😉 - La perfección (en diseño) se alcanza no cuando ya no hay nada que agregar, sino cuando ya no hay algo que quitar.
Cuando el código va mejorando y se va simplificando, es cuando sabe que está en lo correcto.
Cuando tengo archivos de clase muuuy largos o excesivamente cortos, me pregunto si lo estaré planteando bien. - Toda herramienta es útil empleándose de la forma prevista, pero una *gran* herramienta es la que se presta a ser utilizada de la manera menos esperada.
Tengo algunos componentes que de lo flexibles que son, me encuentro utilizandolos para cualquier cosa que no pensé que sirvieran.
