El libro 97 things every programmer should know contiene 97 pequeños consejos y prácticas que como desarrolladores deberíamos aplicar a diario en el desarrollo de software. En su blog, Brian Du Preez destaca 9 consejos en particular que le resultaron de interés. Veamos cuáles son...
1. La regla del Boy Scout (por Robert C. Martin, Uncle Bob)
"No es necesario hacer que cada módulo sea perfecto antes de subirlo al repositorio de código. Simplemente basta con hacer que sea un poquito mejor que cuando lo bajamos".
Nos resulta fácil decirnos cosas como "Ya estaba así", o "ese código horrible está así desde hace años, no voy a tocarlo", o "nunca tuvo pruebas". Si parte de nuestro proceso fuera hacer las cosas un poquito mejor (como borrar código que no se usa, o escribir una prueba unitaria), año tras año... lograríamos ahorrar mucho tiempo y dinero a muchas personas.
2. La belleza está en la simplicidad (por Jørn Ølmheim)
"Al final, el código hermoso es el código simple"
Con los años esto me resultó muy importante. Cuando empecé esta carrera, y especialmente cuando tenía que comenzar algo nuevo, me embarcaba en crear los mega-diseños. Era algo como "Bienvenido a la escuela de la sobre-ingeniería", todo sería una abstracción al décimo nivel, y habría patrones de patrones, interfaces para las abstracciones y enormes cantidades de código y componentes que se encargaban de cualquier "qué pasaría si" que podría existir, y que sólo yo comprendía. Todo esto llevaba a código muy "atractivo", y aumentaba mi ego, ¿pero a qué costo?
Sólo había un pequeño detalle: mantenerlo era una pesadilla. Desde entonces prefiero la implementación más simple para casi cualquier solución, incluso aunque no parezca la mejor implementación técnica. En el mundo del software, la mantenibilidad siempre debería pesar más que otros temas.
3. Detenete y automatizá, automatizá, automatizá (por Cay Hosrtmann)
Debemos automatizar todo lo posible: construcciones, despliegues, análisis de código, pruebas unitarias, pruebas funcionales, pruebas de integración. Nadie quiere mirar estas cosas todos los días y la automatización es la única forma de alejarnos de esto. No podemos automatizar demasiado. Automatizá, automatizá, automatizá.
4. Aprendizaje continua (por Clink Shank)
Este es un tema muy importante, estamos en una industria de constante crecimiento y cambio, y como programadores necesitamos estar aprendiendo y mejorando siempre que podamos. Es fácil caer en la zona de confort y descansar sobre los laureles. Algunas cosas que recomiendo:
- Lean libros.
- Usen Google Reader y agreguen blogs populares y feeds RSS de sitios web para temas específicos de su interés, además de agregar algunos otros temas que no sean de su interés particular.
- Creen un blog, y traten de publicar algo 1 -2 veces por semana, asegurándose que sea cosas nuevas que aprendieron.
- Únanse a alguna comunidad de software libre, en general no tenemos suficiente desarrollo "técnico" en los ambientes corporativos.
5. Antes de culpar a otros verificá tu código (por Allan Kelly)
Como dice el título, tendemos a buscar la culpa en cualquier cosa excepto nuestro código "perfecto". Desde el sistema operativo hasta la red, desde la base de datos hasta la JVM, desde librerías hasta las interfaces de otros equipos. Esto nos lleva a horas y horas de esfuerzo desperdiciado, o ignorar por completo el problema real que eventualmente volverá a molestarnos. La mayoría de nosotros puede recordar momentos en los que hicimos esto... y es tan frecuente que asusta.
6. El trabajo duro no vale la pena (por Olve Maudal)
"La verdad es que trabajando menos podemos lograr más"
"Si tratás de estar enfocado y "productivo" por más de 30 horas a la semana, seguramente estás trabajando demasiado"
Una gran frase de Olve Maudal. Muchos de nosotros ya pasamos por esto, gastamos días, semanas meses de trabajo, pero no solemos ver los efectos negativos que ocurren después de trabajar 50-70 horas por semana. Desde la lógica común hasta la motivación y la dinámica del equipo, todo esto sale por la ventana. Incluso aunque se logren los objetivos a corto plazo, a menudo las repercusiones a largo plazo son mucho peores. Nadie revisa porqué hay que re-escribir después de 4 años debido a que la arquitectura o el código nos sirven. Me encantaría saber cuántas de estas situaciones son por trabajar una cantidad ridícula de horas con tiempos imposibles. Puede haber alguna ocasión donde sea necesario un par de horas extras, pero debemos mantener esto al mínimo.
7. Comentar sólo lo que el código no dice (por Kevin Henney)
Lo que dice. No le contemos a otro programador lo que puede saber leyendo el código. Los comentarios tienen que explicar el motivo de negocio detrás de un algoritmo en particular, lo cual es mucho más útil que un //sumar 1
8. Conocer al IDE (por Heinz Kabutz)
Pasamos varias horas con nuestro IDE. Aprender los atajos, las características que tiene... usar el IDE con todo su potencial nos puede ahorrar incontables horas.
9. Aprender a estimar (por Giaovanni Asproni)
Si bien esto es algo que viene con la experiencia, podemos hacer cosas para mejorar esta habilidad. Algunos puntos para mejorar nuestras estimaciones:
- Sean honestos con ustedes mismos, digan lo que saben y admitan abiertamente lo que no.
- Tengan presente lo que hacen y cuánto les lleva, no necesariamente para el líder del proyecto sino para ustedes mismos. Sean honestos con ustedes mismos.
- No cuenten las estimaciones ni habilidades percibidas de otras personas. Sean honestos con ustedes mismos.
