Taverna /dev/All

Frameworks: são pra qualquer um?

Arquitetura
#1

image
image800×600 151 KB

Topei hoje com um artigo EXCELENTE na ACM Queue que achei interessante compartilhar aqui com vocês: Best Practice: Application Frameworks - While powerful, frameworks are not for everyone Best Practice: Application Frameworks - ACM Queue

Três anos atrás escrevi a respeito: “Framework: você REALMENTE sabe o que é isto?” - Framework: você REALMENTE sabe o que é isto? - /dev/Kico - pois acredito que a maior dificuldade em relação à adoção de frameworks é que as pessoas não sabem o que é um framework.

Então seguem minhas opiniões a respeito.

Pontos positivos

O principal ponto positivo pra mim é a manutenção a médio e longo prazo. Lido com aplicações aqui feitas em Grails, por exemplo, escritas QUINZE anos atrás e cuja manutenção tem sido relativamente tranquila (relativamente não, MUITO tranquila) pois basta seguir os padrões definidos pelo framework.

Mais que isto: o onboarding de novos membros na equipe também é muito facilitado pelo framework. Você consegue, por exemplo, que as pessoas ao aprenderem o framework, rapidamente se tornem produtivas.

Outro ponto muito legal é que você evita egos: há ali no framework um padrão bem definido pelo mercado e testado por este, não pelo ego de alguém.

Resumindo: frameworks organizam nosso pensamento e por isto valem à pena.

Lado negativo

O principal pra mim é a adoção do framework incorreto, muitas vezes por hype. Você gera uma série de problemas com isto:

  • A equipe não se adequa ao framework.
  • O framework passa a ser usado pra fins que não foi projetado.
  • Você tem no final das contas código de má qualidade.

Tem como fugir do framework?

Não acredito que seja possível fugir do uso de um framework, pois mesmo que você não use nenhum, os padrões que você adota no seu projeto já criam um framework focado no contexto da sua aplicação.

De qualquer maneira, é uma discussão interessante. Qual a opinião de vocês a respeito?

#2

Hoje trabalhando com Go vejo quase zero necessidade falando de Web, a biblioteca nativa é muito boa. Agora, na minha experiência com outra linguagens sempre achei melhor ter por conta disso que você comentou de ter padrões bem definidos. Usei Flask e django no Python, Rails e Sinatra no Ruby, Express e Hapi.js no Node e Spring no Java, sempre achei eles importantes para executar meu trabalho de forma mais padronizada e fácil de ser compreendido por outras pessoas. Acho que o problema do framework se divide em dois: 1) aplicações onde odesempenho é extremamente crítico e ele pode gerar gargalos; e 2) usuário que adota framework mas não as suas boas práticas.

1 Curtida
#3

Kico, acredito que a missão dos frameworks é simplificar uma ou mais funcionalidades recorrentes, por meio da adoção de alguns padrões, regras e convenções.

Você definiu muito bem os pontos positivos. Facilita a comunicação interna do time, manutenção, dá velocidade no desenvolvimento.

Costumo sempre dizer que os frameworks são como um trilho. Enquanto você usá-lo exatamente como ele foi proposto, seu caminho vai ser simplificado. Muitos problemas e reclamações surgem quando o “trilho” não atende uma ou mais funcionalidades necessárias.

Isso ocorre, pois uma boa parte das pessoas se limita a aprender somente como usar o framework, ou seja, aprendem somente suas regras e convenções, e não tentam ir mais a fundo para entender o COMO o framework funciona.

Desse jeito, tentam resolver todos os problemas do negócio limitados pela visão do framework, e aí surgem as “gambiarras” e código de má qualidade como você comentou. Pois partem para o “quando eu só tenho martelo, todo problema vira prego”.

Se o desenvolvedor procurar entender como funciona o framework, ele é capaz de estender, ou mesmo substituir componentes do framework por outros mais propícios para um determinado caso, além de também aprender como utilizar de modo mais otimizado o próprio.

