Quando NÃO usar uma estrutura [fechada]

Hoje, é possível encontrar uma estrutura para praticamente qualquer idioma, adequada a qualquer projeto. A maioria das estruturas modernas é bastante robusta (geralmente falando), com hora e hora de teste, código revisado por pares e grande extensibilidade.

No entanto, acho que há uma desvantagem em QUALQUER estrutura em que os programadores, como uma comunidade, possam se tornar tão dependentes das estruturas escolhidas que não compreendem mais o funcionamento subjacente, ou, no caso de programadores mais novos, nunca aprendem o funcionamento subjacente a começar com. É fácil tornar-se especializado a tal ponto que você não é mais um 'programador PHP' (por exemplo), mas um "programador Drupal", com exclusão de qualquer outra coisa.

Quem se importa, certo? Nós temos a estrutura! Não precisamos saber como "fazer à mão"! Direita?

O resultado dessa perda de habilidades básicas (às vezes na medida em que os programadores que não usam estruturas são vistos como "desatualizados") é que se torna prática comum usar uma estrutura onde ela não é necessária ou apropriada. Os recursos que o framework facilita acabam confusos com o que a linguagem base é capaz. Os desenvolvedores começam a usar estruturas para realizar até 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 estou escrevendo um código para realizar algumas tarefas básicas e comuns, posso sentir que estou perdendo tempo quando sei que o framework XYZ oferece todos os recursos que estou procurando e muito mais. A parte "muito mais" ainda me preocupa, mas parece que muitos nem a consideram mais.

É preciso haver uma boa métrica para determinar quando é apropriado usar uma estrutura. O que você considera o limiar a ser, como é que você decidir quando usar um quadro, ou, quando não.

"Tem que haver uma boa métrica para determinar quando é apropriado usar uma estrutura".

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

Os grupos com os quais trabalhei fazem o mesmo: adivinhar custos e benefícios, escolher a rota mais produtiva e esperar que eles 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 de opinião.

Estruturas são apenas ferramentas. Não acho que seja culpa de uma estrutura se for usada em excesso, e sim da pessoa que está usando demais. O velho ditado "se você tem um martelo, tudo parece um prego" mostra que essa maneira de pensar já existe muito antes dos computadores.

Tornar-se especializado demais pode de fato se transformar em 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 várias áreas.

Para responder sua pergunta específica, não acho que exista uma métrica para isso. Eu prefiro usar uma estrutura quando simplifica a solução de problemas. Se o uso de uma estrutura me ajudar a resolver um problema com 2 linhas de código em vez de 20, obviamente o usarei. Mas mesmo que sejam 20 linhas contra 20, posso decidir usar uma estrutura se ela me fornecer abstrações melhores, mais próximas do domínio do problema, facilitando o entendimento e a manutenção do código.

Eu acho que estruturas podem ser superutilizadas em alguns contextos, sim. Uma estrutura é apenas uma ferramenta, sim. Uma estrutura permite que você execute algo 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 uma estrutura começam a sufocar ainda mais o crescimento, parece-me. O truque é reconhecer quando você encontrou esse ponto de inflexão e depois decidir o que você fará sobre isso.

Costumo trabalhar mais com aplicativos da Web e, mesmo tentando ser geral, minha resposta pode não se aplicar à sua área de programação.

Também vou usar "framework" sinonquímico com "library".

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

# 1 A estrutura economizará tempo e esforço?

A resposta a esta pergunta é quase sempre sim . Estruturas tendem a ser construídas para resolver problemas específicos e resolvê-los muito bem. Por exemplo, estruturas, como EntityFramework pode poupar inteiramente de escrever SQL-código. O que pode ser fantástico se sua equipe de programação não for fluente em SQL.

As 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 atrapalhar o desenvolvimento. Isso se aplica especialmente quando você ou sua equipe de programação implementará uma nova estrutura, na qual eles nunca trabalharam antes.

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

# 2 A escala do seu aplicativo

Dizem que "qualquer coisa que vale a pena fazer vale a pena exagerar" , mas geralmente não é esse o caso. Provavelmente, não há um bom motivo para implementar uma estrutura de tamanho grande, se o objetivo do seu aplicativo for imprimir "potato" .

