Muitas vezes você precisa atender à recomendação "não reinvente a roda". Às vezes com negligência pronunciada e auto-afirmação, às vezes, ostensivamente , como um bom conselho. No entanto, mesmo que tenha sido chamado para ser um bom conselho, em vários contextos mostra apenas a incompetência do orador.
O objetivo aninhado da frase é salvá-lo do trabalho inútil, da chamada para usar uma solução pronta para a tarefa e, do ponto de vista de um observador externo, parece realmente razoável.
Mas, ao mesmo tempo, perde-se um fator-chave característico não apenas para o desenvolvimento de software, mas também para a solução de problemas : ao alterar o contexto em que a tarefa está definida, a solução também muda .
Perder de vista esse princípio é o mesmo que admitir sua própria incapacidade de resolver problemas aplicados.
Considere alguns casos.
Fonte
API sobre API
Um dos casos mais comuns de acusações de ciclismo é o invólucro da API de gravação automática de algum serviço, cuja implementação já está disponível.
Um caso da minha prática.
Foi necessário implementar o upload de dados do Facebook para o nosso serviço. O idioma principal e a biblioteca do Facebook foram pesquisados no Google em 2 minutos.
A documentação da biblioteca não correspondia à interface atual do programa ; muitas ações desnecessárias foram envolvidas em cada manipulação. A biblioteca acabou sendo de muito baixa qualidade .
Resultado: após 1,5 horas de trabalho, não era possível fazer login.
Um colega implementou seu próprio invólucro de API do Facebook. No total, levou cerca de uma hora para criar um wrapper e funcionalidade relacionada no lado do serviço. Para a pergunta "por que você está pedalando aqui", ele respondeu nos próximos dias.
Isso é especialmente evidente em idiomas comuns com uma grande comunidade: há uma tendência doentia de publicar wrappers de API em outra API, sob os slogans "Para humanos" e "De uma maneira simples". Esses wrappers se tornam obsoletos assim que a interface empacotada é atualizada e os autores abandonam esses "projetos", tornando o código que os utiliza inoperante.
Uma boa pergunta : e o que, cada vez que escrever esses invólucros manualmente?
Resposta: Uma solução muito mais forte para invólucros grandes seria usar um gerador de código que interprete as especificações.
Controle sobre a base de código e recusa em responder pelos erros de outras pessoas
Nos círculos de aspirantes ao desenvolvimento de jogos de computador, essa frase é dirigida a qualquer pessoa que se atreve a implementar seu mecanismo. "Por que reinventar a roda? Tome a unidade!" . Ou Game Maker, ou, Deus não permita, Defold.
Parece que o dviglo \ constructor fornece todas as ferramentas necessárias para o desenvolvimento, muitas delas são multiplataforma e geralmente simplificam a vida.
Como o contexto deve mudar aqui para que seja necessário criar seu próprio mecanismo?
No mínimo, isso é controle sobre a base de código e as funções do mecanismo (por exemplo, em vários modelos de controle, o criador de jogos é constantemente buggy, e corrigir isso pode ser extremamente problemático). Ou seja, é necessário reduzir a probabilidade de encontrar um "bug externo" , que é impossível ou extremamente difícil de corrigir por conta própria.
Isso é especialmente pronunciado em jogos que não estão saturados de sinos e assobios gráficos e / ou físicos - brega, não tanto que o mecanismo condicional assume a si próprio.
Além disso, não há necessidade de aumentar a quantidade total da base de código se uma pequena parte de suas funções for usada no mecanismo / construtor e as ferramentas necessárias ainda precisarem ser adicionadas independentemente , controlando simultaneamente a correção de seu trabalho com o mecanismo.
Por exemplo, com base nessas premissas, Tommy Refenes escreveu seu próprio mecanismo para o Super Meat Boy .
Alguém objetará: "Mas no armazém \ algum outro armazenamento, há uma montanha de predefinições \ ferramentas \ extensões!" .
Sim, é maravilhoso e dá alguns pontos à frente, mas em mecanismos com uma grande base de usuários ativos, o mesmo efeito "morrer jovem" descrito na seção anterior é bastante observado. Sem um contexto e uma tarefa específica, não se pode afirmar inequivocamente que, de, a abundância de extensões de usuário na loja será útil.
Identidade imaginária. Puxando a tarefa pelas orelhas.
Às vezes, tendo formulado o problema, verifica-se que as soluções existentes que vêm à mente ... não são adequadas. Devido ao seu "teor de gordura" ou à insatisfação de uma das principais condições da tarefa ( sim, existem várias ).
Bom exemplo: CluNet.
Cluster em seu artigo descreveu completamente os motivos das decisões tomadas por ele ao desenvolver o protocolo de casa inteligente. O exemplo é muito revelador e bem descrito, eu recomendo desmontá-lo você mesmo.
Conclusão
Ao procurar uma solução para um problema , o contexto e todas as condições fornecidas devem ser consideradas .
Mesmo em casos simples, pequenos detalhes do contexto invertem a solução e a habilidade de resolver problemas aplicados é amplamente baseada na capacidade de ver e avaliar as premissas iniciais .
Então, a frase “não reinventa a roda” diz sobre a incapacidade do consultor em resolver problemas? Se o consultor mencionou as bicicletas antes de hesitar depois de alguns minutos, provavelmente sim.
Ou, na generalização do capitão:
Pense antes de decidir.
Pense antes de falar.
E, em geral - pense.