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

97

Seu conhecimento comum em programação que reinventa a roda é ruim ou mal .

Mas por que isso acontece?

Não estou sugerindo que seja bom. Eu acredito que esteja errado. No entanto, uma vez eu li um artigo que dizia: se alguém está fazendo algo errado (programação sábia) explique a eles por que está errado, se você não puder, então talvez você devesse estar se perguntando se está realmente errado.

Isso me leva a essa pergunta:

Se eu vir alguém claramente reinventando a roda construindo seu próprio método de algo que já está embutido na linguagem / estrutura. Primeiro, por razões de argumentos, vamos supor que seu método é tão eficiente quanto o método embutido. Além disso, o desenvolvedor, ciente do método embutido, prefere seu próprio método.

Por que ele deveria usar o construído em cima do seu?

    
por JD Isaacks 23.12.2010 / 16:10
fonte

24 respostas

68

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 .

    
por 21.03.2013 / 10:30
fonte
76

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.
por 22.12.2014 / 17:38
fonte
54

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.

    
por 23.12.2010 / 16:00
fonte
21

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.

    
por 23.12.2010 / 16:04
fonte
17

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.

    
por 24.12.2010 / 14:08
fonte
13

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.

    
por 23.12.2010 / 16:16
fonte
13

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á.

    
por 18.12.2014 / 21:23
fonte
9

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.

    
por 23.12.2010 / 17:00
fonte
9

É 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.
por 24.12.2010 / 19:45
fonte
5

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

    
por 23.12.2010 / 15:58
fonte
4

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

    
por 23.12.2010 / 20:37
fonte
4

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 .

Em uma empresa racional, o custo vs benefícios de comprar rodas feitas por outros vs reinventar as próprias rodas seria baseado em custos de curto e longo prazo, bem como custos de oportunidade perdidos porque não se pode fazer novos widgets enquanto um está reinventando rodas. Todo dia que você passa reinventando a roda é outro dia em que você não pode escrever algo novo.

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.

    
por 23.12.2010 / 23:18
fonte
4

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.

    
por 24.12.2010 / 00:07
fonte
4

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.

    
por 24.12.2010 / 06:40
fonte
3

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.

    
por 23.12.2010 / 16:02
fonte
3

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.

    
por 23.12.2010 / 16:28
fonte
3

Minha regra pessoal:

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

    
por 23.12.2010 / 16:41
fonte
3

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.

    
por 24.12.2010 / 04:49
fonte
3

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."

por 24.12.2010 / 16:20
fonte
0

Talvez seja tão eficiente, mas é tão robusto? Eu acho que a razão mais convincente para usar uma biblioteca do que a sua própria é que o framework tem tantas pessoas usando isso que eles podem encontrar e consertar bugs rapidamente. A biblioteca desenvolvida internamente, embora possa fornecer a mesma funcionalidade (ou mais), não pode competir com uma biblioteca com milhões de usuários para fornecer testes em praticamente todos os casos de uso. Você simplesmente não pode superar esse tipo de teste internamente.

    
por 23.12.2010 / 15:58
fonte
0

Bem, seu próprio método sendo tão eficiente quanto o framework seria muito raro, porque a maioria dos frameworks ainda tem bugs e nenhum framework pode fornecer uma solução pronta para uso. A maioria dos programadores que não consegue pensar nunca tentará escrever nada no nível do framework; eles só pesquisarão no Google por uma solução pronta. Qualquer programador sábio verá primeiro se existe um framework livre que tenha a funcionalidade que ele precisa, e então escreva a solução se não houver. Às vezes é muito difícil explicar a situação atual do projeto e o desenvolvedor é o melhor juiz.

Reinventar a roda não é ruim, é uma declaração feita por pessoas preguiçosas para evitar trabalhar duro. Mesmo escritores de framework reinventam; todo o framework .Net foi reinventado para fazer o que COM estava oferecendo.

    
por 23.12.2010 / 21:19
fonte
0

Por mais ofensivo que possa parecer para alguns, sempre achei esse termo não-inteligente quando usado por qualquer forma de engenheiro ou em referência a um tópico de criação ou design de coisas. Na verdade, não posso deixar de considerá-lo insincero ao considerar as pressões para inovar no mundo acelerado de hoje. Repetir-se (ou ignorar soluções pré-existentes adequadas) nunca é sensato, mas, na verdade, há uma razão pela qual não estamos todos ainda olhando para telas negras cheias de letras verdes.

Eu entendo "Se não estiver quebrado, não conserte", embora eu ache que tal frase possa soar ignorante para alguns. No entanto, com o esforço atual de reinventar a roda para as necessidades de viagem espacial, corrida, transporte, etc., "não reinvente a roda" também é bastante ignorante, e não é nem de longe tão inteligente quanto parece.

