Principio AHA
Recentemente em alguns artigos anteriores falamos sobre DRY, nele vimos que através de abstrações podemos evitar duplicidade de códigos. Mas, será que sempre devemos criar abstrações e evitar tais duplicidades? Aqui vem a velha resposta de sempre:
Depende!
Precisamos encontrar um equilíbrio na forma como desenvolvemos softwares e criamos o design dos nossos códigos. Dessa forma, abstrações ou duplicidades demais podem ser prejudiciais.
O ponto é que muitas vezes nos pegamos pensando em jeitos de otimizar os códigos, criar uma boa interface de uso ou ter uma boa API com bons comportamentos de forma abstraída e compartilhada. Repare que logo no ínicio já estamos pensando em compartilhamento, reuse e abstrações, mas, os trechos de códigos são apenas utilizandos em pontos únicos. Não há necessidade de abstraí-los “pensando no futuro”.
Devemos nos preocuparmos com essas coisas quando houver as necessidades, as vezes gastamos tanto tempo nos preocupando com os exemplos anteriores para no próximo dia ou semana a necessidade de tal funcionalidade ser removida e o código ser removido.
Evite abstrações precipitadas
O princípio AHA (Avoid Hasty Abstractions, Evite abstrações precipitadas) foca justamente nisso, ou seja, crie as abstrações por necessidades e quando houver sentido.
É preferível que você crie duplicações do que abstrações erradas e equivocadas.
Comece otimizando seus códigos para mudanças e manutenção.
Quando você tiver certeza dos casos de usos (partes dos códigos que irão necessitar e porque irão precisar), necessidades para duplicação de código e sua interface (quais parâmetros serão necessários e o que deve ser retornado), ai sim, talvez seja a hora de começar a pensar em abstrações.
Conclusão
Nesse post vimos o princípio do desenvolvimento de software chamado AHA, que foca em garantir que seus códigos possuem as abtrações necessárias.
Abraços, até a próxima.
