O motivo deste artigo foi outra publicação na Habré. É chamado "Não aprenda estruturas, aprenda arquitetura" e você pode lê-lo
aqui .
Farei uma reserva imediatamente e concordo totalmente com o autor e só quero adicionar meus "três centavos". No começo, pensei em fazê-lo corretamente nos comentários do artigo, mas rapidamente percebi que o "centavo" é bastante volumoso. E assim nasceu este texto.
Primeiro, um pouco sobre você
Estou envolvido no desenvolvimento da web há um ano desde o 98º. Ele trabalhou para a empresa e freelancer. Ele recrutou equipes. Tanto na vida real quanto online. A primeira linguagem de programação foi o perl, que agora é falecido com segurança, e ainda me arrependo de sua morte prematura. Então veio o php. Um pouco mais tarde, rubi e a era dos fogos de artifício começou.
Grandes promessas pequenas conquistas
Eu a conheci com entusiasmo. De fato - parece que apareceu uma ferramenta projetada para facilitar significativamente o desenvolvimento, o que pode salvá-lo de muita rotina. No entanto, o entusiasmo desapareceu rapidamente. E aqui está o porquê.
Não sei quem, mas, antes de tudo, esperava me livrar de um grande número de ações monótonas que tive que realizar ao trabalhar em cada novo projeto. Projete a "espinha dorsal" da base, escreva a saída essencialmente das mesmas páginas de texto, etc., etc. Quem escreveu um número suficiente de sites complementará facilmente esta lista com muitos, muitos pontos. E a maioria dos fogos de artifício economiza muita rotina. Mas a que preço!
E desta vez ... e esses dois ...
Erast Fandorin
Minha primeira reclamação é ao RoR, Yii, Symfony e quase todos os outros que eu tive que encontrar - sua monstruosidade e toneladas de código completamente redundante que invariavelmente terminam no projeto. Acostumado a muitos anos de trabalho, que o código seja o mais limpo e conciso possível, que o aplicativo seja o mais rápido possível, não concordo com o lixo (desculpe-me, não posso dizer o contrário) que acabei em projetos.
A segunda afirmação é uma tentativa de todos, sem exceção, dos autores de fogos de artifício inventarem, algo como sua linguagem de programação. Deixe-me explicar o que quero dizer. Tomemos, por exemplo, a biblioteca js jQuery mais comum. Ao mesmo tempo, farei uma reserva imediatamente que considero ser quase o único epíteto útil, competente e muitos, muitos elogios, entre outros. Eu dou jq como exemplo apenas porque com certeza todos entenderão o que quero dizer. E assim você pode acessar o elemento por ID nos js nativos, como document.getElementById ("id") e como jQuery $ ("# id"). O fato de ter sido escrito uma dúzia de caracteres a menos não é muito impressionante. Ao mesmo tempo, o jq tem várias outras vantagens para as quais estou pronto para aprender uma nova sintaxe. Além disso, é confiável e quase nunca entra em conflito com outras bibliotecas. O que não pode ser dito, e um monte de sua espécie, que devem substituir.
Mais uma vez, farei uma reserva - não sou contra o fato de aprender algo novo. Mas somente se esse novo código tornar meu código melhor mais rápido e mais limpo. Se eu precisar aprender alguma coisa para depois rebitar sites do mesmo tipo que um macaco e não ousar dar um passo para a esquerda, passo para a direita, porque simplesmente não sabia como - obrigado.
Sim, o pior é que essa abordagem de programação simplesmente desgasta o pensamento e quando esse novo framework super legal falha, e isso, acredite, acontece assim que o cliente pede algo de você, pelo menos um pouco além do escopo, ai do framework (eu descobri recentemente que agora existe tal profissão) cai em um estupor e começa a fazer perguntas estúpidas em todos os fóruns acessíveis a ele. Tudo é baixado pelo fato de um dos programadores (não uma estrutura) esculpir uma muleta e Deus proibir que o cliente não audite o código.
E estes são três ...
Ele é
Todas as opções acima se aplicam não apenas à frente, mas também à parte traseira. Como resultado, surge a pergunta - desde o início eu reconheci que, durante qualquer desenvolvimento, tenho que executar muitos gestos desnecessários que gostaria de otimizar, mas isso pode ser feito a esse preço? Além disso, há outro ponto que, em grande parte, diz respeito ao desenvolvimento em Ruby.
Para implementar as funções mais básicas de um aplicativo Web, você precisa conectar gemas separadas. Para alimentar o banco de dados - mysql2, enviar mail - mail ou poni criado em sua base. E assim por diante e assim por diante. À primeira vista, não há nada errado com isso - todas as jóias em Ruby são geralmente bem testadas e não há problemas com elas. Mas há exceções a essa regra também. Por exemplo, uma vez por semana, tive que me sentar com o odf-report, que não queria funcionar corretamente, e depois cuspir e escrever minha classe. Além disso, é um pouco irritante que, com a conexão de cada gema, o tempo de formação da página inevitavelmente aumente. Em alguns gem-ahs muito ligeiramente. E não alguns .... Tente experimentar esse tópico com o pônei já mencionado - veja você mesmo.
A eterna questão
E o que fazer? Por um lado, o desenvolvimento em uma linguagem "pura" definitivamente não é uma opção, mas por outro lado, as ferramentas existentes não são satisfeitas por várias razões? A saída é vista na criação de uma ferramenta que otimiza as funções usadas com mais frequência e, ao mesmo tempo, não atrapalha o programador, e não impõe a ele um estilo de programação que o autor desta ferramenta considera ser o único correto. Na prática, isso significa que a ferramenta deve:
- contêm um conjunto mínimo de funções otimizadas padrão e máximas
- a ferramenta não deve forçar o programador a aprender algo como uma nova "não linguagem" de programação que desabilita completamente o cérebro
- e tudo isso, idealmente, deve ser transformado em uma biblioteca leve que não tenta competir em termos de quantidade de código com o sistema operacional.
Talvez eu esteja errado, mas até agora ninguém foi capaz de me convencer do contrário. Pronto para ouvir qualquer opinião.