竹迫 良範（たけさこ よしのり）
Shibuya Perl Mongers 2代目リーダーにして，ppencodeの作者。広島市立大学卒業後，大企業向けmod_perl製品の開発に従事。2005年よりサイボウズ・ラボ株式会社に入社。LL Ringに参戦。Namazu for Win32，Plagger，Ajajaのコミッターでもある。

　CGIといえばPerl。そんな風にいわれていた時期もありました。レンタル・サーバーのCGIで手軽にPerlが使えたこともあり，ちょっとした掲示板のスクリプトやアクセス・カウンタなど，CGIプログラムの多くがPerlで書かれていました。このためPerlが爆発的に普及したのです。Perlは日本のインターネット黎明期を支えたプログラミング言語として，広くその名が知られています。

　その半面，Perlで書かれたプログラムの保守性に悩む声も聞かれるようになりました。事実，Perlのプログラミング経験が少ない人にとって，他人の書いたPerlプログラムは大変読みにくいものでした。それゆえ「Perlは汚いプログラミング言語だから駄目なんだ」と揶揄（やゆ）される場面も多くなりました。

　しかし，よく考えてみてください。「匿名掲示板に汚い書き込みが多いから，インターネット全体が悪だ」という主張をたまに見かけますが，はたしてそれは正しい指摘でしょうか。

　筆者は，今のPerlもそれと同じ状況にあるのではないかと考えます。日本語は，優れた文学作品を書くことにも使えるし，罵倒の言葉を浴びせることにも使えます。ツールや言語を正しく使うかどうかは，結局それを使う人の側の問題であることが多いのです（図1）。

図1●ツールや言語を正しく使うかどうかは，結局それを使う人の側の問題である
図1●ツールや言語を正しく使うかどうかは，結局それを使う人の側の問題である

　そこでこの記事では，昔の古いPerl/CGIプログラムの書き方を卒業して，Perlで今どきのWebプログラミングを身に付ける方法について解説したいと思います。まず，Perlの正しいコーディング・スタイルを解説し，次に，CGIの歴史を振り返りながら現在お勧めの書き方を紹介したいと思います。

コーディング・スタイル
読みやすい/使いやすい プログラムを書く

　多くのプログラムは，書くのにかかる時間よりも，他人に読まれる期間のほうが圧倒的に長いものです。自分の書いたPerlプログラムの可読性を高めるためにはどうすればよいのでしょうか。

　その答えの一つが，Damian Conway氏の著書「Perlベストプラクティス」（オライリー・ジャパン発行）にあります。Perlでプログラミングを行う際の200のベスト・プラクティスが著者の豊富な実体験を基にまとめられており，とても参考になります。これからPerlを勉強しようとする人，今までPerlを使っていた人の両方にお勧めできる本です。

　Perlの有名なスローガンにTMTOWTDI＊1という言葉があるのを聞いたことがある人がいるかもしれません。「There's morethan one way to do it.」の略で「そのやり方は一つじゃないよ」という意味です。Perlは一つの問題を解決するのに複数の方法を提供しており，その中で自分の知っているやり方で書けばよいという文化を尊重しています。

　しかし， T M T O W T D I は両刃の剣です。たしかにTMTOWTDIはユーザーの自由度を高めます。一方，企業でのソフトウエア開発やチームによるオープンソース・ソフトウエア開発など，開発に複数のプログラマが携わる場合には，各自が好き勝手なやり方でコードを書いていては収拾がつかなくなります。この際に威力を発揮するのが，ベスト・プラクティスが示す正しいコーディング標準です。

何はなくともCPANは必須

　現代のPerlプログラミングの大前提になるのがCPAN（Comprehensive Perl Archive Network，公式サイトはhttp://www.cpan.org/）です。「車輪の再発明」（英語ではReinventing the wheel）という言葉を聞いたことはありませんか。車輪のように一般的に広く使われている技術・解法を利用せず，新たな付加価値がないものを自分で一から作ってしまうことを皮肉る言葉です。CPANは，Perlで車輪の再発明を避けるための仕組みです。PerlプログラマはCPANに登録されているモジュールを積極的に活用することで，新たなPerlモジュールを自分で再発明することなく，目的のプログラムを少ない労力で開発できます。

　1995年にCPANのサイトが公開されてから，すでに10年以上が経過しています。現在では，5000人以上のプログラマが開発した1万個以上のモジュールがCPANのサイトで公開されています。何か新しいPerlのモジュールを作ろうと思ったら，すでにCPANに似たようなライブラリが存在していないかどうか確かめる習慣を付けるとよいでしょう（カコミ記事「CPANの使い方」を参照）。

