Faça parte da nossa comunidade VIP

Tenha acesso a conteúdos exclusivos

Não enviamos spam. Seu e-mail está 100% seguro!

Você tem dificuldade de fazer estimativa? Então seu código é ruim!

Você tem dificuldade de fazer estimativa? Então seu código é ruim!

Quanto tempo você demoraria para encontrar um par de meias brancas nesse quarto acima?

Posso levar 2 minutos ou 2 horas

Mas Bruno Por que uma estimativa TÃO DISTANTE ASSIM DA OUTRA? Elementar meu caro Watson. por 2 motivos:

  1. Nunca vi esse quarto (código diferente que você nunca viu, sistema que você nunca participou )
  2. Não sei onde ficam as meias. Eu não tenho nenhuma dica, eu vou ter que revirar tudo. Depois de muito tempo eu acho apenas uma meia branca. Mais um pouco de tempo procurando, finalmente acho outra meia. Mas tem um problema: é uma meia preta  =(. ( sistemas com códigos sujos)

E agora, façam de novo uma estimativa com essa imagem abaixo. Quanto tempo?

quarto arrumado

Se você falou menos do que o anterior (muito menos), nós podemos começar a refletir em algumas coisas:

1- Como você sabe se ainda não falei onde estão as meias. Ah, eu sei, você já tinha visto esse quarto antes (já mexeu nesse sistema antes).

“Não, nunca tinha visto esse quarto antes. Mas algo me diz que será mais fácil que o anterior”. Mas olha que interessante, mesmo sem você nunca ter visto esse quarto, o mais importante: você já sabe onde não está. Inclusive o local é maior que o anterior. Mas por ele estar mais organizado, você provavelmente gastará menos tempo.

Aqui provavelmente vai ter uma gaveta escrito meias, separadas por cores. Pronto, achei. Fácil, sei por onde começar. Consigo estimar melhor o tempo que irei gastar. Diferente do sistema abaixo:

Código sem refator. Bad smells =(

Por onde começar? Quanto tempo até encontrar o fio certo? Qual a chance de se errar o fio? Qual o risco do “sistema” parar por causa da sua alteração e gastar mais tempo resolvendo uma coisa que não fazia parte do escopo inicial?

E se seu código pudesse ser diferente do de cima. Se fosse mais parecido com a imagem abaixo:

Fios arrumados
Código com Refactor =)

Esse mundo parece ser bem melhor, concordam?

Esse é um custo escondido de um código ruim:

Um código ruim leva a dificuldade de se fazer estimativas

2 -Grande parte do trabalho do programador é encontrar coisas, encontrar o local onde ocorre o bug, encontrar o local onde será feita uma manutenção ou até mesmo o local onde ele vai adicionar uma nova funcionalidade, assim como procurar o par de meias.

Quem aqui já passou 7, 14, 21 horas revirando código, revirando, abrindo subclasses, procurando valores no banco de dados, e ai a solução depois disso tudo é alterar:

  • uma linha de código
  • um IF, uma cláusula de condição
  • uma variável que estava sendo atribuída de maneira errada.

Imagina que seu gerente olha no github o histórico de linhas de código alteradas x tempo gasto. Qual seria a reação dele? Por que uma linha de código levou tanto tempo assim? Não existe uma explicação plausível para você ter gastado um dia inteiro para alterar essa linha. Eu acho que ele ficou o dia todo no Netflix ou viajando no Youtube.

A resposta é sim, existe uma explicação plausível e simples: Todos os desenvolvedores passam a maior parte do tempo lendo código em vez de escrevendo.

Pera pera pera. A maior parte do esforço não deveria estar em escrever código novo? Parece que não é bem assim.

Se todos passam mais tempo lendo código do que escrevendo, a maior parte do esforço não deveria estar em escrever código bom para se ler, para conseguirmos ser rápidos em entender e poder escrever nosso código novo?

Quantos de vocês antes de escrever já chegaram numa situação onde a aba do Visual Studio ou Elicpse está assim, lotada de classes abertas para finalmente alterar uma função?

abas abertas

Estamos constantemente lendo código antigo como parte do esforço para escrever um novo código.

De fato, a proporção do tempo gasto lendo e escrevendo está bem acima de 10:1

Como essa proporção é tão alta, queremos que a leitura do código seja fácil, mesmo que isso faça a escrita mais difícil.

O código que o primeiro programador escrever, vai ser o código que o próximo irá ler.

várias mudanças no código

Imaginem o seguinte cenário:

  • Fabiano encontrou um código muito ruim e gastou 1 hora refatorando.
  • Bruno economizou 2 horas de leitura com o código que Fabiano alterou que agora está muito fácil de entender e em apenas 1 hora na sua manutenção. Aproveitou o tempo extra e modularizou mais um pouco o código que Fabiano fez.
  • Luna conseguiu reusar o código pois estava modularizado e economizou 3 horas de serviço. Antes era impossível para Luna fazer isso de primeira. Provavelmente, ele iria fazer outro código novo que faz a mesma coisa em outro lugar.

Se a cada alteração/ inserção de código novo for cada vez piorando o código do sistema em vez de melhorar, a ponto de você ter que ficar de ponta a cabeça para entender o que foi feito, será muito difícil você escrever novos códigos. Pior, isso vai custar muito mais $$$$$$, seja do cliente, seja da empresa, seja do órgão público.

Não há como escapar dessa lógica.

Você não pode escrever código novo se não puder ler código antigo. Se você quiser que seu código novo seja fácil de escrever, faça todos fácil de ler.

Se você quer melhorar suas estimativas, invista em refactor e torne seu código limpo. Mas como faço isso? Calma, iremos mostrar passo a passo como limpar o seu código.

limpando o código

Sobre o Autor

0 Comentários

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *