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!
Introdução
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.
Bom, podemos dizer que o mesmo ocorre 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.
Regra Decrescente
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.
Se os métodos que são chamados estiverem em outra classe, trabalhe na arquitetura do projeto (como heranças, interfaces, classes abstratas) para não criar uma distância muito grande entre as classes correlacionadas.
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.
Véri gúdi!!!
Tenkiu!! rsrs
Muito bom o artigo traz uma leitura bem sucinta….
Obrigado pelo comentário, Samuel!
Parabéns, André. Suas explicações são excelentes. Uma dúvida, que não tem a ver com o artigo, porém gostei da maneira clara que você explica as coisas e acho que poderá me ajudar: gostaria de saber quais os arquivos (dll, ini, etc.) que devo distribuir junto com minha aplicação para que não haja necessidade de instalar um banco Firebird no pc do cliente? Estou desenvolvendo um sistema que utiliza Delphi 7 + dbExpress + Firebird 2.0. Desde já, agradeço a atenção.
Olá, Guilherme!
Há duas formas de distribuir um aplicativo desenvolvido com banco de dados Firebird. A primeira delas é instalar o client do Firebird no computador do usuário. A segunda forma é distribuir o aplicativo com a versão embedded do Firebird, que dispensa a instalação do client.
Vou lhe enviar um e-mail com mais detalhes sobre as duas opções. Em breve pretendo postar um artigo sobre esses tipos de distribuição.
Obrigado pelo comentário! Abraço!