Reinventar a roda é realmente tão ruim assim?

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

Mas porque é isso?

Não estou sugerindo que seja bom. Eu acredito que está errado. No entanto, li uma vez um artigo que dizia: se alguém está fazendo algo errado (em termos de programação), explique a eles por que está errado, se você não pode, então talvez você deva se perguntar se está realmente errado.

Isso me leva a esta pergunta:

Se eu vejo que alguém está claramente reinventando a roda, construindo seu próprio método de algo que já está incorporado na linguagem / estrutura. Primeiro, por uma questão de argumentos, vamos supor que o método deles seja tão eficiente quanto o método incorporado. Além disso, o desenvolvedor, ciente do método interno, prefere seu próprio método.

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

Como publiquei no StackOverflow, reinventar a roda geralmente é uma escolha muito boa , contrariamente à crença popular. A principal vantagem é que você tem total controle sobre o software, o que geralmente é essencial. Para uma discussão completa, veja meu post original .

Depende ..

Como em tudo, é sobre o contexto:

É bom quando:

• A estrutura ou a biblioteca é muito pesada e você precisa apenas de funcionalidade limitada. Lançar sua própria versão extremamente leve que atenda às suas necessidades é uma abordagem melhor.
• Quando você quer entender e aprender algo complexo, fazer sentido é algo que você faz.
• Você tem algo diferente a oferecer, algo que as implementações de outras pessoas 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 bugs ou restrições (por exemplo, sua versão não é segura para threads).
• Faltam recursos na sua versão.
• Sua versão tem uma documentação pior.
• Sua versão está sem testes de unidade em comparação com o que está substituindo.

Eu acho que o caso de um desenvolvedor conscientemente reinventando a roda "porque ele prefere seu próprio método" é bastante raro. Principalmente, é por ignorância e, às vezes, por teimosia.

Isso é tão ruim assim? Sim. Por quê? Porque a roda existente provavelmente foi criada ao longo do tempo e já foi testada em várias circunstâncias e contra diversos tipos de dados. Os desenvolvedores da roda existente já encontraram os casos extremos e as dificuldades que o reinventor ainda não pode imaginar.

Rodas quadradas precisam ser reinventadas. Os esforços que sugam têm que ser duplicados. Talvez haja uma falta de documentação para o método, e o outro programador sente que é mais fácil apenas escrever a sua própria, em vez de tentar descobrir. Talvez a maneira como o método está sendo chamado seja estranha e não se encaixe no idioma da linguagem de programação.

Basta perguntar a ele qual é a deficiência.

Em geral, evito reinventar a roda se a funcionalidade que desejo, ou algo parecido com ela, existir na biblioteca padrão da linguagem que uso.

No entanto, se eu tiver que incorporar bibliotecas de terceiros, é uma decisão judicial, dependendo de quão amplamente utilizada e estimada a biblioteca seja. Quero dizer, estamos falando do Boost ou das Ferramentas de Análise de Cordas Kick-ass 1.0 de Bob?

Mesmo que a biblioteca seja geralmente bem conhecida e altamente estimada em todo o setor, ainda é uma dependência de terceiros . Os programadores geralmente colocam ênfase significativa nas virtudes da reutilização de código, enquanto frequentemente ignoram o perigo de dependências. Um projeto com muitas dependências de terceiros provavelmente desmoronará a longo prazo, pois lentamente se transforma 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, portanto o truque é tentar encontrar o equilíbrio certo. É por isso que você precisa identificar dependências aceitáveis . Como eu disse, qualquer coisa na Biblioteca Padrão da linguagem provavelmente é uma dependência aceitável. Movendo-se a partir daí, as bibliotecas que são altamente considerados em toda a indústria também são geralmente aceitáveis (como impulso para C ++, ou jQuery para JavaScript) -, mas eles são ainda menos desejável do que a biblioteca padrão porque eles não tendem a ser menos estáveis do que as bibliotecas normalizadas .

