Discussão do artigo "Desenvolvendo um cliente MQTT para Metatrader 5: uma abordagem TDD — Parte 6"
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Novo artigo Desenvolvendo um cliente MQTT para Metatrader 5: uma abordagem TDD — Parte 6 foi publicado:
Este artigo é a sexta parte de uma série que descreve nossas etapas de desenvolvimento de um cliente MQL5 nativo para o protocolo MQTT 5.0. Nesta parte, comentamos as principais mudanças em nosso primeiro refatoramento, como chegamos a um modelo viável para nossas classes de construção de pacotes, como estamos construindo pacotes PUBLISH e PUBACK, e a semântica por trás dos Códigos de Motivo PUBACK.
A metodologia de Desenvolvimento Orientado a Testes oferece muitos benefícios e tem uma grande desvantagem. Entre os benefícios, ela nos ajuda a escrever unidades bem definidas e variáveis bem nomeadas, alcançar alta cobertura de testes, ter uma melhor compreensão do domínio, evitar superengenharia e manter o foco na tarefa em mãos. A principal desvantagem é uma consequência direta desse foco estreito na tarefa em mãos, ou seja, para evitar ser assustado pela complexidade geral do projeto, nós, como desenvolvedores, continuamos resolvendo o menor desafio possível de cada vez, e apenas um desafio de cada vez. Se o gênio é a pessoa que remove a complexidade resolvendo-a, o desenvolvedor TDD é a pessoa que deliberadamente ignora a complexidade.
Sim, você entendeu: muito parecido com cavalos usando antolhos, muito parecido com aquele burro seguindo a cenoura.
Mas a complexidade não desaparece porque a ignoramos. Ela fica lá, esperando que a enfrentemos. Ao ignorar a floresta para olhar de perto a folha, continuamos deixando uma dívida técnica para trás. Continuamos deixando funções redundantes, membros duplicados, testes inúteis, classes desnecessárias, código ilegível e inacessível, você sabe. Essa dívida técnica acumulada durante o desenvolvimento pode ser prejudicial à nossa produtividade. É por isso que o refatoramento é uma parte integrante da prática de TDD. O diagrama abaixo mostra as etapas típicas de uma prática de TDD.
Fig. 01 - As Etapas Típicas de uma Prática de TDD: Vermelho, Verde, Refatoração (Fonte: IBM Developer)
Autor: Jocimar Lopes