Diseño y testeabilidad

Este post forma parte de una serie que actualicé y consolidé. Recomiendo leer el ensayo completo.

Todo programador que lleve un tiempo en esto, ha vivido debates sobre «arquitecturas» o «patrones de diseño». Dentro de la serie que he iniciado para hablar de desarrollo de software en una PYME, creo que estos debates tienen un encaje fundamental porque una vez seleccionas tecnología tienes que darle forma de alguna manera. Y esa manera es el «diseño» o «arquitectura» de tu producto.

El «buen diseño»

Lo primero que conviene recordar es que la reducción de los tiempos de producción y mayor calidad de producto es el camino de una PYME para ofrecer el máximo valor posible al cliente. En el mercado, eso te pone en una situación favorable con respecto a tu competencia. Definiremos, pues, como «buen diseño», aquel que se pone al servicio de la producción, que permite aumentar la calidad y reducir los tiempos de desarrollo.

Podemos continuar y definirlo como flexible y mantenible, bello y que hace sentirse orgulloso al que lo crea, etc. Pero el problema no es tanto definirlo, sobre lo que existe mucha literatura, sino cómo se llega a él y cómo se mantiene a lo largo del tiempo. Porque tenemos que reconocer que no es fácil y que existen varios problemas. Para empezar, no existe un diseño universal válido sino que hay tantos como contextos, que las personas, además, insisten en tener diferentes opiniones sobre qué es un «buen diseño» y que ambas cosas se reflejan en el código – lo que fácilmente puede convertir tu producto en una torre de babel ininteligible si no se construye una visión común. Tenemos, además, estructuras de comunicación disfuncionales que provocan diseños sub-óptimos, deuda técnica y requisitos cambiantes que introducen variantes a lo largo del tiempo, rotación de personas en los equipos y distintos niveles de experiencia que dificulta la transmisión de ideas, etc. Es decir, el software, su diseño, se ve afectado por las fuerzas humanas y organizacionales. ¿Cómo podemos ponerlo a salvo? ¿Cómo asegurarnos de que las fuerzas están en equilibrio y el diseño sirve a nuestros objetivos?

Necesitamos salvaguardas que nos permitan calibrar qué es un «buen diseño» y controlar su degradación a lo largo del tiempo, herramientas que nos ayuden a caminar hacia a él y nos orienten.

Los tests como salvaguardas

Michael Feathers, en su libro «Working effectively with legacy code» desarrolla la idea de cómo trabajar con software que está degradado. Cómo, partiendo de código degradado, se puede conseguir un «buen diseño» a partir de las restricciones habituales en el día a día (tiempos limitados, código con altas dependencias, etc). Es un libro por ello interesantísimo porque te cuenta ciertas maneras de cómo llegar a ese buen diseño. Y su principal herramienta son los tests:

«When you start to try pull out individual classes for unit testing, often you have to break a lot of dependencies. Interestingly enough, you often have a lot of work to do, regardless of how “good” the design is. Pulling classes out of existing projects for testing really changes your idea of what “good” is with regard to design. It also leads you to think of software in a completely different way.»

Empatizo por completo con su visión. Sobre los tests hay poco que decir: tener o no tener, that’s the question. Porque tenerlos afecta a la producción a varios niveles:

  • El primer efecto y más obvio es que, tenerlos, reduce los tiempos más inciertos y difíciles de estimar en proyectos de software: el testeo manual que hay que hacer en cada versión y el bugfixing. En gran medida, estos tiempos son los que suelen determinar que un proyecto sea o no rentable.
  • Otro efecto un poco más indirecto es que, para desarrollar software testeable, necesitamos dividirlo en trocitos, evitar y romper las dependencias. Es decir, estamos en la dirección de desarrollar software reutilizable, reducir la complejidad.
  • Quizás un poco más sutiles sean los efectos a nivel personal, pero no menos importantes. Por un lado, aportan seguridad y confianza en tu trabajo a posteriori ya que tienes algo objetivo y automático que te dice que funciona. Pero es que además, durante el proceso, tener feedback continuo te ayuda a enfocar tu trabajo y a mantener tu moral alta a base de pequeñas victorias cotidianas. Y la moral, en tareas creativas, es un factor clave en la productividad.

Conclusiones

Tests y diseño van de la mano. Una vez has sentido sus efectos, tu visión cambia. Aprendes que un buen diseño es un diseño testeable. Porque eso es lo que te va a permitir reducir tiempos de producción y aumentar la calidad de lo que ofreces, ganarte la vida desarrollando software de un modo sostenible, que, al final, es de lo que va todo esto.


Comments

3 responses to “Diseño y testeabilidad”

  1. […] Diseño y testeabilidad (para PYMEs) Segunda parte del ensayo definitivo sobre el software para PYMEs […]

  2. […] primer post, escribría sobre cómo seleccionar tecnología; en el segundo, sobre un mecanismo para objetivar el diseño y reducir los costes de producción. En este último escribiré sobre cómo la organización del código que escribes habilita […]

Leave a Reply to La importancia de la selección tecnológica en una PYME | oandre.gal Cancel reply

Your email address will not be published. Required fields are marked *