Quanto às bibliotecas que são relativamente desconhecidas (por exemplo, o upload mais recente no SourceForge), essas são dependências extremamente arriscadas, e eu geralmente recomendo evitá-las no código de produção, a menos que você esteja familiarizado o suficiente com o código-fonte para mantê-las.

Então é realmente tudo um ato de equilíbrio. Mas o ponto é que apenas cegamente dizendo "Código reutiliza bem! Reinventando a roda ruim!" é uma atitude perigosa. Os benefícios de aproveitar o código de terceiros devem ser ponderados contra as desvantagens da introdução de dependências.

Se as pessoas não reinventassem as rodas, o mundo ficaria 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 começar a correr
• Adicionando uma dependência de terceiros para algo trivial
• Você continua sendo tão estúpido como antes de usar o Colorama

Reinventando a roda

• Você entende como alguns programas conseguem mostrar cores
• Você aprende que caracteres especiais podem ser usados ​​para colorir em qualquer terminal
• Você pode colorir qualquer linguagem de programação que possa usar no futuro
• É menos provável que seu projeto seja interrompido

Como você vê, tudo depende do contexto. Reinventar a roda é algo que faço muitas vezes porque quero ser capaz de pensar por mim mesmo e não confiar nas outras pessoas que pensam em mim. Se, no entanto, você estiver executando em um prazo ou o que você tentar implementar for enorme e já existir, será melhor usar o que está lá.

Um motivo útil para reinventar a roda é para fins de aprendizado - mas eu recomendo fazê-lo no 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 comercial, e não nas coisas genéricas que foram aprimoradas uma e outra vez. MAS, por esse motivo, você pode aprimorar 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 é a dependência de uma empresa 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 por aí para recorrer.

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, nos dias de hoje, é muito arriscado demais para você mesmo. Isso nunca vale a pena, e é assustador que eu ainda ouça sobre equipes fazendo isso.

Existem dois tipos de eficiência - processamento / velocidade (que é a rapidez com que é executada) que podem corresponder e velocidade de desenvolvimento que quase certamente não será. Essa é a primeira razão - para qualquer problema de complexidade razoável em que as soluções existentes estejam disponíveis, certamente será mais rápido pesquisar e implementar uma biblioteca existente do que codificar a sua .

A segunda razão é que a biblioteca existente (assumindo que está madura) é testada e está comprovada que funciona - provavelmente em uma variedade de cenários muito mais ampla do que um desenvolvedor e uma equipe de teste será capaz de executar uma rotina recém-escrita e isso ocorre em esforço zero.

Em terceiro lugar, é muito mais fácil apoiar. Não apenas alguém o suporta e aprimora (quem escreveu a biblioteca / componente), mas é muito mais provável que outros desenvolvedores estejam familiarizados com ela e sejam capazes de entender e manter o código daqui para frente , o que minimiza a continuidade custos.

E tudo isso assume equivalência funcional, o que normalmente não é o caso. Freqüentemente, as bibliotecas oferecem funcionalidades que você consideraria úteis, mas que nunca poderiam justificar a construção, e que de repente estão disponíveis gratuitamente.

Há razões para você se destacar - principalmente onde você deseja fazer algo que a função integrada não pode fazer e onde há uma vantagem genuína a ser obtida com isso, ou onde as opções prontamente disponíveis não são maduras - mas elas é menos comum do que muitos desenvolvedores acreditariam.

Além disso, por que você gostaria de gastar seu tempo resolvendo problemas que já foram resolvidos? Sim, é uma ótima maneira de aprender, mas você não deve fazer isso à custa da solução certa para o código de produção, e é disso que estou assumindo que estamos falando.

É claro que reinventar a roda por um capricho, por ignorância e arrogância, pode ser uma coisa ruim, mas IMHO o pêndulo balançou demais. Há uma tremenda vantagem em ter uma roda que faz exatamente o que você deseja e nada mais .

Freqüentemente, quando olho para uma roda existente, ela faz muito mais do que eu preciso, sofre com o efeito da plataforma interna e , portanto , é desnecessariamente complexa, ou está faltando algum recurso essencial de que preciso e que seria difícil de executar. implementar em cima do que já está lá.

