Código Limpo – Bom Código – Parte I

Publicado por

A partir desse pequeno artigo, pretendo abordar um assunto de suma importância para nós programadores. Como podemos identificar bons códigos? O que podemos considerar um bom código? Quais critérios precisamos utilizar para podemos dizer que o código esta limpo e pode ser considerado um bom código?

Sejam bem vindos a essa série de artigos, o objetivo de todo trabalho é estarmos habilitados a escrever bons códigos e aos poucos podermos nos considerar bons programadores.

Não irei atentar a frases bonitas bem elaboradas, utilizando a concordância verbal perfeita e a maneira mais polida de falar sobre os temas que irei abortar. Então me perdoem se não estiver a contento, conto com a compreensão de todos.

Vamos ao que nos interessa, irei separar em tópicos tudo que considerar importante para termos ao final do trabalho um bom código. Contudo, quero chamar a atenção dos amigos que escrever um bom código não se trata apenas de seguir as boas práticas de programação, aplicar corretamente os conceitos de programação orientada a objeto, ter uma identação perfeita etc.

Um bom código precisa ser eficiente, e atender ao requisito apresentado, precisa ser de fácil leitura, precisa estar organizado, precisa ser em outras palavras coerente. Então vamos falar do primeiro critério de avaliação para um bom código.

Análise de Requisitos

Sim, item fundamental para que não percamos tempo desenvolvendo algo errado por não entender qual resultado final nosso código deve gerar. Analisar os requisitos para determinada funcionalidade, vai além de dedicar alguns minutos pensando e partir para o código feito louco. Jamais façam isso, por mais que a ansiedade de começar a produzir código seja grande, lembrem-se que ao analisarmos os requisitos com calma, criarmos diagramas de sequência, listarmos as partes que serão afetadas, etc. Tudo isso já é estar produzindo. Então você jamais deve se considerar improdutivo se passar um ou dois dias fazendo a análise minuciosa do requisito, levantando dúvidas e entendendo a funcionalidade para então podermos escrever um código eficaz e legível.

Adicionar Funcionalidades ao Código

Não é raro estarmos trabalhando em determinado projeto com meia dúvida de requisitos listados, analisados, estudados, discutidos, e então começado a ser transcrito para o código da máquina, e um novo requisito aparece!

A capacidade de abstrair e entender o que o cliente precisa para dentro de um código é algo de suma importância, mas infelizmente não podemos prever novas ideias que o cliente apresenta no decorrer do projeto e que chegam a nós como um novo requisito a ser incorporado ao sistema.

Com certeza essa situação pouco a pouco se torna um grande pesadelo, pois teremos no mínimo dois impactos catastróficos por assim dizer. Primeiro, o prazo definido para a entrega do sistema dificilmente irá mudar, e voce estar atrasado. Segundo tentar adaptar a nova funcionalidade, por mais simples que pareça pode destruir nosso código. Nesse momento o bom código desaparece e a pressa para entregar no prazo aliada a necessidade de não falhar e fazer com que o requisito funcione com o menor esforço, obrigado os programadores a cometer um erro inadmissível. Criar uma pequena Gambiarra tenho certeza que os amigos ja conhecem essa palavra, e mais certeza de que um dia, vocês fizeram uma. Para atender um prazo, para facilitar sua vida naquele momento, etc. Motivos para uma que uma gambiarra seja feita normalmente não faltam.

Infelizmente uma leva a outra que leva a outra que caracteriza nosso código como um lixo. Sim estou sendo severo utilizando esse termo, mas se faz necessário para chamar a atenção do amigo(a) leitor(a) como é importante evitar essa abordagem. Afinal, quem irá fazer a manutenção no código? Provavelmente vocês, então quem irá se arrepender desse atalho? Com certeza vocês.

Então declaro aqui a minha primeira regra inalterável. Gambiarra Jamais!!!!!!

Eu entendo que muitas vezes estamos pressionados pelo chefe para terminar o projeto. Muitas vezes estamos pensando no backlog e em todas as outras coisas que voce prometeu fazer, afinal você quer ser um bom funcionário, talvez até receber um premio, bônus ou algo assim. Então você é aquele funcionário que diz “Sim Senhor” para tudo. Cuidado meu amigo isso pode lhe colocar em uma armadilha e obrigá-lo a escrever um código ruim para atender toda demanda.

Infelizmente o dia que esse código passar por uma análise e você for julgado como um mau programador por ter escrito um código ruim ou feito uma gambiarra, ninguém vai lembrar da quantidade de trabalho que você tinha e quanto estava produzindo deixando assim os chefes felizes. Lembre, em nossa profissão, tempo é dinheiro.

Finalizamos por aqui, em breve estarei publicando a parte II, meu objetivo é manter a sequência de um pequeno artigo por dia.

Até Breve e Bons Códigos a todos!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s