Resumen de Clean Code - tercera parte

Vamos con los ultimos temas teoricos de clean code:

Capitulo 9: Unit Tests

Como me gusta este capitulo!, un libro sobre buenas practicas tiene que hablar sobre buenas practicas de código de test, y casi ninguno lo hace. Hace algo menos de dos años que comenzamos a trabajar usando seriamente unit testing, primero haciendo test depues de escribir el código, y ultimamente vamos consiguiendo escribirlos primero y hacer TDD, cuesta mucho el cambio de mentalidad pero esta es la practica que, con mucha diferencia, más a contribuido a que mejore como programador. Si quieres hacer algo para mejorar como profesional mi recomendación es que pongas al unit testing y al TDD los primeros en tu lista, por delante incluso de aprender nuevos lenguajes y muy por delante de aprender el nuevo framework pepito que piden en las ofertas de trabajo.

La recomendación más importante que se ofrece sobre los test es tomarse el código de test en serio, es decir, el código de test no es un código de segunda categoria, si aplicas X practicas en tu código de producción aplicalas también en el código de test!, no caigas en el error de "como es un test vale todo". Y lo digo desde la experiencia de caer en este mismo error cuando empezamos a escribir pruebas, pruebas que a los dos meses no hay quien entienda ni quien mantenga y que lo que hacen más que mejorar la calidad de desarrollo es ralentizarlo por el costo de mantenerlos.

El tio bob también habla de TDD y ofrece su receta para hacer TDD, son tres pasos:

• No puedes escribir código de producción antes de tener un test que falle.
• No puedes seguir escribiendo código de un test si ya has escrito lo suficiente para que falle, y los errores de compilación son fallos (recordar que con TDD escribes el test incluso antes de que las funciones a probar existan!).
• No puedes escribir más código de producción que el estrictamente necesario para que pase el test que actualmente esta fallando.

Tela eh?, parece facil pero cuando te pones ha hacerlo en la practica es muy dificil lograr la displina y la habilidad escribiendo test (y escribiendo código testable, que es lo más dificil!) para cumplir con estas 3 reglas, a mi me ha costado como os digo casi dos años y todavía no siempre soy capaz de seguir estos 3 principos a simple vista simples. Pero cuando lo logras, cuando construyes de esta forma una funcionalidad, poco a poco pasando pequeños test y añadiendo pequeños trozos de código a un sistema que siempre se mantiene estable, la sensación que te queda de estar haciendo realmente un buen trabajo es fantastica.

Posteriormente se explica el principio FIRST, que son 5 cualidades que debe tener un buen test:

• Fast: Los test deben ejecutarse rapido. Si no al final el equipo terminará por no pasarlos. Yo añadiria que esto es cierto para los test unitarios, para los funcionales no me importa tanto la velocidad sino hacer el test con un sistema real (base de datos, sistema de fichero etc,etc incluidos)
• Independant:Un test nunca debe depender de otros para pasar. Los puedes ejecutar en cualquier orden y deben funcinar igual.
• Repeteable:El test se debe ejecutar encualquier entorno. En el equipo de desarrollo, en el servidor de IC. Lo ideal es bajarselo del sistema de control de versiones ejecutar un comando (mvn clean install by example) y que toda la aplicación compile y los test pasen.
• Self-validating:Un test debe devolver: "correcto" o "fallo" y no debe requerir ningún tipo de intervención manual posterior (mirando un log por ejemplo) que determine si el test paso o no.
• Timely:Con esto se refiere a que los test deben ser escritos en el momento adecuado, es decir, antes que el código que prueban.

En resumen, un gran capitulo sobre test unitarios que si hubiera leido hace dos años me hubiera ahorrado varios dolores de cabeza. Por ponerle alguna pega, no se entra en suficiente detalle en como escribir código testable (aunque si se trata en otros capitulos del libro), que en mi experiencia es lo más dificil de conseguir y de hacer entender a quienes empiezan con el unit testing, para esto os recomiendo el blog de misko hevery, que tiene articulos fantasticos sobre el tema y una guia de como escribir código testable.

