Escrever ou não escrever: Frameworks [closed]

Hoje alguns amigos e eu começamos a discutir estruturas ..

Alguns de nós acreditam firmemente que, em 99,9% dos casos, escrever uma nova estrutura é uma má ideia. Acreditamos que provavelmente alguns dos milhões de estruturas existentes no mercado devam se encaixar no nosso problema e, se não, algum hack, API ou configuração deve ser suficiente. Caso contrário, achamos que contribuir com alguma estrutura, sugerir recursos ou algo assim deve ser a melhor solução. O 0,1% ocorre quando nenhuma das estruturas se encaixa no nosso caso.

Porém, alguns de nós dizem que é melhor ter uma "estrutura corporativa interna" (por exemplo), porque é mais rápido corrigir problemas, cria um ajuste 100% ao aplicativo, por causa do fator "aprendizado" (quando você melhora suas habilidades na construção de uma estrutura) etc.

Eu acho que sair de estruturas de codificação como se não houvesse amanhã não é o caminho certo. Eu já vi muitas equipes pequenas construindo sua própria estrutura apenas para espalhar a palavra: "nós construímos nossa própria estrutura, nós governamos, mano". Geralmente, a estrutura é uma porcaria, sem qualquer documentação e funciona apenas para seus próprios aplicativos.

Opiniões são opiniões, desenvolvedores são desenvolvedores, sem a intenção de iniciar qualquer tipo de guerra de chamas, pergunto:

O que você acha disso? Quais parâmetros você considera ao criar uma estrutura? O que você acha disso tudo?

Estou do lado oposto do GrandmasterB. Para mim, essa é uma pergunta de compra versus construção.

Da minha perspectiva, meu tempo e esforço podem ser representados por um custo. A questão então se torna: quando há retorno suficiente sobre o investimento para construir uma estrutura? (Se estou trabalhando para um cliente, penso nessas questões da perspectiva do cliente.)

Aqui estão as perguntas que me faço:

• A estrutura já existe?
• Se eu criar essa estrutura, é algo que eu quero que seja conhecida? Em outras palavras, esse quadro é um diferencial para mim?

Muitas vezes, acho que a resposta para a segunda pergunta é não. Estou trabalhando para uma empresa de saúde agora. Eles não desejam ser conhecidos como desenvolvedores de um mecanismo de agendamento de última geração. Eu deveria terceirizar o desenvolvimento e a manutenção dessa estrutura.

No entanto, se estamos falando de um mecanismo de preços, esse é o pão e a manteiga da empresa, então devo definitivamente concentrar minha energia em criar um excelente motor.

Minha regra geral é que, se for um produto ou uma parte importante do produto, faça-o sempre que possível. Se não for uma funcionalidade principal ou estiver agindo no suporte a um negócio (algo usado apenas internamente), fique louco com as estruturas.

Muitas das aplicações que faço são investimentos de longo prazo - mais de 10 anos, possivelmente - e são produtos vendidos aos clientes (portanto, é de minha responsabilidade). Portanto, ser capaz de 'rapidamente' começar a usar uma estrutura de terceiros não é tão relevante para mim como seria para alguém que está criando uma dúzia de aplicativos por ano. Portanto, geralmente não me oponho a mergulhar no âmago da questão e criar o meu próprio. Ao longo da vida útil do produto, algumas semanas extras para obter uma estrutura / componente personalizado não importam muito. Mas isso pode significar muito menos dores de cabeça e menos paredes de tijolos, pois foi projetado especificamente para a aplicação.

Parece-me que uma estrutura é uma coleção de bibliotecas. Depois de ter um monte deles e garantir que eles tenham APIs consistentes e que funcionem bem juntos, agrupe-os e chame de estrutura. Mas você deve garantir que todas as bibliotecas da sua empresa tenham APIs consistentes, independentemente de você usar a palavra F ou não.

As estruturas tendem a ser escritas 'acidentalmente' quando alguém olha para tudo o que tem e diz 'hummm, esse monte de coisas pode ser útil para outras pessoas'. Isto é, a menos que você seja uma empresa que envia a fonte ou foi solicitado explicitamente a escrever uma estrutura. Fazer coisas para fazer coisas sempre é uma má idéia na programação.

Faça o que fizer, certifique-se de não reinventar a roda, especialmente como um quadrado.

Se você é como eu, seu trabalho é fornecer valor comercial da maneira mais eficiente possível, não depurar e ajustar projetos de estimação. Se houver uma estrutura amplamente usada que faça o que você precisa, não perca seu tempo reinventando a roda, pois a estrutura amplamente aceita provavelmente faz melhor do que você pode. Eles tiveram mais tempo, experiência e recursos para desenvolvê-lo.

Nos últimos 6 meses, minha empresa recentemente me mandou escrever 2 aplicativos diferentes que fazem muitas coisas semelhantes. Recentemente, fui solicitado a escrever um terceiro aplicativo semelhante, e há muito espaço para aplicativos semelhantes no futuro. Como ninguém desenvolveu uma estrutura para a tecnologia proprietária com a qual estou trabalhando, não vi outra opção a não ser desenvolver minha própria estrutura. Se eu não desenvolver minha própria estrutura, gastarei muito tempo me repetindo, e isso será uma perda de tempo e dinheiro.

Eu acho que essa é a chave para saber se vale a pena construir o seu próprio ou usar o de outra pessoa. Se você precisar desperdiçar uma tonelada de dinheiro nos próximos anos ou criar uma estrutura, construa a estrutura.

É muito difícil prever com precisão como seria uma estrutura ideal sem antes criar algo. As soluções colhidas geralmente são melhores que as soluções de base (obrigado pelos links caarlos0 ), porque seu código não é construído sobre suposições sobre o que o programador cliente deseja, mas sobre a experiência real. Leia: Projeto Emergente .

Dito isso, há apenas uma razão em minha mente para criar sua própria estrutura: se você fez o mesmo trabalho duas vezes e provavelmente o fará várias vezes, e ninguém fez o trabalho por você.

Eu tento obter o máximo de milhas das estruturas e ferramentas disponíveis em qualquer novo projeto. Depois que o projeto evoluiu, talvez queimou por um ano ou dois, então substituir as partes da estrutura que causam mais dor é uma escolha razoável. A menos que seu plano de negócios se concentre na criação de uma nova estrutura, eu não planejaria escrever o seu próprio.

Quando uma parte da tecnologia realmente falha, eu mantenho uma lista de reclamações e idéias específicas sobre como ela deve ser redesenhada para funcionar melhor. No curto prazo, esse "manifesto" me dá uma saída para minhas frustrações enquanto ainda estou usando a estrutura existente . A médio prazo, isso me ajuda a identificar os piores pontos negativos, para que eu não desperdice energia consertando pequenos problemas. A longo prazo, o manifesto pode se tornar um design para uma substituição parcial ou completa ou uma lista de recursos para a escolha de uma nova estrutura.