じゃあ、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文で遊ぶことになるんだよね。（あるいは、まあ、モナドにハマってそれで遊ぶのもいいけど。そっちの方がクールだし。）