Discusión sobre el artículo "Desarrollando un cliente MQTT para MetaTrader 5: metodología TDD (Parte 6)"
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Artículo publicado Desarrollando un cliente MQTT para MetaTrader 5: metodología TDD (Parte 6):
Este artículo supone la sexta parte de la serie que describe las etapas de desarrollo de un cliente MQL5 nativo para el protocolo MQTT 5.0. En esta parte, describiremos los principales cambios en nuestra primera refactorización, obteniendo un borrador de trabajo de nuestras clases de construcción de paquetes, creando los paquetes PUBLISH y PUBACK y la semántica de los códigos de motivo PUBACK.
La metodología Test-Driven Development (TDD) ofrece muchas ventajas y tiene un inconveniente importante. Nos ayuda a escribir módulos bien definidos y variables con nombres adecuados para lograr una amplia cobertura de las pruebas, comprender mejor el tema, evitar una complicación excesiva y centrarnos en la tarea que tenemos entre manos. El principal inconveniente es consecuencia directa de este estrecho enfoque en la tarea que nos ocupa: para evitar sentirnos intimidados por la complejidad global del proyecto, los desarrolladores seguimos abordando la tarea más pequeña posible cada vez. Si un genio es alguien que elimina la complejidad resolviéndola, entonces podemos decir que un desarrollador TDD es alguien que ignora deliberadamente la complejidad.
Puede compararse con un caballo con anteojeras o un burro persiguiendo una zanahoria.
La complejidad no va a desaparecer porque la ignoremos. Ignorando el bosque y escudriñando la hoja, seguiremos teniendo, digamos, una deuda técnica. Así que dejaremos a un lado las funciones redundantes, los miembros duplicados, las pruebas inútiles, las clases innecesarias y el código ilegible e inaccesible. Esta deuda técnica que se acumula durante el desarrollo puede resultar perjudicial para nuestra productividad. Por este motivo, la refactorización forma parte integrante de la práctica del TDD. El siguiente esquema muestra los pasos típicos del TDD.
Figura 01. Etapas típicas de TDD: Rojo, Verde, Refactorización (fuente: IBM Developer)
Autor: Jocimar Lopes