Resumen de Clean Code - segunda parte

Despues de unas pequeñas vacaciones en paris, que ya me hacia falta irme de vacaciones, vamos a seguir con la segunda parte del resumencillo al excelente Clean Code del tio bob. Como comente el libro se dividia en capitulos teoricos y tecnicos, voy a seguir con el resumen de los capitulos teoricos por donde lo deje en la anterior entrada.

Capitulo 5: Formatting

Este capitulo bastante más "ligerito" que otros da algunos buenos consejos sobre formateo de código. Se divide en dos partes: formateo vertical y formateo horizontal.

Me ha gustado sobre todo lo del formateo vertical, en general cuando se habla de formateo es más habitual encontrar recomendaciones sobre formateo horizontal, la eterna batalla de la indentación con espacios o tabuladores por ejemplo. El formateo vertical me parece más interesante, la recomendación que más me gusta es lo que llama "The newspapper methapor" que basicamente consiste en escribir las clases de arriba hacia abajo siempre intentado colocar los métodos llamados inmediatamente despues del llamador, de forma que la clase se pueda leer sin tener que andar constatemente con el scroll para arriba y para abajo. Esto es algo que personalmente siempre he intentado hacer, pero sin pararme mucho a pensarlo, simplemente por sentido común, y me ha echo gracia verlo escrito y bien argumentado.

El resto del capitulo son recomendaciones sencillas para tener un código bien formateado, como por ejemplo usar espacios para resaltar la precedencia de operadores en las operaciones aritmeticas. Otra que me toca directamente es cuando desaconseja organizar el código en columnas, por ejemplo cuando se hacen varias asignaciones seguidas digamos en un constructor, yo personalmente quizas por que vengo de C++ tengo la tendencia a hacer que los iguales estén en la misma columna para que el código quede "cuadrado", y la verdad es que además de no servir para mucho es un poco engorroso sobre todo con el autoformateo de algunos IDE's que se empeñan en no dejarme hacerlo tranquilamente jeje, en esto creo que si me ha convencido el tio bob y poco a poco lo voy dejando.

Capitulo 6: Objects And Data Structures

En este capitulo se plantea fundamentalmente la diferencia entre objetos y estructuras de datos. Objetos son los elementos que ocultan su implementación interna y ofrecen métodos frente a las estructuras de datos que por definición exponen sus interioridades y no ofrecen ningún método.

El este capitulo el tio bob critica una practica muy común en el desarrollo java, la de los famosos getter&setter, basicamente considera a los beans estructuras de datos disfrazadas de objetos que no aportan gran cosa, en resumidas cuentas si vas a tener una clase con N propiedades privadas y un getter y un setter para cada propiedad no lo llames clase, llamalo estructura de datos y pon todas las propiedades publicas. Me gusta especialmente una frase sobre este tema: "The quasi-encapsulation of beans seems to make some OO purists feel better but usually provides no other benefit". El problema en java quiza sea que esta tan extendido el concepto de "bean" que muchos frameworks te obligan a utilizarlos, normalmente para usar introspección sobre estos objetos y hacer su "magia", pero si no estas obligado por ningún framework... ¿realmente necesitas todos esos get&set?

Otra cosa que puede llamar la atención es cuando afirma que la creencia de que todo es un objeto no es más que un mito, y que un programador maduro debe saber distinguir cuando necesita un objeto y cuando necesita simplemente una estructura de datos. La recomendación general que se da es que cuando los datos no varien y se quieran añadir funciones que operen sobre estos datos un enfoque con estructuras de datos, procedural vamos, es más adecuado, mientras que cuando lo que se quiere es tener la flexibilidad de trabajar con distintos tipos (aka polimorfismo) el enfoque OO es superior.

Dificil de aceptar algunas cosas de este capitulo para un taliban de la OO como yo :P, aunque es cierto que cuando generas un monton de getters&setters mecanicamente, aunque sea con un IDE, te queda el regusto de que estas haciendo algo totalmente innecesario y que algo anda mal...

capitulo que me ha parecido muy interesante porque cuestiona cosas que parecen asumidas como "normales" en el mundo java y en el mundo OO, en ocasiones conviene replantearse algunas que uno hace casi mecanicamente y probar otros enfoques, este me lo tengo que releer un par de veces más a ver si me convence del todo que yo sigo viendo objetos por todas partes jeje, pero al menos me ha echo replantearme algunas cosillas, que en definitiva es lo que espero cuando me leo un libro de estilo.

Capitulo 7: Error Handling

