Void Podcast #004 – Frameworks Corporativos

Olá desenvolvedores, designers, analistas, arquitetos e loucos em geral!

Mais uma semana, mais um Voidpodcast. Como sempre, um registro, sem compromissos, de uma conversa bem-humorada, entre (bons) amigos, sobre tecnologia, egos, polêmicas e afins.

Hoje, Leandro Daniel (@leandronet) e Elemar Júnior (@elemarjr) discutem suas definições, decepções, desejos e aspirações sobre os polêmicos Frameworks corporativos. Para muitos, uma “praga” corporativa. Para outros, um mal necessário. Para poucos, uma #CoisaLindaDeDeus.

Participe, comente, critique. Afinal, sua opinião precisa continuar parecendo muito importante para nós. O arrobinha (@vquaiato), de castigo por não ter aparecido, lerá tudo o que você escrever.

Já deu play, né?! Afinal, quem lê os posts do Elemar? 😀


Ouça

Download
VoidPodcast – 04 – Frameworks Corporativos (65,7 MB)

Links

Anúncios

8 respostas em “Void Podcast #004 – Frameworks Corporativos

  1. Não tenho nada contra frameworks, o problema é quando a empresa tem um framework e obriga seu uso para TUDO, até mesmo coisas que não fazem sentido, mesmo quando o que está ali não é a melhor forma de fazer para aquele caso específico.

  2. Não gosto.
    O pior que eu acho é que na maioria das vezes o framework fica preso a uma versão de tecnologia. Coisas novas surgem e você ali preso no seu mundinho infeliz. Cara é uma mordaça, é desumando, afinal nós somos de TI, viciados em coisas novas…

  3. Dia inspiradíssimo do Elemar (ou algo que já tinha uma opinião sedimentadíssima). Uma visão muito, muito madura, mas fica a questão de como passar isto para equipe de modo eficiente, sem desmotivar e sem deixar os desenvolvedores propensos criar códigos amotinados?

  4. Eu sou a favor dos frameworks corporativos, acredito que a grande motivação é em conseguir desenvolver algo tão bom em que todos da organização possam estar utilizando sem maiores problemas. O framework fica preso a uma versão x da tecnologia? não, pois refactoring de código serve justamente para isso, quando sabemos que podemos melhorar algo, vamos lá e refizemos, isso ocorre da mesma forma com qualquer código, seja framework ou não. Por isso concordo com o Elemar nessa questão, acredito que muito se fala, lemos em muitos lugares sobre reutilização de código, pois esse é um dos grandes meritos da POO, mas infelizmente na prática não é o que costumamos ver, então se não trabalhamos assim algo esta errado no conceito.

  5. Será que podemos separar o conceito de framework com o que é praticado no mercado?

    Atualmento trabalho utilizando um framework corporativo, mas é uma horrível!..Mas sabe pq?

    Acredito que um framework é um série de códigos reutilizáveis e que se utiliza o que é interessante para seu domínio (conceito que o Elemar fala). Ex: .Net Framework.

    Porém, o que mais existe no mercado, não é um framework, mas sim um design de referência onde toda e qualquer aplicação para rodar tem que ser feita em cima. É o caso que tenho hoje. Toda aplicação é construída em cima de um “framework” que foi construído antes de ser solucionado qualquer problema real.

    Será que é por isso que temos tantos problemas? Que ao invés de as empresas desenvolverem frameworks, elas desenvolvem um design (mal-feito) de referência?

  6. Pingback: Você já ouviu o Void podcast?! « Elemar DEV

  7. Antes tarde do que nunca, re-escutando o podcast e tentando compatilhar e quem sabe contribuir com algo.
    Primeiro, deixar claro que faço parte da equipe que desenvolve o framework corporativo da empresa em que trabalho. Então já pode supor que seu a favor do uso deles, até porque se não acredita-se não estaria trabalhando com isso.

    Segundo, um pouco do cenário em que nos encaixamos. Nossa empresa já está um pouco grandinha, com mais de 300 desenvolvedores internos e até alguns externos, inclusive o próprio cliente. Temos diversos produtos em áreas distintas, como sáude, jurídico, erp, logística, turismo, etc, inclusive com equipes de desenvolvimento em cidades e estados distintos.

    Nossa equipe tem como um dos seus objetivos, queimar fosfato nos problemas como, segurança, acesso a dados, log, instrumentação, mensageria, performace, UI padronizada, web, desktop, ou seja, recursos comuns e genéricos à maioria dos aplicativos LOB da empresa. Além disto, temos a preocupação de preservação do investimento (legado rodando) com a possibilidade de evolução gradual e flexibilidade.

    Ponto um: Uma parte de nosso framework está voltado à UI em uma arquitetura baseada em metadados, onde dá a infraestrutura inicial de um sistema LOB (desktop e web), por exemplo, autenticação, estrutura de menus, navegação, etc. Algo com um sistema baseado em metadados, que poderia resumir de modo grosseiro, um Sharepoint web e desktop.

    Ponto dois: Na própria empresa há equipes que acham o máximo a utilização do framework, e que preferem se preocupar o mínimo possível com áreas do software que não sejam a do domínio do negócio. Mas também temos equipes que não gostam, preferindo escrever suas próprias rotinas e bibliotecas reutilizáveis, pois acreditam que desta forma poderão utilizar as últimas novidades em tecnologia para entregar uma melhor solução a nossos clientes. Ou seja, assim, como o Leandro comentou, temos a tensão mas também a simpatia entre quem usa e quem desenvolve o framework, e nem sempre isso é racional.

    Uma questão que vejo é que, por termos um framework, não conseguimos incorporar todas as novidades e mudanças que surgem de tecnologia tão rapidamente quanto gostaríamos, o que acho natural e até saudável para um amadurecimento dessas novas tecnologias. Porém, mesmo que o framework não dê suporte a algumas dessas novas tecnologias, tentamos não bloquear o uso delas, o que nem sempre conseguimos devido algum acoplamento indesejado ou até requisitos de um modo geral. Pois para adotarmos algo novo, temos que ver ganho real para nossos produtos e para a empresa, e não só o argumento de que é “mais moderno”, até porque geralmente tem outras formas de fazer a mesma coisa, talvez não a mais otimizada possível mas geralmente tem.

    Porém, o que temos acompanhado ao longo de vários anos, é que, na grande maioria dos casos, quando alguma equipe não utiliza ou utiliza parcialmente o framework, a coisa desanda. Por exemplo, UIs sem padronização, alto-acoplamento, brechas de segurança, má performace, difícil detecção de problemas, etc. E quando o framework evolui, o investimento feito por fora muitas vezes é perdido, pois atendem apenas a alguns requisitos do seu domínio de negócio e não o da empresa como um todo. Os motivos desse descompasso são variados, como inexperiência ou ingenuidade da equipe, pressão do cliente ou do GP para uma solução rápida, alterações nas equipes, mau uso do framework e por consequência o framework “não funciona” e é “ruim”, etc. Até porque, em equipes maiores é comum ter desenvolvedores menos experientes e cheio de energia para utilizar o que tem de mais novo em tecnologia, e isso nem sempre é responsável ou baseado em argumentos.

    Alguns pontos que acredito e tenho observado em relação aos frameworks são:
    * ajudam muito na produtividade (reutilização)
    * ajudam na padronização da UI e na identidade dos produtos da empresa
    * facilitam a vida das equipes de suporte na detecção de problemas
    * guiam equipes menos experientes a entregarem soluções mais consistentes no que se refere à arquitetura e boas práticas.
    * ajudam na preservação do investimento (legado rodando)
    * permitem uma migração de tecnologia, caso seja necessário, com menor custo e impacto
    * exige disseminação e treinamento de uso
    * deve suportar, de forma gerenciável, a colaboração das equipes no desenvolvimento de recursos
    * precisam ser flexíveis, evitando “podar” os desenvolvedores, mas guiá-los quando possível.
    * ajudam a sobreviver à rotatividade nas equipes, pois há uma espinha dorsal norteando o desenvolvimento
    * devem ser criados a partir da experiência de produtos entregues

    Seria isso e espero não ter esquecido de algum argumento importante.
    Ficou mais para um post do que para um comentário 8-).
    E gostaria de ler mais argumentos de quem usa e gosta ou não gosta de usar os frameworks.

  8. Pingback: Void Podcast: episódios #003 e #004 disponíveis! | Leandro Daniel

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s