正しいやり方はモジュール作成で学ぶ

　では，Perlの正しいコーディング・スタイルについて解説しましょう。この記事では，Perlモジュールの作成を通してコーディング・スタイルを学んでいきます。なぜなら，Perlで今どきのWebプログラミングを行おうと思えば，モジュール（クラス）の利用と作成は欠かせないからです。現代のソフトウエア・エンジニアリングでは，テスト，実装，ドキュメンテーション，パッケージングの一連の開発サイクルは必須です。Perlには，この開発サイクルを回しながらモジュールを作成するためのフレームワークがあらかじめ用意されています。

　CGIのテストは骨が折れるものです。人がブラウザから様々な入力を試してテストを行うのは限界があります。このため，ブラウザの自動テストを行うJavaScriptフレームワークが注目を集めています（Part4「テストを自動化する注目のツールSelenium」を参照）。ただ，プログラミング・レベルでのテストが不要になるわけではありません。この記事ではPerlモジュールの単体テストを徹底することで品質を高めるアプローチを紹介します。Perlモジュールの自動テストはとても簡単です。

　実際にPerlモジュールを一から作る方法について，順を追って見ていきましょう。

(1)Module::Starterをインストール

　Perlのモジュールを作る場合，以前はh2xsコマンドでモジュールのテンプレートを作る方法が一般的でした。しかし，現在ではh2xsよりもモダンなModule::Starterを使う方法が推奨されています。

　まずは，Perlベストプラクティスに準拠したモジュールのひな型を作る「Module::Starter::PBP」をインストールします。

$ cpan -i Module::Starter::PBP

　Module::Starter::PBPのインストールの過程で，動作に必要なversion.pmやModule::Starterなどのモジュールなどが自動的にインストールされます。Windowsの場合は，環境変数HOMEとして「C:/home/takesako」といったホーム・ディレクトリのパスを設定しておきます。

　Module::Starter::PBPのインストールが終わったら，図2のようにセットアップを行います。すると，自分のホーム・ディレクトリ直下に.module-starterフォルダが作成され，その中に設定ファイル（リスト1）が作成されます。また，テンプレート・フォルダであるPBPが作成され，コンソールにメッセージが出力されます。この際に表示されたファイルを修正することで，新規モジュール作成時のテンプレートをカスタマイズできます。

図2●Module::Starter::PBPのセットアップ
図2●Module::Starter::PBPのセットアップ 

author: Yoshinori TAKESAKO
email: takesako@shibuya.pm.org
builder: ExtUtils::MakeMaker Module::Build
plugins: Module::Starter::PBP
template_dir: C:/home/takesako/.module-starter/PBP
リスト1●$HOME/.module-starterフォルダに作成されるconfigファイルの例

(2)Perlモジュールのひな型を作成

　ここでは，サンプルとして厄年を計算するPerlモジュールMy::Yakudoshiを作成することにします。適当な作業ディレクトリでmodule-starterのコマンドを実行してください。

$ module-starter --module=My::Yakudoshi

　すると，--module=で指定したモジュール名をベースにMy-Yakudoshiフォルダが作成され，リスト2に示すファイル群が自動的に作成されます。これらのファイルをベースにモジュールの実装を書いていきます。

My-Yakudoshi/.cvsignore
My-Yakudoshi/Build.PL
My-Yakudoshi/Changes
My-Yakudoshi/Makefile.PL
My-Yakudoshi/MANIFEST
My-Yakudoshi/README
My-Yakudoshi/lib/My/Module.pm
My-Yakudoshi/t/00.load.t
My-Yakudoshi/t/perlcritic.t
My-Yakudoshi/t/pod-coverage.t
My-Yakudoshi/t/pod.t
リスト2●module-starterのコマンドを実行したときに生成されるファイル群

(3)ビルドのテスト

　まずは，以下のコマンドを実行して，このひな型のモジュールが正常にビルドできるかどうかを確認します。

$ cd My-Yakudoshi
$ perl Build.PL
$ perl Build
$ perl Build test

　Build.PLは，外部のmakeコマンドに依存しないピュアなPerlの環境でモジュールをビルドできる比較的新しいインストール方式です。Module::Build方式と呼ばれています＊2。

　もしperl Build test実行時にエラーが出る場合は，以下のように足りないCPANモジュールをインストールしてください。

$ cpan -i Test::Pod::Coverage
$ cpan -i Test::Perl::Critic

　依存している数十個のCPANモジュールも一緒にインストールされます（WindowsのActivePerlの場合は事前に「ppm install Clone」を実行しておく必要があります）。