じゃあ、if文の山がビジネスソフトウェアにとって最善の策なの？「Big Ball of Mud」の論文を楽しんでみて。実際のシステムは劣化しやすい。まずは、何を作りたいかわからない状態で大きな泥の塊から始める。そしてシステムの一部が成長するにつれて、設計を改善していく。でもまた状況が変わって、美しい抽象化が崩れてしまう。生産ソフトウェアは常に変わっている。それが面白いところ。あなたの仕事は、ドメインモデリング、十分な抽象化、そして建設的な破壊を組み合わせてこれをサポートすること。村から成長する街のように。

先週Codex CLIで遊んでたんだけど、バグを修正するために特別なケースをコードに追加するのが好きみたい。パターンを指摘して新しい抽象化を作るように頼まないと、見えてこないんだ。彼は「ヒューリスティック」と呼ぶものを追加し続けるだけで、それはバグのときに出てきた特定の条件をテストするif文だった。特定のタイプのバグに対して10個のテストを書いたら、彼はそれを全部喜んで修正してくれる。でも、同じタイプのバグで別のテストを追加すると、当然失敗する。なぜならCodexが考えた修正は最初の10個のテストに合ったif文の山だったから。

この種のソフトウェアで素晴らしい抽象化を作れると思うけど、それを生き残らせたいなら、ビジネスロジックそのものには関わらせないようにしなきゃ。これは製品のようなものにしかできない：認証、監査ログ、データベースの抽象化（CQRS、イベントソーシング）、コンテンツ/翻訳管理、メッセージングインフラ、実際のインフラ。ビジネスそのものがそれらの抽象化に影響を与えたり、指示したりすることを許すと、また混乱が生じる。ビジネスロジックはごちゃごちゃになるのが当然で、それは誰も本当に気にしないからで、責任を開発者や他の誰かに押し付けられるから。逆に、「良いコード」と「悪いコード」を分けることもひどい結果を招くことがある。私が働いていたフィンテックで見た「解決策」の一つは、ビジネスの人々自身にロジックを持たせることで、意思決定エンジンの形で実現された。基本的に、ビジネス自身が自分の泥の塊を維持することを強制された。テストするのも理解するのもシミュレートするのも不可能だった。最終的に、ソフトウェアオペレーターが雇われて、基本的にグラフィカルインターフェースを使ってコードを書くジュニアレベルの開発者だった。何度か書き直されたけど、いつも2、3年後にはすべてが混乱してしまう結果になった。

コードはif文があってもシンプルにできる方法がたくさんある。if文をあちこちに散りばめているなら、それを持ち上げてみて。最終的に同じ場所に集まるから、すべての変動性が一つの場所で実装されて文書化される。抽象化は必要ない。入力と出力を正確にモデル化するのが非常に役立つ。統一データ型を決めるのはできるだけ後回しにして、その決定に合わせてプログラミング言語を使いやすくする。クラスの階層やパターンは、実際に何が起こっているのか確信が持てるときの最後の手段だ。さらに言えば、プログラミングが管理しやすい限り、関数やファイルは必要ない。別のファイルが必要になるのは、バージョン管理システムが使えない場合か、これらの日時ハンドラがどこでも一貫して再利用される必要があると確信している場合だけだ。現代のフルスタックプログラミングは、モデル、ミドルウェア、コントローラー、ビューなどで溢れていて、誰もがそのすべての分離を最初から必要としているわけではない。

ビジネスロジックの大半は「ラストマイル」ソフトウェアだよね。美しい抽象の上に構築されてるけど、それは正しいっていう抽象的なアイデアからじゃなくて、現実との痛い衝突から生まれたものなんだ。最終的に、良い抽象を作るための明確さを得ることができる。時にはラストマイルソフトウェアがその抽象に変わることもあるけど、そうならないことが多い。俺は、早すぎる段階でこういう抽象を作ろうとする賢い開発者たちと一緒に働いたことがあるけど、現実にぶつかると、ただの混乱した「if文のスープ」になっちゃうんだよね。

最近、同僚とこの話をしてたんだ。俺の意見では、たくさんの（ソフトウェア）エンジニアリングの知恵やベストプラクティスは、ビジネスの要件やロジックの前ではうまくいかないと思う。ハードエンジニアリングでは、もっと強く反発できるけど、それはもっと永続的で、命がかかっていることが多いからなんだ。でもソフトウェアの場合は、そうはいかない。俺は、本当に速く動くビジネスの制約や、短期的な利益のための馬鹿げたリクエスト（製品を維持するために）のおかげで、適切なソフトウェアエンジニアリングがほぼ不可能になっていると思うし、実際にはこれらのif-elseのネストが必要になってくるんだ。だから、ソフトウェアエンジニアリングとプロダクトエンジニアリングを区別すべきだと思う。

個人的には、最後の部分で本質に触れてると思う。現実の世界やビジネスはごちゃごちゃしてて、まさに「if文の山」なんだよね。問題自体が技術的だったり一般化できる場合は、抽象化によって何千ものif文を書く開発者が必要なくなるけど、ドメイン自体がごちゃごちゃしていて仕様が不明瞭なら、抽象化（やツール）が役立つのは柔軟性を持たせることだけだよ。矛盾がバグじゃなくて機能かもしれないからね…

