Contratar a un malabarista

Este es el titulo de unos los capítulos de peopleware, libro que Jose Manuel Beas me presto amablemente en la ultima reunión del grupo de agile-spain de madrid (prometo devolverlo pronto que casi lo he terminado jeje).

El libro es una pasada, casi diría que obligatorio para cualquiera que dirija un equipo de desarrollo de software. Cuando me lo termine intentaré hacer un resumen más amplio, de momento el inicio de este capitulo me ha parecido magnifico y además en el pasado me toco hacer unas cuantas entrevistas para contratar malabaristas y como casi todo hijo de vecino también he sido candidato en unas cuantas... y aunque este libro se escribiera hace más de 20 años (la primera edición es de 1987!), es increíble como todavía se siguen cometiendo los mismos errores que estos señores ya advertían, una y otra vez...

Este capitulo en cuestión comienza con una pequeña entrevista (inventada por supuesto) entre un malabarista y el jefecillo del circo que quiere contratarle, en castellano:

• jefecillo del circo: ¿Cuanto tiempo hace que eres malabarista?
• candidato al puesto: oh, alrededor de cinco años


• jefecillo del circo: ¿Eres capaz de manejar tres bolas?, ¿y cuatro?, ¿y cinco?
• candidato al puesto: Si, si y si


• jefecillo del circo: ¿Puedes manejar objetos ardiendo?
• candidato al puesto: Por supuesto


• jefecillo del circo: ¿Tienes comentarios graciosos y chistecillos que haces junto con los malabares?
• candidato al puesto: Hilarantes!


• jefecillo del circo: Bien, esto suena bien, estas contratado!.
• candidato al puesto: Umm, ... no quieres ver como hago malabares
• jefecillo del circo: Emm, no lo había pensado...

Parece ridículo contratar a un malabarista sin haberlo visto hacer malabares primero, es algo de sentido común ¿no?. Bueno, pues a la hora de contratar desarrolladores parece que las reglas del sentido común están suspendidas...

En mi opinión una forma realmente brillante de poner de manifiesto lo rematadamente malos que son los procesos de selección en nuestro sector (por norma general, por supuesto que hay excepciones), y recuerdo, lo escribieron hace veinte años!, a veces uno se pregunta si en este país alguien lee algo más que el marca.

Eso si, miras las ofertas en cualquier portal de búsqueda de empleo y te encuentras listas interminables de tecnologías que debe conocer el candidato (en muchos casos mal escritas, tecnologías que se solapan o simplemente absurdas para el puesto...). Pero luego basta con que en la entrevista si te preguntas hagas como el malabarista de antes y digas "si yo de esto controlo mucho", y ale!, contratado!.

Lo mismo es cosa mía y he dado por casualidad con malos procesos de selección, pero en ninguna entrevista de las que he echo (unas 10 o 15 quizás en 10 años, tampoco muchas) me han echo una prueba practica decente, en ninguna he tenido que hacer malabares, ha bastado con que dijera que sabía hacerlos... Es más siempre recuerdo una entrevista en una empresa de selección (expertos en seleccionar personal técnico según su publicidad claro) después de un rato largo contando mi vida y milagros, que con lo que me enrollo cualquiera que me conozca sabe que es un rato realmente largo jeje, el tio va y me suelta "bien, entonces apunto que eres un java con 4 años de experiencia"... pedazo proceso de selección, en una empresa que seleccione así a su personal ¿merece la pena trabajar?, ¿vas a encontrar compañeros de trabajo de los que aprender?, ¿vas a evolucionar como profesional?

Antes de pensar sobre si metodologías ágiles o pesadas, antes de pensar si java o .net, antes de muchas cosas es necesario preguntarse ¿que proceso de selección tenemos?, ¿que ofrece nuestra empresa para mantener a los buenos profesionales?, ¿cual es nuestro indice de rotación de personal?. Si estas cosas fallan entonces esta fallando el primer eslabón de la cadena, así que tener o no las personas adecuadas para el puesto dependerá fundamentalmente de la suerte, y si asumimos que el factor que tiene más influencia en el éxito o fracaso de un proyecto son las personas involucradas en el, entonces nos queda que en las empresas con malos procesos de selección el éxito o fracaso de los proyectos que acometan depende en mayor medida de la pura suerte que de ningún otro factor. De la suerte de que en ese proyecto hayan caído uno o varios buenos profesionales que lo saquen adelante, que si han caído lo han echo de pura casualidad porque tu proceso de selección no sirve para garantizar un mínimo de competencia y porque tampoco haces gran cosa para retener a los buenos profesionales.