Capitulo 10: Classes

La recomendación más importante en este capitulo coincide con la del capitulo sobre funciones, hacer clases pequeñas!. Tio bob habla sobre mantener el principio de cohesión y el SRP (Single Responsability principle o principio de responsabilidad única) en las clases y como consecuencia de estos terminamos con sistemas formados por muchas clases pequeñas con responsabilidades bien definidas. No podría estar más de acuerdo, no sabría dar un número de lineas maximo porque además me parece un poco arbitrario y dependiente de cada sistema, digamos que personalmente más de 500 lineas debería hacer que saltasen las alarmas y pararse a mirar si podemos subdividir esa funcionalidad en varias clases.

Otra recomendación importante es la de depender de interfaces o bien clases abstractas en lugar de implementaciones concretas. Esto es importante por dos motivos: mejorar la flexibilidad del diseño y mejorar la testabilidad del código. Esto puede ser un poco más discutible porque en ocasiones da lugar a sistemas donde tenemos 1 clase por cada interfaz, y a ojos de muchos resulta excesivo. Yo personalmente si soy partidario de depender siempre de interfaces aún que tenga que escribir un poco más, me parecen más interesantes los beneficios (sobre todo el testing) que lo que me cuesta escribirlos. Aunque para esto se me hace casi indispensable utilizar inyección de dependencias, de esto habla el tio bob en el siguiente capitulo precisamente.

Capitulo 11: Systems

En este capitulo se habla de algunos elementos importantes para la arquitectura general de un sistema orientado a objetos. En primer lugar se habla de algo que me parece realmente interesante, un sistema orientado a objetos tiene dos partes fundamentales que conviene separar:

• Construcción de objetos: Al inicio del sistema cuando se crean los objetos necesarios para su posterior funcionamiento
• Uso de estos objetos: Cuando el sistema esta en marcha y los objetos se usan para proporcionar la funcionalidad requerida

Esta separación sirve para justificar el uso de la inyección de dependencias, que será la encargada de la construcción de los objetos. De modo que nosotros declarativamente indicamos al sistema de inyección de dependencias que objetos queremos que coja para construir nuestro sistema y posteriormente usamos esos objetos cuando el sistema esta en marcha. Esta forma de ver la arquitectura de un sistema OO me parece realmente interesante y es una buena forma de mantener el desacoplamiento entre clases, es el sistema de DI el encargado de saber que implementaciones tiene que instanciar y a que objetos colocarselas como dependencias. Esto da lugar a sistemas más flexibles y cuyas partes (que además son simples y cohesivas) podemos probar facilmente mediante pruebas unitarias y dobles de pruebas (stubs o mocks). Nosotros actualmente seguimos este enfoque utilizando google guice como motor de DI, y estamos muy contentos con la aproximación, tenemos clases más cohesivas, menos acopladas, más facilmente testables y un sistema más flexible donde se puede cambiar una implementación por otra en cada parte del sistema.

Por ultimo el tio bob también habla en este capitulo sobre los "cross-cutting concerns" en castellano sería algo como "funcionalidades transversales", es decir aquellas funcionalidades tipo logging, seguridad, transacciones etc, que están dispersas por todas las clases del sistema. Lo que propone aqui esta claro, usar programación orientada a aspectos. Para esto podemos usar un framework AOP completo como AspectJ o aproximaciones más modestas como el soporte para AOP de spring o el mismo guice. Nostros actualmente usamos interceptores de guice para controlar algunas cosas como transacciones o tratamiento de excepciones.

Capitulo 12: Emergence

