Rafa G. Blanes Blog

Los principios de trabajo "lean" me entusiasmaron desde el primer momento en que tuve conocimiento de ellos. El desarrollo ágil viene de la aplicación en cierta medida de los principios de desarrollo lean y guarda muchas similitudes con estos principios. Como todo, si algo es simple, fácil de entender y sencillo de poner en práctica y de sentido común tiene el éxito garantizado. No obstante, me sorprende cómo muchos de estos principios son totalmente desconocidos para muchos desarrolladores de software y emprendedores de cualquier naturaleza.

El Libro Negro del Programador ha sido escrito siguiendo algunos de los principos lean y su finalización (en el momento de escribir esto está en fase de edición) ha sido posible por y gracias a esta metodología.

Muy pero que muy básicamente, la concepción lean en el desarrollo de un proyecto nuevo y emprendedor viene a indicar que no podemos esperar al final del mismo para comprobar si va a tener éxito o no. ¿Cómo puedo averiguar si una idea genial que he tenido puede convertirse en un éxito comercial? Uno de los errores de muchos emprendedores es volcar todo el esfuerzo, tiempo y dinero en terminar algo completamente antes de lanzarla y después esperar (y rezar) para comprobar si tiene buena acogida o todo lo contrario. En ocasiones cuando se llega al final ha pasado tanto tiempo que la genial idea ya ha sido superada por otras en el mercado, o bien se pule y refina el proyecto tanto que se sufre de parálisis por análisis.

Una de las historias fascinantes que cuenta Eric Ries en El Método Lean Startup es la del dueño de Groupon, actualmente una multinacional con presencia y servicio en multitud de países para el intercambio y promoción de cupones de descuento. Desde luego no invirtió en crear toda la infraesctutura actual de Groupon para ponerse en marcha, sino que comenzó muy humildemente probando el concepto con sus familiares y amigos y, de ahí, según la respuesta obtenida, fue mejorando continuamente y dándole forma como proyecto empresarial. Convirtió una idea sencilla, práctica y barata de probar, en una compañía global.

Del mismo modo, desde El Libro Negro del Programador he ido compartiendo los avances de los capítulos para obtener feedback y comprobar el grado de interés que pudiera despertar un proyecto así. ¿No ocurre lo mismo que en software cuando le enseñamos a un cliente cómo se van implementado las historias de usuario para afinar en requisitos y su idea de lo que quiere y necesita?

Afortunadamente, desde los primeros capítulos, El Libro Negro del Programador despertó suficiente interés como para perserverar en su avance, en forma de correos de ánimo, mensajes sobre erratas, sugerencia de nuevos capítulos, puntualizaciones, diversos puntos de vista, ayuda para revisar los documentos gramatical y ortográficamente (gracias Luis)  y, para mí lo más gratificante, preguntas del tipo "¿cuándo y cómo podré adquirir el libro?".

El método lean no sólo te ayuda a comprobar el interés en algún tipo de idea o proyecto, sino que te permite mejorarlo y afirnarlo mediante una táctica de pivotar sobre la idea o perseverar en ella.

Estamos aprendiendo a hacer las cosas de otro modo, a emprender proyectos con otras tácticas; también la redacción de un libro se puede enfocar así.

Me he encontrado en ocasiones algunos desarrolladores de software que, al menos aparentemente, se obstinan en hacer las cosas exageradamente complicadas. Tanto es así que parece que lo hacen como seña de identidad: cuanto más abstruso más demuestro lo bueno que soy. Digo yo que lo mismo iban por ahí lo tiros.

No obstante, la pregunta que hay que hacerse cuando escribimos una nueva pieza de código es, "¿lo entenderemos nosotros mismos dentro de un tiempo?", si la respuesta es afirmativa, la siguiente pregunta sería "¿lo entenderán los demás, aquellos que hereden para lo bueno o para lo malo este trabajo?".

Yo siempre digo que si el primer objetivo de un buen software es resolver algún problema y que le sea de utilidad a alguien, lo segundo es que debemos programar para que los demás puedan asumir fácilmente aquello que hacemos. Nada más ingenuo que pensar que cuanto más rebuscado hagamos el trabajo mayor la estima técnica que nos puedan tener.