Para resumir minha opinião, acredito que frameworks são para todos, mas se beneficiam muito mais deles aqueles que aprendem como eles funcionam. Desse modo, são capazes de produzir códigos mais otimizados, de qualidade superior e de fácil manutenção.

2 Curtidas
#4

é: eu vou até além Bruno: na minha opinião você simplesmente não consegue ficar SEM um framework, por que mesmo que tente, na prática está criando um que é a estrutura básica do seu projeto.

2 Curtidas
#5

João, eu to experimentando algo similar com Python agora.

Dado a natureza do que estou escrevendo ser essencialmente na forma de scripts, frameworks meio que perderam o sentido (neste contexto). Mas no final das contas, eu acabo sem querer criando um framework (vício do Java? talvez).

No que diz respeito ao Go, já fiz uns experimentos com ele. A sensação que tenho é similar à que tive com Node.js quando saiu e ainda não existiam frameworks: as libs http (acho que era este o nome) eram tão boas que conseguia escrever meus servidores com ele (na época, eu fazia essencialmente mocks).

Com o tempo, entretanto, fui vendo que sem querer eu sempre tava criando frameworks, até aparecer o Express que, essencialmente, era aquele framework que eu sempre criava.

Creio que algo similar acontecerá com Go, viu?

#6

Conheço pouca gente com experiência em Go que usa framework mas existem alguns bem populares. Eu usei Gin, Echo, Chi, Iris e outro que esqueci agora e não vi muitas vantagens de usar, para os meus casos de uso os facilitadores que eles entregam não justifica o uso. Meu contexto foi sempre microserviço com responsabilidade bem reduzida, seria bom ter a opinião de alguém que já fez um monolito com diversas responsabilidades.

#7

Sei exatamente quem chamar João!

@jcbritobr - já fez algo nesta direção?

#8

Vou bancar o advogado do diabo: não sou muito a favor da ideia de frameworks. Penso que são mais limitadores do que úteis, visto que são grandes pacotes fechados.
Se de toda forma temos que saber o que há “por baixo” para fazer direito, então acho que o ideal seria suas funcionalidades existirem como componentes de biblioteca, que me dessem mais liberdade de integrá-los na aplicação da forma que melhor se adequa à aplicação.
Pode haver uma forma padrão de integrar todos os componentes e sim, isso é útil, mas deveria ser opcional e não obrigatório. Nesse sentido, pode existir o framework como um determinado projeto arquitetural bem específico (e como componentes de software que ajudam a implementá-lo), mas todo um conjunto de funcionalidades amarrado a uma arquitetura fixa, sei lá, acho um pouco demais.

biblioteca >>>>>>>>>>>>>>>> framework (podem me trucidar)

#9

Tá ligado que este é o argumento básico por trás do PHP hoje, né?

Especialmente neste livro aqui: https://www.amazon.com.br/dp/B00TKVLL26/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

Eu vejo o framework como uma ferramenta corporativa interessante: o fator limitador, por mais estranho que pareça, agrega demais, pois toda a inversão de controle (que é a base por trás de todo o framework) pro contexto específico pro qual ele se dedica já tá lá. É a experiência de muitos anos ali aplicada.

Sobre limitação, aqui acho que seria mais decorrente da aplicação do framework em um contexto incorreto, não?

#10

Go meio que segue essa linha com bibliotecas boas p/ vc compor dentro do seu software mas isso requer experiência e maturidade.

Imagina uma pessoa que está começando na carreira ter que subir uma aplicação do zero sozinha. Você acha que é melhor ela usar apenas bibliotecas ou usar algum framework que em vários momentos vai proteger ela de algum vacilo se seguir as boas práticas dele? (Ex: SQL Injection)

Imagine o quando de vulnerabilidades de software que já foram evitadas até hoje porque o framework protege o programador?

