ショートカット
ファシリテーター × あり方
コーディングの向こう側
Hello, ANOTHER world!
オブジェクト指向のはなし
プログラミングのはなし
C言語実力診断クイズ
eSkillBooks
プログラミングのはなし

メンテナンスが最優先

いま、自分は何を優先すべきなのだろうか? SE ならトレードオフ問題に頭を悩ませる機会もしばしばでしょう。もちろんクライアントの要求仕様を満たすこと、そしてバグのないことは最低条件として、さて次に優先すべきことは何かと。

  • 実行速度?
  • ファイルサイズ?
  • 実行時サイズ?
  • エラー復旧?
  • ユーザーインターフェイス?
  • それとも開発期間?

いやいや、本当に優先すべきなのはメンテナンスです。メンテナンスにかかる時間を最小限にすることを常に考えてコーディングし、またドキュメントを書くべきです。目先のことにとらわれて(締め切りとかね)、その場しのぎのコーディングをすると、あとで痛い目にあいます。痛い目にあうのはあなた以外の誰かかも知れません。いや、ほとんどの場合はあなた以外の誰かがとばっちりをくっているんです。

たとえば以前にあなたが関わったプロジェクトのクライアントからクレームがきたとしましょう。改造依頼かも知れないし、バグレポートかもしれない。いずれにせよ、いまのあなたは当時とは別のプロジェクトの一員であり、例によって多忙です。メンテナンス作業はすみやかに行われる必要があります。しかし「あのとき」のあなたは「いまの」あなたにふりかかったこの災難を予測していたでしょうか?予測していなかったとしたら、きっと恐ろしい残業が待っています。あなたの心はまったく異なる2つのプロジェクトによって引き裂かれ、きっと多重人格者になってしまうでしょう。

だだし、もしあなたが非常に忙しければ、一時的には助かります。メンテナンスの仕事がほかの誰かにまわされるからです。しかしその人が、仕事をする上でどうしても必要なはずの過去の資料が不十分だと気付けば、結局あなたのもとに質問のメールが山ほど届くことになるでしょう。こうして全ての人が不幸になっていきます。

そう言う訳で、メンテナンスのためのコーディング、メンテナンスのためのドキュメンテーションが必要になります。つまり誰が見ても理解できるように作ること(これが一番高度な技術でもあります)。将来のために時間をさくということは決して無駄ではなく、むしろプロジェクトの作業速度は加速されるでしょう。分かりやすく作るということは、理解しながら作るということと似ているからです。

(「プログラミングのはなし」は1998年1月から1999年1月にかけて作成されたコンテンツです。)