パスワードを忘れた? アカウント作成
64933 journal

taro-nishinoの日記: brian's Guide to Solving Any Perl Problem

日記 by taro-nishino

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は、結局モジュールだけのためのものではない。

「熊に話したか?」
声を出して、問題を説明せよ。実際の言葉にせよ。
2、3年、私は、殆どすべてのことを解決できるであろう、素晴らしいプログラマと仕事をした、喜ばしい経験がある。行き詰った時、彼のデスクへ出向き、問題を説明したものだ。通常、「心配するな、解決したよ。」という三言以外のことにはならなかった。彼は殆どミスもしなかった。
貴方が、このことをもっと必要としているのであろうから、同僚を困らせないために、Perlセラピストとして、豪華な玩具をお勧めする。私は、デスクに小さな熊を置いており、その熊に問題を説明する。私が独り言を喋っている時、ガールフレンドは見向きもしない。

「問題は、紙の上で違って見えるか?」
通常、コンピュータースクリーンで始めているが、違ったメディアでは、事柄が違った、新しい方法に見えるかも知れない。プログラムを紙にプリントしてみよう。

「Jon Stewartの毎日のショーを見たか?」
真面目な話。貴方がJon Stewartを嫌いなら、別の人を選んでもいい。
休憩しよう。しばらく問題を忘れ、心をリラックスさせよう。後で、問題に戻り、解決が本当にすぐに見つかるかも知れない。

「自分のエゴを抑えているか?」
まだ、全然解決してないなら、それは心理的な問題かも知れない。感情的にコードの一部分にアタックしているのであろうが、それでは物事は変えられない。貴方は自分以外の誰かが間違っているとでも思っているのかも知れない。そうなら、バグの最もな根源を真面目に考えていないことになる。つまり、貴方自身だ。すべてのことに虚心になりなさい。全てを検証しなさい。

この議論は、taro-nishino (32033)によって ログインユーザだけとして作成されたが、今となっては 新たにコメントを付けることはできません。
typodupeerror

※ただしPHPを除く -- あるAdmin

読み込み中...