Qual é o nome do antipadrão oposto a "reinventar a roda"? [fechadas]

101

O Reinvent the wheel "antipadrão é bastante comum - em vez de usar uma solução pronta, escreva seu próprio do zero. A base de código cresce desnecessariamente, interfaces ligeiramente diferentes que fazem a mesma coisa, mas ligeiramente , abundam de forma diferente, o tempo é gasto em funções de gravação (e depuração!) Prontamente disponíveis. Nós todos sabemos disso.

Mas há algo no extremo oposto do espectro. Quando, em vez de escrever sua própria função, são duas linhas de código, você importa um framework / API / library, instancia, configura, converte o contexto em datatype como aceitável pelo framework, então chama aquela ú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 construção, manter as licenças em sincronia e seu código de instanciação é dez vezes mais longo e mais complexo do que se você simplesmente "reinventasse a roda".

As razões podem ser variadas: gerenciamento estritamente oposto à "reinvenção da roda" não importando o custo, alguém empurrando sua tecnologia favorita apesar da sobreposição marginal com os requisitos, um papel cada vez menor de um módulo anterior do sistema, ou expectativa de expansão e uso mais amplo do framework, que simplesmente nunca chega, ou apenas entendem 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?

(Eu não estou tentando começar uma discussão quando está certo ou errado, ou se é um antipadrão real ou qualquer coisa baseada em opiniões , esta é uma questão de nomenclatura simples e direta. )

Edit: o "duplicado" sugerido fala sobre a overengineering do próprio código para torná-lo "pronto para tudo", completamente separado dos sistemas externos. Essa coisa pode, em certos casos, derivar dela, mas geralmente se origina da "aversão a reinventar a roda" - reutilização do código a todo custo; Se existe uma solução "pronta" para o nosso problema, nós iremos usá-la, não importa o quão ruim ela se encaixe e a que custo ela venha. Dogmaticamente favorecendo a criação de novas dependências sobre duplicação de código, com total desconsideração dos custos de integração e manutenção dessas dependências quando comparado ao custo de criação e manutenção do novo código.

    
por SF. 18.04.2017 / 16:51
fonte

11 respostas

9

Não. Não existe um nome anti-padrão comumente usado que cubra o que você está descrevendo.

    
por 19.04.2017 / 12:29
fonte
50

Martelo de Ouro

O martelo de ouro é uma ferramenta escolhida apenas porque é extravagante. Não é rentável nem eficiente na execução da tarefa pretendida.

fonte: xkcd 801

(Apesar dos votos negativos, eu mantenho esta resposta. Pode não ser exatamente o oposto de reinventar a roda semanticamente, mas se encaixa em todos os exemplos mencionados na pergunta)

    
por 19.04.2017 / 06:01
fonte
34

Robert Martin usa o termo " Framework Bound " para se referir ao conseqüência negativa mais óbvia deste anti-padrão. Como não acho que exista um nome comum para o padrão em si, uma referência a essa consequência pode ser suficiente para a maioria dos propósitos.

    
por 18.04.2017 / 22:22
fonte
18

Esta página da Wikipédia sobre " Invented Here " descreve uma situação ligeiramente diferente, mas com características muito semelhantes resultados finais. Descreve a aversão de uma equipe em criar seu próprio código quando uma funcionalidade equivalente pode ser encontrada por aí.

Eu diria que o nome é um pouco enganador. Faz sentido quando colocar em contexto com o oposto Não inventado aqui que IMHO é praticamente um sinônimo de Reinventando a roda.

    
por 18.04.2017 / 22:38
fonte
13

Eu ouvi " Comprar Versus Build "e" Invented Here "como nomes anti-padrão para um preconceito contra o desenvolvimento de coisas em casa, mesmo quando pode fazer sentido fazê-lo. (E mesmo que a frase "comprar versus construir" deva indicar uma escolha entre alternativas viáveis, acho que é geralmente mencionado quando alguém acredita que "comprar" é a escolha correta.)

    
por 19.04.2017 / 01:02
fonte
9

Do not use a cannon to kill a mosquito

Confucius

AKA Overkill

    
por 19.04.2017 / 06:07
fonte
8

Bloat é um termo amplo, mas pode incluir o que você descreve. Nosso software se torna excessivamente complexo (inchado) por causa de todas as transformações e abstrações extras necessárias, e a complexidade e as próprias dependências contribuem para um desempenho mais baixo / menos eficiência e maior consumo de recursos (disco, largura de banda).

Se desejarmos, poderemos esclarecer com um termo como dependências inchadas .

    
por 19.04.2017 / 00:43
fonte
5

Eu acho que usar uma marreta para quebrar uma noz é bem próximo. É algo que é possível, mas é preciso uma quantidade excessiva de trabalho para quebrar uma noz dessa maneira, sem que ocorram muitos dos possíveis efeitos colaterais indesejáveis. (E há um saco inteiro de nozes para quebrar ...)

A frase também tem a vantagem de não estar computando o jargão, então pode ser muito útil para dar uma pista para alguém que não tem nenhum.

A propósito, há uma distinção a ser desenhada com hell inference . Se alguém já envolveu todas as complexidades dentro de um encapsulamento que cria interfaces simples, claras e fáceis de usar, e desde que a penalidade nos ciclos de CPU ou uso de memória não seja excessiva, e desde que a futura modificação do código encapsulado seja improvável de ser necessário, então um argumento restante contra usá-lo é o inferno de dependência que pode estar causando.

    
por 19.04.2017 / 14:14
fonte
5

Eu não acho que exista um análogo exato, mas eu diria que overdesign ou overengineering são os que mais se aproximam.

Pelo menos, eu diria que isso é o que estava realmente acontecendo quando eu encontrei algo parecido com o que você descreveu.

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, usar uma biblioteca para substituir "duas linhas de código" pode não ser necessário, mas é improvável que cause muito sofrimento - se for realmente uma biblioteca destinada a fazer a mesma coisa que seus dois linhas de código.

Uma biblioteca para fazer uma coisa simples também será simples. Não é provável que você tenha as dores de cabeça que sua pergunta implica.

Usar uma biblioteca complicada para fazer algo simples provavelmente significa que você está tentando fazer mais do que implementar a funcionalidade necessária.

Como a criação de recursos que não são necessários, prepare-se para um futuro que talvez nunca venha, etc.

O problema aqui não é realmente a falta de reinvenção da roda per se .

    
por 19.04.2017 / 13:25
fonte
4

Se você não reinventou a roda, provavelmente está usando um conjunto existente de rodas fornecido por um fornecedor ou por terceiros.

Se este for um antipadrão, geralmente é chamado de bloqueio de fornecedor.

    
por 18.04.2017 / 20:31
fonte
0

Segurança no trabalho?
Você menciona todo o esforço de manter as coisas em sincronia, etc. Algumas pessoas preferem administrar o código de outras pessoas do que escrever suas próprias. Gerentes, especialmente.

    
por 19.04.2017 / 17:54
fonte