Este capitulo es basicamente una apuesta por el diseño incremental frente el diseño up-front. Muy en la linea del desarrollo ágil y de lo propuesto en XP por Kent Beck. Se trata de no tratar de diseñar mucho antes de tiempo, diseñar sólo lo necesario para la funcionalidad a implementar hoy sin pensar en la de mañana. Cuando llegue la funcionalidad de mañana ya pensaremos en ella, y como además hemos seguido todos los principios anteriores (clases pequeñas, metodos pequeños, cohesión, SRP etc) nuestro sistema será lo suficientemente flexible para aceptar nuevos cambios y además mantenerse limpio (que es el objetivo de este libro ¿no?: clean code). Algo que también esta muy en la linea de unos de los principios de LEAN, no decidir hasta el ultimo momento responsable para hacerlo.

Para lograr que un sistema emergente no se convierta en un caos se mencionan los 4 principios del diseño simple (estos son de kent beck), en orden de importancia:

1. Todos los test pasan
2. No existe duplicación de código
3. El sistema expresa la intención del programador
4. Minimizar el número de métodos y clases

Estos principios basicamente son la base del Red-Green-Refactor-Green de TDD, del 2 al 4 corresponderían a la fase de refactorización.

De nuevo coincido plenamente con todo lo que se dice en este capitulo, he metido la pata muchas veces por anticipar diseños antes de tiempo y he complicado muchos sistemas por incluir cosas que luego no se han usado jamas. En mi opinión el diseño simple, los test y la refactorización, son la mejor aproximación que conozco para el desarrollo de software y la que trato de aplicar todos los días, unos días mejor y otros peor eso si :P

Capitulo 13: Concurrency

Este capitulo es el que menos me gusta y sinceramente me parece algo fuera de lugar en este libro. Supongo que lo habrá incluido por el interes creciente en la programción multihilo. Sin ser un experto ni de lejos en este tema las recomendaciones que se dan me parecen muy basicas y no me a aportado gran cosa, hay libros dedicados a estas cuestiones mucho más completos.

Conclusión final del libro

Como os decia además de los capitulos que he comentado teneis los capitulos puramente practicos, donde se coje un trozo de código de proyectos reales y se destripa para mejorarlo con los principios contados, estos son altamente recomendables pero no tiene mucho sentido que los resuma.

Las practicas y las ideas que defiende el tio bob en este libro están muy en linea con las practicas de desarrollo ágil (unit testing, diseño simple etc,etc) y también están muy en linea con mi forma de hacer las cosas, quizas por eso mi opinión pueda ser un poco sesgada jeje, pero para mi es un libro fundamental que devuelve la importancia y el foco de un desarrollo de software al sitio del que nunca tenia que haber salido: el código por supuesto. Un libro de diseño OO que no dibuja UML's, coje el código de un proyecto Open Source real y lo modifica aplicando las buenas practicas descritas, un libro que habla de profesionalidad a la hora de escribir código en estos días de carnicas y programadores licenciados en filologia hispanica a 100 pesetas unidad. Quien se quiera seguir engañando (o engañando a otros) que siga, pero el buen software lo construyen los buenos programadores que escriben CLEAN CODE, da igual que pongas un jefe de proyecto con un MBA y con un PMP otorgado por el PMI experto en el uso del project, o que hayas pasado las evaluaciones SCAMPI para el CMMI nivel 3 y 1/3. Si quieres desarrollar buen software preocupate de tener buenos PROGRAMADORES (en mayusculas) profesionales y con talento, el resto es papel mojado.

Un libro fundamental para gente con poca experiencia, sobre todo si va a participar en algún proyecto ágil, y un libro que puede hacer a gente con más experiencia replantearse la forma de hacer muchas cosas. Eso si, como consejo para los que tengais experiencia, leer el libro con mente abierta y dispuestos a replantearos vuestra forma de ver las cosas en muchos aspectos, si lo leeis pensando que lo sabeis todo antes de abrir el libro no vais a sacar mucho beneficio, y además, ¿si ya lo sabeis todo para que leeis libros?, escribirlos! :P.