Quando NÃO usar um framework [closed]

Navegue suas respostas
35

Hoje, é possível encontrar uma estrutura para praticamente qualquer idioma, para se adequar a praticamente qualquer projeto. A maioria das estruturas modernas é bastante robusta (em geral), com horas e horas de testes, código revisado por especialistas e grande capacidade de extensão.

No entanto, acho que há uma desvantagem em QUALQUER quadro em que programadores, como comunidade, podem se tornar tão dependentes de suas estruturas escolhidas que não entendem mais o funcionamento subjacente ou, no caso de programadores mais novos, nunca aprendem trabalhos subjacentes para começar. É fácil tornar-se especializado a um nível que você não é mais um 'programador de PHP' (por exemplo), mas um "programador de Drupal", com a exclusão de qualquer outra coisa.

Quem se importa, certo? Nós temos o quadro! Nós não precisamos saber como "fazer isso à mão"! Certo?

O resultado dessa perda de habilidades básicas (às vezes, na medida em que programadores que não usam frameworks são vistos como "desatualizados") é que se torna prática comum usar uma estrutura onde não é necessário ou apropriado. As funcionalidades do framework facilitam confusões com o que a linguagem base é capaz. Os desenvolvedores começam a usar estruturas para realizar até mesmo as tarefas mais básicas, de modo que o que antes era considerado um processo rudimentar agora envolve grandes bibliotecas com suas próprias peculiaridades, bugs e dependências. O que já foi realizado em 20 linhas agora é realizado incluindo uma estrutura de 20.000 linhas e escrevendo 20 linhas para usar a estrutura.

Por outro lado, não se quer reinventar a roda. Se eu estou escrevendo código para realizar alguma pequena tarefa básica, eu posso sentir que estou perdendo meu tempo quando eu sei que o framework XYZ oferece todos os recursos que eu estou procurando, e muito mais. A parte "muito mais" ainda me preocupa, mas não parece que muitos sequer considerem isso.

Tem de haver uma boa métrica para determinar quando é apropriado usar um framework. O que você considera ser o limite, como você decide quando usar um framework, ou quando não.

    
por Chris 18.02.2011 / 22:09
fonte

6 respostas

25

"There has to be a good metric to determine when it is appropriate to use a framework."

Não realmente. Se houvesse boas métricas para determinar o uso apropriado de qualquer tecnologia, você não veria a linguagem, o editor e a metodologia de guerras santas.

Os grupos com quem trabalhei fazem a mesma coisa - adivinhar os custos e benefícios, escolher o caminho mais produtivo e esperar que estejam certos. Não é terrivelmente científico - uma parte de intuição, três partes de experiência, uma parte de suscetibilidade ao marketing, uma parte de astúcia e cinco partes classificam a opinião.

    
por 18.02.2011 / 22:48
fonte
14

Frameworks são apenas ferramentas. Não acho que seja culpa do framework se ele for usado em demasia, e sim do uso excessivo da pessoa. O velho ditado "se você tem um martelo, tudo parece um prego" mostra que esse modo de pensar existe muito antes mesmo dos computadores.

Tornar-se especializado demais pode, de fato, se tornar um problema a longo prazo - tanto para um desenvolvedor quanto para espécies biológicas. Para a sobrevivência a longo prazo, é preciso equilibrar cuidadosamente o esforço para desenvolver suas habilidades em múltiplas áreas.

Para responder à sua pergunta específica, não acho que haja uma métrica para isso. Eu prefiro usar um framework quando ele simplifica a resolução de problemas. Se usar um framework me ajudar a resolver um problema com 2 linhas de código em vez de 20, obviamente irei usá-lo. Mas mesmo que seja 20 linhas contra 20, eu posso decidir usar uma estrutura se ela me der melhores abstrações, mais perto do domínio do problema, tornando o código mais fácil de entender e manter.

    
por 18.02.2011 / 22:19
fonte
6

Eu acho que os frameworks podem ser usados em demasia em alguns contextos, sim. Um framework é apenas uma ferramenta, sim. Um framework permite que você consiga algo rodando muito rapidamente e, como tal, é uma excelente ferramenta de prototipagem.

Em algum momento, quando seu aplicativo atinge algum nível de complexidade, as restrições inerentes a um framework começam a sufocar ainda mais o crescimento, parece-me. O truque é reconhecer quando você encontrou um ponto de inflexão e, em seguida, decidir o que você vai fazer a respeito.

    
por 18.02.2011 / 22:36
fonte
5

Eu costumo trabalhar mais com aplicativos da web e, embora eu esteja tentando ser geral, minha resposta pode não se aplicar à sua área de programação.

Eu também vou usar "framework" synonymical com "library".

Antes de implementar um framework, é preciso considerar algumas coisas, aqui estão alguns exemplos gerais.

# 1. O framework economizará tempo e esforço?

A resposta a esta questão é quase sempre sim . Frameworks tendem a ser construídos para resolver problemas específicos e resolvê-los muito bem. Por exemplo, frameworks como EntityFramework podem salvar você inteiramente da gravação de código SQL. O que pode ser fantástico se a sua equipe de programação não for fluente em SQL.

Estruturas são construídas para, a) adicionar uma interface amigável ao programador para componentes complexos ou b) adicionar abstração a componentes já conhecidos (ou estabelecidos).

O último (ou mesmo o primeiro em alguns casos) pode realmente entrar no caminho do desenvolvimento. Isso se aplica especialmente quando você ou sua equipe de programação vai implementar um novo framework, no qual eles nunca trabalharam antes.

Isso poderia desacelerar seu processo de desenvolvimento, o que poderia ser caro.

