Faça parte da nossa comunidade VIP

Tenha acesso a conteúdos exclusivos

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

Por que escrever código bom se código ruim funciona?

Por que escrever código bom se código ruim funciona?

Resumidamente: Você precisa entender os motivos e custos escondidos em um código ruim, de má qualidade, para que você fique convencido de que vale a pena mudar seu jeito de “codar”. Vale a pena escrever um código bom porque:

  1. Se você tem dificuldade de se fazer estimativa, seu código é ruim.
  2. Se você tem dificuldade de fazer testes , seu código é ruim,
var convenceu = false;
while(!convenceu){
leitura++;
}

Computador ligado. Uma hora tentando fazer um código funcionar. Um programador fazendo diversos try catch, verificações de “is not null” que sempre quebravam a execução e quando menos se espera: Vualá! Funcionou. Pronto. Ufa! Serviço Feito. Vou até levantar e tomar uma água (para muitos, um café). Mas antes, deixa eu mover a task da Sprint para Done. Afinal, não podemos baixar a produtividade do time.

Esse parece ser o dia a dia comum de vários programadores em diversas organizações, start-ups, órgãos públicos, home offices.

Tem algo de errado nessa abordagem? Afinal, o código funcionou! Falta teste? Hummmm. Assim, fiz eu mesmo uns testes e deu certo em todos aqui na minha maquina. Não vamos ter tempo de fazer um teste mais “formalizado”. A Sprint esta apertada. Vamos para frente!

Após dois meses desse código rodando em produção, surge um chamado para um caso muito comum que deveria estar sendo tratado e está gerando erro atrás de erro. Abro o código fonte e vejo isso aqui:

Olho para esse código novamente, tentando entender a lógica que foi utilizada e digo: “Pessoal, quem fez isso aqui? Não tô entendendo nada. Preciso de uma dica de quem fez. Apesar de ser um código pequeno, talvez eu gaste uma hora ou mais para saber onde está o problema com esse código”. Já que ninguém assumiu, pois filho feio não tem pai, eu vou ver quem fez o commit no git blame. Mas…mas..mas. Ora ora pequeno gafanhoto, foi você mesmo quem fez esse commit e esqueceu?

gambiarra
Não precisa de legenda.=P

Gambiarra funciona, certo? Todos sabem como elas resolvem rapidamente nossos problemas. Não é talvez muito elegante, mas, quem precisa de elegância? Precisamos de código funcionando. Essa é a métrica!

Por que eu deveria alterar algo que funciona?  Não faz sentido?  Refactor é perda de tempo, não gera novas funcionalidades e não ajuda no gráfico de burndown.

Só existe uma boa resposta para se alterar uma gambiarra: por conta da sua fragilidade. Se alguém colocar a mão, para de funcionar. Isso é um programa frágil. Vamos alterar o mínimo possível. Qualquer manutenção pode colocar em risco o funcionamento de toda o resto do sistema.

Mas isso não acontece só com as gambiarras. Quando vejo um código de má qualidade eu também tenho medo de colocar a mão e de algo parar de funcionar. Módulos que se alteram e começam a dar erros em outros lugares quando tentamos minimamente colocar alguns parâmetros a mais nas funções. Fazemos a alteração e erros de execução em outros locais começam a pipocar igual uma pipoqueira com a tampa aberta. “Acho melhor fazer tudo do zero”, alguém diz, pois vai dar menos trabalho do que alterar. E aí vem o maior fracasso de um programador: Quando o grupo de negócio  (ou gerente do projeto ou Scrum master) diz:

Até segunda ordem, para manter a estabilidade desse módulo, ninguém mexe nele!

Isso leva a um fato corriqueiro ao qual poucos programadores se atentam: Em geral, o primeiro código que fazemos em uma funcionalidade nova ou manutenção é um código desse tipo. Um código que até funciona, mas um código que no futuro teremos medo de colocar a mão.

Segundo Martin Fowler ,

“Qualquer tolo consegue escrever código que um computador consiga entender. Bons programadores escrevem código que humanos entendem.”

É possível depois de anos programando  códigos ruins e sujos, produzir códigos bons e limpos? A resposta é sim. Se você quer dar esse  passo para se tornar um programador/programadora melhor, continue acompanhando nossa série de clean code. Iremos abordar esse assunto e você definitivamente vai descobrir como melhorar esse soft skill para se tornar, a partir de hoje, um verdadeiro developer.

2 Comentários

  1. Só li verdades… mas será que os “donos dos projetos” permitem “demorar” para ter um código melhor ou a culpa é mais do programador mesmo?

  2. MIKE WESLEY BLUNK disse:

    Sou gerente de projeto e creio que o demandante tem culpa na produção de um produto ruim, ou código ruim, principalmente quando pede um produto “para ontem”, como ouvi recentemente.
    Creio que o programador também tem culpa, mesmo que involuntariamente. Na minha formação acadêmica não lembro ter der aprendido nada de significativo sobre qualidade de código, importância prática de usar testes ou algo do tipo.


Deixe uma resposta

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