Se um bug surge e o programador não vê, ele surgiu mesmo?

Cálculo hipotético universal trigonométrico estatístico!!! ou se um bug surge sem um programador ver, ele surgiu mesmo?!

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, por que “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.
  • Repetir 2 e 3 até ter uma solução que roda.
  • 4- 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. Eh grande, é triste pq 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.

As 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é que o problema está aqui…

Tenho fé 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 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 que recebeu um problema ou vários.

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

Você não decide em qual método esta o bug ou onde vai resolve, não antes de ser convencido pelas evidências. Voce 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.

Escrever duas funções e anotar a cliente, a que consome a outra é usar como exemplo no padrão de “subir análise”.

É 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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s