5 Passos para Codificar para o Próximo Desenvolvedor

A maioria de nós provavelmente não pensa no desenvolvedor que manterá nosso código. Até recentemente, eu também não considerava isso. Nunca escrevi intencionalmente código obscuro, mas também nunca deixei pistas.

Kent Beck sobre bons programadores:

Qualquer tolo consegue escrever código que um computador entenda. Bons programadores escrevem código que humanos entendem.

Douglas Crockford sobre bons programas de computador:

Tudo se resume a comunicação e às estruturas que você usa para facilitar essa comunicação. Linguagens humanas e linguagens de computador funcionam de maneiras muito diferentes em muitos aspectos, mas em última análise, julgo um bom programa de computador pela sua capacidade de se comunicar com um humano que lê esse programa. Então nesse nível, eles não são tão diferentes.

Descobrir o propósito e a intenção é difícil até no código mais bem escrito. Qualquer pista deixada pelo autor, comentários, nomenclatura verbosa e consistência, é imensamente útil para os próximos desenvolvedores.

Começo procurando por padrões. Padrões podem ser encontrados em muitos lugares, incluindo nomes de variáveis, layout de classes e estrutura do projeto. Uma vez identificados, os padrões são insights sobre a intenção do desenvolvedor anterior e ajudam na compreensão do código.

O que é um padrão? Um padrão é uma solução repetível para um problema recorrente. Considere uma porta. Quando um espaço deve permitir que as pessoas entrem e saiam e ainda assim mantenha isolamento, o padrão de porta é implementado. Agora isso parece óbvio, mas em um ponto não era. Alguém criou o padrão de porta que incluía a maçaneta, as dobradiças e o posicionamento desses componentes. Entre em qualquer casa e você pode identificar qualquer porta e seus componentes. Os estilos e cores podem ser diferentes, mas os componentes são os mesmos. O software é igual.

Existem padrões de software conhecidos para problemas comuns de software. Em 1995, Design Patterns: Elements of Reusable Object-Oriented Software foi publicado descrevendo padrões de software comuns. Este livro descreve problemas comuns encontrados na maioria das aplicações de software e ofereceu uma maneira elegante de resolver esses problemas. Os desenvolvedores também criam seus próprios padrões ao resolver problemas que encontram rotineiramente. Embora não publiquem um livro, se você olhar com atenção, pode identificá-los.

Às vezes é difícil identificar os padrões. Isso torna a compreensão do código difícil. Quando você se encontra nessa situação, inspecione o código, veja como ele é usado. Comece uma reescrita. Pergunte-se, como você realizaria o mesmo resultado. Frequentemente, conforme você percorre o processo de pensamento de um algoritmo, você ganha insight sobre a implementação do outro desenvolvedor. Muitos de nós temos a inclinação de reescrever o que não entendemos. Resista a esse impulso! A implementação existente é testada em batalha e a sua não é.

Alguns códigos são simplesmente irritantes, procure um colega — um segundo par de olhos sempre ajuda. Percorra o código juntos. Você ficará surpreso com o que os dois encontrarão.

Aqui estão 5 dicas para deixar pistas para os próximos desenvolvedores

1. Padrões
Use padrões conhecidos, crie seus próprios padrões. Mantenha um paradigma consistente em todo o código. Por exemplo, não tenha 3 abordagens para acesso a dados.

2. Consistência
Este é de longe o aspecto mais importante da codificação. Nada é mais frustrante do que encontrar código inconsistente. A consistência permite suposições. Cada vez que um padrão de software específico é encontrado, deve-se assumir que ele se comporta de forma semelhante a outras instâncias do padrão.

Código inconsistente é um pesadelo, imagine ler um livro onde cada palavra significa algo diferente, incluindo a mesma palavra em lugares diferentes. Você teria que procurar cada palavra e gastar grandes quantidades de energia mental descobrindo a intenção. É frustrante, tedioso e doloroso. Você ficará louco! Não faça isso com o próximo desenvolvedor.

3. Nomenclatura Verbosa
Esta é sua linguagem. Estas são as palavras da sua história. Teja-as bem.

Isso inclui nomes de classes, nomes de métodos, nomes de variáveis, nomes de projetos e nomes de propriedades.

Não faça:

if(monkey.HoursSinceLastMeal > 3)
{
    FeedMonkey();
}

Faça:

int feedInterval = 3;

if(monkey.HoursSinceLastMeal > feedInterval)
{
    FeedMonkey();
}

O primeiro exemplo tem 3 codificado na instrução if. Este código é sintaticamente correto, mas a intenção do número 3 não diz nada. Olhando para a propriedade contra a qual é avaliado, você pode deduzir que são realmente 3 horas. Na realidade, não sabemos. Estamos fazendo uma suposição.

No segundo exemplo, definimos 3 para uma variável chamada ‘feedInterval’. A intenção é claramente declarada no nome da variável. Se faz 3 horas desde a última refeição, é hora de alimentar o macaco. Um efeito colateral de definir a variável é que agora podemos alterar o intervalo de alimentação sem alterar a lógica.

Este é um exemplo artificial, em um grande pedaço de software este tipo de código é autodocumentado e ajudará o próximo desenvolvedor a entender o código.

4. Comentários
Comentários são uma faca de dois gumes. Muito comentário aumenta os custos de manutenção, pouco deixa os desenvolvedores inseguros sobre como o código funciona. Uma regra geral é comentar quando o desenvolvedor médio não entenderá o código. Isso acontece quando as suposições não são óbvias ou o código é fora do comum.

5. Código Simples
Na minha opinião profissional, escrever código complexo é a maior tolice entre os desenvolvedores.

Steve Jobs sobre simplicidade:

Simples pode ser mais difícil que complexo: você tem que trabalhar duro para deixar seu pensamento limpo para torná-lo simples. Mas vale a pena no final porque uma vez que você chega lá, você pode mover montanhas.

A complexidade vem em muitas formas, algumas das quais incluem: prova de futuro, implementações excessivamente complexas, muita abstração, classes grandes e métodos grandes.

Para mais informações sobre como escrever código limpo e simples, veja o livro Clean Code do Uncle Bob e Code Simplicity de Max Kanat-Alexander

Conclusão

Ler código é difícil. Com alguns passos simples, você pode garantir que o próximo desenvolvedor compreenderá seu código.