TL;DR
- 一貫性があると、開発者はある場所で覚えたパターンを別の場所にも当てはめられるので、ミスが減る。
- 一貫性を保つには、ドキュメント化、ルールの強制、既存のやり方に従うことが必要で、無理に当てはめると逆効果になる。
内容
一貫性はミスを減らす
システムに一貫性があれば、開発者はある場所で認識したパターンをもとに、別の場所でも正しく推論できる。一貫性はさまざまなレベルで適用できる。名前（第14章 Choosing Names）、コーディングスタイル、インタフェース、デザインパターン、不変条件などである。複数の実装を持つインタフェースなら、1 つの実装を理解すれば他の実装も理解しやすくなる。不変条件は常に成り立つ性質のことで、コードで考慮すべき特殊なケースを減らし、コードの振る舞いを理解しやすくする。
一貫性を保つ方法
一貫性を保つのは難しい。長い期間に多くの人が関わるプロジェクトでは特にそうである。一貫性を保つ方法には次のものがある。
- ドキュメントを書く: コーディング規約のような重要なルールを列挙したドキュメントを作り、開発者が目にしやすい場所に置く。新しく加わったメンバーには読むよう促し、既存のメンバーにも定期的に見直してもらう
- ルールを強制する: 良いドキュメントがあっても、1 人の開発者がすべてのルールを覚えるのは無理である。ツールでチェックし、通らない限りコミットできないようにする。レビューでも指摘する
- 郷に入っては郷に従え: 新しいファイルで作業するときは、既存のコードがどう書かれているかを見て回る
- 既存のルールを変えない: 優れたアイデアでも、既存のルールで一貫性がとれているなら変えるべきではない。変えるのは、既存のルールを決めたときにはなかった重要な情報を持っていて、なおかつ既存の箇所をすべて更新するほどの価値がある場合だけである。変えた後も新しいルールが知られておらず、古いルールが入り込むリスクがある
やりすぎに注意
無理に一貫性を当てはめると、かえって複雑さや混乱を生む。たとえば、本当は異なるものに同じ変数名を付けたり、無理にデザインパターンを適用したりすることである。一貫性が真価を発揮するのは、開発者が「x のように見えるものは本当に x である」と確信できるときだけである。
一貫性は投資
一貫性も一種の投資である。コーディング規約を決める、チェッカーを導入する、コードを書くときに既存のコードを確認する、レビューするといったコストがかかる。その見返りとして、コードがより明白になり、動作を素早く正確に理解できるようになる。バグを減らしながら速く開発できる。
キーワード
自分の理解
コーディング規約は、Web 上で各社が公開しているものが参考になる。たとえば、Cookpad の Ruby スタイルガイドがある。規約は GitHub Wiki など、開発者が目にしやすい場所で管理するとよい。
ルールの強制には、Husky などを導入してチェックを通らない限りコミットできないようにする方法がある。レビューは厳格であるほど、メンバーは成長できる。
無理な一貫性の話は、一貫性のある名前とはどういうものかを改めて見直すきっかけになった（第14章 Choosing Names）。