O que conta como reinventar a roda?

Os seguintes cenários contam como "reinventar a roda" em seu livro?

• Existe uma solução, mas não no idioma que você deseja usar, e as soluções existentes não podem fazer interface com o idioma que você deseja usar de maneira limpa e idiomática.

• Em princípio, você poderia obter uma biblioteca existente para fazer o que queria com modificações pesadas, mas acha que provavelmente seria mais fácil começar do zero.

• O que você está escrevendo tem a mesma descrição de uma linha das coisas que já foram feitas, mas você está direcionando para um nicho diferente. Por exemplo, talvez seu problema tenha sido resolvido um zilhão de vezes antes, mas de uma maneira ineficiente para grandes conjuntos de dados e seu código funcione bem para grandes conjuntos de dados.

Se existe uma solução existente que, aos seus olhos, seria uma solução prática , não usá-la, mas criar sua própria solução seria reinventar a roda. Fora isso, é altamente subjetivo.

Sobre seus cenários específicos:

1. Você sempre quer código limpo, de fácil manutenção e fácil de entender. Isso vai além de reinventar a roda, IMHO. A restrição de tempo pode fazer com que você queira quebrar isso.
2. Se for mais fácil começar do zero, faça-o. Você provavelmente também obterá um resultado melhor se o código foi adaptado às necessidades específicas.
3. Se uma solução é uma solução ruim para o seu problema, não está reinventando a roda para criar uma nova, que está fazendo uma roda melhor .

Reinventar a roda é o que os outros o acusam quando sua análise indica que você deve escrever algo e o deles não.

Acho que reinventar a roda pode ser definido de maneira bem simples: quando, a longo prazo, você trabalha mais escrevendo-a, em vez de usar a biblioteca. Observe que nem sempre é claro quanto trabalho algo pode ser a longo prazo . Você pode hackear um protótipo em conjunto mais rápido do que pode refatorar o código existente para incluir a biblioteca, mas, a longo prazo, quando você adiciona mais recursos ou precisa dar suporte ao código, a biblioteca funcionaria melhor.

O ponto principal é que você precisa pensar cuidadosamente sobre sua situação ao decidir se deve ou não usar uma biblioteca. Você precisa decidir se a biblioteca é mais fácil para o que você deseja fazer agora e mais fácil para o que você fará no futuro . Saber o que você fará no futuro nem sempre é direto, mas se você tiver um bom plano, deverá ter uma ideia aproximada. Dito isto, às vezes as previsões são imprecisas - você geralmente não percebe que reinventou a roda até depois de fazer isso.

É amplo e subjetivo demais para ser possível responder com precisão, simplesmente porque cada caso é diferente.

É perfeitamente aceitável reinventar a roda quando necessário; a chave é usar seu julgamento para decidir quando a roda anterior é uma solução aceitável e quando ela não é redonda o suficiente para proporcionar uma condução suave.

É uma pergunta que precisa ser feita quase retoricamente às vezes para garantir que a melhor abordagem esteja sendo usada. Muitas vezes, você pode encontrar um algoritmo melhor em um livro do que a maioria dos programadores pode escrever no tempo necessário para encontrá-lo.

Quanto maior e mais complexo o problema, menor a probabilidade de existir uma roda que atenda exatamente às suas necessidades e mais legítimo você será reconstruí-la.

Acho que devemos aplicar apenas "não reinventar a roda" a elementos básicos (funções que já estão integradas na plataforma, padrões de design conhecidos ...) ou se a solução exata para o seu problema estiver disponível - mas isso é raramente o caso.

Seus 3 pontos não contam como reinventar a roda para mim.

Depende ...

Para os dois primeiros:

• Existe uma solução, mas não no idioma que você deseja usar ...
• Em princípio, você poderia obter uma biblioteca existente para fazer o que queria com modificações pesadas ...

Nos dois casos, faz sentido escrever seu próprio código. Mas considere o seguinte: a solução existente contém técnicas, algoritmos ou rotinas com as quais você pode aprender? Ignorá-los seria reinventar a roda.

• O que você está escrevendo tem a mesma descrição de uma linha das coisas que já foram feitas ... talvez seu problema tenha sido resolvido um zilhão de vezes antes, mas de uma maneira que é ineficiente para grandes conjuntos de dados ...

Três perguntas:

1. Um zilhão é muito. Você realmente olhou todas as implementações existentes?
2. A eficiência é seu principal problema?
3. Você precisa codificar a solução ideal agora (e reescrever mais tarde)?

