脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック

12章トラブルシューティング

プロフェッショナルなソフトウェア開発は、機能開発だけではありません。会議、時間レポート、コンプライアンス活動、そして欠陥対応もあります。

エラーや問題はいつものことです。コンパイルが通らない、想定どおりにソフトウェアが動かない、動作が遅すぎる、などなどです。

問題解決がうまくなれば、もっと生産的に活動できます。トラブルシューティングのスキルは、「個人の経験にもとづく移ろいやすいもの[4]」かもしれませんが、使えるテクニックは存在します。

本章ではそのようなテクニックをいくつか紹介します。

12.1　理解

私の思いつくいちばんのアドバイスはこれです。

何が起こっているかの理解に努めよ。

何かが動かない理由がわからなければ†1、まず理由を理解するのが優先事項です。「偶発的プログラミング[50]」はもう見飽きました。たくさんコードを書き殴って、どれが動くのかを確かめるというものです。コードが動いてそうなら、開発者は次のタスクに進んでしまいます。コードが動く理由を理解していないので、動かない理由も本当に理解できないのです。

[†1] なんで動いているのかわからない場合も同じです。

コードを最初から理解できていれば、トラブルシューティングも簡単になります。

12.1.1　科学的手法

問題が起きると、ほとんどの人はすぐにトラブルシューティングモードに飛び込みます。問題にすぐに取りかかりたいのです。偶発的プログラミング[50]をする人たちにとって、問題に取りかかることは、以前同じような問題でうまくいったやり方を手当たり次第に試すことです。最初の呪文がうまくいかなければ、次の呪文を試すのです。サービスを再起動したり、コンピューターを再起動したり、管理者権限でツールを動かしたり、コードを少し変えてみたり、理解していない手順をやってみたりします。問題が消えたように見えたら対応は完了です。理由を理解しようとはしません ...