概念定義#
完備性：
- 現在の要求に対して提供できるサービスのカバレッジ
アーキテクチャの目標#
アーキテクチャは比較的広範な概念です
特定の要求を実現するための一つまたは一連のビジネス
問題を高効率で解決することを目的としています
リファクタリング#
リファクタリングの本質は、現在のアーキテクチャの 完備性 が不十分であるために再構築することです
ソフトウェアをリファクタリングすることは、特定のモジュール / 特定のアプリケーション、さらには特定のシステムを再度書き直すことを意味します
この行動は一般的に次のような場合に発生します：
- 元のコードに多くの問題があり、修正コストが巨大である
- 元のシステムの性能がビジネスの継続的な成長に対応できない
- 新機能を迅速にシステムに統合できない
- アーキテクチャ自体に欠陥がある
どんな理由であれ、リファクタリングは前世代の製品に発生した問題を解決するためのものであることは確かです
リファクタリングは避けられませんが、その頻度は == 制御可能な範囲内 == にあるべきです
さもなければ、3 日ごとに小さな変更、1 週間ごとに大きな変更（これによって生じる時間コストと精神的負担は非常に大きいです）
- 問題を解決する最良の方法は、問題の根源を解決することです
想像してみてください：
あなたはある API（仮に天気インターフェースとし、データには温度 / 湿度 / 変化状況 / 地域が含まれる）を実装しました
現在湿度というパラメータが必要ないと思った場合、湿度のデータを直接捨てるかもしれません
しかし、ある日自分が実装した機能が湿度というパラメータに依存する必要があるとき、あなたは元のコードから湿度を補うか（これは明らかに精神的負担を増やします、特にコードがシステム内にある場合）、新しいラッパーを実装してこのパラメータを取得するかのどちらかです
上記の 2 つの方法は、システムをより 複雑 にします
では、最初からパラメータをラッパーの内部に保存し（外部に出力されるデータには湿度が含まれない）、直接捨てるのではなく、機能を実現する際にはその API を呼び出して湿度パラメータを取得するだけで済むのです！
- 上記の例は、データを捨てるよりも内部にラップして次回使用する方が簡単に発生する状況を示しています
- もちろん、これにより計算リソースや帯域幅がより消費される可能性があります（安定性や開発コストにとって、これはそれほど大きな問題ではありませんよね？）
生活の中の例#
B 站を例に取ると、その Web 端 API インターフェースには「無用」に見える複数のパラメータや重複項目（例えば bvid と bv_id）が存在します
これは互換性を犠牲にして開発の遍歴を得るものであり、bvid と bv_id を使用することで混乱による 暗黙の問題 とコミュニケーションコストを減少させることができます