Reglas de Programación – Eric S. Raymond

Publicado por Iván Gajate el 1 de febrero de 2009 en Desarrollo Web

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 :D

Hay que leerse el artículo, pero copio aquí las lecciones con las que estoy más de acuerdo:

  1. Los buenos programadores saben qué escribir. Los mejores, que reescribir (y reutilizar).
  2. 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.
  3. Cuando se pierde el interés en un programa, el último deber es heredarlo a un sucesor competente.
    Que gráaandeeee (y utópico)
  4. 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:
  5. con muchas miradas, todos los errores saltarán a la vista.
    [...] más usuarios detectan una mayor cantidad de errores.
  6. 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?.
  7. 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 ;)
  8. 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.
  9. 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.

 

4 comentarios para “Reglas de Programación – Eric S. Raymond”

  1. Palabra :)

  2. Si. Tenemos que poder aplicarlos sin cambiar nuestro ritmo de trabajo que si no no interesa.
    Pero el de Contemple desecharlo, de todas maneras tendrá que hacerlo, voy a imprimirlo y a ponerlo sobre el monitor porque es un hecho, al final tienes que desecharlo, pues mejor cuanto antes no? ;)

  3. Di que estoy de acuerdo con todo, pero cuando veo los timming que me salen con estos preceptos en la cabeza… algo me dice que al cliente no le va a gustar :)
    Pero no pasa nada.. me convierto en anarcocapitalista como el Eric este (en todo lo demás que dicen en Wikipedia que es no, que me da mucho más miedo que el anarcocapitalismo per se…) y ya no me importa. Este año todo proyecto que se haga tiene que estar mejor hecho que el anterior… pero empiezo por el próximo, que los de ahora se entregan en breve… ¿vale?….