Get best of the week

É bom que o criador do seu instrumento favorito não tenha ouvido os burros quando ele inventou a bicicleta



No verão passado, os caras e eu conversamos sobre a nossa lib, que nosso cliente não aceitou e jogou no lixo. Nós bombardeamos, porque acreditamos em nossa decisão, e dissemos à comunidade sobre isso - os desenvolvedores comuns definitivamente verificariam e não trocariam nenhuma bobagem.

Bem, claro. Fomos literalmente arrastados por uma onda de críticas. Havia muitas pessoas que não gostaram da minha presunção e eu pessoalmente - tudo bem, não tenho problemas com elas. Fiquei furioso com pessoas aparentemente inteligentes que nem queriam olhar para o código e mergulhar no contexto, porque disseram desde o limiar: "Vocês fizeram uma bicicleta". E todos pegaram - reinventar a roda é ruim, terrível, pesadelo, inaceitável, vergonha, executá-los, linchar. De fato, apenas um idiota desenvolverá uma nova ferramenta para uma tarefa que alguém já resolveu.

Surpreende-me a rapidez com que os projetos são realizados para esse truque. Eu perguntei até para as pessoas mais críticas e profundamente pensantes - “reinventar bicicletas é ruim?”. Eles respondem "sim" em menos de um segundo.

Bem, não, homens, isso não serve. Vamos parar por aqui, dar uma olhada e pensar em detalhes.


Certa vez, fiz um aplicativo front-end em casa por algum tempo. Usei o reagente, mas não o administrei para administrar o estado - não tive esse problema. Então o problema apareceu e eu comecei a fazer "minha bicicleta". Tios inteligentes me disseram que sou um idiota e preciso usar o Redux. Eu peguei.

Dois meses depois, a maior parte do código do projeto foi uma adaptação do editor à minha arquitetura. Essa ferramenta criou muito mais problemas para mim do que resolveu. Não é porque os editores são ruins - simplesmente não se encaixam.

Uma pessoa de uma grande corporação decidiu trabalhar com o estado do aplicativo da web de uma grande corporação. Os editores solucionam vários problemas enfrentados por esse aplicativo e o fazem bem. E o que a indústria está fazendo? A indústria diz - Dan Abramov nos deu o caminho. Agora, meu site, de duas formas, usará editores para trabalhar com o estado.

Amigo, os editores são feitos para trabalhar com o estado - mas não com o seu estado. Você não precisa de uma cadeia persistente de todas as fatias do estado do aplicativo, não transmite a ação na rede e não faz muito mais que o editor deve automatizar. Ao mesmo tempo, o uso de editores não é fácil. Você terá que recompensar cem quilômetros de código para explicar ao editor qual é sua condição, onde e como é atualizada, quais alterações são significativas e quais não são. Para que os editores automatizem um problema que você não possui. Sério, você já viu pelo menos uma vaga para uma reação, mas sem um editor? Eu não.

Existem análogos - mas eles também são volumosos. Às vezes, a maneira mais barata de resolver um problema não é usar uma ferramenta para tudo, mas escrever uma solução de domínio adequada para você. Meu Deus, o texto datilografado é poderoso o suficiente para escrever um mvvm, mvc básico ou o que você quiser em algumas horas - para que ele resolva apenas os problemas que você tem. Faça com que saia mais barato e mais rápido. E talvez sua solução funcione bem, cresça com o projeto e se torne o padrão.

Mas isso é proibido - porque outros desenvolvedores lhe disseram: “Cara, não reinvente a roda. Basta pegar o mais popular do mercado. ”

No meu projeto, por exemplo, o MobX era mais adequado, mas também não super. Funcionaria melhor para mim exatamente a bicicleta que eu inventei. Mas parecia que eles tiraram o meu direito de tomar uma boa decisão, porque não importa o que eu fiz, ninguém iria ouvir. Ninguém está pronto para acreditar que será melhor e mais barato.

Isso cria um círculo vicioso. Se todos usarem apenas o inventado antes deles, o progresso no desenvolvimento será interrompido. Eles dizem a você, se você quer fazer melhor do que no final - faça em casa no seu tempo livre. Você diz que está bem, começa a trabalhar à noite, termina e vai contar às pessoas sobre sua decisão, mas ninguém está nem pronto para olhar sob o capô - “isso é uma bicicleta”.

Mas, na verdade, tudo o que fazemos é inventar bicicletas. "Bicicleta" é simplesmente um ardil retórico prejudicial para justificar sua preguiça ou afirmar-se em uma disputa com outro desenvolvedor.

Os criadores do editorial reagem e mobix - afinal, eles também "fabricaram sua bicicleta". Bem, a menos que, a partir do momento em que o angular aparecesse, não tínhamos uma biblioteca para trabalhar com a interface do usuário do navegador? Nocaute de Jquery A propósito, isso também é ótimo. Afinal, sempre havia vanilla js e uma API do navegador. Então, por que esses idiotas resolveram o problema resolvido?