Desde luego si yo fuera una empresa cliente de desarrollos de software, me preocuparia bastante por cuales son los procesos de selección y indice de rotación de personal de las empresas a las que contrato, desde luego yo confiaría muchísimo más en una empresa que cumpliera simplemente con dos premisas:

• buenos procesos de selección
• saber mantener a los buenos profesionales

que en cualquier otra aunque tuvieran setecientas certificaciones variopintas en CMMI nivel 3 y 1/3. Pero bueno, supongo que un poco como decían los autores de peopleware, en nuestra industria las reglas del sentido común parece que están en off, ¿se pondrán en on algún día?, ¿viviremos para verlo?, quien sabe.

Coding Dojo

El pasado día 22 estube en el coding dojo que organizarón la gente de agilismo.es con colaboración de autentia, os cuento un poco como fue el asunto.

La idea era realizar una pequeña clase para controlar el funcionamiento de un reloj pomodoro en el tiempo que dura un pomodoro (25 minutos), se formarón dos equipos de 5 personas cada uno (yo participe en uno aunque tampoco ayude gran cosa, eso si deje los test pasando que conste! xd). El primer equipo empezo a implementar los primeros pasos y el segundo equipo, en el que estaba yo, continuamos por donde lo dejarón los primeros. No conseguimos completar todo el ejercicio pero por lo menos nos divertimos un rato, y lo mejor de todo fue la cantidad de debates interesantes que se iban produciendo.

Para terminar jose manuel beas realizo una code kata mostrando una posible solución al problema realizada por supuesto haciendo uso de TDD. La idea de las katas esta muy bien, se trata de que alguien que ha pensado y practicado el problema durante unos días hasta dar con una solución suficientemente "pulida" demuestre la solución programandola desde cero en vivo y en directo, esto es importante porque no solo se ve "la solución final" sino que se ve también el proceso de desarrollo para llegar hasta esa solución. Vamos viendo como a través de TDD se va refinando el problema y se enfatiza el papel de TDD no como una tecnica de "pruebas" sino como una tecnica de diseño.

La verdad es que fue una tarde divertida, con un monton de gente pese a lo dificil de estas fechas (estaba "petao") y como siempre Xavi Gost en su estilo habitual showman provocador nos regalo algunas perlas xd, los operadores ternarios no le gustan mucho eso quedo claro jeje, la verdad es que fue muy divertido y con un ambiente de muy buen rollo entre todos los asistentes.

Luego por supuesto terminamos con una cañitas de rigor, la verdad es que se nos hizo un poco tarde y yo me fui sobre las 11 y media y por alli se quedarón unos cuantos valientes tomando la penultima.

Da gusto que se organizen este tipo de cosas, entre las reuniones locales del grupo de madrid de agile-spain, el agile open y estas iniciativas queda claro que se esta formando una comunidad muy activa alrededor de las metodologías ágiles y sus practicas, y es un autentico placer estar siendo participe de todo esto con tantos buenos profesionales que demuestran tanta pasión por su trabajo. Lo que nos queda es seguir apoyando y colaborando en todo esto, y a todos los que tengais posibilidad de asistir a estos eventos y reuniones: ¿a que estais esperando?.

Agile Open 2009: Nosotros somos el cambio que estabamos esperando

pues si, si queremos que algo cambie, si creemos que algo huele a podrido en la industria de las IT, si creemos que hay otro camino mejor, entonces no podemos quedarnos sentados a esperar que alguien lo arregle, nosotros somos los que tenemos en nuestras manos las herramientas y los conocimientos para propiciar este cambio, necesitamos un cambio de actitud que consise basicamente en llorar menos y arriesgarnos más por lo que creemos.

Esta es la idea principal que me ronda por la cabeza despues del agile open 2009, un evento que ha superado con creces cualquier expectactiva, un evento vivo lleno de gente apasionada por su trabajo con ganas de aprender y de compartir. Toda una experiencia, era exceptico con el formato "open" ahora soy fan incondiconal. Resumo un poco el evento desde mi perspectiva, que no es la única porque cada cual vivio el open a su manera en función de las charlas/discusiones a las que fue acudiendo durante el día, otra cosa fantastica de este formato.

