1. ソースコードを書かないようにする

プログラマは複雑そうな仕様をソースコードに落とすことに喜びを覚え、何でも自分で書いてしまうという習性を持ち、車輪を再発明したいという欲求があります。職業プログラマは特にこの衝動をグッと抑えなければなりません。

エリック・レイモンドは「伽藍とバザール」の中で「何を書けばいいかわかってるのがよいプログラマ。なにを書き直せば（そして使い回せば）いいかわかってるのが、すごいプログラマ。」と述べています。

Perlの場合、ライブラリ群が充実しており、「こんなことできないかな」と思ったらCPANを探してみると、即使えるものや、そのままでは使えなくてもちょっと手直しすれば使えるものが多く見つかります。

「そんなのライブラリの仕様を調べるよりも、自分で書いた方が早いよ」というご意見もあると思います。確かに、自分で書いた方が早いかもしれません。しかし、CPANに登録されているものはテスト済みのモジュールですので、品質の面でも一から書くよりは有利なのです。

また、CPANでは更新があったモジュールのRSSも出力しているので、RSSリーダに登録してウォッチしておくと、思わぬ発見があるでしょう。

2. 不要になったソースコードを捨てる

Perlには「There's More Than One Way To Do It.（TMTOWTDI）」というスローガンがあります。和訳すると「やり方は1つではない」を意味するこの概念は、Perlの自由度の高い文法にあらわれていて、他のスクリプト言語と哲学を異にするところであります。これは、優れたプログラマに自由を与える反面、チームで開発する場合にはコーディングルールを統一しづらいという問題を抱えることになります。

しかし、自由度の高さには誰もが注意を払うため、メンテナンスできなくなる程の酷いソースコードはお目にかかりにくいのが現状です。では、保守開発時にもっとも問題となるのは何かというと、使っているのかどうかわからないモジュールやソースコードが散在している点です。

CVSやSubversionといったツールを使ってバージョン管理がされていることが前提となりますが、筆者は不要になったものはコメントアウトせずに消すという手法を行っています。

これは、いつ誰がどこに手を加えたかというのはツールがやることで、人力でやることではないためです。またソースコード中にプログラムの意図以外のコメントを混ぜてしまうと、可読性が大きく下がってしまい、保守開発において命取りになりかねないからです。

職業プログラマの方はとりわけ慎重な気質であると思います。しかし、それに打ち勝って不要なものを整理することが、結果として自分を救うことになるのです。 次のページ