抽象化はOKだけど、SomethingFactoriesはバカげてる。もしコードが実際のロジックよりも抽象化が多くて、その抽象化を管理するためにロジックが必要なら（例えばFactoryFactoriesや2つ以上の継承レベル）、戦略を見直した方がいいよ。

意図を表現したり、基盤となるドメインを説明する方が、単なる「抽象化」よりも価値があるかもしれないね。

ビジネスの人たちがビジネスロジックをちゃんと理解して、実装者に説明できるとは思えない。絶対に無理だよ。彼ら自身は理解してるかもしれないけど、コーダーじゃないし、コードの要件を書くことはできない。だから、少なくとも一人の実装者はアプリケーションの実態をしっかり理解する必要がある。めちゃくちゃ汚れるくらいにね。本当にユーザーが毎日どんな体験をしているのかを知り、気にかけるようになるまで。まあ、ほとんどの会社にとっては現実的じゃないけど、別々のサイロを作って、「ビジネスロジック」は「どうでもいいこと」って意味になって、if文で遊ぶことになるんだよね。（あるいは、まあ、モナドにハマってそれで遊ぶのもいいけど。そっちの方がクールだし。）

マイクロソフトって、開発部門、開発掛け算、開発足し算、開発引き算（解雇される前に移されるところ）があるくらいバルカン化してるの？

DevDivでめっちゃ楽しかった！

明らかに、20年間他の人のひどいコード（自分のも含めて）をレビューしてきたエンジニア、アマンダがいなくて寂しかったんだろうね。彼女は、シンプルに保つことを学んできた。彼女は、コードは主に人が読むために書いていることを知っている。アマンダたちの小さなチームが欲しいな。

アニマルファーム、でもひねりがある。

ソフトウェアエンジニアのための三つのペルソナ これは避けるべきサイコバカの話で、互いに尊重し合っていれば起こらないことだね。マイクロソフトから来てるのは驚きじゃないけど。

俺は、必要な時には両方をドキュメントするのは全然気にしないよ。時には「なぜ」を明確にする必要があるし、時には「何」を明確にする必要もある。コメントは一般的に過小評価されてると思う。毎行に注釈を付ける必要はないけど、逆にほとんどの自己文書化されたコードはそうじゃないからね。

俺はこのスタイルのコメントにもっとシフトしようとしてるんだ。俺はプログラマーとしての教育を受けてないからね。物理学者で、ほとんどの物理学者は「コードにコメントが欲しいから、こうやってやって」って感じなんだ。そして学生としては、良い成績を取るために必要なことをするんだよね。

x = 4 // xに4を代入 うん、チャットGPTスタイルのコメントだね。 > 代わりにこういうのをやってみて: 唯一のマイナスは、コメントが古くなってコードと同期しなくなる可能性があること。コードに触れたら、他のコーダーはコメントを更新するように気をつけるべきだよ。

AIエージェントの一つの特徴は、コメントよりも isValid = val > someConstant に移行したことだね。Cursor（おそらくClaudeも）って、コメントを頻繁に削除したり書き直したりするから。条件チェックが大きくなる場合は、isValid = checkForValidity(val, someConstant) にすることもある。

関数やバリデーションを、関数の最上部に早期リターンリストのように構造化するようにしてる。もし(val って著者もこのテクニックについて言及してるね。特にコントローラーAPI関数で役立つと思う。コードがかなり監査しやすくなるから。条件が何度も繰り返されるのを見ると、それがミドルウェアの候補になるか考えるようにしてる。これを新しい開発者に説明しようとするんだけど、全然理解してくれないか、目をひんむいてくる。この記事を送ったら、少しは助けになるかな。

みんな正しいかもしれない。変数を割り当てることは、良いコメントよりもあまり役に立たないと思う。でも、同じスコープで何度も必要ならやる価値はあるよね。でも、「is valid」、「is allowed」、「is secure」を異なるスコープで何度も使う必要があるのかな？それなら関数にするべきだよね。いつもこの三つを一緒に考える必要があるの？それなら一つの関数にまとめるべきだね。condition2やcondition3が許可されない場所ってあるのかな？もっと複雑になるね。こういうシンプルな例でも、現実の世界では複雑になるんだよね。

リンクされた記事は、主に意味的負荷理論について三つのことを批判しているみたいだね； - 測定が難しく、実証的に研究するのが難しい、または不可能。（悪い科学理論） - 教育や学習理論への適用、他の技術がもっと証明されているところ。 - 人間の学習の主要なメカニズムだという考え、これには反対の研究がたくさんある。これらのポイントは妥当だと思うけど、この記事はこの概念について深く掘り下げてない。例えば、「認知負荷」の代わりに「メンタルストレイン」や「限られた短期記憶」を入れても、主張は成り立つと思う。要するに、コードを読む（または書く）ときに考慮すべきことの量を最小限にすべきだって主張してるんだ。これは、CTLの科学的根拠に関係なく、かなり合理的な主張だと思う。だから、君の批判はこの記事にはあまり関係ないと思うけど、指摘することで他の人が使われている言葉の問題について知る助けにはなるかもね。