Série de artigos sobre o livro As Regras da programação de Chris Zimmerman. O livro trata de 21 regras que ajudam programadores a criarem códigos melhores. Falarei um pouco sobre cada regra do meu ponto de vista trazendo alguns exemplos e opiniões sobre o livro, com o objetivo principal de consolidar e compartilhar o conhecimento.
Como programadores, é comum, quando estamos resolvendo um problema ou implementando uma nova funcionalidade, pensar em todos os pequenos casos de uso que achamos que vão ser úteis para só então começar algum código que resolva tudo de uma vez. Pensamos "É melhor escrever uma função que resolva dois problemas do escrever funções separadas para cada problema."
Vamos a um exemplo: encontrar placas.
Inicialmente temos apenas um caso de uso, encontre placas vermelhas. Nesse momento podemos pensar "E se tivermos que encontrar placas com mais cores? Ou com mais de uma cor? Será que podemos encontrar placas pela localização? Ou pelo texto da placa?", essas e muitas outras perguntas e ideias podem surgir o que nos levará a projetar uma solução que atenda tudo isso de uma vez (mesmo que não esteja descrito no nosso único caso de uso).
A grande questão desse tipo de solução é que em nosso primeiro contato com problema não temos muitos exemplos nos quais nos basear, então apenas prevemos os possíveis casos de uso que poderíamos resolver... e provavelmente essas previsões estarão erradas.
Voltando ao exemplo, vamos supor que agora temos um novo caso de uso: encontrar placas vermelhas e encontrar placas em São Paulo.
Ao ler esses casos de uso, poderíamos dizer que fizemos um bom trabalho ao prever e projetar uma solução que resolve tudo. No entanto, vemos que algumas coisas sobraram, como encontrar pelo texto ou por mais de uma cor; ou seja, resolvemos casos que não estão ocorrendo na prática.
Existe um padrão comum utilizado na programação extrema chamado YAGNI, ou "You Ain't Gonna Need It" (Você não vai precisar disso). Resumindo, muito do que projetamos inicialmente foi apenas desperdício de tempo.
A primeira lição que o livro traz é "Nenhuma solução genérica é previsível após um único caso de uso, logo é um erro tentar escrever uma.". Não tente adivinhar qual será o segundo caso de uso. Escreva códigos para resolver problemas que você conhece e não para os que acha que ocorrerão.
Uma objeção a essa estratégia poderia ser "E se os nossos casos de uso aumentarem, teremos o retrabalho de projetar tudo novamente?". O autor dá uma resposta a isso "Não desperdice seu tempo. Quando surgir um caso de uso que seu código não manipule, escreva um código para manipulá-lo.". Resumindo: refatore.
Então, quando podemos generalizar algo? O nosso ponto de inflexão passa a ser quando temos pelo menos três casos de uso independentes. Nesse momento podemos prever com mais clareza quais poderiam ser o quarto e o quinto casos. A generalização não é obrigatória, mas começa a fazer sentido.
"Só generalize se achar que isso tornará o código mais fácil de ler e escrever, baseando-se apenas nos casos de uso que tiver em mãos. Nunca generalize porque está preocupado com o próximo caso de uso.", essa é a segunda lição desse livro pra mim.
Outro problema que pode ocorrer devido à generalização é a perda do contexto inicial. Começamos a utilizar uma única solução para resolver tudo, apenas estendendo o que ela faz. Ela vai ficando cada vez mais complexa, dificultando atender novos requisitos ou suportar grandes mudanças.
O livro termina dizendo "Quando seguramos um martelo, tudo se parece com um prego, certo? Quando criamos uma solução genérica, estamos fornecendo martelos. Não o faça até ter certeza de que possui pregos em vez de parafusos." e a última lição que eu tiro disso é utilize a estratégia certa para resolver uma problema de forma eficaz.
A tentativa de prever e resolver todos os possíveis casos de uso desde o início de um projeto de programação pode parecer uma abordagem inteligente, mas muitas vezes leva ao desperdício de tempo e recursos. O princípio YAGNI nos ensina que devemos focar nas necessidades imediatas e evitar a complexidade desnecessária. Ao resolver problemas conhecidos e refatorar conforme novos casos de uso surgem, podemos criar soluções mais eficientes e flexíveis.
Generalizar prematuramente não apenas complica o código, mas também pode nos desviar do contexto original do problema, tornando mais difícil atender novos requisitos. Assim, é crucial encontrar o equilíbrio entre a simplicidade inicial e a capacidade de adaptação futura.
Lembre-se, a programação eficaz não é sobre prever todos os possíveis problemas, mas sim sobre criar soluções claras e concisas para os desafios atuais. Ao aplicar essas lições, podemos escrever códigos mais limpos e manter um desenvolvimento de software ágil e eficiente.
Top comments (0)