A Philosophy of Software Design ch17 Consistency

www.goodreads.com

---

Consistency

• 一貫性は複雑性を減らす強力なツール
  • 似ているものは似たやりかた
  • 似ていないものは異なるやりかた

	一貫性がある	一貫性がない
学習にかかる時間	短い	長い
ミス	少ない	多い

• 認知の助け
  • 一つ理解すれば他の部分にも知識を流用できる
• 一貫性がないとミスが増える
  • 誤った仮定をおいてしまうため
    • 例: 「同じだろう」と思いきや実は異なる代物だった

Examples of consistency

• さまざまなレベルで適用できる
  • 識別子の名前
    • ch14に詳しい
  • コーディングスタイル
    • インデント
    • 中カッコ位置
    • 危険な言語機構の使用の制限
  • インタフェース
    • 複数の実装に共通のインタフェースをもたせる
    • ひとつ学習すれば他の実装も簡単に理解できる
  • デザインパターン
    • 広く受け入れられている解法
      • 例: UIのMVC
    • 効能
      • よりすばやく開発できて
      • よりうまくいく見込みがあり
      • 読み手にとって、より明瞭になる
    • ch19.に詳しい
  • 不変条件
    • 常に真であるような特性
    • 【補】コンストラクタで確立するアレ
    • 例
      • Textクラスが集約する各行の文字列はLFで終わる
      • 【補】バスが必ず/で終わる、とかもこれかな
    • 効能
      • 特殊ケースを減らせる
      • コードの振る舞いの理由付けが容易になる

Ensuring consistency

• 新参は知らずのうちに規約を破ってしまったりするもの
• 一貫性をどう維持するか
  • 文書化する
    • 目に触れる場所に配置する
      • Wikiなど
    • ときどき更新する
    • 不変条件のような、より局所的な規約は、コード中に書き下す
  • 強制する
    • しくみで強制する
      • linterが通らないとcommitできないようにする、みたいな
        • LF/CR-LFの話(省略)
          • 【所感】Gitなら.gitattributesで一撃
      • コードレビューで口うるさく言う
  • 郷に入っては郷に従え
    • 既存のコードベースで規約らしきものを見つけたら従う
    • 既存の設計思想に従う
  • 既存の規約を変えようとするな
    • 「より良いアイデアだから」というだけでは、一貫性を壊す理由としては不十分
      • 新しい手法を正当化できる有意義な根拠はありますか？
      • 新しい手法は、時間をかけて古いやり方を全て置換するに足る良いものですか？
    • これらの問いに対して、組織の合意がとれたらどうぞ
      • その場合、古い規約は跡形もなくすこと
      • 他の開発者が、新しい規約を知らず、古い規約を再導入してしまうリスクもある
    • 既存の規約を再考するのに工数を費やすのは、たいてい良くないことである

Taking it too far

• 似ていないものを似たやり方でやるな
  • 例:
    • 異なるものに同じ変数名を割り当ててしまう
    • フィットしないデザインパターンを適用してしまう
  • 逆に複雑になり混乱を招く
• 「似ていれば、それそのものである」と自信を持って言えること

Conslusion

• 投資の姿勢
  • 【補】ch3.にて述べた「戦略的姿勢」
  • 一貫性を保証するためには、「動くコード」に加え、余剰の工数を要する
• 投資の例
  • 規約の決定
  • 規約の自動チェッカの構築
  • 既存のコードベースを真似るために、似ている部分を探す
  • コードレビューでチームを教育する
• 「明瞭なコード」という形で返ってくる
  • 速く正確に読み解ける
  • 開発が速くなり、バグも減る

---

英語

• conspicuous
  • 目立つ
• every once in a while
  • たまに
    • everyは強意
• nit-picky
  • 口うるさい
    • 人の頭からシラミの卵を取る、という意味から
• overzealous
  • 熱心すぎる