この記事は、私が先日LinkedInのMulticsフォーラムに投稿したメッセージを編集したものです。
自分の変更が即座に「本番環境」に反映されることは、大きなモチベーションになるものです。これは、1960年代後半から1970年代初頭にかけてMITで開発が進められていた主要なオペレーティングシステム「Multics」に、私が初めてバグを混入させてしまった時の話です。
私は当時、MITに入学したばかりの1年生で、Multicsプロジェクトに参加することになっていました。私は、ラインプリンタデーモンが処理するリクエストをキューに入れるdprint（「デーモンプリント」）コマンドに、ある機能を追加することを志願しました。あるマネージャーから、キューにN件のリクエストを追加するのではなく、リクエスト内の部数を記録するようにと指示されました。この変更により、完了した印刷リクエストの削除に関わるレースコンディションが解決されるはずでした。私は変更を加え、満足のいく結果が得られるまでテストを行いました。
私の修正はすぐに適用され、システムを改善できたことに胸を躍らせた。しかし、その喜びも束の間だった。間もなくオフィスの電話に出ると、怒り狂ったユーザーから、私が彼のプログラムを壊してしまったと苦情を言われていることに気づいたのだ。確認してみると、同じソースファイル内のサブルーチンのエントリポイントに気づいていなかったし、テストもしていなかった。案の定、私はそれを壊してしまっていた。 私はそれを修正し、日常は続いた。しかし、あの電話のことは今でも忘れていない。私はまだ完璧ではないが、頭の中でこだまするあの怒りの声が、それ以来長年にわたり、多くの同様の不注意なミスを犯すことから私を守ってくれたのだ。
この事例から私が導き出した格言は、「テストされていないコードは機能しない」です。
コードをテストしましょう。自分でバグを見つけましょう。他の人にバグを見つけさせないでください。怒鳴られるような事態は避けましょう！