O antipadrão " Reinventar a roda " é bastante comum - em vez de usar uma solução pronta, escreva a sua do zero. Base de código cresce desnecessariamente, ligeiramente diferentes interfaces que fazem a mesma coisa, mas ligeiramente diferente abundam, se perde tempo para escrever (e depuração!) Funções que estão prontamente disponíveis. Todos nós sabemos disso.
Mas há algo no extremo oposto do espectro. Quando, em vez de escrever sua própria função com duas linhas de código, você importa uma estrutura / API / biblioteca, instancia-a, configura-a, converte o contexto em tipo de dados como aceitável pela estrutura e chama essa única função que faz exatamente o que você precisa, duas linhas de lógica de negócios sob um gigabyte de camadas de abstração. E então você precisa manter a biblioteca atualizada, gerenciar dependências de compilação, manter as licenças sincronizadas e seu código de instanciação é dez vezes mais longo e mais complexo do que se você apenas "reinventasse a roda".
Os motivos podem ser variados: gerenciamento estritamente contrário à "reinvenção da roda", não importa o custo, alguém empurrando sua tecnologia preferida, apesar da sobreposição marginal com os requisitos, um papel cada vez menor de um antigo módulo do sistema, ou expectativa de expansão e expansão mais ampla uso da estrutura, que simplesmente nunca chega, ou apenas entendendo mal o "peso" que algumas instruções de importação / inclusão / carregamento carregam "nos bastidores".
Existe um nome comum para esse tipo de antipadrão?
(Não estou tentando iniciar uma discussão quando está certo ou errado, ou se é um antipadrão real ou qualquer coisa baseada em opiniões , essa é uma pergunta simples e objetiva da nomenclatura.)
Edit: o "duplicado" sugerido fala sobre o próprio código da superengenharia para torná-lo "pronto para tudo", completamente separado dos sistemas externos. Em certos casos, isso pode resultar disso, mas geralmente se origina da "aversão à reinvenção da roda" - reutilização de código a todo custo; se existir uma solução "pronta" para o nosso problema, nós a usaremos, não importando o quanto ela caiba e a que custo. Favorecendo dogmaticamente a criação de novas dependências em detrimento da duplicação de código, com total desconsideração dos custos de integração e manutenção dessas dependências quando comparados ao custo de criação e manutenção do novo código.
fonte
Respostas:
Não. Não existe um nome anti-padrão comumente usado que cubra o que você está descrevendo.
fonte
Martelo de Ouro
O martelo de ouro é uma ferramenta escolhida apenas porque é chique. Não é econômico nem eficiente na execução da tarefa pretendida.
fonte: xkcd 801
(Apesar dos votos negativos, eu mantenho essa resposta. Pode não ser exatamente o oposto de reinventar a roda semanticamente, mas se encaixa em todos os exemplos mencionados na pergunta)
fonte
Robert Martin usa o termo " Framework Bound " para se referir às conseqüências negativas mais óbvias desse antipadrão. Como não acho que exista um nome comum para o próprio padrão, uma referência a essa conseqüência pode ser suficiente para a maioria dos propósitos.
fonte
Esta página da wikipedia em " Inventado aqui " descreve uma situação ligeiramente diferente, mas com resultados finais muito semelhantes. Descreve a aversão de uma equipe em criar seu próprio código quando uma funcionalidade equivalente pode ser encontrada lá fora.
Eu diria que o nome é um pouco enganador. Faz sentido quando colocado em contexto com seu oposto. Não inventado aqui, que IMHO é praticamente um sinônimo de Reinventar a roda.
fonte
Eu ouvi " Buy Versus Build " e " Invented Here " como nomes antipadrão para um viés contra o desenvolvimento de coisas internamente, mesmo quando faz sentido fazê-lo. (E mesmo que a frase "comprar versus compilar" deva indicar uma escolha entre alternativas viáveis, acho que geralmente é mencionada quando alguém acredita que "comprar" é a escolha correta.)
fonte
AKA Overkill
fonte
Bloat é um termo amplo, mas pode incluir o que você descreve. Nosso software se torna excessivamente complexo (inchado) devido a todas as transformações e abstrações extras necessárias, e a complexidade e as dependências contribuem para menor desempenho / menor eficiência e maior consumo de recursos (disco, largura de banda).
Se desejarmos, poderíamos esclarecer com um termo como dependências inchadas .
fonte
Eu acho que usar uma marreta para quebrar uma noz é bem próximo. É algo que é possível, mas precisa de uma quantidade excessiva de trabalho para quebrar uma porca dessa maneira, sem que ocorram muitos dos possíveis efeitos colaterais indesejados. (E há um saco inteiro de nozes para quebrar ...)
A frase também tem a vantagem de não estar computando o jargão, por isso pode ser muito útil para dar uma pista a alguém que não a possui.
A propósito, há uma distinção a ser traçada com o inferno da dependência . Se alguém já tiver envolvido todas as complexidades dentro de um encapsulamento que cria interfaces simples, claras e fáceis de usar, e desde que a penalidade nos ciclos da CPU ou no uso da memória não seja excessiva, é improvável que seja necessária uma modificação futura do código encapsulado necessário, então um argumento restante contra usá-lo é o inferno da dependência que pode estar causando.
fonte
Não acho que exista um análogo exato, mas eu diria que o design excessivo ou a engenharia excessiva se aproximam.
Pelo menos, eu argumentaria que isso é o que realmente estava acontecendo quando encontrei algo semelhante ao que você descreve.
Usar uma biblioteca em vez de escrever seu próprio código para implementar a mesma funcionalidade quase nunca é prejudicial.
Mesmo em seu exemplo hipotético, o uso de uma biblioteca para substituir "duas linhas de código" pode não ser necessário, mas é improvável que lhe cause muito sofrimento - se for realmente uma biblioteca que pretende fazer o mesmo que suas duas linhas de código .
Uma biblioteca para fazer uma coisa simples também será simples. Não é provável que você tenha dores de cabeça que sua pergunta implica.
O uso de uma biblioteca complicada para fazer algo simples provavelmente implica que você está tentando fazer mais do que implementar a funcionalidade necessária.
Como criar recursos desnecessários, preparar-se para um futuro que talvez nunca venha, etc.
O problema aqui não é realmente falha em reinventar a roda em si .
fonte
Se você não reinventou a roda, provavelmente uma está usando um conjunto de rodas existente fornecido por um fornecedor ou por terceiros.
Se esse é um antipadrão, geralmente é chamado de bloqueio de fornecedor.
fonte
Seguro desemprego?
Você menciona todo o esforço de manter as coisas sincronizadas, etc. Algumas pessoas preferem gerenciar o código de outras pessoas a escrever o seu. Gerentes, especialmente.
fonte