Un cosa clara me ha demostrado la experiencia, algo además irrefutable: las mejores soluciones con las que más me he sorprendido, han sido claramente las más sencillas. Todos podemos deliberadamente hacer algo complejo, pero pocos, muy pocos, podemos dar con el medio o la solución más sencilla.

Este debería ser uno de los prinpios con los que trabajar en el día a día: intentar buscar siempre la solución más sencilla a cualquier problema, tanto de programación, de diseño, etc.

No sólo este principio mejorará nuestros productos, nuestro día a día en el futuro cuando tengamos que volver a modificar una aplicación, sino que con el tiempo te das cuenta de que el hábito constante de buscar siempre simplificar las cosas, precisamente te reprograma la cabeza para que de manera natural te surjan soluciones sencillas.

Recomiendo encarecidamente la lectura (y relectura) del libro Code Simplicity, el libro de Max Kanat-Alexander, ingeniero software en Google en donde reflexiona sobre estos conceptos que tanto pueden hacer por mejorar la calidad del trabajo que realizamos. Su blog también contiene entradas muy interesantes.

¡Vamos llegamos al final del libro!

Después de más de un año dándole forma a El Libro Negro del Programador, ya es hora de darlo por cerrado y publicarlo oficialmente.

Como siempre he indicado a lo largo de los capítulos, su versión publicada en la web son adelantos: la versión final del libro tendrá los capítulos más desarrollados, con más ejemplos y además se incluirá una serie de capítulos inéditos, entre ellos el de conclusiones y uno que me gusta especialmente: el test del desarrollador de software altamente productivo.

Es sorprendente la cantidad de cosas que te planteas y re-planteas cuando escribes sobre los temas que te gustan y apasionan: una cosa es creer que sabes algo y otra muy distinta ponerlo por escrito para contárselo a otros, sobre todo de una forma que hasta tu abuela lo tendría que entender.

No sé si he tenido mucho o poco éxito, pero la motivación principal de El Libro Negro del Programador es la de allanar el camino a quienes llegan a nuestra profesión y a quienes llevan más tiempo pero que creen que han alcanzado todo lo que había que saber...

Si es verdad que aprendemos de los errores, en el libro tenéis los que desde mi punto de vista cometemos con más frecuencia los desarrolladores de software y que nos impiden trabajar con la excelencia como único propósito; porque lo que sí tengo más que claro es que la economía que viene no es la de la titulitis, sino la del talentismo, o como diría el gran Raimon Samsó, la clase emergente de los expertos.

En los próximos días se publicará un último capítulo y en unas semanas podréis disfrutar del libro editado con profesionalidad desde distintos portales en Internet.

Gracias y hasta pronto.

Reconozco que comencé a tomarme muy en serio el ser más estricto con el desarrollo y refactorings de las pruebas desde hace relativamente pocos años. Efectivamente, me llevó su tiempo darme cuenta de la enorme rentabilidad metodológica al pasar de una aplicación de consola para depurar (...) que tener formalizadas correctamente una completa y contundente batería de pruebas. Tanto es así, que hoy día sólo veo a través de las pruebas, quiero decir, cuando desarrollo nuevo código de producción, pocas veces entro en él en modo depuración si las pruebas correspondientes indican que todo va bien.

(Update: no en vano he publicado en 2019 un nuevo trabajo sobre todas aquellas prácticas ágiles que permiten escribir código mejor diseñado y de mejor calidad y que permite así escribir mejores tests: El Libro Práctico del Programador Ágil)

No obstante, y sin caer en la simpleza de reconocer lo fácil que es detectar en qué otros fallan, veo a menudo (muchas más veces de las que me gustaría) que el hecho de tener implantantado una arquitectura y metodología que permite y exige el crear pruebas, éstas se desarrollan como para salir del paso, en lo que se suele en llamar el happy path y que yo llamo particularmente "pruebas felices".

¿Qué es una prueba feliz?. Cuando escribimos una nueva clase o añadimos una nueva funcionalidad a código ya existente, tenemos la tendencia natural de escribir pruebas que consciente o inconscientemente sabemos que van a dar pocos problemas. Probamos entonces el mejor caso y que resuelve bien nuestro código: la prueba feliz viene a decirnos que nuestro código hace bien aquello para lo que lo hemos desarrollado. No obstante, si nos limitamos a escribir exclusivamente pruebas felices, estamos ignorando gran parte del objetivo de tener una solución respaldada por tests. Buscamos sólo pruebas felices porque en realidad percibimos el escribir pruebas como un mal que hay que asumir en lugar de un pilar fundamental y esencial en el desarrollo de un software de calidad y profesional.

