97 Things every programmer should know
Kevlin Henney
Libro que es un compendio de pequeños artículos, sí en concreto 97, en el que distintos "expertos" exponen diferentes aspectos de la programación. Son artículos cortos y superficiales, por lo que es un libro fácil de leer.
Y a continuación las notas que tomé:
- Postponer la resolución de un problema a un problema posterior suele ser una mala práctica, ya que la resolución puede ser aún más compleja. Como mal menor, apuntarlo en la lista de TODO para que no se olvide.
- El conocer la programación funcional puede ser de mucha utilidad para evitar problemas con referencias.
- Los usuarios finales no piensan como los programadores. Se aprende mucho pasando una hora viendo cómo trabajan los usuarios, qué tipo de cosas hacen.
- Las reglas de desarrollo deben seguirse y no relajarse, llegando a evitar subir código al repositorio si no cumple las reglas.
- Hay que hacer código simple, aunque la aplicación sea muy compleja.
- Cuidado con las refactorizaciones de código. El viejo código puede no ser elegante, pero funciona. No se puede tirar a la basura el conocimiento y horas usadas para conseguir ese viejo código.
- No todo debe reutilizarse. En ocasiones es mejor duplicar código para evitar crear dependencias.
- Implantar revisiones de código donde todo el equipo esté involucrado y no exista o parezca existir un equipo de élite que juzga a los demás.
- El mejor comentario es el que no hace falta, ya que el código es autoexplicativo.
- El peor comentario no es el que falta, sino el que existe y es incorrecto.
- Aprender otros lenguajes es útil ya que nos dará ideas de cómo afrontar problemas desde otras perspectivas. Será doblemente útil si son lenguajes pertenecientes a distintos paradigmas (procedimentales, orientado a objetos, funcionales, lógicos, ...).
- Trabajar en proyectos open-source es una buena forma de aprender mucho.
- Un gurú puede tener mucho conocimiento, pero necesitará de un contexto para poder ayudar.
- La formación continua es parte del trabajo de un programador.
- Si quieres que alguien pruebe tu producto, da todas las facilidades: descarga sin pasos intermedios, incluir guía rápida de uso, documentación, ejemplos, ...
- Un algoritmo eficiente parecerá malo si las comunicaciones son malas.
- Los IDEs nos hacen más productivos pero nos ocultan qué estamos haciendo realmente. Con las herramientas desde línea de comandos, somos más conscientes de lo que está sucediendo.
- Los build debe codificarlos el equipo de desarrollo.
- Automatizar todo lo posible, ya que al final se ejecuta más veces de lo que suponíamos.
- Escribe código como si tuvieras que mantenerlo durante el resto de tu vida.
Mi calificación: 7