Primer día

El primer día se hizo la presentación del evento, agustin yague, jose manuel beas, xavi albadalejo y xavier quesada fuerón los maestros de ceremonias que presentarón el evento y la asociación agile-spain y sus objetivos. Posteriormente los asistentes iban proponiendo charlas y más tarde había que votar las charlas para llenar los 30 slots disponibles (6 aulas y 5 sesiones).

Lo primero que me sorprendio es la cantidad de gente que propuso charlas, se monto una cola que no veas y se propusierón más de 50 charlas creo recordar. Algunas charlas se juntarón en un slot por ser de tematica muy similar y algunas pocas quedarón fuera, la verdad es que yo pensaba que iba a ser un caos total pero la autogarnización funciono realmente bien y entre más de 100 personas se pudo confeccionar el programa de charlas, sin duda el primer exito del open!

Segundo día, el meollo del asunto

La variedad de las charlas hizo que cada uno se hiciera su hoja de ruta en función de sus gustos, y creo que todos encontramos en el open "nuestra conferencia", mi elección fue mayoritariamente hacia los temas más tecnicos, ultimamente me preocupa mucho que se esten perdiendo las practicas tecnicas que están en el corazón de agile (XP fundamentalmente) con la popularización de Scrum y me encontre rodeado de mucha gente con la misma preocupación y con la idea clara de que estas practicas son fundamentales, y diciendolo bien alto no con la boca pequeña.

1 - Artesania del software, belleza en el código:

Fue la primera toma de contacto con Xavier Gost, sin duda la persona que más me ha impresionado en este open. Más que una charla fue una discusión donde se debatio sobre la belleza en el código y sobre el concepto del desarrollo del software como una artesania muy alejado de los procesos industriales y de la idea de ingenieria, algo con lo que resulta obvio que estoy de acuerdo para cualquiera que lea el titulo de este blog jeje. Discutimos sobre la idea del maestro y el aprendiz como metodo para formar a nuevos artesanos, y se pusierón sobre la mesa ideas realmente importantes que nuestra industria parece ignorar completamente:

• Un buen artesano del software se forma en 10 años o más, esto de aprenda java en 2 días o el cursillo por fasciculos "programar es facil" es una soberana estupidez. Y nuestra industria insiste en que quien lleva 10 años y sigue siendo programador es un "fracasado" y en forzar a la gente a abandonar las tareas tecnicas por otras de gestión justo cuando empieza a alcanzar un cierto nivel de artesania aceptable.
• Escribir código es como escribir un ensayo, lo escribimos para que lo lean otros no para que lo lea la máquina. Aplicando esta metafora en lugar de la metafora industrial de cadena de montaje quizas logremos que alguien entienda de una vez que 3 becarios mal pagados y peor formados no pueden hacer el trabajo de un verdadero artesano.

2 - Metricas en el desarrollo ágil

Charla impartida por rodrigo corral, magnifico ponente y magnifica charla, rodrigo fue conduciendo a través de lanzar preguntas de modo que de forma deductiva todo el mundo terminará convencido de las conclusiones. Las conclusiones más destables fuerón:

• Dividir en pequeñas historias y reestimarlas de forma atomica: esta terminada o no, no nos interesa nada más.
• Estimaciones con la colaboración de TODO el equipo.
• Visibilidad del estado del proyecto con indicadores objetivos y simples (los podría entender mi abuela), es decir, la grafica de burndown.

3 - Agilismo de guerrilla

Charla genial!, la presentación de xavi gost de la charla el primer día fue algo como "como introducir el agilismo sin permiso". Xavi nos hablo de como introducir el agilismo desde las bases, en las areas más tecnicas, sin permiso si quiera de tus compañeros, algunas ideas:

