C.H.U.T.E. – essa é a sigla que descreve um paradigma de desenvolvimento que pode ser descrito com uma lista de iterações bem pequena, que segue abaixo.

1. Escrever uma solução inteira que surgiu na cabeça, sem testes e muita análise, porque “você já sabe”.
2. Rodar o software é encontrar um problema.
3. Alterar um trecho do código escrito adicionando o if para um caso específico.
4. Repetir 2 e 3 até ter uma solução que roda.
5. Git add, commit -m”resolvido bug x”, push master.

Essa metodologia também pode ser descrita como Desenvolvimento por experimentação, ou método tentativa e erro, M.T.E.

Não há nada de errado com M.T.E, a não ser o fato de que ele deve ser usado para descoberta, e não para criação. Primeiro você descobre e depois cria.

M.T.E. é para descoberta e não para desenvolver.

Desenvolver colocando código que acredita funcionar e depois ir tratando os efeitos colaterais é a melhor maneira de cruzar um gremilin com um panda, um ornitorrinco e um fusca quebrado. É grande, é triste porque já foi muito bom, consome muito bambu e fica fora de controle quando você joga água, ou lágrimas.

Não cruze um gremilin com um panda, um ornitorrinco e um fusca quebrado.

Às vezes, se faz MTE sem perceber, repetindo o ato de trocar o valor de um parâmetro na esperança de um algoritmo funcionar #sóQueNão, mas é definitivamente fácil identificar quando você chegou nesse ponto – basta prestar atenção na sensação fé. Tenho fé de que o problema está aqui…

Tenho fé de que o problema está aqui…

A abordagem de M.T.E. pode entregar um resultado, mas existe uma diferença entre o que o programador acha que está entregando e o que o programador que depois vai lidar com o código tem certeza de que recebeu.

Aquele que escreve acredita que resolveu um bug, e sorri com a medalha no peito; já aquele que recebe o código depois tem certeza de que recebeu um problema ou vários.

Por exemplo, chega um ticket de bug e o programador que o recebe decide que o bug está num método específico. Quando digo que decide é porque ele se apega àquele método e dentro dele vai escrever o que for preciso para dar #FIX no bug.

Você não decide em qual método está o bug ou onde vai resolver, não antes de ser convencido pelas evidências. Você tem que analisar e coletar evidências.

Seja convencido pelas evidências. Analise o problema.

Condicionais para um input dependendo do valor

Observe se o método começa a receber muitos casos de exceção, ou seja, tem comportamentos diferentes para o mesmo input dependendo do valor. Talvez seja o caso de subir um pouco mais a análise e dar uma olhada nos métodos que são clientes desse método a que você está apegado.

É como esquecer um ponto e vírgula na linha 13 e ver o erro ser lançado como linha 14.

Se para lidar com o bug você adiciona mais parâmetros ao método.

Parâmetro passado para o método para ajudar com sua estratégia de administração do bug não resolve o problema, ele administra os efeitos colaterais da existência dele.

Ele controlou o efeito colateral do bug, não resolveu.

Não confunda consertar o casco do barco com usar um balde maior para tirar água.

Alias, o bug surge mesmo que não tenha ninguém de olho no código. Principalmente nesse caso.