Quando você está desenvolvendo um aplicativo (seja ele na Web, desktop, celular ou qualquer outro tipo de aplicativo concebível) - se você acha que o tamanho da sua estrutura "diminui" a sua (talvez futura) implementação, então isso pode ser um grande problema. sinal de aviso de que sua estrutura pode inchar seu aplicativo. Uma boa anedota seria se você incluísse o jQuery, apenas para adicionar uma classe "carregada" à sua etiqueta corporal quando o documento estiver pronto. Fazer isso apenas com JavaScript nativo pode ser um pouco mais difícil , mas não incha seu aplicativo.

Por outro lado, se uma estrutura faz muito trabalho sujo por dentro (ou seja, estruturas de banco de dados), pode ser viável implementá-la, mesmo se você estiver "parcialmente" usando a estrutura. Uma boa anedota seria não tentar criar seu próprio driver ADO.NET ou MongoDB, apenas porque você não precisa utilizar a biblioteca inteira.

Às vezes, as estruturas são de código aberto (e com licenças do tipo "faça o que você quiser"). Isso abre uma nova possibilidade em que uma equipe de programação pode optar apenas por partes de uma estrutura.

Em última análise, isso está relacionado à questão 1 e 3.

# 3 Impacto.

Às vezes, a implementação de uma estrutura pode afetar 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 problemas de renderização lenta, problemas de desempenho com javascript ou problemas semelhantes causados ​​por máquinas de baixa qualidade. O usuário com conexões lentas pode enfrentar tempos de carregamento lentos (pelo menos iniciais).

Mesmo em outros tipos de aplicativos, os usuários finais podem ser impactados 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 mesmo um aplicativo de desktop), isso pode ser necessário para ser levado em consideração.

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 próprias, o que pode exigir que você reinicie o servidor da Web, apenas o serviço ou o servidor completamente.

Algumas estruturas também podem ter muitos recursos.

É claro que isso remete aos 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 uma estrutura ou não.

Corbin March resumiu muito bem:

Os grupos com os quais trabalhei fazem o mesmo: adivinhar custos e benefícios, escolher a rota mais produtiva e esperar que eles 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 de opinião.

Também é importante não ser elitista . Frameworks são ferramentas que devem ser usadas. Conheço pessoas dos dois extremos; por um lado, você tem o cara que torna a vida muito difícil, por outro, o cara que cria aplicativos lentos e inchados.

Todas as estruturas têm casos de uso, é apenas uma questão de implementá-las para os propósitos corretos.

Os outros desenvolvedores conhecem a estrutura?

Se todos os desenvolvedores conhecem o framework X, dadas todas as outras razões para usá-lo, é possível! Para mim, não faz sentido impor o aprendizado de uma estrutura específica quando a maior parte do tempo de desenvolvimento é gasta aprendendo os meandros da estrutura.

Em relação à sua afirmação de que os programadores mais novos não sabem o básico, você é muito mais compassivo do que eu! Sim, é uma pena, mas vou gastar meu tempo me preocupando com a inaptidão de outra pessoa? Nup. (Com base no pressuposto de que esses novos membros da comunidade não estão trabalhando imediatamente com você.)

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

A estrutura parece provável que seja suportada por algum tempo. Eu já tive o fim da vida deles antes, e é MUITO irritante. Especialmente quando você tem 9 meses em seu projeto e a troca não é mais uma opção. E se a estrutura JÁ não é mais suportada, pense três vezes antes de escrever algo novo usando essa estrutura. Não importa o quão bem você já o saiba.

O projeto realmente corresponde à estrutura. Como um exemplo bastante antigo, você viu o que o MFC foi feito para fazer? As pessoas não terminavam coisas estranhas para fazê-lo funcionar para tipos de aplicativos em que simplesmente não fazia sentido. Geralmente, gastam mais tempo espancando o MFC do que gastariam apenas escrevendo o aplicativo que desejavam.

A equipe do projeto é capaz de trabalhar dentro da estrutura. Algumas pessoas não têm 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 da maneira que a estrutura precisa. Essa incompatibilidade entre código e estrutura geralmente acaba custando a todos muito tempo e esforço.