Consistency
システムに一貫性があると、開発者はあるコンテキストで認知したパターンに基づいて、別のコンテキストでも正しく推論・仮定・理解できる コーディングスタイル
複数の実装を持つインタフェースは、1つの実装を理解すれば他の実装も理解しやすくなる
常に true である条件（特性）
コードで考慮する必要がある特殊なケースの数を減らし、コードの挙動を理解しやすくする
特に、長期間に渡って多くの人が携わるプロジェクト
ドキュメントの作成
コーディングルールのような、重要なルールを列挙したドキュメントを作成する
Web 上に様々な会社が公開しているので、それを参考にすると良い
GitHub Wiki など、開発者が目にしやすい場所で管理する
新しく参画したメンバに、そのドキュメントを読むように促す
従来のメンバには、定期的にレビューするように促す
ルールを強制する
いくら良いドキュメントがあったとしても、1人の開発者がすべてのルールを覚えるのは無理
Husky などを導入し、パスしない限りはコミットできないようにする レビューで指摘する
厳格であるほどメンバは成長できる
新しいファイルで作業するときは、既存のコードがどのような構造になっているかを見て回ること
既にあるルールは変えない
優れたアイデアであっても、既にあるルールで一貫性が取れているならば変えるべきではない 本当に変える際には、以下の2点を自問自答し、どちらも当てはまる場合のみに行うこと
既存のルールを設定したときには無かった、（新しいルールを正当化するような）重要な情報を持っているか
既存のルールに則っている箇所をすべて更新するほどの価値があるか
また、変更した後も新しいルールが認知されていない可能性があるため、既存のルールが入り込んでしまうリスクもある
e.g. 本当は異なるものに同じ変数名を付ける
一貫性 のある名前とは、どういったものなのかを改めて見直すradish-miyazaki.icon e.g. 無理やりデザインパターンを適用する
一貫性 が真価を発揮するのは、開発者が「それが x のように見えるなら、それは本当に x である」という確信を持てるときだけである コーディング規約を決めるコスト
チェッカーを導入するコスト
コードを記述するときに、既存のコードを確認するコスト
レビューするコスト
etc...
これにより、コードの動作をより迅速かつ正確に理解できるようになる バグを減らしつつ、スピードを上げて開発できる