Além disso, o uso de rodas existentes geralmente adiciona restrições ao meu projeto que eu não quero. Por exemplo:

• A roda existente requer uma linguagem e / ou estilo de programação diferente do que eu preferiria usar.
• A roda existente funciona apenas com a versão herdada de uma linguagem (por exemplo, Python 2 em vez de Python 3).
• Onde existem vantagens e desvantagens entre eficiência, flexibilidade e simplicidade, a roda existente faz escolhas abaixo do ideal para o meu caso de uso. (Sou conhecido por reinventar até a funcionalidade 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 atualmente preciso de algo que seja muito rápido no meu específico caso.)
• A roda existente possui toneladas de lixo herdado que é totalmente inútil no caso de um novo código, mas dificulta a vida (por exemplo, uma biblioteca Java que eu uso que me obriga a usar suas classes de contêineres ruins porque foram escritas 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 e referências de nós, mas a roda existente usa uma matriz de adjacência ou vice-versa. Talvez seja conveniente que eu coloque meus dados na ordem principal da coluna, mas o roda existente insiste na linha principal ou vice-versa.)
• A biblioteca adiciona uma dependência massiva e quebradiça que seria um grande aborrecimento para ser instalado e executado em qualquer lugar que eu queira implantar meu código, quando tudo o que preciso é de um pequeno subconjunto de seus recursos. Por outro lado, nesse caso, às vezes, apenas extraio o recurso que desejo para uma nova biblioteca menor ou apenas copio / colo se a biblioteca for de código aberto e a base de código simplificar o processo. (Até fiz isso com bibliotecas relativamente grandes que escrevi para mim, não apenas para outras pessoas.)
• A roda existente tenta ser pedanticamente compatível com algum padrão que é inconveniente e irrelevante para o meu caso de uso.

Geralmente uso o meu próprio porque o construí antes de descobrir o já existente e tenho preguiça de encontrar e substituir todas as instâncias. Além disso, eu entendo completamente meu próprio método, embora possa não entender um método pré-existente. E, finalmente, como não compreendo completamente o pré-existente, não posso verificar se ele faz absolutamente tudo o que o meu atual faz.

Há muito para codificar, e não tenho muito tempo para voltar e codificar novamente algo, a menos que isso afete a produção.

De fato, um aplicativo da web asp ainda usado hoje possui um gráfico totalmente funcional que exibe dados em um formato tabular e permite a classificação / edição, no entanto, não é um datagrid. Ele foi construído alguns anos atrás quando eu estava aprendendo o asp.net e não sabia de datagrids. Estou com medo do código, pois não tenho idéia do que estava fazendo naquela época, mas funciona, é preciso, é fácil de modificar, não trava e os usuários adoram

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

Atualmente, trabalho para um monte de baratinhos.

Quando a decisão é tomada entre "construir ou comprar", em vez de tomar uma decisão racional baseada na economia, os gerentes optam por "construir". Isso significa que, em vez de pagar alguns milhares de dólares por um componente ou ferramenta, gastamos homens-mês construindo os nossos. Comprar uma roda de outra empresa custa dinheiro que sai do orçamento - o que conta contra os bônus de final de ano não administrativos. O tempo dos programadores é gratuito e, portanto, não conta com os bônus de final de ano (com o benefício adicional de enganar os programadores por não fazer tudo "pontualmente"), portanto, uma roda reinventada é uma roda livre .

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

Apresentação sobre build vs buy .
Artigo sobre build vs buy .

Se eu vejo que alguém está claramente reinventando a roda, construindo seu próprio método de algo que já está incorporado na linguagem / estrutura. Primeiro, por uma questão de argumentos, vamos supor que o método deles seja tão eficiente quanto o método incorporado. Além disso, o desenvolvedor, ciente do método interno, prefere seu próprio método.

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

