CHATGPTなどの大規模な言語モデル（LLM）の開発により、ますます多くの開発者がそれらを使用してコードを生成し、設計アーキテクチャを生成し、統合を加速します。ただし、実用的なアプリケーションでは、それは顕著になります。建築の古典原則 – 固体、乾燥、清潔 – LLMコドゲンデーションの特性とうまくやっていません。
これは、原則が時代遅れであることを意味するものではありません – それどころか、それらは手動開発と完全に連携しています。しかし、LLMでは、アプローチを適応させる必要があります。
なぜLLMが建築原則に対処できないのか
カプセル化
インクシレーションでは、システムの一部間の境界、開発者の意図に関する知識を理解し、厳格なアクセス制限に従う必要があります。 LLMは、多くの場合、構造を簡素化したり、理由もなくフィールドを公開したり、実装を複製したりします。これにより、コードはエラーに対してより脆弱になり、アーキテクチャの境界に違反します。
要約とインターフェイス
抽象的な工場や戦略などの設計パターンには、システムの全体的な見方が必要であり、そのダイナミクスを理解する必要があります。モデルは、実装を保証せずに明確な目的なしでインターフェイスを作成したり、レイヤー間の接続に違反したりできます。結果は、過剰または非機能的アーキテクチャです。
dry（donolt繰り返し自分で繰り返します）
LLMは、繰り返しコードを最小限に抑えようとはしません – それどころか、一般的なロジックを作成するよりもブロックを複製する方が簡単です。リクエストに応じてリファクタリングを提供できますが、デフォルトでは、たとえ冗長性につながる場合でも、「自己適切な」フラグメントを生成する傾向があります。
クリーンアーキテクチャ
Cleanは、厳格な階層、フレームワークからの独立性、指向性の依存性、およびレイヤー間の最小のつながりを意味します。このような構造の生成には、システムのグローバルな理解が必要です。また、LLMは、建築の完全性ではなく、単語の確率のレベルで機能します。したがって、コードは混合され、依存の方向に違反し、レベルへの単純化された分割が違反されます。
LLMを使用するときにうまく機能する
乾燥する代わりに濡れています
WET（すべてを2回書く）アプローチは、LLMでの作業においてより実用的です。コードの複製は、保持のモデルからのコンテキストを必要としません。つまり、結果は予測可能であり、正しく修正しやすくなります。また、非自明なつながりやバグの可能性を減らします。
さらに、複製はモデルの短いメモリを補うのに役立ちます。いくつかの場所でロジックの特定の断片が見つかった場合、LLMはそれをさらなる生成で考慮に入れる可能性が高くなります。これにより、伴奏が簡素化され、「忘却」に対する抵抗が増加します。
カプセル化の代わりに単純な構造
複雑なカプセル化を回避し、コードの部分間のデータの直接送信に依存すると、生成とデバッグの両方を大幅に簡素化できます。これは、MVPの迅速な開発または作成で特に当てはまります。
簡略化されたアーキテクチャ
プロジェクトのシンプルでフラットな構造は、最小量の依存関係と抽象化を備えており、発電中はより安定した結果をもたらします。モデルはこのようなコードを簡単に適応させ、コンポーネント間の予想される接続に違反することが多い場合があります。
SDK統合 – 手動で信頼できる
ほとんどの言語モデルは、時代遅れのバージョンのドキュメントでトレーニングされています。したがって、SDKをインストールするための手順を生成する場合、エラーがよく表示されます。時代遅れのコマンド、無関係なパラメーター、またはアクセスできないリソースへのリンク。練習のショー：公式のドキュメントと手動チューニングを使用して、LLMを補助的な役割にします。たとえば、テンプレートコードや構成の適応を生成します。
なぜ原則がまだ機能しているのか – しかし、手動開発で
固体で乾燥した清潔から清潔からの困難は、LLMを介したコドヘゲエネーションに懸念していることを理解することが重要です。開発者がコードを手動で書き込むと、これらの原則は引き続き価値を示し続けます。つながりを低下させ、サポートを簡素化し、プロジェクトの読みやすさと柔軟性を高めます。
これは、人間の思考が一般化する傾向があるという事実によるものです。私たちはパターンを探しています。個々のエンティティに繰り返し論理を持ち込み、パターンを作成します。おそらく、この動作には進化的なルーツがあります。情報の量を減らすと、認知リソースが節約されます。
LLMは異なる行動をとる：彼らはデータの量から負荷を経験せず、貯蓄を努力しません。それどころか、複雑な抽象化を構築および維持するよりも、それらが重複した断片化された情報を使用して作業するのが簡単です。そのため、繰り返し構造と最小限のアーキテクチャの重大度を備えた、カプセル化なしでコードに対処する方が簡単です。
結論
大規模な言語モデルは、特に初期段階で、または補助コードを作成する際に、開発において有用なツールです。ただし、アプローチを適応させることが重要です。アーキテクチャを簡素化し、抽象化を制限し、複雑な依存関係を避け、SDKを構成する際にそれらに依存しないようにすることが重要です。
固体、乾燥、きれいの原則はまだ関連していますが、人の手に最善の効果をもたらします。 LLMで作業する場合、手動で簡単に完成できる信頼できる理解可能なコードを取得できる簡素化された実用的なスタイルを使用することが合理的です。そして、LLMが忘れる場所 – コードの複製は彼が覚えておくのに役立ちます。