# 2 A escala da sua aplicação

Diz-se que "vale a pena fazer qualquer coisa que valha a pena" , mas geralmente não é esse o caso. Provavelmente, não há uma boa razão para implementar uma estrutura super dimensionada se o ponto de sua aplicação for imprimir "potato" .

Quando você está desenvolvendo um aplicativo (seja web, desktop, móvel ou qualquer outro tipo de aplicativo concebível) - se você acha que o tamanho do seu framework "anões" sua implementação (talvez futura) dele, então isso pode seja um grande sinal de alerta de que sua estrutura pode simplesmente inchar seu aplicativo. Uma boa anedota seria se você incluísse o jQuery, apenas para adicionar uma classe "carregada" ao seu body-tag quando o documento estivesse pronto. Fazer isso apenas com JavaScript nativo pode ser um pouco mais difícil , mas não incha seu aplicativo.

Por outro lado se um framework faz muito trabalho sujo no interior (ie frameworks de banco de dados), então pode ser viável implementá-lo, mesmo se você está apenas "parcialmente" usando o framework. Uma boa anedota seria não tentar construir seu próprio driver ADO.NET ou MongoDB, apenas porque você não precisa utilizar toda a biblioteca.

Às vezes, os frameworks vêm com código aberto (e com licenças 'do-que-você-quiser'). Isso abre uma nova possibilidade em que uma equipe de programação só pode optar por partes de uma estrutura.

Isso, finalmente, volta às questões # 1 e # 3.

# 3 Impacto.

Às vezes, implementar um framework pode impactar diretamente o usuário final. Isso é especialmente verdadeiro para aplicativos da Web, pois ter grandes estruturas do lado do cliente pode afetar negativamente a experiência do usuário final. Os usuários com máquinas mais lentas podem ter uma renderização lenta, problemas de desempenho com o javascript ou problemas semelhantes causados por máquinas insignificantes. O usuário com conexões lentas pode ter um tempo de carregamento lento (pelo menos inicial).

Mesmo em outros aplicativos de tipos, os usuários finais podem ser afetados negativamente por suas dependências de aplicativos. As estruturas, pelo menos, sempre ocupam algum espaço em disco, e se você estiver desenvolvendo um aplicativo móvel (ou até mesmo um aplicativo de desktop), isso pode ser necessário para ser levado em consideração.

As estruturas do lado do servidor (ainda mais específicas da Web) provavelmente não afetarão seus usuários finais, mas afetarão sua infraestrutura . Algumas estruturas têm dependências elas mesmas que podem exigir que você reinicie seu servidor da Web, apenas o serviço ou o servidor por completo.

Algumas estruturas também podem ser muito pesadas em recursos.

Isso, claro, vincula os pontos 1 e 2.

É tudo apenas um grande "círculo de considerações", e não existe um método científico real para decidir se você deve implementar um framework ou não.

Corbin March resumiu muito bem:

The groups I've worked with all do the same thing - make a guess at costs and benefits, choose the most productive route, and hope they're right. It's not terribly scientific - one part intuition, three parts experience, one part susceptibility to marketing, one part cunning, and five parts rank opinion.

Também é importante não ser elitista . Frameworks são ferramentas que devem ser usadas. Eu conheço pessoas de ambos os extremos; de um lado você tem o cara que torna a vida muito difícil para si mesmo, do outro lado você tem o cara que constrói aplicações lentas e inchadas.

Todos os frameworks têm casos de uso, é apenas uma questão de implementá-los para os propósitos corretos.

    
por 10.08.2015 / 00:53
fonte
4

Os outros desenvolvedores conhecem o framework?

Se todos os desenvolvedores conhecem o framework X, então todas as outras razões para usar o framework são viáveis, vá em frente! Para mim, não faz sentido impor o aprendizado de uma estrutura específica quando a maior parte do tempo de desenvolvimento será gasto aprendendo as complexidades do framework.

Em relação à sua declaração sobre programadores mais novos que não conhecem o básico, você é muito mais compassivo do que eu! Sim, é uma vergonha, mas vou gastar meu tempo me preocupando com a inépcia de outra pessoa? Nup. (Com base na suposição de que esses novos membros da comunidade não estão trabalhando imediatamente com você.)

    
por 18.02.2011 / 22:21
fonte
3

Eu usaria uma estrutura se (e APENAS se) as seguintes condições forem verdadeiras:

A estrutura parece ser suportada por algum tempo. Eu já os experimentei no final de vida, e é realmente irritante. Especialmente quando você está 9 meses no seu projeto, e mudar não é mais uma opção. E se a estrutura JÁ não for mais suportada, pense três vezes antes de escrever algo novo usando essa estrutura. Não importa quão bem você já saiba disso.

O projeto realmente corresponde ao framework. Como um exemplo bem antigo, você viu as coisas que o MFC foi feito para fazer? As pessoas não tinham fim de coisas estranhas para fazer com que funcionasse para tipos de aplicativos em que simplesmente não fazia sentido. Geralmente gastando mais tempo batendo no MFC do que gastariam apenas escrevendo o aplicativo que eles queriam.

A equipe do projeto é capaz de trabalhar dentro da estrutura. Algumas pessoas não podem ou não podem dedicar tempo para entender como um aplicativo deve ser escrito em uma determinada estrutura e, em vez disso, escrevem as coisas da maneira que costumam fazer, em vez do modo como a estrutura precisa. Esse erro de correspondência entre código e estrutura geralmente acaba custando muito tempo e esforço a todos.

    
por 18.02.2011 / 22:32
fonte

Tags

Quão rápido pode ir? Posso reduzir o Javascript que exige aviso de direitos autorais?