El desarrollo de software como un proceso de aprendizaje

Casi todos los proyectos de software tienen un componente que lo hace único. Ese componente puede referirse a las personas del equipo trabajando juntas, el negocio de la aplicación, la tecnología que se utiliza o, lo más probable, una combinación de todo.

A pesar de nuestros esfuerzos, experiencia y disciplina, casi todos los proyectos tienen elementos de sorpresa. Los proyectos interesantes que resuelven problemas reales a los clientes, suelen tener muchas sorpresas.

Es habitual que los desarrolladores a menudo no conozcamos en profundidad la tecnología utilizada. Tenemos que aprenderla a medida que avanza el desarrollo del proyecto. Incluso si tenemos un buen conocimiento de la tecnología, el nuevo negocio puede requerir usos desconocidos de las mismas. Lo habitual es que un sistema combine muchas variables con la mezcla, negocio y tecnología.

Lo que significa que será demasiado complejo para que cualquier persona comprender todo su alcance a lo largo del tiempo. Además, necesitamos aprender a trabajar con la incertidumbre de futuros y constantes cambios.

Para los clientes y usuarios finales, la experiencia suele ser peor. El proceso de construcción de un sistema les obliga a observar su organización más de cerca que antes. Y cambiar requisitos a medida que avanza el desarrollo, buscando el mayor valor para el negocio.

Todos los involucrados en un proyecto de software tienen que aprender a medida que avanza. Para que el proyecto tenga éxito, las personas involucradas deben trabajar juntas. Todos deberíamos saber, que en un proyecto habrá cambios a medida que se avanza, simplemente no sabemos qué cambios.

Es necesario contar con una serie de prácticas que nos ayude a hacer frente a la incertidumbre y las sorpresas a medida que avanza el proyecto.

Feedback temprano

Una de las mejores prácticas que ayuda a gestionar la incertidumbre en un proyecto es usar feedback.

Podemos tener feedback interno en nuestra metodología de desarrollar y también feedback externo del cliente o de los usuarios. Cuanto más frecuente sea este feedback, tendremos mayores oportunidades de ir corrigiendo el desarrollo del software basándose en nuestro aprendizaje y el del cliente. Por lo tanto, es ideal que los ciclos de desarrollo sean cortos y siempre aportando valor que pueda validarse.

En nuestro trabajo, aplicamos ciclos de feedback en todos los niveles de desarrollo, tales como: pair programming, pruebas unitarias, pruebas de aceptación, reuniones diarias cortas, iteraciones, lanzamientos, etc. . Cada ciclo se expone a feedback para descubrir y corregir cualquier error o concepto erróneo.

Cada tipo de feedback aborda diferentes aspectos del sistema y del proceso de desarrollo. El feedback interno se centran más en los detalles técnicos: lo que hacen partes específicas del código, cómo se integra con otros sistemas. El feedback externo se centran más en la organización y el equipo: si la aplicación satisface las necesidades de los usuarios, si el equipo es tan eficaz como podría ser.

Cuanto antes podamos recibir feedback sobre cualquier aspecto del proyecto, mejor.

Soportando el cambio

Necesitamos prácticas para hacer crecer un sistema de forma segura y hacer frente a los cambios imprevistos que siempre suceden.

En primer lugar, es importante un testing constante para detectar errores de regresión, por lo que podemos agregar nuevas funciones, sin romper las existentes.

Para sistemas de cualquier tamaño interesante, el testing manual frecuente es poco práctico, por lo que debemos automatizar las pruebas tanto como podamos para reducir el coste de construir, implementar y modificar versiones del sistema.

En segundo lugar, debemos mantener el código lo más simple posible, para que sea más fácil entenderlo y modificarlo. Los desarrolladores dedicamos mucho más tiempo a leer el código que a escribirlo, por lo que debemos optimizarlo.

La simplicidad requiere esfuerzo, por lo que constantemente deberíamos refactorizar nuestro código a medida que trabajamos con él, para mejorar y simplificar su diseño, eliminar la duplicación y garantizar que exprese claramente lo que hace.

Disfrutando de escribir test

El problema es que pocos desarrolladores disfrutan escribiendo tests. Existe una cultura generalizada donde escribir pruebas automatizadas no se considera un trabajo "real" en comparación con agregar funcionalidades, y también se considera aburrido.

Test-Driven Development (TDD) le da la vuelta a esta situación. Escribimos nuestras pruebas antes de escribir el código. En lugar de utilizar simplemente las pruebas como una forma de verificar nuestro trabajo una vez realizado, TDD convierte las pruebas en una actividad de diseño. Escribir una prueba primero también nos brinda un feedback rápido sobre la calidad de nuestras ideas de diseño. TDD nos ayuda a escribir código más simple.

Existe un efecto secundario al usar TDD. Construimos una red de seguridad de pruebas de regresión automatizadas que nos dan la confianza para hacer futuros cambios.

Conclusiones

El desarrollo de software es un proceso de aprendizaje continuo y el feedback frecuente es la solución para aprender y aplicarlo en ciclos cortos.

La sensación de trabajar en un proyecto que aplica lo visto de forma correcta es similar a trabajar en un proyecto nuevo de forma constante. Con la seguridad de que podemos concentrarnos en la tarea que tenemos entre manos, seguros de que estamos haciendo el trabajo correcto y en caso de romper comportamiento existente, contamos con una red de seguridad de tests.

Una buena arquitectura de software es esencial para tener una calidad en el código que permita apoyarse en feedback constante que nos ayude con las incertidumbres de cualquier proyecto de software. Puedes apuntarte a la lista de espera de la próxima edición del curso de Clean Architecture:

Curso Clean Architecture en abierto - Lista de Espera

¿Te ha gustado esta newsletter?

El mejor regalo de agradecimiento que me puedes hacer es compartirla 👇

Te animo a que me des tu opinión, o me transmitas dudas en los comentarios de esta newsletter desde la web o respondiendo a este correo.

A veces tardo, pero siempre acabo contestando.