Está reinventando a roda realmente tão ruim assim?

Como uma vez eu postei no StackOverflow, reinventar a roda é frequentemente uma escolha muito boa , ao contrário da crença popular. A principal vantagem é que você tem controle total sobre o software, o que geralmente é essencial. Para uma discussão completa, veja minha postagem original .

Depende ..

Assim como tudo, é sobre o contexto:

É bom quando:

• O Framework ou a biblioteca é muito pesado e você requer apenas uma funcionalidade limitada. Rolar sua própria versão extremamente leve que atende às suas necessidades é uma abordagem melhor.
• Quando você quer entender e aprender algo complexo, é muito útil fazer sua própria experiência.
• Você tem algo diferente para oferecer, algo que outras implementações não têm. Pode ser uma nova reviravolta, novo recurso, etc.

É ruim quando:

• A funcionalidade já existe e é conhecida por ser estável e bem conhecida (popular).
• Sua versão não adiciona nada de novo.
• Sua versão apresenta erros ou restrições (por exemplo, sua versão não é thread-safe).
• Sua versão está sem recursos.
• Sua versão tem uma documentação pior.
• Sua versão não tem testes de unidade em comparação com o que está sendo substituído.

Eu acho que o caso de um desenvolvedor conscientemente reinventando a roda "porque ele prefere seu próprio método" é bem raro. Principalmente é feito por ignorância e, às vezes, por teimosia.

É tudo tão ruim assim? Sim. Por quê? Porque a roda existente provavelmente foi trabalhada ao longo do tempo e já foi testada em muitas circunstâncias e contra muitos tipos diferentes de dados. O (s) desenvolvedor (es) da roda existente já encontrou os casos-limite e as dificuldades que o reinventor ainda não pode imaginar.

As rodas quadradas devem ser reinventadas. Esforços que sugam têm que ser duplicados. Talvez haja falta de documentação para o método, e o outro programador sente que é mais fácil apenas escrever o próprio, em vez de tentar descobrir. Talvez a maneira como o método está sendo chamado seja desajeitada e não se encaixa no idioma da linguagem de programação.

Pergunte a ele qual é a deficiência.

Em geral, evito reinventar a roda se a funcionalidade que desejo ou algo próximo a ela existir na biblioteca padrão da linguagem que eu uso.

No entanto, se eu tiver que incorporar bibliotecas de terceiros, será um julgamento dependendo de quão amplamente usada e estimada é a biblioteca. Quer dizer, estamos falando de Impulso ou das ferramentas de análise de corda de Bob 1.0?

Mesmo que a biblioteca seja geralmente bem conhecida e altamente estimada em toda a indústria, ainda é uma dependência de terceiros . Os programadores geralmente colocam ênfase significativa nas virtudes da reutilização de código, enquanto freqüentemente encobrem o perigo de dependências. Um projeto com muitas dependências de terceiros provavelmente se desintegrará a longo prazo, à medida que ele lentamente se transformar em um pesadelo de manutenção.

Portanto, aproveitar o código existente é bom, mas as dependências são ruins. Infelizmente, essas duas afirmações estão em desacordo umas com as outras, então o truque é tentar encontrar o equilíbrio certo. É por isso que você precisa identificar as dependências aceitáveis . Como eu disse, qualquer coisa na Biblioteca Padrão da linguagem é provavelmente uma dependência aceitável. Continuando a partir daí, as bibliotecas que são altamente consideradas em toda a indústria também são geralmente aceitáveis (como Boost para C ++ ou jQuery para Javascript) - mas elas ainda são menos desejáveis do que a Biblioteca Padrão porque elas > do tendem a ser menos estáveis do que as bibliotecas padronizadas.

Quanto a bibliotecas relativamente desconhecidas (por exemplo, o último upload no SourceForge), estas são dependências extremamente arriscadas, e eu geralmente recomendaria evitá-las em código de produção, a menos que você esteja familiarizado o suficiente com o código-fonte para mantê-las.

Então, é realmente um ato de equilíbrio. Mas o ponto é que apenas cegamente dizendo "Código reutilize bom! Reinventando roda ruim!" é uma atitude perigosa. Os benefícios de aproveitar o código de terceiros devem ser ponderados em relação às desvantagens de introduzir dependências.

