5 Passos para Programar Pensando no Próximo Desenvolvedor

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

Kent Beck sobre bons programadores:

Qualquer tolo pode escrever código que um computador consegue entender. Bons programadores escrevem código que humanos conseguem entender.

Douglas Crockford sobre bons programas de computador:

Tudo se resume à comunicação e às estruturas que você usa para facilitar essa comunicação. Linguagem humana e linguagens de computador funcionam de maneira muito diferente 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 propósito e 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 pessoas entrem e saiam e ainda assim manter isolamento, o padrão da porta é implementado. Agora isso parece óbvio, mas em algum momento não era. Alguém criou o padrão da 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. 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 comuns de software. Este livro descreve problemas comuns encontrados na maioria das aplicações de software e oferece uma maneira elegante de resolver esses problemas. 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 suficiente, pode identificá-los.

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

Algum código é simplesmente irritante, procure um colega — um segundo par de olhos sempre ajuda. Percorram o código juntos. Você ficará surpreso com o que vocês 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 ao longo do código. Por exemplo, não tenha 3 abordagens para acesso a dados.

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

Código inconsistente é um pesadelo, imagine ler um livro com cada palavra significando 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. Teça-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 diretamente na declaração if. Este código está sintaticamente correto, mas a intenção do número 3 não te diz nada. Olhando para a propriedade contra a qual é avaliado, você pode supor 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 está claramente declarada no nome da variável. Se passaram 3 horas desde a última refeição, é hora de alimentar o macaco. Um efeito colateral de definir a variável é que agora podemos mudar o intervalo de alimentação sem alterar a lógica.

Este é um exemplo artificial, em um grande 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 espada de dois gumes. Comentários demais aumentam os custos de manutenção, poucos demais deixam 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 está fora do comum.

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

Steve Jobs sobre simplicidade:

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

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

Para mais sobre 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.