El objetivo de escribir pruebas no es sólo el de tener un mecanismo por el que poder comprobar automáticamente que algo funciona ahora y seguirá funcionando en el futuro. Escribimos tests no sólo para la situación ideal (el camino feliz) sino que debemos desarrollarlos para comprobar todas aquellas situaciones incómodas en las que una funcionalidad particular se podría ver comprometida. Se nos olvida en ocasiones que los tests persiguen detectar errores, si nos quedamos con los casos más sencillos, seguramente estaremos ocultando bugs que tarde o temprano nos explotarán en las manos.

¿Cuándo es el momento más oportuno para detectar errores y problemas?, ¿cuando estamos precisamente desarrollando una nueva funcionalidad o cuando el software está ya en producción con uno o varios clientes usándolo?. La respuesta es más que obvia.

Recientemente he desarrollado un servicio de Windows para instanciar ciertos servicios web que emulan el comportamiento de un tipo de dispositivo. Se simula uno de estos dipositivos instanciando sus servicios web correspondientes en un puerto específico. Desarrollé como es lógico ciertas pruebas para garantizar que los web services se instancian bien para el puerto 8000, ¿y ya está?. Absolutamente no, ¿qué pasaría si al desplegar ese software en una máquina en producción ese puerto está ya siendo usado?. En este caso, las pruebas tienen que garantizar que somos correctamente notificados cuando se da esa circunstancia, que un error de este tipo no provoca un crash completo del servicio de Windows, etc. Si me hubiera quedado en la prueba feliz, seguramente habría terminado antes, pero con toda seguridad en el futuro habría tenido que dedicar muchísimo más tiempo a solucionar ese tipo de errores en producción y con un cliente insatisfecho...

Esto no es más que un ejemplo pero es que a veces no nos damos cuenta de la cantidad de esfuerzo y tiempo que nos podemos ahorrar detectando errores en producción sencillamente creando una batería correcta de tests en la fase de desarrollo. Pocas cosas hay que tranquilicen más en software que saber que tu producto está tan suficientemente probado que muy difícilmente se van a encontrar problemas en el despliegue del mismo.

Una ley del software viene a ser que cuanto más y mejor pruebes un software, mayor lo vas a rentabilizar, en el sentido de dedicar menos tiempo a depurar errores, el tener menos clientes reportando problemas, etc.

Tampoco es cuestión de crear el mayor número de pruebas porque sí sino de crear éstas con la calidad suficiente y cubriendo todos los posibles casos.

Este es un asunto que, me temo, solemos subestimar y es que no es trivial crear y saber desarrollar pruebas con la suficiente calidad; el problema es que en nuestra profesión muy a menudo debemos tener un carácter polifacético (lo que viene siendo tener que hacer de todo un poco); este no es un tema sencillo sino que el tester es un claro perfil de persona cualificada con ciertas aptitudes en su profesión, como bien indica este magnífico libro de Software Testing.

A veces me he planteado la pregunta de cómo evaluar un buen software de uno que no lo es tanto. Aquí entran en juego seguramente aspectos muy subjetivos; sin embargo, si intentamos llegar a algún tipo de principio del tipo de los que muestra Max Kanat en su libro Code Simplicity, existen realmente varias maneras de evaluar la calidad de un buen software.

No me gusta nada ni siquiera plantear el concepto de calidad, ya que en la mayoría de las ocasiones, los desarrolladores de software hacen lo que pueden en el contexto laboral con el que les toca lidiar; pocas veces he visto que realmente las cosas se hagan mal por pura y llana pereza mental. Sí he visto muchas a menudo que las cosas se hacen mal por ingenuidad o por la falta de un tutor que sirva de guía y ganas de traspasar su experiencia.

¿Cómo entonces distinguir una librería o trozo de software bien hecho de otro no tan bueno?.

Un error muy común que cometen muchos desarrolladores de software es escribir código de manera que es difícil crear a su alrededor las suficientes pruebas o tests que garanticen que ahora y más adelante, el software funciona.

