Não é de hoje que existe uma guerra, quase ideológica, a respeito da utilização de frameworks em projetos de software. Seja qual for a linguagem – Java, C#, PHP, Go, Javascript, Python, Ruby, ou qualquer outra –, existe uma grande variedade de frameworks disponíveis que fornecem uma quantidade sem fim de recursos para facilitar o desenvolvimento.
Frameworks são legais. Eles resolvem problemas comuns. Eles provem um conjunto de soluções baseadas em padrões de arquitetura e design. Eles aceleram (e muito) o desenvolvimento de um projeto, fazendo com que valor agregado seja entregue rapidamente. E ainda que fosse muito bom, isso não é o bastante.
Na maioria dos casos, nós não aprendemos a projetar software muito bem na faculdade. Nossas grades curriculares são cheias de matérias técnicas, tais como Análise de Processos, UML e Modelagem de Sistemas, Estruturas de Dados, e Linguagens de Programação. Contudo, pouca ênfase é dada no que chamamos de "abordagem orientada a resolução de problemas". Em outras palavras, somos capacitados a pensar tecnicamente, mas não analiticamente.
O que isso quer dizer? Que estamos rodeados de pessoas com uma mentalidade técnica, mas não tem profundidade na análise e proposta de soluções que realmente resolvam o problema proposto. Essa é uma das bases para um projeto ser executado com qualidade: o entendimento correto do problema e a proposta de uma solução de acordo.
Quando não temos a capacidade de analisar e propor soluções bem desenvolvida, precisamos compensar com algo além: a profundidade técnica. E é aí que entra o dilema dos frameworks.
Como disse Abraham Maslow, "é tentador tratar tudo como um prego se a única ferramenta que você tem é um martelo". Em outras palavras, não podemos resolver todos os problemas que temos com uma única ferramenta – ou então precisaríamos apertar um parafuso com um martelo. Da mesma forma é o engenheiro de software: ele precisa conhecer as ferramentas com as quais trabalha e quais tipos de ferramentas servem para resolver certos problemas.
Com isso, fica claro que, muitas vezes, estamos tentando resolver tecnologicamente um problema que é processual. Uma simples alteração em um processo de negócio dispensa totalmente o desenvolvimento de novas funcionalidades, que só servirão para tornar o projeto maior, mais pesado e mais complexo.
Por fim, o que fica de lição? Seja aquela pessoa que conhece as ferramentas e as usa corretamente (mesmo que de forma desajeitada em alguns casos), e saiba usar muito bem aquilo que pode resolver grande parte dos problemas a pequeno e médio prazo.
Top comments (0)