どうしたらコードは簡潔に書けるのか?
同じ5行のコードが全く違って見える12の瞬間、なぜ私たちは学ぶのか？
とても良い記事だが、つまりは様々な視点から「足りない」部分が存在するという指摘。
エラーハンドリング
コードはいつもうまく動くというわけではなく、何かのエラーが発生する可能性がある。
パフォーマンス
コードが動くときには時間がかかる。(CPU時間、ネットワークI/O、ファイルI/Oなどなど)
セキュリティ
インジェクションなどの不正なアクセスをされないようにする必要がある。
認証・認可
誰でも操作できていいわけではない。
信頼性
一時的に様々な原因で失敗する可能性がある。これをリカバリする手段が必要になる。
保守性
コードは読みやすく、変更しやすくなければならない。
外部の変更にも耐えられる仕組みが必要。(ハードコーディングを避けたい)
テスタビリティ
テストをしやすくしなければならない。
テストができるようにモックやスタブを噛ませられるようにする必要がある。
テストで変動する部分を最小限に抑える必要がある。(例えば外部システム、時間や乱数など)
スケーラビリティ
複数のサーバー(インスタンス)で扱えるようになっていないと、スケーラブルにならない。
可観測性
ログやメトリクス(レスポンスタイムなど)を取っていないと、運用時に何かトラブルが起きても何が悪かったのかわからない。パフォーマンスに問題があっても、どこを改善すべきかがわからない。
チーム開発
コメント(あるいはドキュメントへのリンク)が書かれていないと、なぜそうしたのかがわからない。
Vibe Coding
どういうプロンプトで生成したのかがわからないと、コードの目的、仕様、実装制約などが不明瞭になり、また再現性がない。
本質的にやりたいことは最初のコードで示せている。直感的でとても正しい。
最初のコードをこれらの考慮に応じて全面的に「正しく」した結果が記事の最後に書かれているが、「正しい」にも関わらず、可読性は極めて低くなっている。
(こういうコードは Enterprise版 xxx のように揶揄される。)
つまり、本当にやりたい処理と、様々な周辺の要件による付加的な処理が、手続き型として書かれてしまうことにより混在してしまうことが問題となる。 これを解決するために、アスペクト指向という手法が一時期ごく一部で流行ったが、結局そんなにうまく行っていない。 また、最近では宣言的記述によってこれらを解決しようという試みがなされているが、これもそこまでうまく行っていない。 なぜうまく行かないのかというと、処理を噛ませる場所(タイミング)、様々な変数を何らかの方法で指定しないとうまく行かないためで、結局再び手続き型記述に舞い戻ってきてしまう。
今できる最善の方法は、本質的な仕様を簡潔に記述して、その上で様々な処置を行ったコードを実際のコードとして記述するという二段構えにするくらい。