Esto es un mantra que repito a menudo: la estructura de una solución que puede ser probada no tiene nada que ver con la estructura de otra para la que es imposible crear un conjunto de tests. Por tanto, aquí tenemos un elemento que nos puede indicar en cierta medida la calidad de una pieza de código: si se puede probar con facilidad o dificultad.

Pero, ¿qué hay del mantenimiento?, ¿no es verdad que queremos escribir software que viva muchos años y que pueda ser vendido y desplegado en el mayor número de clientes posible?. ¿Cómo vamos a hacer esto si la solución que escribimos es imposible de mantener?. Volvemos a la metáfora del coche que no se puede reparar...

Del mismo modo que antes, un buen software escrito para facilitar su mantenimiento no tiene nada que ver en su forma y estructura de otro que es imposible o muy difícil de mantener (diseño rígido), entendiendo por mantenimiento la detección fácil de pequeños bugs y la capacidad de mejorar el producto con nuevas características o mejoras de las ya existentes.

Efectivamente, con el tiempo nos damos cuenta de que el diseño, estructura y forma de un software que permite ser probado con facilidad y que puede ser mantenido con sencillez, no tiene nada que ver con el diseño, la estructura y forma de un software que ni podemos probar bien y para el que es muy complicado introducir algún cambio.

Esto es un principio de desarrollo de software inquebrantable que uno termina por aprender a lo largo de varios años después de algunas etapas de fracasos y errores.

Cuando llegamos a este tipo de conclusiones, nos damos cuenta de que programar bien no se consigue sencillamente leyendo un buen manual de C#, Ruby on Rails o lo que sea; conocer los rudimentos de cualquier tecnología no es suficiente. Existen principios, leyes, diseños, etc. que nos indican realmente cómo llegar a una solución con la suficiente calidad.

¿Qué es lo que distingue un buen profesional de una persona que se gana la vida con aquello que le ordenan hacer?. Llevo mucho tiempo preguntándome qué es lo que realmente distingue a alguien por el que las compañías se pelearían en conseguir de aquellos que nada más entregar un currículum, éste va a parar a una enorme y creciente pila. Me temo que queda muy atrás el tiempo en que bastaba con decir tu título o profesión para convertirte en candidato: los paradigmas laborales están cambiando más rápidamente de lo que nos estamos dando cuenta.

No obstante, podemos esbozar un enorme y relevante corolario de logros en nuestra pasada vida laboral, mientras que sólo podemos ser verdaderamente profesionales en aquello que hacemos en el día a día.

Programadores, desarrolladores de software, aquellos en general que trabajan creando nuevas soluciones, sólo pueden prosperar de un modo, ni títulos, ni el soporte de grandes compañías en las que uno ha trabajado y nada de todo esto: somos profesionales cuando somos capaces de realizar un trabajo igualmente profesional.

Esto no es ninguna novedad, claro está, pero lejos de una actitud complaciente y egocéntrica que nos hace considerar todo lo que hacemos como lo mejor, tenemos que reconocer una cosa: hacer un trabajo pro requiere de una disciplina diaria que no tiene todo el mundo.

Me he encontrado en muchas ocasiones en la tesitura de tener que corregir detalles y bugs de compañeros, lo cual no está mal y forma parte de nuestro trabajo. Sorprende cuántas veces he descubierto cosas que manifiestamente se podrían haber hecho mucho mejor exactamente con el mismo esfuerzo.

Si cuesta el mismo trabajo hacer una cosa regular y hacerla de manera excelente, ¿por qué elegir la primera?. En muchos casos es sencillamente por pura pereza; en otros por que para exigirnos un nivel de excelencia en todo lo que hacemos se tienen que dar una serie de condiciones en el contexto en el que trabajamos.

No termino de entender cómo sabiendo hacer algo muy bien, por qué lo dejamos con un nivel de calidad pésimo si además nos cuesta el mismo esfuerzo. Un profesional esto lo tiene muy claro y es que la única métrica por la que se nos puede medir y valorar no es otra que la calidad del trabajo realizado. No hay más.

En el lugar donde trabajo llegan frecuentemente currículums y me sorprende que la mayoría de la gente no pone en valor la calidad de los trabajos realizados: casi siempre se ensalza el dominio de tal y cual tecnología, el haber trabajado en la renombrada empresa X, cuando en realidad lo que a un responsable de recursos humanos (o al menos es lo que yo mismo aplico) le gustaría ver algo como "Desarrollo de la aplicación tal actualmente en producción con tantos usuarios", "módulo X compartido en Github con tantos usuarios", etc. etc.

