同じモノは規則的に統一感を持たせる・例外や複数の手法を混在させない

同じモノ・似たようなモノたちは、ある一定の規則に則って、同じような作りにする。積極的に似せていく。

同じような動きを期待しているのに、実装方法が全く違い、その理由や意図が特にないモノは、他の人にとってむやみに分かりにくくなる。

例

• 似たような複数のクラスがあった時に、show() と display()、get() と fetch()、といった、似たような名前のメソッド名が混在していると、同じモノとして読みづらい。こういうモノはインターフェースで縛ったりすると良いだろう
• 1つの資料の中で、見出しのスタイルが複数あったり、場当たり的に「ココは中央揃え」「ココは気分的に右揃え」といった作りにしていると、文書全体をざっと眺めた時に構成が読み取りづらくなる。本人はデザインをしているつもりなのかもしれないが、デザインセンスのかけらもないので止めるべき

対策

• 何かを作り始める前に、一定の規則を作る
  • コーディングスタイル、命名規則。資料のテンプレートや使う図形・記号など
  • できれば大きな団体・組織が取り決めている規則をそのまま利用するべき
  • 「個人ルール」はその共有から始めないといけないので伝わりづらい。既にある規則は前提知識として共有しやすい
  • 大きな組織が決めた事柄は、大抵の場合において、既に自分個人よりずっと頭の良い人達がよってたかって長い時間をかけて議論の末に構築したモノだから、汎用性が高く、従った時の効果が大きい。「その良さが分からない」場合は往々にしてコチラの読解力のなさが原因だから、よくよく勉強する
• 場当たり的な判断をしない
  • 都度都度「コレはどうしようか、こうしよう」と「判断」をしないようにする
  • 事前に「大見出しはこのフォントサイズ」「中見出しは下線を引く」とルールを決めておいて、それを適用するだけ、という風にしておく
  • 「その場で判断したこと」があったら、過去の成果にも遡及反映して統一感を持たせられないか、ルール化できないか考える
• 似たようなモノが後からまとめられないか考える
  • 類義語を複数使用していて、全く同じモノを指しているのであれば、1つの単語のみ使用するように直す
  • 役割や構造をまとめる上位概念 (親クラスやインターフェース) を考える

注意

• 「同じやり方を選ぶこと」に固執しすぎない → 「ゴールデンハンマー病」を避ける
  • 本来は別々のやり方を選んだ方が良いモノにまで同じ手法を適用しようとしない