Fórum Questão de Produtividade: Delphi ou Framework? #431181

Assunto legal, mas falar é difícil falar com critério e certeza pois esse campo é extenso e cheio de variáveis.
Portanto todo o descrito aqui dará-se de experiência.

Já trabalhei com um framework chamado MCA, um cliente em potencial na área de seguros de vida, sinitos e bla bla bla...

Falando tecnicamente o framework era (ainda é) sensacional, fazia a separação de todas as camadas de programação (Nem tão sensacional depois que precisei entender), tinha assinaturas de métodos na camada DAL para acessos as procs, o layout era todo gerado por uma ferramenta, assim como parte do código, tudo era lindo e maravilhoso (para o cliente e dono do framework).

Para nós: Primeiro que o arquiteto com vasta experiência teve que sentar por alguns dias (Imagina o valor desse cara) e fazer uma POC (prova de conceito) firmando o conhecimento dele com o framework e ele se tornar um replicador e assim foi, ele nos ensinou e a empresa nos pagou para praticar e entender o framework até que nos levantassemos a bandeira para iniciar o projeto.

E assim fizemos e começamos o projeto, e só então sentimos as dificuldades, a curva era maior do que pensavamos.

Até mesmo esse arquiteto citou: Framework vem para trazer produtividade e não mais barreiras, e esse framework era barreiras atrás de barreiras, muito complexo, erros completamente encapsulados e sem nexo, por ser um sistema crud, alguns acessos ao banco se tornaram limitados, muito gesso para pouca parede.

Então fica claro que o framework é perigoso quando sua intenção vem para engessar ao extremo o desenvolvimento, ele deve servir de facilitador, agilizar tarefas.

Eu desenvolvi um "Framework" que gera classes POCO de todas as entidades, sua propriedades e devidos relacionamentos. Agilizando o start de um projeto.

Por isso eu falo que o assunto é extenso, existe frameworks prontos para ajudar sim, mas geralmente dentro das empresas que criam frameworks impera a necessidade de: Padronizar a programação, Padronizar a estrutura e esquecem que cada negócio demanda de uma análise própria...
Ou então parte para ERP e seus módulos... que pensando bem também não foge muito das necessidades mutantes...

Olá Robson, obrigado pela resposta.
Gostei de uma frase que você ressaltou:



Concordo plenamente.
Esse realmente é um assunto bem relativo, mas acho que na maioria das vezes o Framework não é bem-vindo em uma equipe de desenvolvimento. Já ouvi muitos desenvolvedores dizerem que "esquecem" de programar quando utilizam o Framework, já que este normalmente possui funções, componentes e códigos pré-programados e encapsulados aos olhos do desenvolvedor.

Perfeito.

Eu me coloco no lugar de quem cria um framework e realmente o desafio de criar uma ferramenta que irá gerir tanto serviço e criar padrões e sistemas praticamente prontos (Na teoria) é lindo e maravilhoso, mas como todo software e tudo na vida. Passamos pela pré-adolescência, adolescência e a maturidade.
Os frameworks geralmente morrem na pré-adolescência, pq são difíceis, se acham o dono da razão, complicam tarefas simples...
São esquecidos logo, por um milhão de justificas com fundamentos, as quais você citou.

Então a analogia de um framework tem que mudar.

Tem um artigo no DEVMEDIA que fala do programador Pragmático e que o mesmo sempre será preguiçoso.
mas onde isso é vantagem?
Um programador preguiçoso cria automatizações de serviços rotineiros e com certeza muitas rotinas são compartilhadas por todos em projetos distintos, então ele cria e ajuda a todos.
Devemos pensar em atingir pequenos focos de incêndio, com certeza a produtividade irá só aumentar.

Abraços.