Uma razão útil para reinventar a roda é para fins de aprendizado - mas eu recomendo fazê-lo em seu próprio tempo. À medida que mais soluções pré-enlatadas se tornam disponíveis e mais níveis de abstração são fornecidos, nos tornamos muito mais produtivos. Podemos nos concentrar no problema de negócios, e não nas coisas genéricas que foram alteradas várias vezes. MAS, por esse motivo, você pode aperfeiçoar suas habilidades e aprender muito tentando reimplementar uma solução por conta própria. Apenas não necessariamente para uso em produção.

Uma outra coisa - se uma preocupação for a dependência de uma biblioteca de terceiros de uma empresa que pode desaparecer, verifique se há uma opção para obter o código-fonte ou pelo menos algumas outras opções disponíveis para usar .

A propósito, se você optar por implementar o seu próprio, evite fazer isso para criptografia ou outras funcionalidades relacionadas à segurança. Ferramentas estabelecidas (e totalmente testadas) estão disponíveis para isso, e hoje em dia, é muito arriscado fazer as suas. Isso nunca vale a pena, e é assustador que eu ainda saiba de equipes fazendo isso.

Se as pessoas não reinventassem as rodas, o mundo estaria cheio delas ...

Aqui está um diálogo do meu local de trabalho:

- I would like to add some colors to the output of this program.
- Oh, there is this library called Colorama ..

Existem duas opções: reinventar a roda OU usar o Colorama. Aqui está o que cada opção resultaria em:

Usando o Colorama

• Talvez um pouco mais rápido para ser executado
• Adicionando uma dependência de terceiros para algo trivial
• Você continua sendo tão estúpido quanto antes usando Colorama

Reinventando a roda

• Você entende como alguns programas podem mostrar cores
• Você aprende que caracteres especiais podem ser usados para colorir em qualquer terminal
• Você pode colorir em qualquer linguagem de programação que possa usar no futuro
• Seu projeto tem menos chances de quebrar

Como você vê, tudo depende do contexto. Reinventar a roda é algo que eu faço com muita frequência porque quero ser capaz e pensar por mim mesmo e não confiar em outras pessoas pensando por mim. Se, no entanto, você está executando em um prazo ou o que você tenta implementar é enorme e já existe, então é melhor você usar o que está lá.

Existem dois tipos de eficiência - processamento / velocidade (que é a rapidez com que é executada), que podem corresponder e velocidade de desenvolvimento, o que quase certamente não acontecerá. Essa é a primeira razão - para qualquer problema de complexidade razoável onde as soluções existentes estão disponíveis, quase certamente será mais rápido pesquisar e implementar uma biblioteca existente do que codificar sua própria .

A segunda razão é que a biblioteca existente (assumindo que é madura) é testada e está provada que funciona - provavelmente em uma variedade muito maior de cenários do que um desenvolvedor e uma equipe de teste poderão colocar uma rotina recém escrita por escrito e isso vem com esforço zero.

Em terceiro lugar, é mais fácil de suportar. Não apenas o alguém suporta e o melhora (quem escreveu a biblioteca / componente), mas é muito mais provável que outros desenvolvedores estejam familiarizados com ele e sejam capazes de entender e manter o código daqui para frente , o que minimiza os custos contínuos.

E tudo isso pressupõe equivalência funcional, o que normalmente não é o caso. Freqüentemente, as bibliotecas oferecerão funcionalidades que você consideraria úteis, mas que nunca poderiam justificar a criação, todas de repente disponíveis gratuitamente.

Existem razões para criar o seu próprio - em grande parte, quando você quer fazer algo que a função incorporada não pode fazer e onde há uma vantagem real a ser obtida ao fazer isso, ou onde as opções prontamente disponíveis não são maduras - mas são menos comuns do que muitos desenvolvedores gostariam que você acreditasse.

Além disso, por que você quer gastar seu tempo resolvendo problemas que já foram resolvidos? Sim, é uma ótima maneira de aprender, mas você não deve fazer isso com o custo da solução certa para o código de produção, e é disso que estou supondo que estamos falando.