A versão incorporada terá muito mais pessoas trabalhando nela - encontrando e corrigindo mais bugs do que o seu código de homebrew jamais poderia 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á na estrutura. Eu sei que isso acontecerá porque meu empregador atual possui um 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 foi isso que aconteceu. O desenvolvedor com o emprego mais longo em meu escritório está aqui há 17 anos.

O importante em reinventar a roda é que, às vezes, não existe uma roda padrão e pronta para uso que faça o que você precisa. Existem muitas rodas boas por aí, em muitos tamanhos, cores, materiais e modos de construção. Mas alguns dias você só precisa ter uma roda realmente leve que é de alumínio anodizado verde, e ninguém faz uma. Nesse caso, você tem que fazer o seu próprio.

Agora, isso não significa que você deve fazer suas próprias rodas para cada projeto - a maioria das coisas pode usar peças padrão e ser melhor para isso. Mas, de vez em quando, você descobre que as peças padrão simplesmente não funcionam, então você cria as suas.

O mais importante é saber QUANDO fazer o seu próprio. Você precisa 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.

A reinvenção ou não da roda é uma questão de custo / benefício. Os custos são bastante óbvios ...

• Demora muito tempo para reinventar.
• Leva ainda mais tempo para documentar o que você inventou.
• Você não pode contratar pessoas que já entendem o que você inventou.
• É muito fácil reinventar algo mal, causando custos contínuos para os problemas causados ​​pelo mau design.
• Novo código significa novos bugs. O código antigo geralmente já removeu a maioria dos erros e pode ter soluções sutis para problemas que você não conhece e, portanto, não pode solucionar o 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 grande parte do lixo antigo que você não entende é realmente uma correção essencial. Há uma história de advertência sobre o Netscape, IIRC.

As vantagens podem ser ...

• A capacidade de adicionar recursos que as bibliotecas existentes não possuem. Por exemplo, eu tenho contêineres que "mantêm" suas instâncias de iterador / cursor. Inserções e exclusões não invalidam os iteradores. Um iterador apontando para um vetor continuará apontando 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, visando seus requisitos específicos e respeitando suas prioridades (mas cuidado com a tendência ao efeito da plataforma interna).
• Controle completo - alguns terceiros não podem decidir reformular a API de uma maneira que signifique que você precise reescrever metade do seu aplicativo.
• Compreensão completa - você a projetou dessa maneira, e esperançosamente entenderá como e por que fez isso.
• EDIT Você pode aprender as lições de outras bibliotecas sem ser pego nas mesmas armadilhas sendo seletivo sobre como imitá-las.

