Como desarrollar un código a prueba de cambios

código a prueba de cambios

código a prueba de cambios

Como desarrollar un código a prueba de cambios

Empecemos viendo un par de técnicas para mejorar nuestra comunicación e interacción con el personal (cliente) que se encarga de definir los requisitos.

El método MoSCoW (Must, Should, Could, Won’t)

Se aplica antes de iniciar la fase de desarrollo y sirve para priorizar los requisitos de las entregas en 4 niveles:

  1. Mínimos para considerar la entrega completada (Must)
  2. Importantes pero negociables (Should)
  3. Deseables pero no prioritarios (Could)
  4. Descartados para esta entrega (Won’t)

Con este método se fija el alcance del producto a priori y así se evitan malentendidos en el momento de la entrega. Además, el cumplimiento de los tres primeros puntos nos puede servir para cuantificar el éxito del entregable.

La filosofía RERO (Release Early, Release Often)

Esta filosofía apuesta por una política de despliegues muy

frecuentes para poder recibir feedback del usuario o cliente lo antes posible.

Esta forma de trabajar suele utilizarse en entornos cerrados donde el acceso está restringido a los desarrolladores, el equipo de pruebas y algunos usuarios finales, pero algunas veces, sobretodo en startups, también se usa en entornos de producción.

La finalidad de esta metodología es no desviarnos de lo que el cliente realmente quiere. Al tener un entorno siempre actualizado con los últimos cambios, éste tiene la oportunidad de supervisar los avances y detectar cualquier desviación en la entrega.

La experiencia nos demuestra que seguir estas técnicas se acaba traduciendo en una clara mejora en la relación desarrollo – producto que acaba resultando beneficiosa para ambas partes.

Una vez cubiertos los requisitos, veamos cómo mejorar nuestras habilidades de programación a través de tres de los principios más populares del mundo del desarrollo:

DRY Don’t Repeat Yourself: No repitas código, abstráelo y reúsalo.

KISS Keep It Simple, Stupid!: Mantén tu código simple y evita complejidad innecesaria.

YAGNI You Ain’t Gonna Need It: No añadas ninguna funcionalidad que no vayas a usar.

Pueden sonar triviales pero aplicarlos en el día a día no es tan sencillo como parece. Las fechas de entrega juegan en nuestra contra y su aplicación suele posponerse a la fase de refactor, una de las más importantes del ciclo de desarrollo.

Veamos una serie de consejos prácticos para cumplir estos principios.

DRY Usa patrones de diseño software, en especial los estructurales como por ejemplo el adaptador (Adapter), el objeto compuesto (Composite) o el envoltorio (Decorator).

KISS Evita el spaghetti code dividiendo las funciones enormes en subfunciones y minimiza las dependencias siempre que puedas.

YAGNI Escribe las pruebas primero (Test First Development) y desarrolla el código después. Esta práctica se conoce como Test-Driven Development (TDD)3.