Avalie os impactos das "concessões"​ realizadas ao utilizar frameworks e boilerplates - Thiago Candido


2020-06-10

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.

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.

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.

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, que são trechos de código que permanecem na base, mesmo não sendo mais utilizados, devido a falta de segurança da equipe em remover essas seções.

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.

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. Caso contrário, a capacidade de entrega poderá ser influenciada de maneira negativa, destruindo toda vantagem obtida no início dos trabalhos.

Algum comentário ou dúvida? Entre em contato comigo via Twitter ou LinkedIn.

Originalmente publicado em EximiaCo