Hace una semana que compré sus screencasts sobre tdd y hace algo más de un mes que leí su "Implementation Patterns" (Previa recomendación de Xavi Gost en las cañas de la primera code retreat española). De los screencasts ya os hablaré otro día, hoy le toca al libro.
No voy a haceros un resumen, simplemente os diré que es un libro espectacular. Debería ser de lectura obligatoria en la carrera de informática junto con el "Clean Code" de Robert Martin :) Os recomiendo leerlo (176 páginas que se leen en un plis plas) pero, como es muy probable que mi recomendación no os baste, voy a tiraros la caña para que piquéis escribiendo las frases que más me han impactado. Vamos a ello.
[Decidí]Dejar de fingir que programo por instinto
Mis primeros pasos en esto de la programación fueron así. Hacía lo que yo pensaba (intuía) que estaba bien, pero en realidad no tenía ni idea. No tenía visión global, no pensaba en el usuario, iba a impulsos, no hacía pruebas automáticas, etc. Era un patán, una inconsistencia con patas. Y sin embargo, ¡Me parecía que hacía las cosas bien! Que barbaridad... No tenía ningún tipo de criterio.
Cuando empece a tomar conciencia de mi profesión (y en esto le debo mucho a Alfredo Casado) descubrí lo malo que era. Avergonzado, decidí empezar a aprender mi oficio y, no es que ahora sea la hostia, pero estoy a años luz de aquel paquete :D Espero que dentro de unos años vuelva a pensar lo mismo del paquete que os escribe ahora mismo, querrá decir que no me he estancado.
Los programas se leen más a menudo de lo que se escriben.
Espero que esto lo tengamos todos más que asumido. Hay que hacer código legible porque vamos a pasar más tiempo leyéndolo que escribiendo código nuevo. Sin embargo, cuando empiezas en esta profesión no eres consciente. En mi caso, no pensaba en el mantenimiento de mi programa porque, obviamente, una vez que lo hiciera funcionar nadie iba a volver a tocarlo :D Ahora, cada vez que me toca "enseñar" a alguien intento explicarle ésta necesidad y casi siempre me encuentro con lo mismo: "caras de pescao y culos torcios" ¿Nadie explica esto en las empresas o en las universidades?
Encontrar el nombre correcto es uno de los momentos más satisfactorios cuando se programa
Cuando empiezas a pensar en leer código más que en escribirlo se te plantea el problema de cómo nombrar una clase, un método, una variable... ¿Qué nombre representa mejor a esta clase? ¿Es lo suficientemente comunicativo? Para mi, es una de las partes más complicadas de la programación por eso, cuando consigues dar en el clavo, es de las más gratificantes.
Los programadores deben pensar, comunicar y aprender. Es parte de ser un profesional
Ser un profesional. Si queremos que nos tomen en serio como sector debemos empezar a tomarnos en serio nosotros mismos. Debemos empezar a ser profesionales. Para Kent Beck, los tres pilares de un programador profesional son
- Pensar: Programar es muy difícil. Si haces las cosas a la ligera lo acabaras pagando.
- Comunicar: Como ya he dicho antes, debemos empezar a hacer código expresivo, sencillo de leer y entender.
- Aprender: No anclarnos, no quedarnos obsoletos. Intentar mantenernos al día.
El mejor código para optimizar es el legible, modular y probado
Me gusta esta frase porque pone por delante de la optimización las pruebas y la legibilidad. Haz que funcione, ya harás que funcione rápido.
Espera a tener pruebas que demuestren que necesitas optimizar y optimiza entonces.
Haz que tu código funcione, decide después como debe estructurarse. Si gastas mucho tiempo estructurando tu código antes de escribirlo, tendrás que deshacer todo ese trabajo y rehacerlo de nuevo cuando aprendas algo durante la implementación
Código que funcione, código que funcione, código que funcione, código que funcione, código que funcione, código que funcione, código que funcione... ¡Hazlo! Deja el análisis y pasa a la acción. Pero recuerda, PIENSA.
[sobre los setters]Intenta entender que problema está resolviendo el cliente al asignar la variable.
Orienta tu código al dominio del cliente, no al contrario. En esta cita en concreto, Beck se refiere a los típicos métodos "set" que únicamente sirven para asignarle el valor a una variable. ¿Por qué necesita tu cliente hacer ese "set"? ¿Qué problema necesita resolver? Cuando empecé a programar nunca me hacía estas preguntas. Pasaba de mi cliente (Entendido como el programador que utilizaba mi código). El solo hecho de pensar en ellas te asegura un código mucho mejor.
Antes de añadir complejidad a un programa, asegurate de que dicha complejidad traerá beneficios
Manten tu código lo más simple posible. Muchas veces los programadores somos los que añadimos la complejidad a nuestro código sin venir a cuento. Si cuando estás programando te da la impresión de estar creando un código demasiado complejo párate a pensar en por qué está pasando eso. Puede que hayas perdido el foco y estés añadiendo funcionalidad innecesaria.
Algo que me ha ayudado mucho a mantenerme enfocado en el problema a resolver es TDD. ¡A tope con el TDD!
Con esto paro, que me veo comentando el libro entero y eso prefiero hacerlo delante de unas cañas. Yo pago la primera :P
