Quando precisamos ler e interpretar um código, seja para realizar uma manutenção ou apenas para compreender a regra de negócio, desejamos que seja rápido. É fato que desenvolvedores não gostam de perder tempo lendo um código mal escrito. Na prática do Clean Code, uma das técnicas para produzir um código compreensível é contar uma história. Ficou curioso? Confira!
Imagine que você esteja consultando um livro para fazer um trabalho da faculdade. Primeiro, você abre o índice do livro e descobre que o tópico do trabalho está na página 210. Ao consultar a página, o texto faz referência a um parágrafo na página 115, e esse, por sua vez, recomenda a visualização de um gráfico que está na página 360. Embora este seja o sentido ao consultar o livro, gastamos um bom tempo para percorrer as páginas e marcá-las para que possamos revê-las e retomar a leitura.
Você e suas analogias…
Sim, isso é o que acontece em uma unidade de código-fonte. É bem comum encontrar métodos que fazem referência a outros métodos ou variáveis espalhadas no código. Para evitar o desperdício de tempo e a desorientação, o desenvolvedor sinaliza vários bookmarks ou breakpoints nas linhas de código. Porém, bookmarks, por exemplo, geralmente são números e não contém uma descrição do código no qual ele está vinculado. Sendo assim, se o desenvolvedor sinalizar 10 bookmarks no código, o que o fará lembrar que o 6º se refere a um método de consulta?
E então, caímos na mesma situação da consulta no livro: é necessário navegar nas linhas de código, subindo e descendo, para interpretar uma determinada funcionalidade.
Isso é radicalismo! Bookmarks foram criados justamente para essa necessidade.
Claro, mas isso não significa que você é obrigado a utilizá-los sempre. Não seria melhor se houvesse uma maneira de organizar o código de tal forma que não fosse necessário atribuir bookmarks para navegar entre as linhas? No caso do livro, se os assuntos estivessem relacionados logo na página seguinte, dispensaria o leitor de procurar páginas distantes e a consulta certamente seria mais rápida.
Uma das maneiras de alcançar essa organização é escrever o código como se estivesse contando uma história. Tecnicamente, essa prática é chamada de Regra Decrescente e sugere que uma unidade de código-fonte deve estar sistematicamente disposta para facilitar a leitura de cima para baixo, como uma leitura uniforme. Em outras palavras, cada método deve ter uma relação com o método seguinte, basicamente do mesmo modo que os autores escrevem parágrafos em um livro. Ao percorrer a lista de métodos, é possível observar cada nível do programa se relacionando verticalmente com os níveis consecutivos.
Como exemplo, suponha que criamos um método para cadastrar clientes e que dentro deste método há uma chamada para uma função de validação. Já que estão intimamente relacionados, faz todo sentido colocá-los próximos. O desenvolvedor que ler este código encontrará o método de validação imediatamente abaixo do método que o chama.
Agora, imagine se a função de validação estivesse no final do arquivo? Bom, a única saída seria utilizar bookmarks.
Mas o meu método chama 5 funções…
Em primeiro lugar, atente-se à responsabilidade do seu método. Se ele realmente faz 5 chamadas, provavelmente está fazendo coisas demais! Caso você ainda não conheça o SRP (Single Responsibility Principle), aguarde os futuros artigos!
De qualquer forma, se este não for o caso, procure dispor as 5 funções logo abaixo na sequência como são chamadas. Lembre-se: a intenção é declará-las em um fluxo lógico, como se fosse os parágrafos de uma história.
E se os métodos chamados estiverem em outra classe?
Se forem métodos intimamente ligados, não deveriam estar em outra classe. Isso irá dificultar ainda mais a compreensão do código. Portanto, a Regra Decrescente também induz a ideia de mover (ou reescrever) métodos relacionados entre classes para dar sentido à história. Por outro lado, se for necessário mantê-los em arquivos separados, trabalhe na arquitetura do software (como heranças, interfaces, classes abstratas) para não criar uma distância muito grande entre as classes que possuem estes métodos.
Certo, e a única vantagem é facilitar a leitura?
Não! As vantagens estão nos detalhes. Ao implementar o código da forma como foi apresentada neste artigo, o desenvolvedor evita que métodos duplicados sejam criados. Ou então, em outras situações, alguns métodos são unificados por compartilharem da mesma responsabilidade, resultando, claramente, na redução do código.
Além disso, imagine se uma empresa de desenvolvimento decidisse padronizar essa estrutura nos arquivos de código? Não só facilitaria a leitura e a produtividade, como também iria favorecer a manutenção do software. É uma prática engenhosa de programação.
Para finalizar, convenhamos: é bem mais confortável trabalhar em um código com métodos organizados pela Regra Decrescente. Ao abrir um arquivo para alteração, por exemplo, teremos a sensação de que pelo menos a hierarquia dos métodos está ao nosso favor.
Seja um grande autor e conte uma história com seu código. Bons programadores irão apreciá-la. 🙂
Fico por aqui, leitores.
I’ll be back next week.