No somos profesionales por lo que decimos y ni siquiera por dónde trabajamos, sino por la calidad de lo que hacemos.

Lo sorprendente es que esta calidad en muchas ocasiones se consigue sencillamente eligiendo correctamene, a pequeños pasos y creando el hábito de hacer las cosas bien, obviando la pereza de terminar de cualquier forma, sin darnos cuenta de que así vamos dejando piedras que tarde o temprano se desmoronarán encima nuestra. No necesitamos participar en grandes y subvencionados programas de I+D para realizar cosas fantásticas (...): la mejor innovación se puede hacer cualquier día en el trabajo que estamos realizando. Si conseguimos como hábito que la excelencia sea la base de todo lo que realizamos, será entonces cuando irán surgiendo nuevas ideas, oportunidades de éxito y posibilidades para mejorar nuestra carrera profesional. Hacer, por lo contrario, un trabajo cutre, posiblemente nos permitirá pagar algunas facturas más, pero irá menoscabando nuestras oportunidades tarde o temprano.

Si aquello en lo que estoy enfrascado ahora mismo lo puedo hacerlo mejor, ¿por qué no hacerlo?. Un profesional se labra con el trabajo diario de muchos años.

Es recurrente la pregunta que me hacen según la cual siempre se pone en duda la necesidad de realizar software sencillo, fácil de entender (por nosotros y por los demás) pero sobre todo, mantenible. Muchos de quienes nos dedicamos a desarrollar software profesional no tenemos claro aún ciertos conceptos esenciales, como por ejemplo que un diseño matenible no tiene nada que ver con un diseño de algo que es imposible modificar, depurar, evolucionar, etc. Aun funcionando bien, el primero nos dará un mayor rendimiento del trabajo realizado, mientras que en el segundo caso el software pasa a producción moribundo y sin apenas solución de continuidad.

No obstante, nos cuesta reconocer la relación que existe entre la sencillez y la facilidad de mantenimiento.

Mantenible (palabra mantra en el Libro Negro del Programador) no significa trivial, que un principiante sin apenas esfuerzo pueda entender a la primera, sino coherente, un diseño eficiente que facilita los cambios en el futuro y que la adaptación a nuevos requerimientos relacionados son viables (a un coste asumible).

A diferencia del autor de un best-seller que cuando publica un libro que funciona bien recoge royalties según las ventas, cuando publicamos un producto software tendremos más o menos éxito si este puede evolucionar, si puede ser cambiado y fácilmente mantenido.

En Code Simplicity (libro que recomiendo aunque no se lea ni una línea de código) se pueden leer frases auténticamente reveladoras que el autor intenta sintetizar a modo de leyes comunes que gobiernan el desarrollo de cualquier software.

Una de estas afirmaciones que sostiene el autor es que la facilidad de mantenimiento de cualquier pieza de código es proporcional a la simplicidad de sus partes individuales ("The ease of maintenance of any piece of software is proportional to the simplicity of its individual pieces").

Cuando leí esta frase pensé que cuánto tiempo había intuido esta relación pero sin embargo había sido incapaz de sintetizarla de esta manera tan magistral. Una virtud tiene ese libro: sintetiza de una manera genial auténticas verdades que aún siendo sencillas de entender no lo es tanto de aprehender e introducir en nuestro adn de programadores profesionales.

Efectivamente, parece básico pero no es tan elemental tenerlo presente en nuestro día a día.

Si queremos hacer software mantenible, la clave está en conseguir que cada una de sus partes sean sencillas. La cuestión no es contraponer sencillez versus mantenibilidad, sino que ambos conceptos están íntimamente relacionados (y además su relación es proporcional).

¿Por qué nos debemos preocupar de que lo que desarrollamos pueda ser mantenido con relativa facilidad?, por la sencilla razón de que durante la vida de cualquier producto software, sea algo que se venda bajo licencia, un desarrollo interno en nuestra compañía o incluso cualquier proyecto personal, éste va a ser mantenido durante mucho más tiempo que el que ha costado desarrollarlo. Es más, cuanto más éxito tenga, más cambios y mejoras se nos van a pedir, por lo que el ritmo de evolución de un producto puede ser considerado también como un síntoma de su éxito.

