> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2020/w28-definitions-and-interface-dependencies.md).
# W28-定義と API の依存関係
### 定義の重要性
日常で混同しやすく、権限や責任が曖昧なことは、概念の定義に問題がある場合が多い。定義が不明確だったり、明確でも合意がなかったりする。例えば QA が ones でバグの担当者を指定するとき、複雑な場面では誰に割り当てるべきか迷う。根本の原因は、担当者の定義が曖昧か、共通認識がないことだ。明確な定義がないと、問題を作った人、処理する人、責任を持つ人を合わせた複合概念として受け取りがちだ。少し複雑になるだけで、一つの語に複数の意味が生まれる。そんなときは、簡潔で明確な定義が問題を解く。最も単純な原則は、修正する人に割り当てることだ。担当者は処理する人であり、責任の切り分けとは無関係だ。根本原因や責任者を探すのは、COE の振り返りで行う。
### **API 間の依存が後方互換性へ与える影響**
フロントエンドとバックエンドを分離した構成では、API の変更時に後方互換性へ必ず注意する。通常、バックエンドのフィールドは追加し、既存のものは変えない。後方互換性がなければ、公開順を調整しても、新旧 API の切り替えスイッチを設けても、切り替え時点の異常の急増は防げない。特に API 間の依存には注意したい。既存 API を変えず、新版を追加した場合でも、それが前段の API に依存することがある。例えば前段が後段へのリクエスト先を返す場合だ。単なる追加でも、前段の API が新しい後段の API に対し、バージョン互換性を確保しているかを、特に確認する必要がある。