Meu histórico consiste em liderar muitos projetos e tive que trabalhar com muitos estagiários e outras formas de desenvolvedores ecológicos, e tive que lidar com muitas perguntas ingênuas que alguns chamariam de 'estúpidas', e também tive que desviar pessoas de perseguir coelhos totalmente fora do escopo de suas tarefas. No entanto, eu nunca nunca desencorajaria a inovação ou a criatividade, e vi grandes coisas vindo de 'reinventar a roda'.

Minha resposta real à pergunta: existem apenas duas situações que fazem a reinvenção da roda como algo ruim:

  1. Se não for realmente necessário
  2. Se é o outro cara fazendo isso quando você poderia ter

Editar: Eu posso ver pelos votos que eu devo ter ofendido alguns. A única coisa que eu gostaria de acrescentar é que essa frase sempre foi uma grande preocupação minha. Eu entendo que meus dois centavos podem parecer bastante trollish, mas eu não tenho nenhuma intenção de trollar, causar incêndios ou ofender.

    
por 03.02.2014 / 11:14
fonte
0

Argumentos sobre "reinventar uma roda" são frequentemente usados em contextos errados de escolha de usar uma biblioteca, mas isso não é coisa semelhante.

Digamos que estou avaliando uma biblioteca 'forms-plus', que ficou popular recentemente e ajuda a lidar com formulários. Ele tem uma boa página de destino, gráficos modernos e um -cult- (oops, quero dizer comunidade) em torno dele, que jura como faz com que as formas sejam ótimas novamente. Mas "formulários mais" é uma abstração sobre "formulários". "formas" era possível, mas complicado de lidar, então a abstração que torna isso mais fácil está se tornando popular.

Novas abstrações estão acontecendo o tempo todo. É difícil compará-los com as rodas. É mais como um novo dispositivo de controle e um novo manual para qualquer dispositivo já complicado que você precise executar.

A avaliação deste novo dispositivo "forms-plus" será diferente, dependendo da experiência pessoal. Se eu nunca construí formulários antes, o "forms-plus" será muito atraente porque é mais fácil começar. A desvantagem é que, se "forms-plus" for uma abstração com vazamento, eu ainda precisarei aprender "forms" de qualquer maneira. Se eu estivesse criando formulários sem "formulários mais", precisaria levar em conta o tempo necessário para aprender uma nova ferramenta. Upside é que eu já conheço "forms", então não tenho medo de abstrações. Benefícios de curto prazo, muitas vezes, serão maiores para iniciantes, porque provavelmente não haveria nova biblioteca se não melhorasse em alguma coisa. Os benefícios a longo prazo variam muito em termos de qualidade de abstração, taxa de adoção e outros fatores já discutidos em outras respostas.

Depois de avaliar cuidadosamente os benefícios e os negativos de usar uma nova abstração "formas-mais" versus usar "formas" de osso nu, eu tomo uma decisão. A decisão é altamente baseada em minhas experiências pessoais e pessoas diferentes tomarão decisões diferentes. Eu poderia ter escolhido usar "formas" de ossos nus. Talvez mais tarde no tempo formas-plus ganhou mais movimento por trás disso e se tornando um padrão de fato. E talvez a minha implementação ao longo do tempo tenha ficado peluda e começado a cobrir muito o que o forms-plus está fazendo agora. As pessoas que chegam neste momento serão atraídas para criticar que estou interessado em reinventar a roda e eu deveria ter usado a biblioteca existente. Mas também é possível que na época em que tive de tomar decisões sobre o "forms-plus" também houvesse várias outras alternativas para "forms-plus", a maioria deles projetos mortos até agora, e possivelmente ganhei ao não escolher o errado. 1.

No final, escolher ferramentas certas é uma decisão complicada de se fazer e "reinvenção da roda" não é uma perspectiva muito útil.

    
por 07.06.2018 / 06:30
fonte
-1

Eu escrevi um pequeno artigo sobre isso - link

Na minha experiência, a reinvenção foi realmente ótima - embora muito longa e tediosa. Eu diria que, se você não sabe exatamente os modelos de programação que vai usar, escreva-os você mesmo (se tiver tempo e energia). Isso vai te ensinar sobre o que exatamente esses modelos de programação significam e você se tornará um programador melhor no final das contas. É claro que, se você está trabalhando para um cliente e só precisa obter algo rapidamente, provavelmente só vai querer fazer uma pesquisa e encontrar o software certo para você.

    
por 25.02.2014 / 17:23
fonte