Quando é mais produtivo criar sua própria estrutura do que usar uma existente? [fechadas]

Gostaria de saber por que você decidiu criar sua própria estrutura em sua empresa.

Por estrutura, não quero dizer poucas bibliotecas usadas com freqüência. Refiro-me a uma maneira específica de criar aplicativos sobre ele, com classes base, convenção etc.

Então, por que você construiu sua própria estrutura? Como você poderia justificar isso para a pessoa que o emprega. Você mediu o impacto positivo e negativo disso?

Com relação às suas experiências, você notou que, em alguns casos, uma estrutura da empresa produziu benefícios reais ou, por outro lado, aumentou os custos de desenvolvimento (curva de aprendizado, depuração, manutenção, ...)?

Responda ao motivo:

• Problemas de licença
• Requisitos específicos da empresa que não existiam nas estruturas atuais
• A empresa quer ter controle sobre o suporte e manutenção da estrutura
• O arquiteto não sabia melhor! Ele não sabia que essa estrutura específica existia, então eles decidiram reinventar a roda.

Atualizar:

As empresas preferem reinventar a roda ao invés de usar estruturas "pequenas". Por pequeno, refiro-me à estrutura que pode ter futuro incerto. Por exemplo, a estrutura .NET é mais segura para empresas do que uma estrutura criada por uma pequena comunidade. As empresas precisam de segurança porque muitas de suas aplicações são críticas para os negócios e também duram muito. O custo de reinventar a roda pode ser mais em curto prazo. Mas o custo pode ser maior se a estrutura usada no aplicativo da empresa for descontinuada e não for mais suportada ou se as licenças forem alteradas. Aqui, a empresa pode ter que descartar a estrutura atual e colocar outra. O Visual Basic é um bom exemplo de um idioma que não é mais suportado pela Microsoft. E isso custa bilhões de empresas, uma vez que elas precisam recomeçar com um novo desenvolvimento.

Por que construir o seu próprio?

1. porque nunca foi construído antes (raro, mas é uma possibilidade)
2. porque você quer controle total.
3. porque você só precisa de um pouco de funcionalidade para que seja mais barato criar você mesmo

Por que não construir o seu próprio?

1. você não tem tempo para fazê-lo
2. provavelmente é muito mais barato se você comprar uma estrutura existente
3. você economiza muito tempo e pode ser produtivo muito mais rápido

No meu post sobre quando é apropriado reinventar a roda , listo uma série de vantagens de uma reimplementação. Eu acho que essas vantagens se aplicam especialmente às bibliotecas de framework. Por exemplo, muitas vezes é impossível isolar o uso de uma biblioteca de estrutura em uma pequena parte do seu aplicativo. Em vez disso, eles tendem a ditar a estrutura do código-fonte do cliente e, portanto, é desejável ter controle total sobre a biblioteca.

A única razão real para reinventar a roda é se é uma aplicação crítica para os negócios. Se sua empresa estará usando por algum tempo. Se este aplicativos / framework / etc. provavelmente evoluirá além do que a estrutura comercial existente tem a oferecer, fazendo com que os codificadores da empresa tornem sua implementação certamente aceitável.

As únicas razões reais contra isso são se:

1. A estrutura existente é bem mantida, se adapta perfeitamente à sua tarefa e será bem no futuro.

2. Este é apenas um caso da síndrome do ' não inventado aqui '

3. Sua configuração atual não poderá criar com êxito essa estrutura em um período de tempo razoável por um custo razoável.

Joel Spolsky escreveu um artigo muito bom sobre o assunto: Em defesa da síndrome do não inventado aqui

Basicamente, quando você usa o trabalho de outras pessoas, você as adiciona como empregadores invisíveis ou "mãos extras".

Se eles são bons, eles o ajudarão. Caso contrário, você deve fazer o trabalho deles além do seu - em outras palavras, manter o código deles. Esse pode ser um risco inaceitável, mas eu consideraria muito raro.

A palavra-chave é tornar a estrutura trocável, codificando para uma interface. As interfaces mais rígidas do mundo Java são as especificações da Sun, comprovadas pela API do servlet.

Então, eu não consideraria que existe alguma razão para não usar uma estrutura.

Temos uma estrutura bem madura onde eu trabalho. Aqui está um resumo do Foundations Framework

Uma das principais razões para usá-lo é a estabilidade. Não devemos prestar atenção à Microsoft ou a qualquer outro fornecedor que é obrigado a adicionar novos recursos e complexidade ano após ano.

(Meus pontos de vista, não os do meu empregador, etc.)

Eu fiz isso várias vezes, para atender aos requisitos não cobertos pelas estruturas existentes (na época).

Na maioria dos casos, essas estruturas domésticas foram posteriormente removidas por estruturas novas e totalmente cultivadas. Por exemplo, em 2000, criei uma estrutura da web Java, em alguns aspectos comparável ao Rails, usada para criar um sistema complexo de entrada de pedidos com várias formas ocultas. Funcionou bem, mas é claro, alguns anos depois, estruturas mais maduras como Struts e JSF tornaram obsoletas. Mas naquela época, era a coisa certa a fazer, funcionava bem e a velocidade de desenvolvimento era impressionante.

Outra estrutura que desenvolvi ainda está em uso (e também em desenvolvimento ativo); a primeira versão foi escrita em 2004. Esta é usada principalmente para aplicações intralogísticas; a empresa que o usa ainda o vê como uma característica distintiva. O principal motivo para criá-lo foi facilitar a criação de aplicativos conectados ao banco de dados para scanners de código de barras móveis (executando um pouco do Windows CE); funcionou tão bem que os chefes decidiram usar o mesmo conceito também para o software para PC e, bem, ainda estão felizes com isso.