On m'a confié la tâche d'implémenter un langage spécifique au domaine pour un outil qui peut devenir très important pour l'entreprise. Le langage est simple mais pas trivial, il autorise déjà les boucles imbriquées, la concaténation de chaînes, etc. et il est pratiquement sûr que d'autres constructions seront ajoutées à mesure que le projet avance.
Je sais par expérience que l'écriture d'un lexer / analyseur à la main - à moins que la grammaire soit triviale - est un processus long et sujet aux erreurs. Il me restait donc deux options: un générateur d'analyseur à la yacc ou une bibliothèque de combinateur comme Parsec. Le premier était bon aussi, mais j'ai choisi le second pour diverses raisons et j'ai implémenté la solution dans un langage fonctionnel.
Le résultat est assez spectaculaire à mes yeux, le code est très concis, élégant et lisible / fluide. Je concède que cela peut sembler un peu bizarre si vous n'avez jamais programmé autre chose que java / c #, mais cela serait vrai de tout ce qui n'est pas écrit en java / c #.
À un moment donné cependant, j'ai été littéralement agressé par un collègue. Après un rapide coup d'œil à mon écran, il a déclaré que le code était incompréhensible et que je ne devais pas réinventer l'analyse mais simplement utiliser une pile et String.Split comme tout le monde. Il a fait beaucoup de bruit, et je n'ai pas pu le convaincre, en partie parce que j'ai été pris par surprise et sans explication claire, en partie parce que son opinion était immuable (sans jeu de mots). J'ai même proposé de lui expliquer la langue, mais en vain.
Je suis certain que la discussion va refaire surface devant la direction, alors je prépare des arguments solides.
Voici les premières raisons qui me viennent à l'esprit pour éviter une solution basée sur String.Split:
- vous avez besoin de beaucoup de ifs pour gérer des cas spéciaux et les choses deviennent rapidement incontrôlables
- de nombreux index de tableaux codés en dur rendent la maintenance pénible
- extrêmement difficile à gérer des choses comme un appel de fonction comme argument de méthode (ex. add ((add a, b), c)
- très difficile de fournir des messages d'erreur significatifs en cas d'erreurs de syntaxe (très susceptible de se produire)
- Je suis tout pour la simplicité, la clarté et pour éviter les trucs intelligents et cryptiques inutiles, mais je pense aussi que c'est une erreur de simplifier chaque partie de la base de code afin que même un hamburger flipper puisse le comprendre. C'est le même argument que j'entends pour ne pas utiliser d'interfaces, ne pas adopter la séparation des préoccupations, copier-coller du code, etc. Un minimum de compétence technique et de volonté d'apprendre est nécessaire pour travailler sur un projet logiciel après tout. (Je n'utiliserai pas cet argument car cela semblera probablement offensant, et le déclenchement d'une guerre ne va aider personne)
Quels sont vos arguments préférés contre l' analyse de la méthode Cthulhu ? *
* bien sûr, si vous pouvez me convaincre qu'il a raison, je serai aussi parfaitement heureux