Repare no nível de detalhe do “net/http” do Go que precisa saber para não vacilar em coisas simples nesse artigo: The complete guide to Go net/http timeouts

Eu já peguei falha no código de pessoas de nível senior por conta desses detalhes.

1 Curtida
#11

image

dica de dinâmica para quando precisar tomar decisões do tipo =)

#12

Acho que não deveríamos nos meter a desenvolver sem conhecer a fundo como é desenvolver. Falo isso como alguém que começou jovem, autodidata, sem formação e, entre os acertos, cometeu uma porção de erros.
Pensando pelo lado humanístico/psicológico, o framework nesse sentido serve como ferramenta de acomodação. Porque o Rails faz tudo para você, é muito fácil um iniciante ficar preso ao seu modo de funcionamento e adotá-lo como ferramenta “do coração” (levei ANOS para sair fora do Delphi, que hoje para mim é mais uma ferramenta para contextos específicos e não “o” framework). Só o que salva o sujeito disso é um estudo mais aprofundado, ou seja, não podemos fugir disso. Infelizmente, pensando de modo realista, a maioria das pessoas não irá estudar tão a fundo e, por isso, frameworks sempre existirão. Essa palavra não era tão usada até os anos 90, quando a coisa era mais elitizada.
Pelo lado social, serve como ferramenta de mecanização e padronização da mão de obra. Já traz grande parte do trabalho arquitetural e mesmo funcional pronto, bastando ao dev preencher lacunas. Eu tenho que saber “Rails”, não entender a fundo MVC, ActiveRecord e outros padrões de projeto por trás.
Por esses motivos, eu defendo uma linha como essa seguida pelo Go, onde as coisas são oferecidas mais na forma de bibliotecas e o dev tem a maturidade necessária. Porque, convenhamos, essa maturidade é o que importa no final das contas.
Sobre limitações e uso incorreto (@kicolobo), isso acontece muito sim, mas acho que o cerne da questão é a liberdade (com responsabilidade) do desenvolvedor e o “buraco” de conhecimento que o framework tenta tapar.

#13

Oi Ederson,

mas a ideia do framework é justamente fazer com que você opere dentro do modo como foi projetado pra operar.

A questão que você levanta aí, parece, é mais uma questão de formação mesmo: tipo, a pessoa só saber programar em Rails e achar que o mundo é Rails, ignorando padrões, etc. Aí nem é culpa do framework, mas sim da formação do indivíduo, não?

#14

Não. O framework tem sua parcela de culpa, assim como o próprio indivíduo, a comunidade que faz hype em cima… Problemas sistêmicos não têm “o” culpado.
Perceba que não sou contra a existência das funcionalidades e “arquitetura pronta” do framework, e sim seu oferecimento em um pacote fechado, amarrado e obrigatório. E isso não é limitador apenas do molde da aplicação, mas da mente.
De um ponto de vista técnico, um programador mais maduro sempre se sentirá limitado pelo framework que usa. As lacunas a serem preenchidas são muito carregadas de contexto do framework, o que é difícil (não impossível) de desacoplar do código de aplicação. Mas se eu posso evitar o problema, por que vou procurá-lo?
(agora eu sei porque algumas pessoas gostam tanto de polemizar, é divertido :slight_smile:)

#15

mas dentro de uma equipe, com toda esta liberdade que você menciona, como se evitaria um caos com cada um agindo com sua liberdade infinita?

e outra: mesmo sem usar um framework, o projeto cria um framework em si que são os padrões que ele adota para ser mantido.

#16

@edersoncassiolf, respeito e entendo sua visão. Entretanto, eu tenho uma visão diametralmente (adoro essa palavra :grinning:) oposta.

É importantíssimo esse diálogo de opiniões diferentes, para que todos possamos repensar e reforçar, ou alterar nossos argumentos.

Eu acho que o framework permite que quem está iniciando possa navegar em águas mais tranquilas, até desenvolver “músculos” para nadar em águas mais revoltas.