É claro que reinventar a roda por capricho, por ignorância e arrogância pode ser uma coisa ruim, mas IMHO o pêndulo balançou muito longe. Há uma tremenda vantagem em ter uma roda que faça exatamente o que você quer e nada mais .

Muitas vezes, quando olho para uma roda existente, ela faz muito mais do que eu preciso, sofre com o efeito da plataforma interna, e, portanto, é desnecessariamente complexo ou está faltando algum recurso importante que eu preciso e que seria difícil de implementar além do que já existe.

Além disso, usar rodas existentes muitas vezes adiciona restrições ao meu projeto que eu não quero. Por exemplo:

• A roda existente requer um idioma e / ou estilo de programação diferente do que eu preferiria usar.
• A roda existente só funciona com a versão legada de uma linguagem (por exemplo, Python 2 em vez de Python 3).
• Onde há compensações entre eficiência, flexibilidade e simplicidade, a roda existente faz escolhas que são abaixo do ideal para o meu caso de uso. (Sou conhecido por reinventar até funcionalidades de bibliotecas que eu mesmo escrevi nesses casos. Geralmente, é porque eu escrevi a versão da biblioteca da função para ser genérica e razoavelmente eficiente, quando eu atualmente preciso de algo que é muito rápido no meu específico caso.)
• A roda existente tem toneladas de lixo legado que é totalmente inútil no caso de novo código, mas dificulta a vida (por exemplo, uma biblioteca Java que eu uso que me obriga a usar suas classes de contêiner porque ele foi escrito antes dos genéricos, etc).
• A maneira como a roda existente modela o problema é completamente diferente do que é conveniente para o meu caso de uso. (Por exemplo, talvez seja conveniente para mim ter um gráfico direcionado representado por objetos de nó e referências, mas a roda existente usa uma matriz de adjacência ou vice-versa. Talvez seja conveniente depositar meus dados na ordem principal da coluna, mas o roda existente insiste na linha principal ou vice-versa.)
• A biblioteca adiciona uma dependência enorme e frágil que seria um incômodo importante para começar a trabalhar em todos os lugares que eu quero implantar meu código, quando tudo que eu preciso é um pequeno subconjunto de seus recursos. Por outro lado, nesse caso, às vezes, apenas extraio o recurso que quero em uma nova biblioteca menor, ou apenas copio / colo, se a biblioteca for de código aberto e a base de código fizer isso de modo suficientemente simples. (Eu até fiz isso com bibliotecas relativamente grandes que eu mesmo escrevi, não apenas de outras pessoas.)
• A roda existente tenta ser pedantemente compatível com algum padrão que é inconveniente e irrelevante para o meu caso de uso.

Geralmente eu uso o meu próprio porque o construí antes de descobrir o pré-existente e estou com preguiça de encontrar e substituir cada instância. Além disso, eu entendo completamente o meu próprio método, embora eu possa não entender um pré-existente. E, finalmente, como não entendo completamente o pré-existente, não posso verificar se ele faz absolutamente tudo que o meu atual faz.

Existe muito para codificar, e eu não tenho muito tempo para voltar e recodificar algo, a menos que isso afete a produção.

Na verdade, um aplicativo da Web asp que ainda é usado atualmente tem um gráfico totalmente funcional que exibe dados em um formato tabular e permite classificar / editar, no entanto, não é um datagrid. Foi construído há alguns anos quando aprendi asp.net e não conhecia datagrids. Eu estou meio que com medo do código, pois não tenho ideia do que estava fazendo naquela época, mas funciona, é preciso, é fácil de modificar, não falha, e os usuários adoram isso

Reinventar a roda é uma ótima maneira de aprender como uma roda funciona, mas não é uma boa maneira de construir um carro.

Eu atualmente trabalho para um monte de cheapskates.

Quando a decisão é tomada entre "construir ou comprar", em vez de tomar uma decisão racional baseada em economia, os gerentes optam por "construir". Isso significa que, em vez de pagar alguns milhares de dólares por um componente ou ferramenta, gastamos meses construindo os nossos. A compra de uma roda de outra empresa custa dinheiro que sai do orçamento - o que conta contra os bônus de gestão inadequada do final do ano. O tempo dos programadores é grátis e, portanto, não conta contra os bônus de final de ano (com o benefício adicional de fazer com que os programadores não façam tudo "no prazo"), portanto uma roda reinventada é uma roda livre .

