スラッシュドット・ジャパン

Perl界隈で有名な人に、brian d foyという方がいます。Perlをやっている人
で知らない人はいないでしょう。
そのbrianが書いた文書で、
brian's Guide to Solving Any Perl Problem
というのがあるのですが、不思議に日本語訳がありません。その他の、例えば
ドイツ語や中国語訳はありますが。私は元来、世の中に多く見受けられる、何と
か日本語化プロジェクトというものに懐疑的でした。
と言うのは、本当にドキュメントを読もうとする人は英語であっても読むだろう
し、読まない人は、日本語訳があっても読まないだろうと思っているからです。
それなのに、何故わざわざ、日本語訳に汗水たらすのだ、という疑問を持って
います。しかしながら、他言語訳があるのに、日本語訳が無いのは、ちょっと
具合がよくないと思い、ここに訳を載せる気持ちになりました。

名称
brian's Guide to Solving Any Perl Problem
 
概要
このガイドに従って、健全さを保ちなさい。
 
記述
私のデバッギング哲学
私は、3つのことを信じている。
「個人的なことではない」
コードの作者を忘れなさい。貴方は自分が名人であると思っているかも知れない
が、どんな達人でも多くを間違えて来たのだ。
誰のコードも間違っている、つまり、私のコードも貴方のコードも間違っている。
それがいいことだと思いなさい。何か問題があれば、貴方は先ず、「私の変なコー
ドには何か間違いがある。」と考えるべきである。これは、Perlのせいにすべきで
ないことを意味する。個人的なことではないからだ。
貴方がやっていることを忘れなさい。貴方のしている方法がうまくいっているので
あれば、こんなものを読んではいないであろうが、忘れることは悪いことではない
のだ。まさに飛躍すべき時なのである。私達が経験してきたことだ。
 
「個人の責任」
貴方のスクリプトに問題があるのであれば、単に、それは貴方の問題である。自分
で解決するように、出来る限り努力すべきである。しかし、覚えておきなさい。
スクリプトが他の誰かのものであるなら、それは彼等の問題であることを。他人に
貴方の問題を投げる前に、自分でやり、最善の試行をせよ。このガイドにあること
をすべて本当にやり尽くし、それでも問題が解決しないのであれば、最善の試行を
やったのであるから、その時は他者に問題を投げる時である。
 
「貴方の方法を変えよ」
二度と問題が起きないようにフィクスせよ。問題はおそらく、貴方がコード
しているものが悪いのではなく、コードしている方法が悪いのであろう。楽
になるために、方法を変えなさい。Perlに問題ないのであろうから、Perlを
貴方に合わせるな。貴方をPerlに合わせよ。Perlは単なる言葉であり、慣
習ではない。
 
私の方法
「厳密性で、コンパイルしているか」
まだ厳密性を使用していないのであれば、即に使用しなさい。Perlの第一
人者達は、strictを使っている。それが、彼等に、別の問題の解決、新しい
物事の学習、CPANへの役立つモジュールのアップロードに時間を費やさ
せるが故に、彼等は第一人者なのである。
スクリプト内にstrictプラグマを使えば、厳密性をオンに出来る。
use strict;
 
Perlの-Mスイッチを使えば、コマンドラインで厳密性をオンに出来る。
perl -Mstrict script.pl
 
貴方は厳密性に困惑するかも知れないが、厳密性をオンにしたプログラミ
ングを数週間した後には、よりいいプログラムを書き、より少ない時間で単
純なエラーを追撃し、おそらくは、このガイドを必要としなくなるだろう。
 
「警告は何なのか？」
Perlは、疑問あるプログラム構築に多くの警告をするだろう。warningsを
オンにし、Perlに貴方を手伝わせるようにしなさい。
シェバング行でPerlの-wスイッチを使用出来る。
#!/usr/bin/perl -w
 
コマンドラインからwarningsをオンに出来る。
perl -w script.pl
 
すべての興味ある特色と共に、レキシカルwarningsを使用出来る。詳しく
はwarningsを見なさい。
use warnings;
 
もし、警告の意味が解らなければ、perldiag内のwarningsの詳細を見る
ことが出来るし、またはコード内に、diagnosticsプラグマを使用出来る。
use diagnostics;
 
「最初の問題を最初に解決せよ！」
エラーまたは警告のメッセージをPerlから受けた後、最初のメッセージをフ
ィックスし、それから、他にPerlがメッセージを発するかどうかを見なさい。
それらの他のメッセージが最初のメッセージの複合であるかも知れないか
らである。
 
「エラーメッセージが表示する行の前に位置するコードを見よ！」
Perlは、困った時点で（その前ではなく）警告を発する。Perlが困った時点
までに、問題が既に発生しているのであり、Perlが発する行は、実際は問
題の後のものである。警告されている行の位置の前の記述を見なさい。
 
「その値は、貴方が考えているものなのか？」
推測するな！　事前に想定していた値であるか検証せよ。一体全体、最高
のデバッガーは、printである。
print STDERR "The value is [$value]\n";
 
私は$valueをブレースで囲む。それで、先頭や最後尾にスペースや改行
を見ることが出来る。スカラーより以上のものが欲しければ、私は、データ
構造をプリントするためにData::Dumperを使う。
require Data::Dumper;
print STDERR "The hash is ", Data::Dumper::Dumper( %hash ), "\n";
 
値が想定していたものと異なるのであれば、数ステップを後戻りして、再度
やってみること！これを、その値が関係しない所まで繰り返しなさい！
 
Perlの-dスイッチを使えば、ビルトインデバッガーも使用出来る。
perl -d script.pl
 
ptkdb（グラフィックな、Tkベースなデバッガー)やKomodo (モジラベース
のActiveStateのPerl IDE) のような、他のデバッガーまたは開発環境も使
用出来る。
 
