Desarrollo, pruebas, refactoring, (todo va en el mismo paquete)
«Creamos software de producción, lo probamos con tests que podemos automatizar y nos paramos un segundo a preguntarnos ¿puedo mejorar esto o aquello? Estos son los hábitos que debemos incorporar a nuestro arte de programar, la deuda de no incluirlos a nuestro ADN de programadores profesionales es demasiado alta.»
Recuerdo que los primeros años de universidad siempre hacen la analogía de que programar es muy similar a una receta de cocina, donde tenemos un conjunto de ingredientes que representan nuestros datos y también tenemos una receta que representa nuestro algoritmo o nuestros pasos a seguir para que el plato de comida salga bien.
Podemos decir que es una analogía válida pero no es la más precisa, puesto que una vez terminado el plato y si es que hacemos todo bien, el comensal o cliente estará satisfecho y ya, no hay que decir o explicar nada más, es un proceso cerrado donde no hay más que hacer.
Ahora bien, una analogía mas precisa es la del jardín.
Programar es como la jardinería, puesto que a diferencia de un plato de cocina, la jardinería es una actividad de control constante, no podemos simplemente podar nuestras plantas, abonarlas y regarlas una vez y ya, tenemos que realizar esto de manera periódica, cuidado que no salgan hierbas malas que infestan el jardín, teniendo cuidado de posibles plagas o insectos que matan las plantas, entres otros.
Si no se hace lo que se debe en un jardín, a largo plazo será muy complicado poderlo mantener, y muy costoso también. Del mismo modo si tenemos una deuda técnica con nuestro software, a la larga será caro y difícil poder realizar cambios que solicite el cliente, o corregir bugs, etc.
Más que «cocineros» somos «jarnineros».
Deuda técnica
Según Rafael Gómez Blanes los desarrolladores de software no conocemos (o no nos han enseñado) buenos hábitos de programación para el día a día, nos gusta empezar a escribir código y tener un prototipo funcionando cuando antes sin asegurarnos lo suficientemente bien que lo que vamos construyendo tiene que ser probado de la manera adecuada.
Este es uno de nuestros mayores vicios: creamos software de producción sin software que lo pruebe o respalde y nos muestre a nosotros mismos que funciona. — Rafael Gómez Blanes
En este apartado del libro el autor hace una referencia a la deuda técnica que existe en un proyecto, por deuda técnica se entiende todas las tareas adicionales que se deben realizar para que el proyecto sea sostenible a largo plazo
Algunos ejemplos de deuda técnica serán:
- Escribir código sin una arquitectura de software sustentable.
- Usar tecnologías obsoletas.
- Falta de documentación
- Ausencia de actualización de dependencias del proyecto.
Y, quiza, la deuda técnica por excelencia: No escribir test
Testing
El autor identifica 3 razones por las cuales no escribimos test:
No estamos acostumbrados a escribir código enfocado a pruebas, puede que el software esté escrito bien y que funcione pero quizá no sea posible testearlo de manera automática.
No percibimos el **«coste oculto» que tiene no implementar pruebas**. Volviendo al jardín, dejamos que crezcan hierbas malas que lo dañan y que mientras más tardemos en arreglar, más difícil y costoso será.
Nadie nos obliga a hacer pruebas. Si no convives con un grupo de trabajo mentalizado en que se debe hacer software de producción soportado por pruebas, tú no vas a convertirte en el «rarito» que avance de esa manera.
Dime si usarias un auto que no fue testeado por ejemplo contra choques fuertes, ¿lo usarías? O por otro lado, si te proponen ponerte una vacuna sin probarla antes, ¿te animarias?
Muchas devs argumentan: «De acuerdo, me convenciste que hacer pruebas es una buena práctica pero, en casi todos los proyectos los tiempos de desarrollo son muy problemáticos y escasos, si ni siquiera tenemos tiempo de acabar con las actividades del proyecto, ¿como sacar tiempo para escribir pruebas?»
Lo óptimo y adecuado (y lo que no pasa en la vida real) es tener un equipo de testers en el proyecto que se encarguen de realizar estas pruebas, pero esto no ocurre. ¿En cuántos proyectos has trabajado donde haya un grupo de testers que solo se dediquen a hacer pruebas?
¿Qué hacer para subsanar esto?
- Aprender a escribir código con patrones de diseño robustos, como por ejemplo S.O.L.I.D., KISS* o **DRY. Hay mucha información sobre estos temas en internet.
- Las herramientas de testing no son complicadas de usar o aprender, al menos saber lo básico, es muy importante.
- No poner como excusa el no escribir pruebas, como profesionales y desarrolladores como mínimo estamos obligados a escribir pruebas unitarias a la ruta crítica del proyecto.
Más detalles sobre esto en el podcast de Fernando Herrera:
Refactoring
Programo, ergo refactorizo.
«Refactoring» y no es más que buscar cómo mejorar o simplificar lo que ya tenemos desarrollado.
Lo bueno de los test es que nos ayudan a darnos cuenta cómo podemos mejorar nuestro código, contemplar casos de uso que inicialmente no los apreciamos, etc., en pocas palabras mejorar y poder escribir programas de mejor calidad a largo plazo.
Como desarrolladores debemos tener siempre presentes que nuestro código puede mejorar, una vez acaba una feature debemos preguntarnos: ¿cómo puedo mejorar este código? ¿puedo escribirlo de una manera más legible u óptima? Los test sirven mucho para esto.
Para nosotros los devs, la famosa ley de Pareto del 80/20 aplica así: 20% para escribir código, 80% para leer código y depurarlo.
Conclusiones
- Intentar que nuestro código está respaldado por pruebas.
- El coste de tener deuda técnica, a la larga provocará que el software se resista a cambios y sea más costoso.
- Siempre debemos preguntarnos si nuestro código puede ser mejorado o simplificado.
- Las pruebas deben ser de calidad.
Te dejo el link gratuito de El libro negro de programador por si te intesa leerlo, o dale click a la imagen:
Top comments (0)