名前付けの複雑さ

シンプルな名前付け

設計をシンプルにするためには、名前付け自体もシンプルさが必要です。
ただし、名前付けの複雑さの適用範囲を区切る必要があります。

名前付けの例

オブジェクト指向の場合はクラス名は「責任、担当」がそのまま名前になります。 Observer や Manager 等ですね。
また、メソッド名は「やる事」がそのまま名前になります。 doCheck() や execJob() ですね。
ただし、これらの 名前から逸脱した情報を持ったり、処理が行われたり が世の中にはあり得ます。
つまり、 Observer だから監視担当なのに、逆に監視される。
つまり、 doCheck() だからチェックのみの担当なのに、チェック対象そのものを作る。
こういう事は、当初設計自体に問題がある場合もあれば、その後の修正でルールが守られない場合もあります。当初設計自体の話であっても、その後の修正であっても、一概に間違いとは言えません。
工数そのものが足りなかったり、担当者自体の能力不足(適材適所出来ていない)であったり、非機能要件を満たすためだったりするわけです。ですので、そもそもの名前付け自体に範囲を持たせて、処理を適材適所に分けておけばやりやすいわけです。
(人の行動自体を防ぐのは難しいので、行動を防ぐためには色んな静的解析ツールを導入するしかないですね・・・)

名前付けの複雑さの適用範囲を設計する

名前付けの複雑さを、プロジェクト全体で同じものを使うのではなく、
名前付けの複雑さも段階を分けて適用すれば、わりかし楽なルールでプロジェクトをハッピーな状態に出来るのではと考えています。

例えばの例

1. コア機能やユーティリティの名前付けはシンプルにする
2. 機能を使う側として、業務ロジックであれば複雑さを許す(例：ファサードパターンの時)

というルールです。
特に業務ロジックの場合、そもそも複雑な場合が多く、シンプルにすると逆に意味が分からなくなる場合もあり得ます。

名前付けの信頼性

名前付けに信頼性があれば、中身のコードがブラックボックスであっても、表面的な処理フローだけを見る理解だけで済む事が多くなります。
「名前付けに信頼性がある」とは、今までの流れ通り 名前の通りの責任、役割を持ち、余計な事をしない という事です。
もし余計な事をするのであれば、それを外部から見えるインターフェース(クラスやメソッド)のコメントに書いたり、別の名前でクラスやメソッドを作ってラップしましょう。
(これもやり過ぎると余計な複雑さを生み出すので、ご利用は計画的に)