アスペクト指向プログラミングの再来

アスペクト指向プログラミングの再来 プログラマーがコードを書く際に注意すべきすべてのことを考えてみましょう。1) 正確性：プログラムが正しいことを行い、すべての要件を満たし、すべての重要な不変条件を維持し、望ましい方法でビジネスロジックを実行することなど。 2) 効率性：プログラムが最小限の時間、メモリ、リソースを使用すること。これには、必要以上にメモリを保持しないこと、可能であれば使用済みメモリを断片化した状態で解放しないことが含まれます。一部のプログラムには、「リアルタイム制約」があり、ユーザーへの応答を0.2秒以内に返すといった特定の効率目標が、その正確性の一部と見なされます。 3) デバッグ可能性：プログラムに問題が発生した場合、それが何であるか、どのように修正するかを見つけるのが難しすぎないこと。 4) 保守性：プログラムは文書化され、読みやすくあるべきです。内部的に一貫したスタイルで書かれ、それが一部である外部のコードベースのスタイルとも一致しているべきです。 5) テスト可能性：プログラムは、単体テストと統合テストの両方が役立ち、作成が難しすぎないように書かれているべきです。 6) ロギング：プログラムは、通常、その実行パスと変数状態の包括的ではない追跡を生成し、デバッグを容易にし、効率を監視できるようにし、その動作に関する統計を収集できるようにすべきです。 7) セキュリティ：プログラムは、ユーザーが許可されたアクションのみを実行できるようにすべきです。通常、これらはユーザーがプログラムなしで既に実行できたアクションと、プログラムを実行するアクセス権を得ることでユーザーに明示的に付与される可能性のある少数の定義されたアクションです。 8) 拡張性：プログラムへの少数の小さな変更が比較的容易にできること。 9) プライバシー：プログラムは、明示的に望まれない限り、あるユーザーに関するデータを他の誰にも—プログラムの所有者を含む—開示してはなりません。 10) 依存関係管理：ほとんどのプログラムは、他の人々や他の組織によって書かれたコードを、しばしばライブラリの形で使用します。プログラマーは、これらのライブラリの使用が合法的であること—すなわち、外部コードが共有されているライセンスに違反しないこと—、そしてライブラリの集合が相互互換性があること—すなわち、ライブラリAがライブラリCバージョン1を使用し、ライブラリBがライブラリCバージョン2を使用する場合、プログラミングシステムがそれをサポートする必要があるか（ほとんどはそうではありません）、または状況を解決する必要があること—を確認する必要があります。プログラマーはまた、使用されるライブラリのいずれも、このリストの他の考慮事項に違反しないことを確認する必要があります。 11) デプロイメント：多くのプログラムは、プログラマーがそれらを書いたコンピューター以外の場所で実行されます。これは通常、プログラマーがプログラムを実行環境を検出し適応させるか、標準環境で実行するためにコンテナ化するか、または新しい環境のために元のプログラムを変換する別のプログラムを書くかによって、作業を必要とします。 12) 監視可能性/可観測性：すべてのプログラムがこれを心配する必要はありませんが、長時間実行されるプログラムは、ロギングで記述された種類の情報を別のインターフェースでリアルタイムに利用できるようにしたいと考えるでしょう。 13) 永続性：すべてのプログラムがこれを心配する必要はありませんが、長時間実行されるプログラムは、停止して再起動する必要があることが多く、ほとんどすべてのプログラミングシステムにおいて、再起動の部分はプログラマーが追加の作業を行う必要があります。 14) 入力検証：すべてのプログラムが入力Sを受け取るわけではありませんが、ほとんどのプログラムは入力Sを受け取り、その場合、入力が期待されるまたは必要な形式に従っていること、および/またはその形式に変換できることを確認するためのチェックを通常実行する必要があります。 15) エラー処理：問題が発生した場合、プログラムはエラーをログに記録し、正しいユーザーのセットに警告し、プログラムを許容できる状態に戻すことで、適切に劣化すべきです。 16) 国際化と地域化：すべてのプログラムが複数の国で実行されたり、複数の言語でユーザーと通信したりすることを心配する必要はありませんが、多くはそうです。 17) アクセシビリティ：これも、すべてのプログラムがこれを心配する必要はありませんが、多くのプログラムは、異なる身体的または精神的能力を持つユーザーに対応し、それを適切に行う必要があります。 私は続けていくこともできますが、それが非常に多くのことであり、プログラマーがコードを書く以外の時間に行う必要があること（スケジュールの見積もりや同僚とのコミュニケーションなど）は含まれていない、という点を明確にしたと思います。 アスペクト指向プログラミング（AOP）は、1990年代半ばにXerox ParcのGregor Kiczalesらが提唱したアイデアで、プログラマーがコードの各行ですべての懸念事項を同時にではなく、それぞれを個別に一度に集中して扱えれば、プログラミングがもっと簡単になるかもしれない、というものでした。私は常にそのアイデアを愛していましたが、AOPがそれを実装するために選んだ具体的なメカニズム、つまり「ジョインポイントモデル」は常に嫌いでした。これは基本的に、プログラムの呼び出しスタックに対するランタイムパターンマッチングと、パターンが一致するたびにいくつかのコードを実行することに帰着します。例えば、呼び出しスタックにファイルオープンルーチンが最後にプッシュされたものとして含まれるたびに、プログラムは開かれようとしているファイルの名前をログに記録するかもしれません。AOPに関するWikipediaのページが指摘するように、これは冗談として提案された「COME FROM」ステートメントと非常に近く、同様にデバッグや保守が困難です。 しかし、LLMの新たなコーディング能力のおかげで、AOPはもう一度検討されるべきだと思います。その新しい形では、プログラマーは各懸念事項について個別のドキュメントを書くだけで済みます。もちろん、ドキュメントの長さは大きく異なり、正確性に関するドキュメントが通常最も長くなるでしょう。多くのドキュメントは、プロジェクト間で再利用および共有できます。例えば、組織のスタイルガイドは保守性に関する懸念事項に使用できます。そして、AOPの用語を使うなら、「ウィーバー」は、単にドキュメントからプログラムを生成するLLMです。 これがAOPの古いジョインポイントモデルよりも優れているのはなぜでしょうか？あのモデルは脆かったのです。すべてのファイルオープン後にログを記録するには、ファイルオープン関数の特定の文字列名または名前のセットに一致させる必要がありました。そして、同僚が新しいファイルオープン関数を追加したり（さらに悪いことに、名前を変更したり）した場合、それはログに記録されませんでした。ここでは、LLMがウィービングを行うことで、ファイルを開くことが何であるかについての背景知識に依存してマッチングを行います。LLMには、ウィーブの出力が静的（つまり、プログラムの実行時に計算されない）で読みやすいという利点もあります。AspectJのajcのように「コンパイル時ウィービング」を行うAOP実装もありますが、それらは読みにくい生のJavaバイトコードのようなものを出力します。LLMがAOPを行うかどうかにかかわらずコードを生成するのに使われることを考えると、これは少し不公平な比較でもあります。私の要点は、AOPの懸念事項の概念が、LLMに与える文を整理するのに役立つ方法を提供してくれる、というだけです。（あるいはLLMたち。各懸念事項の記述を、その観点からコードを批判する役割を持つ別のエージェントに与えることもできます。）