Apresentação sobre construir vs comprar
Artigo sobre construção vs. compra .

If I see someone is clearly reinventing the wheel by building their own method of something that is already built into the language/framework. First, for arguments sake, lets assume that their method is just as efficient as the built in method. Also the developer, aware of the built in method, prefers his own method.

Why should he use the built in one over his own?

A versão embutida terá muito mais pessoas jogando fora - assim encontrando e consertando mais bugs do que o seu código homebrew pode ter.

Finalmente, quando o desenvolvedor local sair, e alguém tiver que manter o código que ele escreveu, ele será totalmente refatorado e substituído pelo que está no framework. Eu sei que isso vai acontecer porque o meu empregador atual tem código que foi migrado para versões mais recentes do VB ao longo dos anos (o produto mais antigo está no mercado há cerca de 20 anos) e é isso que aconteceu. O desenvolvedor com o emprego mais longo em meu escritório está aqui há 17 anos.

A coisa de reinventar a roda é que às vezes não há uma roda padronizada e pronta para uso que faça o que você precisa. Há muitas rodas boas por aí, em muitos tamanhos, cores, materiais e modos de construção. Mas alguns dias você tem que ter uma roda realmente leve que seja alumínio anodizado verde, e ninguém faz um. Nesse caso, você tem que fazer o seu próprio.

Agora, isso não quer dizer que você deve fazer suas próprias rodadas para cada projeto - a maioria das coisas pode usar peças padrão e ser melhor para ele. Mas de vez em quando, você descobre que as partes padrão simplesmente não funcionam, então você faz o seu próprio.

O mais importante é saber QUANDO fazer o seu próprio. Você tem que ter uma boa idéia do que as peças padrão podem fazer, e o que elas não podem, antes de começar a projetar suas próprias peças.

Se reinventar ou não a roda é uma coisa de custo / benefício. Os custos são bastante óbvios ...

• Demora muito tempo para fazer a reinvenção.
• Demora ainda mais tempo para documentar o que você inventou.
• Você não pode contratar pessoas que já entendam o que você inventou.
• É muito fácil reinventar algo mal, causando custos contínuos pelos problemas causados pelo mau design.
• Novo código significa novos bugs. O código antigo geralmente já teve a maioria dos bugs removidos e pode ter soluções sutis para problemas dos quais você não está ciente e, portanto, não pode trabalhar no novo design.

O último é importante - há um post em algum lugar alertando sobre a tendência de "jogar fora o código antigo e começar do zero" com base no fato de que muitos dos antigos problemas que você não entende são correções de bugs essenciais. Há um conto preventivo sobre o Netscape, IIRC.

As vantagens podem ser ...

• A capacidade de adicionar recursos que as bibliotecas existentes não possuem. Por exemplo, tenho contêineres que "mantêm" suas instâncias de iterador / cursor. Inserções e exclusões não invalidam iteradores. Um iterador apontando para um vetor continuará a apontar para o mesmo item (não o mesmo índice), independentemente de inserções e exclusões anteriores no vetor. Você simplesmente não pode fazer isso com contêineres C ++ padrão.
• Um design mais especializado direcionado a suas necessidades específicas e respeitando suas prioridades (mas tenha cuidado com a tendência para o efeito de plataforma interna).
• Controle completo - alguns terceiros não podem decidir reprojetar a API de maneira que você tenha que reescrever metade da sua inscrição.
• Compreensão completa - você projetou dessa forma, então, esperamos que você entenda como e por que você fez isso.
• EDITAR Você pode aprender as lições de outras bibliotecas sem ser pego nas mesmas armadilhas por ser seletivo sobre como você as imita.

