プログラムを書くとき、後の保守のしやすさに重点を置いております。しかし納期が厳しい場合はどうしてもぞんざいになってしまうのが悲しいところです。

そんな背景から「プレファクタリング」という本を読んでいます。第２章の時点ですでに目から鱗でした。忘れぬように書き留めておこうと思いました。

要件の定義には信頼性・テスト容易性・配置容易性・パフォーマンスが暗示されている

つまり、顧客にとって不便にならないような設計になっているか最初の段階で試算する必要があるとのことです。

これは痛感できました。

すでにあるプログラムを作らない

いわゆる車輪の再開発をしないというやつですね。

現実にはひとつの概念であっても、別の視点が明白にある場合ば、それぞれを別の名前で管理する

本文では CD に例えられていました。

一言に CD といっても「○○というアーティストが CD を出した」と「ラックに入っている CD を整理する」とでは意味が違います。前者は著作物としての CD 、後者はディスクとしての CD です。本文ではそれぞれを CDRelease, CDDisc と名前をつけていました。これは概念の混乱を最小限にする工夫かと思われます。

本文ではこれを分割と呼んでいました。

また、もし別の名前で管理していた概念が本質的に同じであることが判明した場合、単純な置換で修正が可能とのことです。確かに長い名前は grep で見つけやすいですね。

本文ではこれを一括化と呼んでいました。

データをまとめる

本文では一連の属性をひとつの名前がつけられた概念に結合することを凝集化と呼んでいました。

たとえば郵便番号、県、市区町村、番地などを結合して住所とすることがそれに当たります。

データの情報を捨てない

たとえばプログラムでお金を取り扱う際、お金を単なる integer 型で管理するのではなく、 Yen という抽象型で管理すべきとのことです。

たしかにオブジェクトが自分の性質を把握しておくというのはメリットが多いかと思われます。

先のお金の例ですと負数が必要ないことがしばしばあるのですが、 integer 型で管理していたばっかりに、かえってデバッグが大変だったことがあります。

コード中に定数を書かない

ここでいう定数とは #define などのテキストとしての定数です。 Java 言語のように const をつけたオブジェクトを定数の代わりにを使いましょうとのことです。

プロトタイプは紙で作ろう

「なんだ、もうできてるじゃん？」と思われる顧客が多いそうです。笑いました。