他人よりまず自分を疑う – プログラマが知るべき97のこと

Developers — all of us! — often have trouble believing our own code is broken.

プログラマというものは(つまりわたしたちは)自分の書いたコードに何か誤りがあるとは、なかなか考えようとしない人種です。

It is just so improbable that, for once, it must be the compiler that’s broken.

現に問題が起きていても、それが自分のせいだと思うことは滅多になく、「きっとコンパイラのせいだろう」などと思ったりします。

Yet in truth it is very (very) unusual that code is broken by a bug in the compiler, interpreter, OS, app server, database, memory manager, or any other piece of system software.

しかし実際には、コンパイラやインタプリタ、OS、アプリケーションサーバ、データベース、メモリマネージャなど、システムソフトウェアのバグで問題が発生するということは、極めて稀なのです(ほぼないと言っていいでしょう)。

Yes, these bugs exist, but they are far less common than we might like to believe.

もちろんシステムソフトウェアにもバグはあるものですが、責任を押し付けたがる人が期待するよりは、はるかに少ないと言えます。

I once had a genuine problem with a compiler bug optimizing away a loop variable, but I have imagined my compiler or OS had a bug many more times.

私が「本当にコンパイラのバグが問題の原因だった」というけいけんをしたのはたった1度だけで、ループ変数の最適化に関わるバグでした。それよりも、コンパイラあるいはOSのバグのせいだとばかり考えて時間を無駄にした回数のほうがずっと多いのです。

I have wasted a lot of my time, support time, and management time in the process only to feel a little foolish each time it turned out to be my mistake after all.

自分の時間、サポート担当の時間、管理者の時間をさんざん無駄にした挙句、結果は自分のミスが原因だったと判明して力が抜けたということが何度もありました。

Assuming the tools are widely used, mature, and employed in various technology stacks, there is little reason to doubt the quality.

多くの人に使われているツール、「枯れた」ツール、様々なテクノロジスタックに採用されているツールは、必然的に品質が上がっています。つまり、何か問題が起きた時にこうしたツールの品質を疑ってもあまり意味が無いということです。

Of course, if the tool is an early release, or used by only a few people worldwide, or a piece of seldom downloaded, version 0.1, Open Source Software, there may be good reason to suspect the software.

もちろん、初期リリースや、世界中でも利用者が少ないツール、めったにダウンロードされないツール、バージョン0.1、オープンソースのソフトウェアなどであれば疑う意味はあるかもしれません。

(Equally, an alpha version of commercial software might be suspect.)

(商用ソフトウェアのαバージョンなども同様です)

Given how rare compiler bugs are, you are far better putting your time and energy into finding the error in your code than proving the compiler is wrong.

コンパイラにバグがほぼ無いのだとしたら、コンパイラの誤りを証明するよりも、自分のコードのバグを見つけることに時間とエネルギーを注いだほうがずっと良いということになります。自分の書いたコードを疑い、デバッグに関して一般に「すべき」と言われていることをやってみましょう。

All the usual debugging advice applies, so isolate the problem, stub out calls, surround it with tests;

具体的には、問題箇所を切り分け、呼び出し先をスタブに置き換え、テストを書いてみる、といったことをまず行います。

check calling conventions, shared libraries, and version numbers;

呼び出しの作法、共有ライブラリ、バージョン番号のチェックも忘れずに行いましょう。

explain it to someone else;

作業内容をチームの他のメンバーに説明してみましょう。

look out for stack corruption and variable type mismatches;

スタック破損や変数の型の不一致を見張りましょう。

try the code on different machines and different build configurations, such as debug and release.

マシンやビルド設定を変えて、例えばデバッグ用、リリース用両方の環境で実行してみましょう。

Question your own assumptions and the assumptions of others.

このとき重要なのは前提条件を考えることです。何を当然とみなすかは人によって違っています。自分と他人では違っているでしょう。

Tools from different vendors might have different assumptions built into them — so too might different tools from the same vendor.

たとえ同様のツールであっても、提供するベンダが違えば前提条件は違っているでしょうし、たとえ提供するベンダは同じでも、違うツールならば、やはり前提条件が違っていると考えられます。

When someone else is reporting a problem you cannot duplicate, go and see what they are doing.

問題発見の報告を受けたが、それを自分で再現できない場合には、報告者が実際にどういうことをしているのか、その現場を見るべきです。

They may be doing something you never thought of or are doing something in a different order.

ひょっとすると、あなたが想像もしなかったようなことをしている可能性があります。予想とは全く違った発想、違った順番で行動していることがあり得るのです。

As a personal rule if I have a bug I can’t pin down, and I’m starting to think it’s the compiler, then it’s time to look for stack corruption.

私は、何か問題が起きた時には必ず真っ先に自分の書いたコードのバグを疑うことにしています。自分のコードを徹底的に調べて、それでもバグが見つからなかった時、初めてコンパイラのバグを疑い、スタック汚染を調査します、

This is especially true if adding trace code makes the problem move around.

たとえば「トレースコードを加えてみたら、問題箇所があちこちいどうしていくのがわかった」という場合なら、自分のコード以外を疑ってもいいでしょう。

Multi-threaded problems are another source of bugs to turn hair gray and induce screaming at the machine.

マルチスレッドがらみの問題も厄介なバグの原因になりやすく、マシンの前で叫び声を上げたまま白髪になりかねません。

All the recommendations to favor simple code are multiplied when a system is multi-threaded.

「コードはできるだけシンプルにすべき」と常に言われますが、マルチスレッド環境においてこの言葉は何倍も重要です。

Debugging and unit tests cannot be relied on to find such bugs with any consistency, so simplicity of design is paramount.

スレッド間の整合性に関わるバグを、一般的なデバッグ作業やユニットテストで見つけ出すことは困難です。設計をシンプルにするということが何より大切になるのです。

So before you rush to blame the compiler, remember Sherlock Holmes’ advice, “Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth,” and prefer it to Dirk Gently’s, “Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth.”

システムに何か問題が起きて、それをコンパイラやOSのせいにしたくなった時は、シャーロック・ホームズの「完全にありえないことをすべて取り除いていけば、残ったものがいかに信じがたいものでも、事実に違いない」という言葉を思い出すといいでしょう。同じく探偵のダークジェントリーも「あり得ないことを全部排除して残ったものは、どんなに信じがたくても、間違いなく真実だ」と言っていますが、ホームズのほうが通りはいいでしょう。