Douglas Crockford inventou o JSON. O boob incompetente não parece saber que já temos XML. Muito antes dele, os programadores inventaram uma maneira de trocar dados: quem ele achava que estava lá?

Maus exemplos? Bem, claro. De fato, na sua opinião, pessoas de grandes empresas têm o direito de inventar bicicletas. Eles têm, mas você e eu não.


A TI mais corporativa da Federação Russa são os bancos. E se você olhar para os produtos técnicos de qualquer Sberbank, Tinkov ou Alf, verá: todos eles têm as mesmas aplicações com aproximadamente o mesmo design. Estes são sistemas quase idênticos. O mesmo para o usuário, eles são feitos de maneiras diferentes, em pilhas diferentes, por pessoas diferentes. Todos esses bancos têm suas próprias abordagens de desenvolvimento. Os gigantes globais de TI também têm muitos dos mesmos produtos. Quando os grandes banqueiros se reúnem e decidem que precisam de produtos digitais, contratam um exército de desenvolvedores e os forçam a fazer as mesmas coisas que outros bancos já fizeram, pela centésima vez - mas de uma nova maneira.

Isso é tudo sobre bicicletas.

Em todos os projetos em que trabalhei, havia problemas de longa duração, porque algo não era automatizado. Porque uma vez que alguém foi informado - não reinvente a roda, basta fechar o bilhete. Sim, a empresa aguarda seus ingressos e precisa ser alimentada, mas sejamos honestos - sei que sempre temos mais orçamento do que a empresa pensa.

Eu tenho tudo apenas com o dinheiro dos negócios que gasto nele. Uma grande empresa tem muito dinheiro e leva-a ao desenvolvimento. Essa enorme pilha de dinheiro pode ser gasta por desenvolvedores que resolvem problemas e, ao mesmo tempo, realizam algumas pesquisas. E os gerentes podem gastar, mas os gerentes os gastam para pagar por nossa sessão sem sentido em milhões de reuniões inúteis. Os negócios já gastaram dinheiro com desenvolvimento e, se você não transformá-lo em programação, os gerentes de negócios os gastam em processos estúpidos que não são necessários para ninguém, exceto eles mesmos.

Eu já vi muitos caras que “trabalham” por 18 horas por dia. E eu sei muito bem que, se você permanecer no escritório por 18 horas, realmente trabalhará tanto como se estivesse sentado 8.

Nossa maneira coletiva de enganar uma empresa é explicada com muita simplicidade - ela não se atrapalha. As empresas não entendem por que não devemos criar recursos por duas semanas, mas colocamos o legado em ordem. Isso é normal e sabemos como resolvê-lo. Você trabalha para uma empresa por meio dia e trabalha para um projeto por meio dia. Eu vim para o trabalho, fechei a norma diária - só isso, você tem uma carta branca para a pesquisa.

Enquanto resolvemos os negócios práticos e momentâneos da lista de desejos - ele está pronto para pagarmos por esse trabalho. De fato, o verdadeiro desenvolvimento começa onde há programação em prol da programação. Quando você se deleita com a pura mecânica em troca de nada, um clique momentâneo e entusiasmo da engenharia, porque essa é a única maneira de definir os limites, novas formas e ferramentas parecem resolver problemas práticos novamente, só que melhor.

Quando desenvolvo algo, algo que já foi feito, não o reinvento exatamente como o deles. Eu proponho minha abordagem. Ele é sempre algo melhor, sempre algo pior. E é sempre uma invenção. A grande maioria das minhas invenções vai para o caixote do lixo da história, mas sempre há uma chance de que eu invente algo realmente legal. Mesmo que de passagem, mesmo que eu próprio não dê importância a isso, isso não importa. Alguém verá que, em outro lugar, o setor receberá um novo padrão que começará a resolver nossos problemas. Somente essa idéia me leva a escrever código.

O código aberto também possui muitos dos mesmos projetos. Aqueles que resolvem o mesmo problema. Você está pronto para dizer que todos que os fazem são tolos? Eu não estou preparado. Quando quero criar um lote para serialização, recebo cinco ou seis soluções principais, cada uma com vantagens exclusivas. Às vezes, uma dessas vantagens é fundamental para mim; nesses momentos, sinto muita gratidão pelos caras que decidiram fazer essa “bicicleta”.

Quando me dizem que tudo já foi inventado no desenvolvimento, pergunto: “o que, não temos problemas?”.

Não escrevemos um clichê diário? Não fazemos automação repetidamente quando preenchemos nossos arquivos com o mesmo código? Ainda estamos fazendo muito do que a máquina poderia fazer agora. E fazemos isso porque ainda não inventamos abordagens, porque sempre inserimos paus nas rodas das bicicletas.


Assista ao meu podcast

More articles:


All Articles