与太話
.NETのクラスライブラリ設計を読みました。
これは改訂版で、僕は改訂版で初めて読みました。 改訂前の本は10年ほど前に出ているようで、若干古い言及もあるのですが、良い本でした。
すごいテクニックが沢山！ というのではなく、むしろ、膨大なライブラリを作るにあたっての苦労や失敗、後悔といった、しくじり先生的な本になっています。 マイクロソフトのエンジニアも間違えるんだという謎の安心感を得られますね。
命名の話
前にも書いたのですが、チームで開発するときに1番重要なルールは単一責任原則だと思います。 色々大切なことはありますが、1つ選べと言われたら多分これ。
そして、これと付随するのが命名だと思います。 チーム開発の場合、他人の書いたコードを読むほうが、自分がコードを書くよりも断然多くなります。 その際に苦労するのが、名前から中身が推測できないコード。 ◯◯Managerとかですね。
こういう名前をつけてしまう理由はいくつかあるでしょうが大きく2つでしょうか。
1つは、中身が多く、バシッと決まった名前がつけられないから。 中身がフワフワしてるなら名前もフワフワしちゃうのは当然です。単一責任原則を守ればこれは回避できます。
もう1つは、読み手の気持ちになっていないから。 書いてる人は、「クラスの役割」->「クラスの名前」と名付けているかもしれませんが、読み手は「クラスの名前」->「クラスの役割」の順に読むのだから、それは改めるべきです。 これは、クラス設計を先に行い、詳細を後回しにすることで自然と実現できます。 必要な役割を洗い出す過程で適切にクラス分けを行い命名することで、神クラスの誕生を防ぎ、読み手に優しいコーディングにならざるを得ない状況を作りましょう。
もし、これらの理由ではなく単に命名に関心が無い故なのだとしたら、チーム開発においては大きな問題であると思います。 単一責任原則が守られているかチェックするのは結構難しいことだとは思いますが、例えば、 クラスの名前から、そのクラスが公開しているメンバを過不足無く推測できるか考えてみましょう。 「過不足無く」というのは、本当に適切なクラス分けと命名がなされているなら決して不可能なことではないです。
終わり
SOLID原則だとか、命名だとか、プログラミングを始めたばかりの頃は意識できなくて当然なんですが、これらがしっかりできている人、これらがいかに恩恵をもたらすかを理解している人は安心感が違います。ゲームエンジンを使ってとにかく動くものを作る、というのもモチベーション維持になりますし非常に価値あることだと思いますが、こういった基礎も同時に進めていくと、信頼されるプログラマにより近付けるのではないかなと、それを目指している身として感じます。