「関数を正しく使っているか？」
私は本当に長くPerlのプログラムをしているが、殆ど毎日perlfuncを見る。
ある事柄が覚えてられないし、時には、あまりの眠たさに、頭がはっきりせ
ず、sprintf()が何故スクリーンにプリントしないのか不思議に思うこともあ
るのである。
perldocコマンドと、その-fスイッチを使えば、見たい関数を調べることが
出来る。
perldoc -f function_name
 
モジュールを使っているなら、正しく使用しているか確認するために、ドキ
ュメントをチェックしなさい。perldocを使用して、そのモジュールのドキュ
メントをチェック出来る。
perldoc Module::Name
 
「正しい特殊変数を使っているか？」
再度、私はいつもperlvarを参照している。え～っと、"The Perl Pocket
Reference"を使うのがより便利なことが分かったので、実は本当では
ないが。
 
「正しいバージョンのモジュールか？」
あるモジュールは、バージョン間で振舞いが変わっている。想定している
バージョンなのか？　簡単なPerlワンライナーで、殆どのモジュールの
バージョンをチェック出来る。
perl -MModule::Name -le 'print Module::Name->VERSION';
 
http://www.perldoc.comやhttp://search.cpan.orgのように、オン
ラインで読むならば、ドキュメントでバージョンの違いに出くわすであろう。
 
「小さなテストケースを作ったことがあるか？」
何か新しいことをしている時や、特定のコードがおかしいと考える時、それ
を示す、短くて、動くプログラムを書きなさい。これは、考察の邪魔になるも
のを取り除く。小さなテストプログラムが、そのようにするであろうことをす
れば、問題はおそらく、そのコードには無い。そのプログラムが、するであ
ろうと貴方が考えていることをしなければ、おそらく、問題を見つけたことに
なる。
 
「動作環境をチェックしたか？」
いくつかの事は環境変数に依存する。環境変数が正しく設定されているこ
とを確認しているか？　プログラムが走る時、同じ環境であるか？　CGIプ
ログラムまたはcronジョブのためのプログラムは、インタラクティブシェル
での環境とは（特に違うマシンにおいて）違うものを見ているかも知れない
ことを覚えておきなさい。
Perlは環境を%ENVに収めている。それらの変数の一つが必要であれば、
たとえテストだけのためでも、存在してない時はデフォルトの値を設定せよ。
それでもトラブルがあるなら、環境変数を調査せよ。
require Data::Dumper;
print STDERR Data::Dumper::Dumper( \%ENV );
 
「Googleでチェックしたか？」
問題があれば、他の誰かも同じ問題を持ったかも知れない。他の誰かの一
人がusenetグループcomp.lang.perl.miscに投稿しているかどうか、
Google Groups (http://groups.google.com)をサーチせよ。usenet
において、質問をする人と、それに回答する人の差は、Google Groupsを
有効に使う技量である。
 
「アプリケーションのプロファイルを取ったか？」
プログラムの遅い部分を突止めたい時、そのプロファイルを取ったことがあ
るか？
Devel::SmallProfに重労働させよ。Devel::SmallProfは、コードの行を
Perlが実行する時間を計測すると共に、どれくらい時間がかかったか、素晴
らしいレポートをプリントする。
 
「どのテストが失敗しているのか？」
テストスイーツがあれば、どのテストが失敗しているのか？　各々のテストは
コードのごく一部分をたんに実行しているだけだから、エラーをすぐに突止め
ることが出来るはずである。
テストスイーツが無いなら、何故作らないのか？　小さなスクリプトがあれば、
または、これが一行そこらのスクリプトであっても、私はテストを書けとは言わ
ない。テストスクリプトから得られるものは、テストを書くことよりも何らかの利
便がある。Test::Harnessは、弁解の余地が無いほど、この作業を簡単にす
る。時間が無ければ、テスト無しのデバッグはもっと時間がかかるであろう。
MakeMakerは、結局モジュールだけのためのものではない。
 
「熊に話したか？」
声を出して、問題を説明せよ。実際の言葉にせよ。
２、３年、私は、殆どすべてのことを解決できるであろう、素晴らしいプログラマ
と仕事をした、喜ばしい経験がある。行き詰った時、彼のデスクへ出向き、問題
を説明したものだ。通常、「心配するな、解決したよ。」という三言以外のことに
はならなかった。彼は殆どミスもしなかった。
貴方が、このことをもっと必要としているのであろうから、同僚を困らせないため
に、Perlセラピストとして、豪華な玩具をお勧めする。私は、デスクに小さな熊を
置いており、その熊に問題を説明する。私が独り言を喋っている時、ガールフレ
ンドは見向きもしない。
 
「問題は、紙の上で違って見えるか？」
通常、コンピュータースクリーンで始めているが、違ったメディアでは、事柄が
違った、新しい方法に見えるかも知れない。プログラムを紙にプリントしてみよ
う。
 
「Jon Stewartの毎日のショーを見たか？」
真面目な話。貴方がJon Stewartを嫌いなら、別の人を選んでもいい。
休憩しよう。しばらく問題を忘れ、心をリラックスさせよう。後で、問題に戻り、
解決が本当にすぐに見つかるかも知れない。
 
「自分のエゴを抑えているか？」
まだ、全然解決してないなら、それは心理的な問題かも知れない。感情的にコード
の一部分にアタックしているのであろうが、それでは物事は変えられない。貴方は
自分以外の誰かが間違っているとでも思っているのかも知れない。そうなら、バグ
の最もな根源を真面目に考えていないことになる。つまり、貴方自身だ。すべての
ことに虚心になりなさい。全てを検証しなさい。