Frequentemente, o negócio demanda o desenvolvimento de uma feature em prazos desafiadores. Para atender essa demanda, é comum que times de tecnologia recorram a frameworks e ferramentas que aceleram o desenvolvimento ou, até mesmo, implementações de referência. Entretanto, essas escolhas frequentemente representam aumento no custo da manutenção.
Veja também
Há muitas soluções que prometem auxiliar o desenvolvimento, trazendo praticidade e velocidade de desenvolvimento para o time. Alguns exemplos são frameworks MVC/MVT, projetos boilerplate, e bibliotecas que possuem integração ao banco de dados e disponibilizam, inclusive, dashboards de administração. Entretanto, não raro, componentes assim, se transformam em pontos negativos – verdadeiras dívidas técnicas – na medida que os sistemas crescem e se tornam complexos.
Ao adotar soluções assim, deve-se tomar cuidado com padrões, convenções e práticas de escrita de código suportados por elas. Não são raros os casos em que essas premissas de utilização de um determinado framework, implementadas inicialmente, acabam definindo a arquitetura e o design de sistemas, de maneira não proposital. O mesmo problema acontece quando utilizamos um projeto de referência como ponto de partida para nossas aplicações. Esses projetos servem como “implementações” de arquiteturas que, não raro, se afastam muito do problema que precisamos resolver.
[tweet]Não há sentido em utilizar implementações e arquiteturas de referência genéricas a menos que a solução que está sendo desenvolvida seja genérica.[/tweet]
Com o crescimento da complexidade das aplicações, funcionalidades oferecidas por componentes que “botam o projeto no ar em 10 minutos” podem não atender, de maneira adequada, os casos que inicialmente apresentavam um ótimo fit. Com frequência, essas “saídas fáceis” continuam custando caro aos negócios, influenciando negativamente nos lead times.
As “concessões” realizadas para utilizar um certo framework ou referência podem dificultar a escrita de código coeso e de testes, além de promover acomplamento entre componentes do sistema e, eventualmente, podem prejudicar na compreensão da base de código, por conter seções de oxbow code, devido a falta de segurança da equipe em remover esses trechos.
Oxbow code
Oxbow code refere-se a trechos de código que antes eram necessários mas que não são mais utilizados. Esse código geralmente é criado quando quando uma funcionalidade é substituída por uma implementação mais atual, uma chamada a alguma biblioteca ou por uma chamada a um serviço externo, mas o código antigo não é removido.
O processo de elaboração de design e arquitetura das aplicações deve levar em consideração essas pequenas “concessões” realizadas para a utilização de frameworks.
[tweet]Trabalhar de maneira sensível, determinando técnicas e padrões que conciliem a utilização de frameworks, sem abrir mão do uso do uso de boas práticas de desenvolvimento, é ato fundamental[/tweet]. Caso contrário, a capacidade de entrega poderá ser influenciada de maneira negativa, destruindo toda vantagem obtida no início dos trabalhos.
