Foi-me atribuída a tarefa de implementar uma linguagem específica de domínio para uma ferramenta que pode se tornar bastante importante para a empresa. A linguagem é simples, mas não trivial, já permite loops aninhados, concatenação de strings, etc. e é praticamente certo que outras construções serão adicionadas à medida que o projeto avança.
Sei por experiência que escrever um lexer / analisador manualmente - a menos que a gramática seja trivial - é um processo demorado e propenso a erros. Então fiquei com duas opções: um gerador de analisador à la yacc ou uma biblioteca combinadora como o Parsec. O primeiro também foi bom, mas eu o escolhi por vários motivos e implementei a solução em uma linguagem funcional.
O resultado é espetacular aos meus olhos, o código é muito conciso, elegante e legível / fluente. Eu admito que pode parecer um pouco estranho se você nunca programou algo além de java / c #, mas isso seria verdade para qualquer coisa que não estivesse escrita em java / c #.
Em algum momento, no entanto, fui literalmente atacado por um colega de trabalho. Após uma rápida olhada na minha tela, ele declarou que o código é incompreensível e que eu não deveria reinventar a análise, mas apenas usar uma pilha e String.Split como todo mundo. Ele fez muito barulho, e eu não pude convencê-lo, em parte porque fui pego de surpresa e não tive uma explicação clara, em parte porque sua opinião era imutável (sem trocadilhos). Eu até me ofereci para explicar o idioma, mas sem sucesso.
Tenho certeza de que a discussão voltará à tona na frente do gerenciamento, por isso estou preparando alguns argumentos sólidos.
Estas são as primeiras razões que me vêm à cabeça para evitar uma solução baseada em String.Split:
- você precisa de muitos ifs para lidar com casos especiais e as coisas rapidamente saem de controle
- muitos índices de matriz codificados dificultam a manutenção
- extremamente difícil lidar com coisas como uma chamada de função como argumento de método (por exemplo, add ((add a, b), c)
- muito difícil fornecer mensagens de erro significativas em caso de erros de sintaxe (é muito provável que isso aconteça)
- Eu sou a favor da simplicidade, clareza e evito coisas desnecessárias de criptografia inteligente, mas também acredito que é um erro simplificar todas as partes da base de código, para que até mesmo um barbante de hambúrguer possa entendê-lo. É o mesmo argumento que ouço por não usar interfaces, por não adotar separação de preocupações, copiar e colar códigos etc. Um mínimo de competência técnica e vontade de aprender são necessários para trabalhar em um projeto de software. (Não usarei esse argumento, pois provavelmente soará ofensivo, e iniciar uma guerra não ajudará ninguém)
Quais são seus argumentos favoritos contra a análise da maneira Cthulhu ? *
* é claro que se você puder me convencer de que ele está certo, eu também ficarei perfeitamente feliz