# 目次
# はじめに
以下の記事は,オライリージャパン社から出版された
『プログラマが知るべき97のこと』
の中から1つのエッセイを選び,
そのエッセイを,クリエイティブコモンズ3.0の条件の元で転載したものです.
Creative Commons ― 表示 3.0 アメリカ合衆国 ― CC BY 3.0
もし,他のエッセイを読みたい場合には,
記事末のリンクを辿るか,
以下のリンク先のTwitterアカウントのつぶやきからお探し下さい.
Twitter Account: 97 Things Bot
9. 他人よりまず自分を疑う アラン・ケリー(Allan Kelly):『プログラマが知るべき97のこと』
プログラマというものは,
つまり私達は,
自分が書いたコードに何か誤りがあるとは,
なかなか考えようとはしない人種です.
現に問題が起きても,
それが自分のせいだとは思うことは滅多に無く,
「きっとコンパイラのせいだろう」
などと思ったりします.
しかし,実際には,
コンパラやインタプリタ,OS,アプリケーションサーバ,
データベース,メモリマネージャなど,
システムソフトウェアのバクで問題が発生するということは,
極めて稀なのです.
(ほぼ無いと言ってもいいでしょう)
もちろんシステムソフトウェアにもバグはあるものですが,
責任を押し付けたがる人が期待するよりは,
はるかに少ないと言えます.
私が「本当にコンパイラのバグが問題の原因だった」
という経験をしたのはたった一度だけで,
ループ変数の最適化に関わるバグでした.
それよりも,コンパイラあるいはOSのバグのせいだとばかり考えて,
時間を無駄にした回数の方がずっと多いのです.
自分の時間,サポート担当の時間,管理者の時間を散々無駄にした挙句,
結局は自分のミスが原因だったと判明して
力が抜けたということが何度もありました.
多くの人に使われているツール,
「枯れたツール」,
様々なテクノロジスタックに採用されているツールは,
必然的に品質が上がっています.
つまり,
何か問題が起きた時にこうしたツールの品質を疑っても
あまり意味がないということです.
もちろん,初期リリースや,
世界中でも利用者数が少ないツール,
滅多にダウンロードされないツール,
バージョン0.1,
オープンソースソフトウェアなどであれば,
疑う意味はあるかもしれません.
(商用ソフトウェアのαバージョンなども同様です)
コンパイラにバグがほぼ無いのだとしたら,
コンパイラの誤りを証明するよりも,
自分のコードのバグを見つけることに
時間とエネルギーを注いだ方が
ずっと良いということになります.
自分の書いたコードを疑い,
デバックに関して,
一般的に「すべき」と言われていることをやってみましょう.
具体的には,
問題箇所を切り分け,
呼び出し先をスタブ*1に置き換え,
テストを書いてみる,
といったことをまず行います.
呼び出しの作法,
共有ライブラリ,
バージョン番号のチェックも忘れずに行いましょう.
作業内容をチームの他のメンバに説明してみましょう.
スタック破損や変数の型の不一致を見張りましょう.
マシンやビルド設定を変えて,
例えばデバック用,リリース用両方の環境で実行してみましょう.
この時重要なのは,
前提条件を考えることです.
何を当然とみなすかは人によって違っています.
自分と他人では違っているでしょう.
たとえ同様のツールであっても,
提供するベンダが違えば前提条件は違っているでしょうし,
たとえ提供するベンダは同じでも違うツールならば,
やはり前提条件が違っていると考えられます.
問題発見の報告を受けたが,
それを自分で再現できない場合には,
報告者が実際にどういうことをしているのか,
その現場を見るべきです.
ひょっとすると,
あなたが想像もしなかったことをしている可能性があります.
予想とは全く違った発想,
違った順番で行動していることがあり得るのです.
私は,
何か問題が起きた時には必ず真っ先に
自分の書いたコードのバグを疑うことにしています.
自分のコードを徹底的に調べて,
それでもバグが見つからなかった時,
初めてコンパイラのバグを疑い,
スタック汚染を調査します.
例えば,
「トレースコードを加えてみたら,
問題箇所があちこち移動していくのがわかった」
という場合なら,
自分のコード以外を疑ってもいいでしょう.
マルチスレッド絡みの問題も厄介なバグの原因になりやすく,
マシンの前で叫び声を上げたまま白髪になりかねません.
「コードはできるだけシンプルにすべき」
と常に言われますが,
マルチスレッド環境においてこの言葉は何倍も重要です.
スレッド間の整合性に関わるバグを,
一般的なデバック作業やユニットテストで見つけ出すことは困難です.
設計をシンプルにするということが,
何より大切になるのです.
システムに何か問題が起きて,
それをコンパイラやOSのせいにしたくなった時は,
シャーロック・ホームズの
「完全にありえないことをすべて取り除いていけば,
残ったものは,如何に信じがたいものでも,
事実に違いない」
という言葉を思い出すといいでしょう.
集英社
売り上げランキング: 813645
同じく探偵のダーク・ジェントリー*2も
「ありえないことを全部排除して残ったものは,
どんなに信じがたいものでも,
間違いなく真実だ」
と言っていますが,
ホームズの方が通りはいいでしょう.
■著者データ
[アラン・ケリー (Allan Kelly)]
豊富な経験を持つソフトウェアエンジニア.
現在は主としてマネージメント関係の仕事に携わり,
ソフトウェア開発チームのパフォーマンス向上,
アジャイルソフトウェア開発の導入などを支援する.
ロンドンを拠点に,
大小様々な企業に対し,
コーチング,トレーニング,コンサルティングなども行なっている.
定期刊行物やカンファレンスへの寄稿も多く,
『ソフトウェア開発を変革するーもっと俊敏になるために』
共立出版
売り上げランキング: 748898
などの著作がある.
コンピューティングの理学士号とマネージメントのMBAを持つ.
現在は,ソフトウェア企業向けにビジネス戦略パターンの本を執筆中.
詳しくは,サイトを参照のこと.
allan kelly - agile software development consultant
関連記事
1.分別のある行動 Seb Rose:『プログラマが知るべき97のこと』 - MY ENIGMA
2.関数プログラミングを学ぶことの重要性 Edward Garson:『プログラマが知るべき97のこと』 - MY ENIGMA
3.ユーザが何をするかを観察する (あなたはユーザではない) Giles Colborne:『プログラマが知るべき97のこと』 - MY ENIGMA
4.コーディング規約を自動化する Filip van Laenen:『プログラマが知るべき97のこと』 - MY ENIGMA
5.美はシンプルさに宿る Jorn Olmheim:『プログラマが知るべき97のこと』 - MY ENIGMA
6.リファクタリングの際に注意すべきこと Rajith Attapattu:『プログラマが知るべき97のこと』 - MY ENIGMA
7.共有は慎重に Udi Dahan:『プログラマが知るべき97のこと』 - MY ENIGMA
8. ボーイスカウト・ルール Robert C. Martin:『プログラマが知るべき97のこと』 - MY ENIGMA
MyEnigma Supporters
もしこの記事が参考になり、
ブログをサポートしたいと思われた方は、
こちらからよろしくお願いします。
*1:スタブ (stub) とは、複数のモジュールからなるコンピュータプログラムの検査(ソフトウェアテスト)時における下位モジュールの代用品のこと.元々の意味は、切り株のこと.呼び出す側(上位)のモジュールを検査する場合に、呼び出される側(下位)の部品モジュールが未完成であることがある.このとき、呼び出される側の部品モジュールの代用とする仮のモジュールを、「スタブ」と呼ぶ.スタブモジュールは設計仕様に定義されている全ての関数を実装してあるが、関数内部は正規の動作をする事無く適当な定数を返すというような作りになっている事が多い。スタブ - Wikipedia
*2:『ダーク・ジェントリー』とは『銀河ヒッチハイク・ガイド』で有名なイギリスのSF作家、ダグラス・アダムズの小説のタイトルである。ダーク・ジェントリー