Yo siempre pongo el mismo ejemplo: ¿compraríamos un coche que es casi imposible de reparar o al que es muy difícil cambiarle el aceite?.

¿Verdaderamente tenemos esto presente cuando escribimos líneas y líneas de código?.

Estos conceptos de sencillez y facilidad de mantenimiento son fáciles de entender, pero lo que no es tan fácil es tenerlos presentes en nuestro día a día: nadie es capaz de escribir código limpio a la primera, sino que para llegar a él debemos buscar esa solución sencilla mediante refactorings, repaso continuo de lo ya realizado, etc.

Un ingenuo desarrollador simplificará cuando le venga bien, no de manera sistemática, no se preocupará de que lo que hace pueda ser matenido / depurado con facilidad (no percibe que esto le puede golpear en el rostro con efecto boomerang); un programador cándido busca exclusivamente que lo que está haciendo funcione a cualquier precio, sin tener en cuenta eso de que pan para hoy y hambre para mañana...

Si nuestro software es mantenible, estaremos poniendo los cimientos del éxito del mismo. Si no lo es, nacerá moribundo y terminará convirtiéndose en un fracaso y fuente de clientes insatisfechos. Conseguimos este objetivo de mantenibilidad cuidando de que las partes individuales de nuestro producto sean sencillas.

Hay diferentes maneras de aprender y mejorar nuestro trabajo como desarrolladores de software. El aprender una nueva tecnología (o mejorar las habilidades en aquellas que dominamos) requiere a menudo repensar cómo hacemos las cosas.

Hay quien se siente cómodo buscando en foros continuamente para resolver cualquier problema; esto para mí es algo así como aprender por prueba y error llevado al extremo. Hay quien, como yo, preferimos aproximarnos a una nueva herramienta o tecnología leyendo un buen libro de arriba abajo. Las opciones son diversas y como se suele decir cada maestro tiene su librillo.

No obstante, he visto durante mucho tiempo el que es un gran defecto de muchos programadores profesionales: cuando conocen en profundidad las herramientas, lenguajes, etc. que utilizan en el día a día, se anquilosan haciendo siempre, durante años, las mismas cosas y del mismo modo. El desarrollar software tiene un grado versatilidad y flexibilidad que difícilmente hay una única forma de hacer algo, todo lo contrario, siempre existen cientos de formas de resolver un problema; entonces, ¿por qué nos abstenemos de descubrir esos otros enfoques?.

Una manera fundamental de aprender a mejorar, conocer alternativas y producir el efecto pero-por-qué-a-mí-no-se-me-ha-ocurrido-esto es sencillamente leer el código de proyectos realizados por otros.

Desde hace muchos años soy asiduo lector de CodeProject, web colaborativa donde se puede encontrar casi de todo; igualmente, existen repositorios públicos bien conocidos donde se encuentran verdaderas joyas de programación; hablo de GitHub, CodePlex y Google Code, por poner unos ejemplos. Cualquiera quiera compartir un proyecto lo puede publicar en alguno de esos portales.

Sin embargo, lo que aquí quiero señalar es que no hay mejor manera de aprender a programar que leyendo proyectos realizados por otros. Así de sencillo. En esos repositorios públicos que apuntaba antes se encuentra verdaderamente el state-of-the-art de muchas áreas y tecnologías.

Husmear en las tripas del código de otros proyectos te permite descubrir nuevas formas de hacer, te enseña cómo otros han resuelto ciertos problemas e incluso nuevos estilos de programación.

Por mucho que dominemos ciertos lenguajes de programación, de scripts o de cualquier cosa, cada problema, solución o proyecto que tengamos que afrontar se puede resolver de muchas formas diversas; yo siempre digo lo mismo: tonto del todo no soy, o eso creo, pero seguro que hay otras mentes más privilegiadas a las que se les ha ocurrido a resolver algo de una manera más smart. Bucear en otros proyectos te lleva a ese tipo de aprendizaje que difícilmente se va a encontrar leyendo un libro.

Por poner un sólo ejemplo, he aquí una de esas joyas de desarrollo por su buen diseño e implementación: moq.

En ocasiones me han preguntado por qué insisto tanto en que el código que se escriba sea lo más legible posible, que se pueda leer y entender sin que construcciones extrañas o clases de cientos de líneas te arañen la vista, por poner unos ejemplos.

