Como escrever um bom código em Java
Neste artigo serão dadas algumas dicas básicas para que o desenvolvedor possa criar um software mais robusto e fácil de manter. Serão abordadas algumas práticas de desenvolvimento que podem até mesmo parecerem óbvias, como comentários, tratamento de exceções, testes unitários e a não repetição de código, porém que se aplicadas de forma correta, são muito úteis e podem fazer a diferença entre um código de referência com boa manutenibilidade, reutilizável, e algo que pode se tornar um pesadelo no momento que alguma alteração ou correção, pelo próprio criador da funcionalidade ou outro desenvolvedor, seja necessária.
O assunto melhores práticas pode ser aplicado em diversas etapas de um projeto de software, como na fase de desenvolvimento, testes, documentação, gerenciamento do projeto, etc. Neste artigo, este assunto será voltado para o ponto de vista do desenvolvedor. Assim, serão exibidas algumas das principais práticas para se obter um código limpo, de fácil compreensão.
Como você já deve ter ouvido falar, escrever um bom código é extremamente importante, pois com o tempo um código mal estruturado pode levar a uma complexidade excessiva no desenvolvimento de novos módulos e na manutenção, criando um projeto em que desenvolvedores não queiram trabalhar ou tenham medo de alterar algo e fazer uma funcionalidade não relacionada parar de funcionar.
Confira nosso Guia de Linguagem Java
Outro ponto muito importante em se criar um bom código desde o início é que geralmente a estrutura inicial do projeto é replicada, sofrendo apenas algumas alterações para acomodar uma nova funcionalidade. Por exemplo, se o projeto já possui um mecanismo de geração de relatório, infelizmente, mesmo que não seja um mecanismo adequado, um novo desenvolvedor ao ser solicitado para adicionar um novo relatório, provavelmente irá apenas copiar o relatório existente, alterando alguns parâmetros, aumentando a quantidade de código não muito bem escrito. Existem muitos motivos para que isso aconteça: prazos curtos, backlogs grandes, desmotivação, inexperiência, além de muitos outros.
Independentemente do motivo, um código ruim, mesmo que sem bugs, muito provavelmente irá gerar problemas de manutenção, que farão com que o custo a longo prazo provavelmente não justifique a pressa inicial, agravando ainda mais o backlog, a desmotivação e os prazos.
Como mencionado, existem inúmeras práticas que tornam um código melhor. Neste artigo, serão abordados os tópicos de não repetição de código, testes unitários, comentários e tratamento de exceções.
Para que o conteúdo seja bem compreendido, é interessante que o leitor conheça pelo menos conceitos básicos do framework JUnit, utilizado como ferramenta para os testes unitários. Pode ser adotada qualquer ferramenta de testes unitários, porém no exemplo fornecido o JUnit foi o escolhido. O uso deste framework é recomendável porque possui um grande número de usuários, integração nativa com as principais IDEs (Eclipse e NetBeans) e é de uso muito fácil, apresentando uma barra verde para cada teste correto e uma vermelha para cada teste com erro.
Conteúdo relacionado: Cursos de Engenharia de Software
É interessante também o conhecimento básico de como utilizar Javadoc, que é a forma padrão de documentação através de comentários em código Java, sendo utilizado pelo próprio Java para documentar sua API. Este também possui integração nativa com as principais IDEs e é uma ferramenta completa para documentação do fonte.
Evite código repetido
Copiar e colar código ou escrever códigos diferentes com uma mesma funcionalidade é algo que muitos desenvolvedores fazem, podendo ser encontrado em muitos projetos. Como mencionado, isto pode acontecer por vários motivos, como: falta de tempo, por medo, preguiça, por não perceber que é possível alterar algo para que se este torne genérico, desconhecimento de que algo semelhante já existe no projeto, entre outros motivos.
De qualquer forma, sempre que uma funcionalidade estiver implementada mais de uma vez, a correção de bugs e implementação de melhorias se torna muito mais complicada, pois tudo que precisar ser alterado em um trecho do fonte, também precisará ser alterado no outro.
Como um ex ...