Uma coisa: usar uma biblioteca de terceiros pode contar como reinventar a roda. Se você já tem sua própria biblioteca antiga, bem usada e bem testada, pense cuidadosamente antes de descartá-la para usar uma biblioteca de terceiros. Pode bem ser uma boa ideia a longo prazo - mas pode haver uma enorme quantidade de trabalho e muitas surpresas desagradáveis (de diferenças semânticas sutis entre as bibliotecas) antes de você chegar lá. Por exemplo, considere o efeito de eu mudar de meus próprios contêineres para os de biblioteca padrão. Uma tradução ingênua do código de chamada não permitiria o fato de que os contêineres da biblioteca padrão não mantêm seus iteradores. Casos em que eu salvo um iterador para mais tarde, pois um "favorito" não poderia ser implementado usando uma tradução simples - eu precisaria de alguns meios alternativos não triviais de indicar posições de favoritos.

Se houver um componente em funcionamento que faz o que você precisa , por que gastar o tempo escrevendo e depurando sua própria versão? Da mesma forma, se você já escreveu código para preencher uma função semelhante anteriormente, por que reescrevê-lo?

Joel escreveu um artigo sobre Não-inventado-aqui que fala muito sobre quando reescrever código e software não é e não é útil.

Reinventar a roda pode ser uma ótima maneira de aprender como algo funciona - e eu recomendo reinventar apenas para esse propósito em seu próprio tempo - mas ao escrever um aplicativo, por que reinventar se existem soluções bem estabelecidas que já fazem a mesma coisa?

Por exemplo, eu nunca escreveria código JavaScript do zero; em vez disso, eu começaria com o jQuery e criaria meus aplicativos no topo desse framework.

Minha regra pessoal:

Reinventar a roda é bom quando você está aprendendo. Se você tiver um prazo, talvez queira usar as rodas existentes.

Ser "ruim" ou até mesmo "mal" é uma palavra bastante strong.

Como sempre, há razões para escolher uma implementação pessoal em vez de uma embutida. Antigamente, um programa em C poderia encontrar erros na biblioteca de tempo de execução e, portanto, simplesmente teria que fornecer sua própria implementação.

Isso não se aplica a programas Java, pois a JVM é definida de forma muito rígida, mas alguns algoritmos ainda são muito difíceis de acertar. Por exemplo, Joshua Bloch descreve como o algoritmo de busca binária enganosamente simples na biblioteca de tempo de execução de Java continha um bug, que levou nove anos para aparecer:

link

Foi encontrado, corrigido e distribuído em futuras distribuições Java.

Se você usar a pesquisa binária incorporada, você economizou tempo e dinheiro fazendo com que a Sun faça o trabalho pesado, encontrando, corrigindo e distribuindo essa correção de bugs. Você pode aproveitar o trabalho deles dizendo "você precisa pelo menos do Java 6 update 10".

Se você usa sua própria implementação - o que muito provavelmente continha esse erro também - primeiro você precisa do bug para se manifestar. Dado que este em particular mostra apenas em conjuntos de dados GRANDES, está fadado a acontecer em produção em algum lugar, significando que pelo menos um dos seus clientes será afetado e provavelmente perderá dinheiro real enquanto você encontrar, corrigir e distribuir o bugfix.

Portanto, é perfeitamente válido preferir sua própria implementação, mas a razão é melhor ser realmente boa, já que é mais cara do que alavancar o trabalho de outras pessoas.

Eu recentemente escrevi meus pensamentos sobre esse assunto. Para resumir:

1. É quase sempre o mal para construir o seu, especialmente se for uma função embutida na linguagem. Mas se você está avaliando uma estrutura imatura / questionavelmente mantida / mal documentada que você encontrou na Internet contra a possibilidade de escrever a sua própria, pode ser um acéfalo.

2. Eu acho que reinventar a roda é uma analogia horrível para um anti-padrão de software. Isso implica que a solução original nunca pode ser melhorada. Isso é um absurdo. A chamada roda pode se tornar obsoleta durante a noite, ou seus proprietários podem parar de mantê-la. A roda tem um valor diferente em cada sistema em que é usada. Então, é sempre possível inventar uma roda melhor.

3. Um dos principais benefícios de criar sua própria estrutura é que você não precisará assumir a responsabilidade pelos erros de outra pessoa. (Isso é a filosofia da Amazon .) Pense nisso desta maneira: qual deles é melhor para dizer a um cliente? -

   "Our website broke. It was someone else's fault, and we've logged a bug with its creator. There is nothing we can do about it except wait. We'll keep you updated."

   "Our website broke, and we were able to fix it immediately."