Otro tema habitualmente "polemico", empieza recomendando el uso de excepciones sobre códigos de retorno de las funciones, esto puede parecer hasta evidente para cualquier programador OO con un poco de experiencia, pero se encuentra uno cada cosa por ahí... he trabajado bastante con código en C construido con uso constante de códigos de error y se me ocurren pocas formas mejores para hacer el código cuasi ilegible.

Otra recomendación, en la que ultimamente parece que hay cierto consenso, es no utilizar checked exceptions. En esto es bastante tajante y empieza de una forma que lo deja claro "the debate is over". Afirma que si se puede construir código robusto sin checked exceptions en otros lenguajes como C#, python, ruby etc,etc en java también se puede construir código robusto sin checked exceptions. El principal problema que plantea sobre las checked es la violación del principio "open-close" derivada de las dependencias que generan las excepciones checked, ya que no queda más remedio que capturarlas y relanzarlas o colocar un throws haciendo que el código de las capas más altas tenga que conocer excepciones de bajo nivel varias capas más abajo. Personalmente coincido al 100% con esto, nunca uso excepciones checked y API's como JDBC me parecen un ejemplo perfecto de porque no hay que usarlas, es un martirio para el usuario de estos API's.

Otra recomendación importante que realiza en este capitulo es la de evitar tanto devolver como pasar "null", en lugar de devolver null lanzar una excepción o bien devolver un objeto que cumpla el interfaz esperado pero no haga nada.

Capitulo 8: Boundaries

En este capitulo se refiere a como tratar con los limites del sistema, es decir, cuando nuestro código interactua con librerías de terceros. Hoy en día nadie se imagina hacer una aplicación sin usar alguna que otra librería: log4j, hibernate, quartz, lucene... cada uno seguro que podría hacer una lista cuasi interminable con todas las librerías que ha tenido que utilizar.

La recomendación inicial para usar código de terceros en encapsularlo en lugar de tratar con el directamente integrado por varias partes de nuestra aplicación. La idea es sencilla, una librería por lo general ofrece gran cantidad de funciones para uso general de las que nosotros normalmente sólo queremos un subconjunto, de modo que la idea es crear nuestro propio interfaz que sólo ofrezca la funcionalidad que necesitamos e implementarlo utilizando la librería en cuestión. Esto ofrece varias ventajas:

• Nuestra aplicación sólo interactua con un interfaz que ofrece justo lo que nos hace falta, ni más ni menos. Esto simplifica nuestra aplicación que no tiene que tratar con los detalles de la librería en cuestión.
• Llegado el caso podriamos cambiar esta librería por otra de funcionalidades similares sin mucho esfuerzo. Esto no siempre es tan facil logicamente, pero si la librería de terceros la utilizamos diseminandola por todas partes de nuestro código nos estamos casando con ella, ya sabeis "hasta que la muerte nos separe", y hombre ¿tampoco nos vamos a casar con cualquiera no?
• Encapsulamos toda la funcionalidad que necesitamos de la librería en una clase (o varias claro, dependiendo de la complejidad del tema), lo que hace que sea mucho más facil hacer pruebas unitarias, que por ejemplo nos permitiran descargarnos una nueva versión de la librería y saber que no se ha roto nada de lo que nos hacia falta.

Nosotros esto lo hacemos habitualmente con librerias, cuando hablamos de frameworks tan habituales en java con spring, struts, jsf etc,etc este enfoque no funciona, estos frameworks condicionan fuertemente la arquitectura de tu aplicación, vamos que si quieres meterle mano a alguno de estos te tienes que casar primero, son menos liberales :P.

Otra recomendación que me gusta de este capitulo es la de aprender a usar liberías de terceros mediante test unitarios. Todos en alguna ocasión hemos creado un "proyecto de prueba" con nuestro metodo main para probar esta o aquella librería, luego cuando hemos evaluado la librería y aprendido como usarla este proyecto suele acabar en la basura o olvidado en algún recondito lugar. La propuesta es hacer esta evaluación mediante test unitarios, de forma que hacemos un test por cada funcionalidad de la librería que queramos incorporar a nuestro programa. Estos test luego se incorporán a la base de código y sirven como una fantastica documentación del uso de la librería y para comprobar que nuevas versiones siguen funcionando como se esperaba. Un enfoque que me gusta bastante.

Y con esto termino la segunda parte, creia que con dos entradas llegaría pero me va ha hacer falta una tercera para los temas sobre clases, unit testing o diseño emergente, que me enrollo cosa mala :P