viernes, 14 de febrero de 2014

Fundamentos de la filosofía Unix

Recientemente he estado ojeando un libro (el último hasta la fecha) de Eric S. Raymond, autoproclamado hacker (en el sentido clásico, no confundir con cracker) portavoz del movimiento open source y antropólogo de la subcultura hacker alrededor de Unix e Internet (no en vano es desde hace años editor del Jargon File, publicado en papel como New Hacker's Dictionary). Se trata de la obra titulada "The Art Of Unix Programming" (disponible en PDF buscando un poco en Google).

El libro es muy recomendable (al menos algunas de sus partes, otras pueden ser demasiado técnicas y/o filosóficas) para cualquiera interesado en los sistemas Unix (incluyendo sus descendientes modernos como Linux y FreeBSD) y la filosofía y principios de diseño que se destilan de su legado de más de 40 años. Además puede ser de interés para cualquiera dedicado al desarrollo de software, ya que del mismo pueden extraerse numerosas enseñanzas y reflexiones valiosas a la hora de diseñar un programa, no sólo para entornos tipo Unix.

Como muestra, quería traducir el conjunto de reglas que según el autor resumen los fundamentos de la filosofía Unix a la hora de escribir programas y que pueden encontrarse en su primer capítulo. Espero que "iluminen" a alguien:
  1. Regla de la Modularidad: escribe partes sencillas conectadas por interfaces limpias.
  2. Regla de la Claridad: la claridad es preferible al ingenio.
  3. Regla de la Composición: diseña programas para que puedan conectarse a otros programas.
  4. Regla de la Separación: separa las políticas de los mecanismos para aplicarlas.
  5. Regla de la Sencillez: diseña con la sencillez como objetivo; añade complejidad solo cuando sea necesario.
  6. Regla de la Parsimonia: escribe un programa grande cuando esté claro que nada más funcionará.
  7. Regla de la Transparencia: diseña con la visibilidad como objetivo para facilitar la inspección y la depuración del código.
  8. Regla de la Robustez: la robustez es hija de la transparencia y la sencillez.
  9. Regla de la Representación: incorpora el conocimiento a los datos para que la lógica del programa pueda ser estúpida y robusta.
  10. Regla de la Mínima sorpresa: al diseñar la interfaz de usuario haz siempre lo menos sorprendente.
  11. Regla del Silencio: cuando un programa no tenga nada interesante que decir no debería decir nada.
  12. Regla de la Reparación: cuando un programa deba fallar, que lo haga ruidosamente y cuanto antes.
  13. Regla de la Economía: el tiempo de un programador es caro; ahórralo en lugar del tiempo de la máquina.
  14. Regla de la Generación: evita las soluciones manuales; escribe programas para generar programas cuando sea posible.
  15. Regla de la Optimización: prototipa antes de perfeccionar. Haz que funcione antes de optimizarlo.
  16. Regla de la Diversidad: desconfía de cualquiera que asegure que solo hay una forma correcta.
  17. Regla de la Extensibilidad: diseña para el futuro porque llegará antes de lo que piensas.