Já vi pessoas auto didatas, que aprendiam rapidamente conceitos complexos partindo “do zero” e fazendo tudo na mão, mas acredito que é uma “esmagada minoria” :slight_smile:.

O framework permite que você entenda algum conceito, por exemplo o MVC, sem ter um esforço danado para criar todos os componentes. Eu concordo que deve haver um segundo passo do desenvolvedor que seria uma vez compreendidos os conceitos, desenvolver “na raça” algo semelhante, como modo de aprimorar seus conhecimentos. É aí que a maioria para.

Mas vejo isso acontecendo em todos os ramos da sociedade. Por exemplo, uma parte dos médicos, aprende a resolver sintomas de doenças e pára aí, não tenta entender as causas da doença para resolvê-la de fato. Acho que a causa é muito mais cultural, ou talvez comodismo.

Acho que um ponto que não tocamos ainda, e que é importantíssimo, é a qualidade de um framework. Para mim, um framework para ser considerado de qualidade, deve ter os seguintes pontos:

  • resolver de modo eficiente um determinado problema
  • ser fácil de utilizar
  • ser atualizado constantemente
  • ter uma comunidade ativa
  • ter bons tutorias
  • ser fácil de ser customizado/extensível

O último ponto é essencial e você colocou muito bem :

Quando isso ocorre, realmente limita a equipe. Para ser um bom framework, você tem que conseguir substituir ou alterar as partes do framework por outras que você julgue mais adequadas, de modo tranquilo.

Vou dar um exemplo. No Grails, a gente usava o Scaffold para geração de páginas com base na definição da classe de domínio. Ele funcionava razoavelmente bem, mas não atendia nossas regras de negócio. Mas foi possível alterá-lo de modo simples para que ele atendesse nossas necessidades.

Nesse caso, resolvemos nosso problema, e ainda “de brinde” aprendemos como ele fazia a geração “automágica” das páginas.

E vou te dizer mais, já trabalhei com vários estagiários (e já fui estagiário), e mesmo com algo “mágico” já era bem difícil o começo deles (e meu). Se tivessem que fazer do 0, seria ainda mais traumático.

#17

Cria um microsserviço para cada um se divertir :smiley:…

Brincadeira, concordo com você, sem definição mínima de regras e convenções de como tratar os problemas, vira uma torre de Babel.

#18

O que falei do “desenvolvedor” pode ser estendido para “equipe”, talvez a minha escolha de vocabulário tenha sido infeliz – digitando rapidamente e focando o pensamento em outro aspecto do problema.

Agora, calma lá, ninguém falou sobre liberdade infinita e sim sobre as limitações de liberdade. Restrições à autonomia do dev/equipe. Um desenvolvedor ou equipe pode chegar às suas conclusões de forma individual ou conjunta, agora se não sabemos como isso pode ser feito a culpa (ou parte dela) é de quem…? (eu tenho meu chute e vocês sabem qual é)

Também, se o projeto criou “seu” framework, isso quer dizer que se atingiu a arquitetura adequada para esse projeto em específico. Claro que ele vai ter muitas coisas em comum com frameworks existentes, mas também coisas próprias e que nem sempre vai funcionar nos outros projetos. (falando de forma bem abstrata)

Aqui é possível imaginar um meio-termo. Se fosse possível começar a aplicação através de um framework e, quando for preciso, removê-lo, soltar a app do framework. No início ninguém sabe como fazer, então começa-se com um framework que pareça mais adequado. Quando ele começar a limitar demais, é cortado fora. Do jeito que são feitos hoje, os frameworks são as colunas do prédio e não os andaimes. A minha proposta de oferecê-los como componentes de biblioteca é para que sirvam de andaimes.

#19

mas esta questão do “limitar demais” não seria simplesmente a má escolha de uma ferramenta?

#20

Ferramenta é martelo e serrote, não a estrutura da casa.

itexto