• Haz pruebas unitarias, aunque los demás no las hagan tu hazlas y demuestra que son utiles. Alguien pregunto que si tu te pones ha hacer pruebas vas a ir más lento que el resto, la respuesta fue magnifica "no se conoce el caso de nadie que le hayan echado por programar lento y hacer test!, y si te echan por hacer test es que son unos mamones". El agilismo de guerrilla implica mojarse y correr riesgos, si vas más lento pues vas más lento, pero haces un buen trabajo como profesional y muestras el camino a otros para hacerlo bien. Y desde luego, si te echan por esforzarte en hacer las cosas bien esa empresa no se merece tu tiempo.
• micro-commits, esta es muy buena, consiste en bajarse el código "de otros" del scm y cambiarlo, para mejorarlo obviamente, cuando se lo bajen y les empieze a dar conflictos empieza la diversión jeje. De esta forma por un lado verán la forma de hacer mejor las cosas y por otro se hará patente la necesidad de una politica de scm como dios manda, decia xavi "en algunos sitios en los que trabaje pregunte: habrá que hacer un mergue no?, y me respondierón: un que?".
• haz integración continua, por tu cuenta y sin permiso, en tu equipo donde sea, y da el coñazo cuando se rompa el build, o mejor aún, configura la herramienta de IC para que mande correos a los que rompan el build. Cuando vean la utilidad del cacharro no podrán vivir sin integración continua.
• Pair programming forzoso, de vez en cuando te sientas al lado algún compañero ha hacer pair, a lo mejor alguno te manda a la mierda, pero son los riesgos que debe asumir un guerrillero!

Brutal, vaya crack. Lo mejor es no me queda la menor duda de que no esto lo ha echo más de una vez, no es de boquilla.

Se puede estar más o menos deacuerdo con los metodos de guerrilla y con lo radical de la propuesta, pero lo que desde luego es una verdad como un templo es el fondo y el titulo de esta entrada, el cambio esta en nostros mismos y si queremos el cambio hay que llorar menos y mojarse más. ¿Somos agentes de cambio o nenazas lloronas?

4 - Artisanal Retro-Futurism and Team-Scale Anarcho-Syndicalism

O más resumidamente, la charla del queso jeje. charla propuesta por Luismi Cavallé, que de nuevo era otro crack, un tio con las ideas muy claras y que supo trasmitir muy bien las ideas detras del ARxSA.

Yo no conocia este "movimiento", me sonaba pero no le había prestado mucha atención, y acabo de descubrir que si encajo en algún lugar dentro del agilismo es justo aqui!. Algunas de las premisas de esta idea son:

• La tecnología es importante, hay tecnologías con las que hacer agilismo es más facil que con otras y esto no lo podemos obviar y sacarlo de la ecuación. El paso hacia el agilismo puede suponer también un cambio tecnologico. Cosas como rails, grails o REST en contraposición a SOAP son algunos ejemplos. La metodología no es "neutra" y da igual con que tecnología la apliques, la tecnologia usada y la forma de usarla es parte del agilismo también. Podriamos ser agiles sin hudson?, sin las herramientas de testing de las que disponemos? etc,etc.
• Vuelta a los valores core del agilismo, lo resumia el ponente con un twit de Ron Jeffries, "si no haces TDD ni intentes hacer scrum". Es decir, si no engrasas la maquinaria primero, si no dispones de buenos artesanos, ¿donde vas con tu pizarra llena de post-it de colores?, hay que ser muy inocente para pensar que algo así va a solucionar tus problemas.

5 - Pair Programming y ping-pong programming (jose manuel beas vs xavi gost)

Esta charla fue muy divertida, se comentarón entre todos ventajas/desventajas del pair programming y cuando aplicarlo y por otro lado jmb y xg hicierón un ejercicio de ping-pong programming, basicamente esto consiste en que uno escribe el test y el otro luego escribe el código necesario para pasar ese test y un nuevo test y así sucesivamente.

Aunque era la ultima del día y ya no estaba el cuerpo para muchas maravillas en la programación lo mejor fue la cantidad de discusiones interesantes cuando pones a unos cuantos artesanos del software delante de un trozo de código jeje, muy divertido. A xavi casi le da un ataque cuando alguien puso un nombre de propiedad comenzando con guion bajo! xd.

Retrospectiva del evento

Al final del evento se hizo una restrospectiva con todos los asistentes (si con todos, 160!) donde se cerro la conferencia y se hizo una lista con lo bueno y con lo malo del evento. Lo mejor fue que practicamente todo el mundo se quedo a la retro, que se veia en las caras de la gente que lo habían pasado realmente bien, el buen rollo era evidente en el ambiente, lo nunca visto en una conferencia!, sin palabras!.

Ya termino que me queda mu largo esto (como siempre xd), espero haberos dado un poco de envidia a los que no estubisteis, envidia sana para que os animeis a venir a los proximos eventos y para que os apunteis/formeis grupos locales, en el grupo de madrid somos unos cuantos pero hay sitio para todos los que vengan!.

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.

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