Uma coisa - usar uma biblioteca de terceiros pode contar como reinventar a roda. Se você já possui sua própria biblioteca antiga, bem usada e bem testada, pense com cuidado antes de descartá-la para usar uma biblioteca de terceiros. Pode ser uma boa idéia a longo prazo - mas pode haver uma enorme quantidade de trabalho e muitas surpresas desagradáveis ​​(devido a sutis diferenças semânticas 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. Os casos em que eu salvei um iterador para mais tarde como um "marcador" não puderam ser implementados usando uma tradução simples.

Se houver um componente funcional que faça o que você precisa , por que gastar tempo escrevendo e depurando sua própria versão? Da mesma forma, se você já escreveu um código para desempenhar 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.

Reinventar a roda pode ser uma ótima maneira de aprender como algo funciona - e eu recomendo reinventar para esse fim 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, começaria com o jQuery e construiria meus aplicativos sobre essa estrutura.

Minha regra pessoal:

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

Ser "mau" ou mesmo "mau" é uma palavra bastante forte.

Como sempre, existem razões para escolher uma implementação pessoal em vez de uma embutida. Antigamente, um programa C podia encontrar erros na biblioteca de tempo de execução e, portanto, simplesmente precisava fornecer sua própria implementação.

Isso não se aplica a programas Java, pois a JVM é muito rigorosamente definida, mas alguns algoritmos ainda são muito difíceis de corrigir. Por exemplo, Joshua Bloch descreve como o algoritmo de pesquisa binária enganosamente simples na biblioteca de tempo de execução Java continha um bug, que levou nove anos para aparecer:

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

Foi encontrado, corrigido e distribuído em futuras distribuições Java.

Se você usar a pesquisa binária incorporada, economizou tempo e dinheiro fazendo com que a Sun fizesse o trabalho duro de encontrar, corrigir e distribuir esse bugfix. Você pode aproveitar o trabalho deles apenas dizendo "você precisa pelo menos do Java 6, atualização 10".

Se você usar sua própria implementação - que provavelmente conteria esse erro também - primeiro será necessário que o bug se manifeste. Dado que esse em particular é exibido apenas em conjuntos de dados GRANDES, é provável que aconteça em produção em algum lugar, o que significa que pelo menos um de seus clientes será afetado e provavelmente perderá dinheiro real enquanto você encontra, corrige e distribui a correção.

Portanto, é perfeitamente válido preferir sua própria implementação, mas é melhor que o motivo seja realmente bom, pois é mais caro do que alavancar o trabalho de outras pessoas.

Eu escrevi recentemente meus pensamentos sobre este tópico. Para resumir:

1. É quase sempre ruim criar o seu próprio, especialmente verdadeiro se for uma função incorporada à linguagem. Mas se você estiver avaliando uma estrutura imatura / mantida de maneira questionável / mal documentada que encontrou na Internet contra a possibilidade de criar sua própria, isso pode ser um acéfalo.

2. Eu acho que reinventar a roda é uma analogia bastante terrível para um anti-padrão de software. Isso implica que a solução original nunca pode ser aprimorada. Isso é um absurdo. A chamada roda pode se tornar obsoleta da noite para o dia, ou seus proprietários podem parar de mantê-la. A roda tem um valor diferente em cada sistema em que é usada. Portanto, muitas vezes é inteiramente possível inventar uma roda melhor.

3. Um grande benefício de criar sua própria estrutura é que você não terá que se responsabilizar pelos erros de outra pessoa. (Essa é a filosofia da Amazon .) Pense da seguinte maneira: qual dessas é melhor informar ao cliente? -

   "Nosso site quebrou. Foi culpa de outra pessoa, e registramos um bug com seu criador. Não podemos fazer nada além de esperar. Vamos mantê-lo atualizado."

   "Nosso site quebrou e pudemos corrigi-lo imediatamente".

Talvez seja tão eficiente quanto, mas é tão robusto? Eu acho que a razão mais convincente para usar uma biblioteca em vez de criar a sua é que a estrutura tem tantas pessoas que a utilizam que podem encontrar e corrigir 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 consegue vencer esse tipo de teste internamente.

Bem, seu próprio método, sendo tão eficiente quanto a estrutura, seria muito raro, porque a maioria das estruturas ainda possui bugs e nenhuma estrutura pode fornecer uma solução pronta para uso. A maioria dos programadores que não conseguem pensar nunca tentará escrever nada no nível da estrutura; eles apenas pesquisam no Google por uma solução pronta. Qualquer programador sábio primeiro verá se existe uma estrutura livre com a funcionalidade necessária e, em seguida, escreverá 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 afirmação feita por pessoas preguiçosas para evitar trabalhar duro. Até os escritores de frameworks reinventam; toda a estrutura .Net foi reinventada para fazer o que a COM estava oferecendo.

Por mais ofensivo que possa ser para alguns, sempre achei esse termo impróprio quando usado por qualquer forma de engenheiro ou em referência a um tópico para criar ou projetar coisas. Na verdade, não posso deixar de vê-lo como falso quando consideramos as pressões para inovar no mundo acelerado de hoje. Repetir a si mesmo (ou ignorar soluções adequadas e pré-existentes) nunca é sábio, mas, na verdade, há uma razão pela qual ainda não estamos todos olhando para telas pretas cheias de letras verdes.

Entendo "Se não está quebrado, não conserte", embora eu ache que essa frase possa parecer ignorante para alguns. No entanto, com o esforço atual de reinventar a roda para as necessidades de viagens espaciais, corridas, remessas, etc., "não reinvente a roda" também é bastante ignorante e não é nem de longe tão inteligente quanto parece.

Minha formação consiste em liderar muitos projetos e tive que trabalhar com muitos estagiários e outras formas de desenvolvedores verdes, e tive que lidar com muitas perguntas ingênuas que alguns chamariam de 'estúpidas', e também tive que desviar as pessoas de perseguir coelhos todos fora do escopo de suas tarefas. No entanto, nunca desencorajaria a inovação ou a criatividade e vi grandes coisas advindo da "reinvenção da roda".

Minha resposta real à pergunta: há apenas duas situações que tornam a reinvenção da roda uma coisa ruim:

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

Edit: Eu posso ver pelos votos drive-by down que devo ter ofendido alguns. A única coisa que eu gostaria de acrescentar é que essa frase sempre foi uma das minhas maiores irritações. Entendo que meus dois centavos podem parecer um tanto traiçoeiros, mas não tenho intenção de trollar, causar incêndios ou ofender.

Argumentos sobre "reinventar uma roda" são frequentemente usados ​​no contexto errado da escolha de usar uma biblioteca, mas não é algo parecido.

Digamos que estou avaliando uma biblioteca 'forms-plus', que ficou popular recentemente e ajuda a lidar com formulários. Ele tem uma página de destino bacana, gráficos modernos e legais e um -cult- (oops, eu quero dizer comunidade) ao redor dela, que jura como torna as formas excelentes novamente. Mas "forms-plus" é uma abstração em cima de "forms". "formas" era possível, mas difícil de lidar, então a abstração que torna mais fácil está se tornando popular.

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

A avaliação deste novo dispositivo "forms-plus" será diferente dependendo da experiência pessoal. Se eu nunca criei formulários antes, o "forms-plus" será muito atraente, porque é mais fácil começar. A desvantagem é que, se o "forms-plus" for uma abstração com vazamento, ainda assim preciso aprender "forms". Se eu estava criando formulários sem "forms-plus", precisarei levar em consideração o tempo necessário para aprender uma nova ferramenta. O lado bom é que eu já conheço "formas", então não tenho medo de abstrações. Os benefícios de curto prazo geralmente serão maiores para os novos iniciantes, porque provavelmente não haveria nova biblioteca se ela não melhorasse alguma coisa. Os benefícios a longo prazo variarão amplamente na qualidade da abstração, taxa de adoção,

Depois de avaliar cuidadosamente os benefícios e negativos do uso de uma nova abstração "forms-plus" vs usando bare bone "forms", 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" simples. Talvez, mais tarde, as formas-plus tivessem ganhado mais movimento por trás disso e se tornado um padrão defacto. E talvez minha própria implementação ao longo do tempo tenha ficado complicada e comecei a cobrir muito o que o forms-plus agora está fazendo. As pessoas que vierem neste momento serão atraídas a criticar que estou interessado em reinventar a roda e que eu deveria ter usado a biblioteca existente. Mas também é possível que, no momento em que eu tive que tomar uma decisão sobre "forms-plus", houvesse várias outras alternativas para "forms-plus",

No final, escolher as ferramentas certas é uma decisão complicada a ser tomada e a "reinvenção da roda" não é uma perspectiva muito útil.

Eu escrevi um pequeno artigo sobre isso - http://samueldelesque.tumblr.com/post/77811984752/what-re-inventing-the-wheel-can-teach-you

Na minha experiência, reinventar foi realmente ótimo - embora muito longo e tedioso. Eu diria que, se você não conhece exatamente os modelos de programação que irá usar, escreva-os você mesmo (se tiver tempo e energia). Isso ensinará o que exatamente esses modelos de programação significam e você se tornará um programador melhor. Obviamente, se você estiver trabalhando para um cliente e precisar obter algo rapidamente, provavelmente desejará fazer alguma pesquisa e encontrar o software certo para você.