アーキテクチャ腐敗の一因は開発コストへの妥協
腐敗したアーキテクチャの特徴としては、大量の特別処理、互換処理、深刻な結合、負債の蓄積があります。 アーキテクチャは徐々に腐敗していきます。腐敗したアーキテクチャでは新機能の開発が難しく、バグの修正も困難で、一箇所を変えると全体に影響し、テストやQAも非常に困難になります。 かつて、他業種から開発に転向した愛好家が投稿で、モデルがコードを書く際の抽象化行動を制限すれば、コードがより理解しやすくなると言っているのを見たことがあります。人間が理解しやすいコードは、LLMも理解しやすいため、迅速な開発とエラーの削減が可能になります。他業種からの開発者はおそらく工数が小さく、ライン流式の論理に慣れているのだと思いますが、規模拡大の見込みがあるなら、思考をライン流に限定せず、建築工のように考えるべきです。30階建てのビルを建てることを見込むなら、10メートルの基礎を打ち、給水・給電を見込むなら、水道・電気のスペースを確保します。これは目標が明確な設計です。さらに、目標が不明確な設計もあり、例えば部屋のどこかに将来家電を置くが何を置くかは未定の場合、コンセントを予め設置しておけばよいのです。 ソフトウェア工学には設計を指導するためのSOLID原則がすでに存在します。多くの場合、表面的にはSOLID原則に従うと同じ機能を実現するために多くのファイルを跨ぎ、より多くのコードを書くことになりますが、短期的な結果としては、設計の有無は経営層・テスト・ユーザーの目から見てほとんど違いがなく、設計のメリットは長期的にしか現れません。良いアーキテクチャは機能の追加、変更、バグ修正が容易で、問題の混入も少なくなります。 設計に必要な思考は、直接機能開発に着手するよりも多くなることがよくあり、設計には粒度の考慮が必要です。コンセントパネルをタイル代わりに部屋中に貼り付け尽くすのは、別の荒唐無稽なやり方です。以前の開発では開発期間を考慮してトレードオフを行い、時間がない時は設計すらせずに数個の関数を追加して終わりにし、将来のことは将来に任せていました。今はAIの助けを借りて、設計の粒度をより小さくでき、生成されるコードは人間にはより理解しづらくなりますが、エンジニアリングはより保守しやすくなります。抽象化を増やした後、能力の低いモデルでは確かにうまく扱えないこともあるため、現在最高のモデルを使うのが最善です。単なるスクリプトを書くだけなら、モデル間の能力差はあまり目立たないかもしれません。 AIが開発者の参入障壁を下げたかどうかについては、私は疑問を持っています。新人開発者の学習経路は過去とすでに大きく異なっており、障壁の高低を議論する意味はないかもしれません。なぜなら、障壁がどこに移されたかわからないからです。