Se a resposta para qualquer uma dessas opções for "Não", você está reinventando a roda.

Dito isto, não estou convencido de que reinventar a roda seja sempre uma coisa ruim:

1. É uma ótima maneira de aprender e a única maneira de realmente entender as soluções existentes.
2. As rodas de outras pessoas podem não ser boas . É a única maneira de fazer rodas melhores.
3. Mesmo que a roda de outras pessoas seja ótima, às vezes você pode fazer bons negócios fazendo rodas ainda melhores .

Seu primeiro cenário, se aplica para reinventar a roda, é auto-explicativa.

O segundo cenário, NÃO se aplica se o código existente exigir pouca modificação, mas se for o caso, é uma boa ideia tentar usar propriedades, métodos e uso semelhantes aos de um código existente, para que outros desenvolvedores não tenham problemas ao usar o seu "roda".

Tenha cuidado com a abordagem "é sempre melhor começar do scrath", pois pode levar mais tempo do que o esperado.

O terceiro cenário mencionado, é a abordagem "prática". A "roda dada" pode fazer o trabalho, mas, na realidade, consome muitos recursos, memória, velocidade, etc.

Trabalhei uma vez em um aplicativo que exige mostrar dados hierárquicos em um controle de árvore em uma única tabela. Já temos um controle que poderia fazer isso, mas suportamos várias tabelas por item.

Para usá-lo, tive que aprender muitas coisas, atribuir muitas propriedades, executar muitos métodos, e FOI LENTO. Um colega de trabalho insistiu em usá-lo, a fim de "não reinventar a roda".

Eu fiz um novo controle, a partir do zero, li uma única tabela, programe apenas algumas propriedades fáceis de aprender. E antes que eu percebesse, havia outro colega de trabalho que o retirou do repositório de código compartilhado e substituiu o controle anterior.

Bônus:

Quando a roda que você já possui é "ao quadrado". Por "quadrado", quero dizer que, na superfície, parece que parece uma solução para o seu problema, mas depois de uma boa olhada, você chega à conclusão de que não.

Depende se você possui as habilidades e o tempo (e a autorização da sua empresa) para reinventar a roda.

Leia pela primeira vez este excelente artigo de Joel Spolsky: Em defesa da síndrome do não-inventado aqui

Então todas as razões técnicas se tornam realmente pequenas nuances. Se você acha que este software é crítico para o seu trabalho, reescreva-o. Sim, está "reinventando a roda", mas provavelmente vale a pena gastar tempo escrevendo e mantendo. Se não for crítico, basta usar o que está disponível.

... se você já teve que terceirizar uma função crítica de negócios, percebeu que a terceirização é um inferno. Sem controle direto sobre o atendimento ao cliente, você terá um atendimento ao cliente terrivelmente ruim - o tipo que as pessoas escrevem em seus blogs quando tentam convencer alguém, alguém , de uma companhia telefônica a fazer a coisa mais básica. Se você terceirizar a satisfação, e seu parceiro de satisfação tiver uma idéia diferente sobre o que constitui a entrega rápida, seus clientes não ficarão felizes e não há nada que você possa fazer sobre isso, porque levou três meses para encontrar um parceiro de satisfação no primeiro lugar, e de fato, você nem vai saberque seus clientes estão descontentes, porque não podem falar com você, porque você configurou um centro de atendimento ao cliente terceirizado com o objetivo explícito de não ouvir seus próprios clientes. Aquele mecanismo de comércio eletrônico que você comprou? Não há como ser tão flexível quanto o que a Amazon faz com os óbidos, que eles mesmos escreveram. (E se for, a Amazon não tem vantagem sobre seus concorrentes que compraram a mesma coisa). E nenhum servidor Web disponível no mercado será tão rápido quanto o que o Google faz com seu servidor otimizado para mão, codificado e manualmente.

Infelizmente, esse princípio parece estar diretamente em conflito com o ideal de "reutilizar código bom - reinventar a roda ruim".

Os melhores conselhos que posso oferecer:

    Se é uma função principal do negócio - faça você mesmo, não importa o quê.

Escolha suas principais competências e objetivos de negócios e faça-os internamente ...

Se você estiver desenvolvendo um jogo de computador em que o enredo é sua vantagem competitiva, não há problema em usar uma biblioteca 3D de terceiros. Mas se efeitos legais em 3D forem o seu diferencial, é melhor usar o seu próprio ...