O nome deste modelo é função.
Mais especificamente, é uma interface, que geralmente é uma coleção de funções.
Que línguas você aprendeu?
Um dos primeiros, quando aprendemos programação, aprendemos o princípio da lógica reutilizável. Isso invariavelmente nos leva a funcionar - o bloco de construção de todo projeto de software. Os recursos em si não são tão ruins, mas é precisamente porque eles são usados como um componente reutilizável que escrever, manter e dimensionar software se torna tão caro.
Por quê?
Escrever código reutilizável é difícil.
Não, não é bem assim. Isso é inaceitável.
Qualquer desenvolvedor pode escrever código reutilizável, independentemente de sua experiência. Linguagens como JavaScript, Python, Ruby e Go são compostas por milhões de pequenos módulos comuns que demonstram a facilidade de escrever código-fonte simples e reutilizável. É fácil escrever código reutilizável .
Vamos refatorar essa declaração.
Mas também não é o caso. Dê uma olhada na biblioteca node.js
repeat-string
em npm. Ele não faz nada além de repetir a linha, e os desenvolvedores o baixam 17 milhões de vezes por semana.
Número de downloads de strings repetidas em npm
Dezessete milhões é apenas o número de downloads. Este número não nos dará nenhuma idéia de quantas vezes esta função é usada no código-fonte. A quantidade deve ser astronômica!
Então o que estou fazendo?
Como você pode encontrar um módulo como
repeat-string
para o seu projeto node.js. Procure por "string de repetição" em npm . Talvez você insira "string repeat", mas os resultados serão semelhantes. O problema de que estou falando pode ser visto no segundo resultado da pesquisa. E no quarto, e no nono, e no décimo e no décimo primeiro.
Dê uma olhada nestes exemplos. Cada biblioteca oferece um comportamento completamente idêntico.
Exemplos de bibliotecas de repetição de linha npm
Você vê qual é o problema?
Não, não que um deles seja assíncrono por algum motivo desconhecido. Sem mencionar que a repetição de strings faz parte da linguagem JavaScript (
"A".repeat(5)
) há mais de seis anos . O problema é que cada biblioteca é diferente:
- Na assinatura dos dados recebidos. Alguns podem receber
(string, int)
, outros podem receber(int, string)
. Um aceita números de ponto flutuante, o outro requer uma função de retorno de chamada. - Na assinatura da saída. Cada biblioteca imprime uma string, exceto uma, que nada imprime e passa seu resultado para a função de retorno de chamada. E não me deixe nem começar a analisar seus erros.
- No comportamento quando são executados. Um é assíncrono, os outros são síncronos.
- Pelo método de concessão de acesso. Alguns fornecem acesso a uma única função exportada, outros fornecem uma função como método de um objeto.
Você pode culpar o JavaScript por vários motivos, mas isso não é um problema com a linguagem. Devido à popularidade do JavaScript e às limitações de suas bibliotecas padrão, esse problema é tão comum que consegui demonstrá-lo com um exemplo tão simples quanto a repetição de string. Por outro lado, nada me impede de recriar todas essas diferenças em qualquer outro idioma. Este é um exemplo muito simples, mas à medida que a funcionalidade se torna mais complexa, essas diferenças se tornam ainda mais pronunciadas.
Por que isso é um problema?
O problema é que tal riqueza de opções não cria nenhum valor , apenas problemas por si só. Eles não afetam a "lógica de negócios" (isto é, o que importa em primeiro lugar). Estes são os detalhes de implementação. Às vezes, essas opções surgem da falta de algo na linguagem ou estrutura e, às vezes, são apenas escolhas espontâneas. Estamos tentando escolher uma opção que irá simplificar o trabalho do desenvolvedor agora ou no futuro, mas é impossível prever o futuro. Essas soluções são verdadeiramente diabólicas - cada opção que você escolhe parece boa no início, enquanto tudo funciona. Recebemos um aumento de dopamina e sentimos que estamos no topo do mundo. Senhores de todos os sistemas! Porém, quando precisamos adicionar, substituir ou mudar algo, percebemos que não éramos aquele gênio.
Com que frequência precisamos mudar algo? Todos os dias. Isso é o que estamos fazendo. Com que frequência o software falha por causa disso? Literalmente todas as vezes. Às vezes, o colapso é mínimo e o consertamos com pouco esforço. Chegamos a um acordo com o fato de que software quebrado é normal. Mesmo quando escrevemos testes automatizados que não fazem nada além de verificar se algo está quebrado.
O problema com as interfaces decorre do fato de que um programador pode tomar muitas decisões durante o processo de desenvolvimento. Decisões como escolher entre parâmetros posicionais, configurações e linkers, assíncrono versus síncrono, global versus local, stateful versus stateless, construtores versus fábricas, abordagem funcional versus orientada a objetos e um número infinito de outras opções. Cada escolha é determinada pelas melhores práticas modernas e cada uma se torna um grão de areia preso dentro do mecanismo.
Este problema não é novo, no entanto, toleramos isso e ensinamos essa abordagem a cada nova geração. Por quê? O problema não é que tomemos as decisões erradas, mas sim que temos opções ruins. Cada opção é um caleidoscópio de compensações e a resposta correta depende do ponto de vista. Quando tudo é um compromisso, sempre existe uma opção melhor . Você sempre pode reescrever seu código para torná-lo melhor.
Vamos refatorar nossa declaração uma terceira vez.
Esta afirmação não é tão atraente, mas mais próxima da verdade.
Sem o código para apenas colar, precisamos passar a ferro todas as dobras da interface antes de podermos usá-la. Você precisa personalizar cada pedaço de código que entra no aplicativo. Cada entrada. Cada conclusão. Cada API. Empurramos linkers para adaptadores e os envolvemos em fábricas baseadas em serviços. Mas nenhuma quantidade de maquiagem fará seu padrão de design parecer bonito .
É como se estivéssemos construindo software no século 18. Vimos manualmente as árvores em placas de qualquer tamanho. Fazemos martelos e perfuramos pregos do zero apenas para construir uma casa que se parece exatamente com a próxima. Custa muito e leva muito tempo. Mesmo após a conclusão do projeto, ainda somos puxados ao chão pelo peso do suporte. As dimensões não são padronizadas, a fiação choca os eletricistas e os construtores que acabam de se formar na escola profissionalizante não gostam da maneira como fazemos os pregos. É chegada a hora de Leroy-Merlin e o 2x4 digital aparecerem no mundo do software.
“Oi, meu nome é Tim. Trabalho como líder de tecnologia no Google, tenho 30 anos de experiência em programação, mas preciso descobrir como obter o comprimento de uma string em Python. "
Para obter ajuda com qualquer API para constantemente procurar você pessoalmente ?
Não será uma surpresa se eu disser que poderíamos ter padrões que sejam bons o suficiente para todos. A Microsoft introduziu a tecnologia COM nos anos 90 para trocar lógica entre aplicativos escritos em qualquer idioma. A tecnologia JVM tem quase a mesma idade e demonstrou quantas linguagens podem lidar com o mesmo bytecode e também interagir umas com as outras. O mundo continua a redescobrir o Flow por décadas e Linda como uma forma de vincular as caixas pretas distribuídas entre si, e o Docker é uma nova maneira de ver o que uma caixa preta moderna pode ser.
Este problema apresenta muitas possibilidades e muitos estão tentando resolvê-lo. Dapr e WasmCloud procuram novas soluções promissoras ... Eles resolvem parcialmente o problema de maneiras diferentes. Por mais triste que seja o estado do desenvolvimento de software hoje, tenho mais esperança hoje do que nos últimos 10 anos. Esse breve período de promessa emocionante veio do JavaScript, que prometia criar uma plataforma universal na qual aplicativos amorfos poderiam se espalhar pelo mundo, mas, como resultado, ele se transformou em um monte de Electron, React e RAM desperdiçada. Para mim, o Web Assembly se tornou uma nova fonte de otimismo. Está longe do ideal, mas também é maravilhoso. O ideal nunca vence.
Propaganda
Você está procurando um servidor para aluguel para depuração de projetos, um servidor para desenvolvimento e hospedagem? Definitivamente, você é nosso cliente :) Cobrança diária de servidores, crie sua própria configuração em poucos cliques, o anti-DDoS já está incluso no preço.
Inscreva-se no nosso chat no Telegram .