Se pueden dar muchos argumentos a favor de añadir un poco de esfuerzo a nuestro trabajo para escribir código que otros puedan entender; de todos los posibles a mí me parece que hay un criterio fundamental que no siempre se tiene tan en cuenta.

Cualquier trozo de código va a ser muchas veces leído que escrito o modificado. Esto es, cualquier método, función, clase, etc. va a ser repasado y leído en más ocasiones que las veces que hay que ir a ellos para hacer una pequeña modificación. Por tanto, si a todas esas veces le añadimos un coste de tiempo por la complejidad de entender lo que leemos estamos ante un obstáculo que nos quitará tiempo para dedicarnos a tareas más productivas o creativas.

No escribimos software para nosotros sino para que otros lo entiendan. Esto es clave para conseguir soluciones mantenibles y evolucionables. A veces ignoramos que ese otro podemos ser nosotros mismos.

¿He mencionado un extra de esfuerzo?. En realidad ese esfuerzo lo tenemos que hacer explícitamente si no estamos acostumbrados a fluir con los buenos hábitos de programación que existen para este tema en particular; elemenos tan sencillos y triviales como elegir buenos nombres descriptivos para nuestros artefactos de software (¿por qué llamar a una variable _nde cuando le podemos poner _numeroDeEntidades, por ejemplo), métodos o funciones que hacen una única cosa sin más de tres o cuatro argumentos, elementos de una clase ordenados siempre de la misma manera en toda la solución y un larguísimo y extenso etcétera.

Soy de la opinión de que quien no intenta escribir legiblemente realmente no le interesa hacer un buen trabajo y está dejando piedras en el camino con el que un compañero se tropezará cuando tenga que asumir ese código.

Lo sorprendente es que muchas veces el esfuerzo de escribir algo de manera complicada ¡es el mismo que escribirla de manera simple!. Si tenemos las dos opciones, ¿por qué entonces no hacer la que supone un mejor trabajo?.

La productividad de un equipo de trabajo en ocasiones viene dada por pequeños detalles que en sí mismos pueden parecer insignificantes pero sumados marcan una gran diferencia. El Libro Negro del Programador habla intensivamente acerca de cómo desterrar malos hábitos e incorporar buenos precisamente para aumentar la productividad. En ocasiones se entiende ésta exclusivamente como echar más horas: yo digo que trabajar con productividad tiene más que ver con usar herramientas correctamente, tener un equipo de trabajo bien organizado y buenos procedimientos.

Uno de estos procedimientos que pueden ahorrar muchísimo tiempo de esfuerzo inútil es subir correctamente al repositorio de código los últimos cambios introducidos. Como en muchas ocasiones, los mejores hábitos y técnicas son precisamente los más sencillos.

¿Cuánto tiempo hemos pasado resolviendo conflictos de código introducido al mismo tiempo o después de nuestros últimos cambios?. Demasiado si se tiene en cuenta que ese es tiempo no productivo y, en ocasiones, frustrante.

La siguiente técnica busca minimizar las posibilidades de generar conflictos; cuanto mayor sea el número de desarrolladores en un equipo, más posibilidades habrá de generar este tipo de problemas.

Para reducir las posibilidades de conflicto en el código cuando vamos a introducir un nuevo cambio:

• Obtenemos la última versión (lo que nos garantiza que no vamos a usar en ningún momento código obsoleto).
• Introducimos los cambios o nueva funcionalidad.
• Ejecutamos todos los tests; deben pasar el 100%.
• Obtenemos de nuevo la última versión. De este modo vemos si nuestros cambios han introducido algún error de compilación con los cambios introducidos por otros (o al revés).
• Antes de subir, volvemos a ejecutar todos los tests.
• Ahora sí que subimos los cambios.

De este modo reducimos radicalmente la posibilidad de conflictos.

Hay diversas opiniones sobre la frecuencia de subir los cambios (cada X horas, cuando se termina una funcionalidad completamente, etc.). Esto dependerá de la naturaleza de cada proyecto. Personalmente me siento cómodo con subir frecuentemente (varias veces al día).

Lo mejor es acordar entre los miembros del equipo el procedimiento a seguir en este proceso (check-in process): ¡mejor uno aunque no sea el mejor que ninguno!.