クトゥルフの方法の解析に対する議論は何ですか?
会社にとって非常に重要になる可能性のあるツールのために、ドメイン固有言語を実装するタスクを割り当てられました。この言語は単純ですが、些細なことではなく、ネストされたループ、文字列の連結などを既に許可しており、プロジェクトが進むにつれて他の構成要素が追加されることは実質的に確実です。 レクサー/パーサーを手書きで書くことは(文法が簡単でない限り)時間がかかり、エラーが発生しやすいプロセスであることを経験から知っています。そのため、yaccのパーサージェネレーターまたはParsecのような組み合わせライブラリーという2つのオプションがありました。前者も同様に優れていましたが、さまざまな理由で後者を選び、関数型言語でソリューションを実装しました。 結果は私の目にはかなり壮観で、コードは非常に簡潔で、エレガントで読みやすく/流fluentです。java / c#以外でプログラミングしたことがない場合、少し奇妙に見えるかもしれないと思いますが、java / c#で書かれていないものには当てはまります。 しかし、ある時点で、文字通り同僚に攻撃されました。私の画面を一目見た後、彼はコードが理解不能であり、解析を再発明するのではなく、誰もがするようにスタックとString.Splitを使用するだけだと宣言しました。彼は多くの騒ぎをしました、そして、私は彼を納得させることができませんでした、私が彼を信じることができませんでした 私は彼に言語を説明することさえ申し出ましたが、役に立ちませんでした。 私は議論が経営陣の前で再浮上することを確信しているので、いくつかの確固たる議論を準備しています。 これらは、String.Splitベースのソリューションを回避するために頭に浮かんだ最初のいくつかの理由です。 特殊なケースや物事を迅速に制御不能にするには、多くのifが必要です 多数のハードコードされた配列インデックスにより、メンテナンスが困難になります メソッドの引数として関数呼び出しのようなものを処理することは非常に困難です(例:add((add a、b)、c) 構文エラーの場合に意味のあるエラーメッセージを提供することは非常に困難です(発生する可能性が非常に高い) 私はすべて単純さ、明快さ、そして不必要なスマート暗号のようなものを避けるためにいますが、バーガーフリッパーでも理解できるようにコードベースのすべての部分を馬鹿にすることは間違いだと思います。インターフェースを使用しない、懸念事項の分離を採用しない、コードをコピーアンドペーストするなど、私が聞いたのと同じ議論です。結局、ソフトウェアプロジェクトに取り組むには、最低限の技術的能力と学習意欲が必要です。(この議論はおそらく不快に聞こえるかもしれませんが、戦争を開始しても誰も助けにはなりません) クトゥルフの方法を解析することに対するあなたの好きな議論は何ですか?* *もちろん、彼が正しいと私を納得させることができれば、私も完全に幸せになります