abstract business code coder

97 Things Every Programmer Should Know y la importancia de no empezar desde cero

Este será el segundo post de mi serie sobre libros que he leído. De este post lo pude hacer gracias a las notas que había tomado mientras lo iba leyendo, así que aunque no tuve mucho tiempo para planear, tampoco tuve que empezar desde cero y eso me permitió poder siempre tener un post para hoy. Esa es la gran ventaja de tener una base de conocimiento externa, un tema que trataré en un próximo post.

97 Things Every Programmer Should Know: Collective Wisdom from the Experts – Kevlin Henney, 2010

Este libro también lo compré en un HumbleBundle de O’Reilly, por lo que me tuve en precio muy barato. El libro es una recopilación de consejos de diferentes expertos de diferentes áreas de desarrollo, sobre cosas importantes que consideran que todo programador debería saber. Estos consejos van desde temas muy técnicos hasta consejos de vida y soft-skills. Cada consejo representa un “capitulo” del libro, y se extiende entre dos y tres paginas.

Creo que mi mayor critica a este libro es que si bien los consejos en su mayoría son útiles, no hubo como un acuerdo general de cual debería ser el alcance, nivel técnico o estilo de redacción estándar para todos los capítulos. Así que el libro termina teniendo capítulos sobre detalles sumamente técnicos que prácticamente ya no son tan necesarios en tecnologías modernas, seguido de un capitulo donde se nos cuenta una anécdota, seguido de otro capitulo super general sobre project management. Además algunos capítulos son redundantes con capítulos anteriores, o expanden sobre el mismo tema, lo cual hubiera sido mejor en un solo capitulo.

Los siguientes son los principales puntos a rescatar del libro a mi parecer:

  • Cada linea de código debe tener un propósito claro. Seguir este principio ayuda a reducir código necesario o a dividir código que no es claro
  • La regla de los Boy Scouts también aplica al código: Siempre dejar el código que uno modificó en un mejor estado de como uno lo encontró
  • La regla del 1%: En cada cambio que se haga agregar un prueba unitaria, un refactor, o un comentario. Una mejora de un 1% es pequeña, pero haciéndola todos los días se acumula y produce resultados enormes a medio y largo plazo
  • Diseñar los métodos de un objeto teniendo en cuenta la facilidad de quien lo usará, no de quien lo codificará. Por ejemplo si un usuario del código tiene que hacer dos llamados seguidos siempre para hacer una operación, eso se pudo haber prevenido si solo un método estuviera expuesto que internamente se encarga de todo
  • Aprender nuevos lenguajes le ayuda a uno a aprender nuevas técnicas y patrones que pueden ser usados en todos los lenguajes
  • Tener un experto gurú es peligroso porque la gente se confía en que esa persona todo lo podrá solucionar, entonces le satura con preguntas o problemas sin haber hecho ningún intento de solucionarlo antes. Tener personas con más experiencia y/o conocimiento técnico es natural, lo que se debe hacer es asegurarse que ese conocimiento se distribuya a todo el equipo
  • Siempre es bueno conocer las herramientas de consola y no solo el IDE. Las herramientas de consola permite extender y automatizar procesos y tareas, además que normalmente son más rápidas que un IDE con interfaz gráfica
  • Programar es un trabajo que es mitad lógico y mitad creativo, por eso es necesario a veces tomar un break para desbloquearse y tomar perspectiva ante los problemas
  • Contrario a lo que se enseñan, el objetivo principal de un code review no es encontrar errores. Esto le ha dado una connotación negativa a una gran herramienta en el proceso de desarrollo. El objetivo de un code review es en realidad el compartir conocimiento: la persona que revisa comparte conocimiento sobre mejores formas de hacer las cosas, y la persona que hizo el código comparte su trabajo para evitar silos de información
  • No hay que tenerle miedo a borrar y volver a empezar. Código mal hecho que debe ser modificado puede ser fuente de más errores y problemas que se pudieron evitar empezando desde cero. Lo mismo aplica cuando uno tenia una idea de como hacer algo pero debe cambiarla por motivos de rendimiento o estabilidad
  • Hacer commits pequeños da la libertad de poder experimentar con refactor y alternativas de cambios sin tener miedo de que no se puede deshacer porque va perder trabajo ya hecho
  • Todas las mejores practicas y aprendizajes no valen nada si no se tiene la actitud para hacer el esfuerzo que implica seguirlas. Y esa actitud se resumen en tratar el código como si uno fuera responsable de darle mantenimiento de por vida, aun ya estando en otros trabajos o proyectos

Esos serian los puntos más importantes de los 97 que contiene el libro. Si tienen algún comentario sobre esta lista o sobre el libro, por favor déjenla en los comentarios. Tambien estoy pensando hacer sesiones por Zoom para comentar los libros que he comentado en los post. Si tienen interes de participar por favor diganme en los comentarios o en mi Twitter @juanfrandiaz.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.