Artigos Java Código limpo com Clean Code
Artigo do tipo Teórico
Recursos especiais neste artigo:
Conteúdo sobre boas práticas.
Código limpo com Clean Code
Neste artigo veremos uma série de tópicos relacionados principalmente à responsabilidade e profissionalismo no desenvolvimento de software. Abordaremos pontos importantes para proporcionar o aumento da qualidade do código como a programação em pares, os testes automatizados, os fundamentos da orientação a objetos, além de técnicas de refactoring e métricas de qualidade para manter o código limpo e evitar muitas dores de cabeça no futuro.

Em que situação o tema é útil
Atualmente, a maior parte das empresas sofre com problemas de qualidade de código que se refletem no acúmulo de defeitos, na insatisfação dos clientes e na dificuldade em manter os custos dos projetos em equilíbrio. Neste contexto, esse tema é fundamental para desenvolver um olhar crítico e profissional nas equipes em relação ao desenvolvimento de software, elevando seu nível de maturidade.

Escrever código com baixa qualidade, de forma ilegível e bagunçada pode até funcionar! No entanto, esse tipo de atitude, seja ela consciente ou não, resulta na contração de uma dívida que cobra juros altos, pagos com a perda constante de produtividade e motivação.

Com o tempo, o custo de desenvolvimento e manutenção do projeto aumenta, ficando cada vez mais caro e demorado criar novas funcionalidades e realizar qualquer tipo de modificação, sem falar na quantidade de defeitos.

Esse tipo de problema pode trazer prejuízos financeiros e até afetar a imagem da empresa no mercado. Outro reflexo negativo é a rotatividade da equipe, que em muitos casos acaba desistindo do projeto por não aguentar mais a pressão e o ambiente caótico.

Muitas vezes, as empresas acabam jogando projetos inteiros fora e começam tudo de novo, do zero. Será que apenas começar novamente resolverá os problemas de qualidade de código que levaram o projeto ao fracasso da primeira vez?

Neste artigo serão abordados tópicos relacionados principalmente à responsabilidade e profissionalismo no desenvolvimento de software. Pontos importantes como motivação, qualidade de código, orientação a objetos, pair programming, métricas, técnicas de refactoring, testes e boas práticas para manter o código limpo e evitar muitas dores de cabeça no futuro serão abordados.

Motivação para os desenvolvedores

Não é difícil observar desenvolvedores que encontram cada vez mais dificuldade para acordar e ter vontade de ir trabalhar todos os dias. A desmotivação ataca silenciosamente, muitas vezes sem explicação aparente, e quando percebemos já é tarde demais.

Muitos fatores podem nos levar a perder motivação: salários baixos e não revisados por um longo período, falta de um ambiente de trabalho saudável, trabalho monótono e com poucos desafios. No entanto, um dos fatores mais críticos é a sensação de fracasso profissional, de que o trabalho não tem resultado e que está sendo jogado fora.

Por conta disso, a atenção e o investimento despendido na qualidade do código produzido é um dos principais responsáveis pela retenção de profissionais e por índices de rotatividade saudáveis, além de um ambiente de trabalho menos caótico.

Nos tempos de faculdade, a principal preocupação dos jovens aspirantes a desenvolvedores é de fazer com que o software pedido pelo professor simplesmente funcione, não importando a qualidade do código, seu desempenho ou mesmo durabilidade.

Já no mercado de trabalho, é absurdo que desenvolvedores profissionais tenham a mesma postura. A ilusão do imediatismo é a principal causa da mortalidade de projetos de software que poderiam ter mais sucesso se critérios mínimos de qualidade fossem adotados.

Em 1982, James Q. Wilson e George L. Kelling escreveram um famoso artigo chamado “Janelas Quebradas” que dizia o seguinte: “Pense em um edifício com apenas algumas janelas quebradas. Se as janelas não forem reparadas, a tendência é para que vândalos quebrem mais janelas. Eventualmente, poderão inclusive entrar no edifício, e se este estiver desocupado, pode ser tomado ou até mesmo incendiado.”.

No desenvolvimento de software, a teoria das janelas quebradas pode ser entendida de uma forma até pior. Se o código está ruim, o projeto não tem testes, as exceções não são tratadas da forma correta, a tendência é que as pessoas não tenham a mínima vontade de melhorar e simplesmente continuam programando da mesma forma, agravando ainda mais a situação.

A importância do Pair Programming na qualidade do código

Por conta de uma matemática equivocada, alguns gerentes de projeto afirmam que programar em par acaba aumentando muito o tempo de desenvolvimento de um projeto de software, chegando a duplicar o tamanho do cronograma. Essa afirmação não leva em consideração uma série de fatores importantes e que ao serem ignorados podem levar um projeto inteiro ao fracasso.

Para ser produtivo como desenvolvedor é necessário foco e principalmente concentração. Infelizmente, fazem parte do nosso dia a dia inúmeras fontes de interrupção como: o chat aberto, o e-mail conectado e nos alertando de cada novo e-mail que chega a nossa caixa de entrada, telefone celular tocando, colegas ansiosos para conversar sobre os últimos acontecimentos do mundo do futebol e ainda chefes que adoram fazer reuniões a todo o momento.

Ao trabalhar em pares, a chance de responder a um chat ou e-mail, atender uma ligação ou mesmo ser incomodado pelos colegas e até pelo chefe é reduzida imensamente, contribuindo para o aumento da produtividade. Muitos pensam, “Se eles estão juntos e concentrados trabalhando, deve ser algo importante, melhor deixar a conversa para outra hora!”.

Outra coisa que impacta nossa produtividade é trabalhar em partes desconhecidas do sistema. Descobrir onde está e como funciona o código responsável por processar uma determinada regra de negócio pode levar um bom tempo. Ações como a programação em par podem auxiliar imensamente na disseminação de conhecimento dentro da equipe, reduzindo a dependência dos autores do código, eliminando gargalos e facilitando os processos de gestão. Trabalhar junto por algumas semanas é uma excelente maneira de receber um novo desenvolvedor na equipe, reduzindo imensamente a curva de aprendizado.

Quando pensamos na qualidade do que é produzido, a programação em par apresenta resultados extremamente positivos. Aquela velha frase que diz: “Duas cabeças pensam melhor que uma”, que inclusive é defendida em inúmeros estudos científicos, se mostra muito eficaz, já que a melhor decisão geralmente emerge de uma discussão madura entre duas ou mais pessoas.

Enfim, é inegável que existe uma evolução tanto na qualidade do que é produzido quanto no nível técnico e motivacional das equipes quando trabalham juntas e se tornam mais colaborativas, e o pair programming sem dúvida é uma maneira de proporcionar tudo isso.

Refactoring

Martin Fowler, um dos mais extraordinários autores na área de desenvolvimento de software, tem uma definição muito boa para o refactoring, ou refatoração. Ele diz: “Refactoring é uma alteração feita na estrutura interna do software para torná-lo mais fácil de ser entendido e menos custoso de ser modificado, no entanto, sem alterar seu comportamento observável.”.

O refactoring é uma forma de manter um projeto de software sustentável e competitivo com o passar do tempo. Por esse motivo, as empresas deveriam se preocupar mais com a qualidade de tudo que é produzido. Desta forma tanto a produtividade quanto a satisfação da equipe de desenvolvimento tendem sempre a aumentar, ao contrário do que vemos acontecer no mercado onde cada vez mais projetos fracassam, além do alto índice de rotatividade dos desenvolvedores.

...
Quer ler esse conteúdo completo? Tenha acesso completo