質の高い Perl アプリケーションを書くために

概要
----

動的型付き言語であり中でも自由度の高い Perl だが、それでもコードの堅牢性をなるべく確保しできる範囲で質を上げる方法を考えてみようというお話。アプリケーションを構築する際にある程度実用的だと思われる手法のみまとめ、便利だけれども超変態的なモジュールなどは外している。

*注意* 個人的な考え方・手法のメモに過ぎないので、すべてをそのまま導入するのはキケンです。まずは読み物としてどうぞ。中級者向け。

なお、Perl に興味ある方には [Perl 入学式](http://www.perl-entrance.org) という有志の入門者向け定期イベントがあります。

アサーション（表明）を活用する
-------------------------

他の（特に静的型付き）言語ではよく言及されるのに Perl で話題になることはあまりない、アサーション。堅牢なプログラムを書くには欠かせない道具で、端的にはプログラムに埋め込む小さなテストと言える。`Carp::Assert` モジュールを使う。

`assert()` の中に、結果が真となる条件を記述する。この場合なら、「`$x` は 100 より大きい（はず）」と表明したことになる。なお後ろに続くメッセージ文字列はオプションなのでつけなくてもよい。

```pl
use Carp::Assert;

my $x = 42;
assert( $x > 100, "x must be larger than 100" );
```

このように書くと、もし `$x` が 100 以下なら実行時にこの行で例外が発生する。具体的にはあらかじめ指定したメッセージとともに `Carp::confess()` が呼ばれプログラムが停止する。

```:stderr
Assertion (x must be larger than 100) failed!
    ....
    Carp::Assert::assert('', 'x must be larger than 100') called at ./assert.pl line 15
```

つまり、「こうあるべき」という「状態/条件」をあからじめ「表明」しておくことで、実行時に**予期しない状態になっていることに気付く**ことができる（プログラムは止まるが）。

通常は、開発中はアサーションをオンにして意図しない動作を検知するのに役立て、本番系では環境変数 `PERL_NDEBUG` をセットしてアサーションをオフにする。すると`assert()` 内に書いたコードは実行されないので、速度面でのペナルティも発生しない。

	PERL_NDEBUG=1 ./prog.pl

アサーションの仕組み自体は単純だが、「副作用を起こすようなコードを指定しない」を徹底しないと思わぬ罠にはまるので注意すること。つまり、以下の例で `init_something()` が（正しく動けば）真を返すからといって次のようなコードを書いてはならない：

```pl
assert( $obj->init_something );  # Bad!
```

`PERL_NDEBUG` に真をセットして実行すると `init_something()` メソッドは決して呼ばれない。それに気付かず本番系に投入すると痛い目に遭うので、あくまでも「神の視点でこっそり値を覗き見」るだけにすること。

ほかにもいくつか便利な書き方がある。２つの値を比較するだけなら `should()` のほうがよい。`affirm()` を使えば複数行にわたる複雑なアサーションも記述もできる。

```pl
should( $this, $that );
shouldnt( $this, $shouldntbe );

affirm {
	my @cards = @{ $customer->credit_cards };
	$cards[0]->is_active;    # 最後の式が返す真偽値で成否判定
};
```

また、ドキュメントを見ると `if DEBUG` があちこちに出てくるが基本的にアサーションのオンオフは環境変数を使ったほうがよいだろう。`Carp::Assert::More` という便利ヘルパーモジュールもある。


不要な変数をクリーンアップする
-------------------------

`Test::Vars` は、コードのなかで定義したはいいものの一度も使用されず「浮いて」しまっている変数を教えてくれる。次のようなケースをきっちり拾ってくれるのでとてもありがたい。未使用の変数があることで：

* 実装漏れに気付ける（あとで実装するつもりだったのに忘れていた、など）
* コーディングミスに気付ける（コピペでコードを移植して改変した時に変数名を間違えた、など）

```pl:t/vars.t
use Test::Vars;

all_vars_ok(
	ignore_vars => [ qw($class) ],
);

done_testing;
```

基本的に CPAN モジュール作者のためのモジュールのようなので `all_vars_ok()` を使う場合には `MANIFEST` ファイルが必要（`vars_ok()` を使えばファイル指定もできる）。とりあえず適当に用意してからテストを実行する。

	perl -MExtUtils::Manifest -e 'ExtUtils::Manifest::mkmanifest()'
	prove -v t/vars.t

```plain:stderr
# $total is used once in &Foo::calc at lib/Foo.pm line 27
```

ただし、現時点ではサブルーチンリファレンスの中を精査することはできないようだ。これは例えば `Moose` 環境で `after` や `override` などのメソッドモディファイアを積極的に使っている場合に特に問題となる。

```pl
after 'run' => sub {
	my $self = shift;
	...
	my $p = 10;    # 検出できない
	return;
};
```

このように環境によっては効果は限定的だがプログラム的に検出できるのはじつに強力で頼もしい。作者は gfx 氏。


メトリクスを計測する
-----------------

`Test::Perl::Metrics::Lite` を使えばメトリクスに基づいたテストができる。簡単に言うと、複雑過ぎる（＝長すぎる）サブルーチンがあれば教えてくれる。コードを副作用のない小さなサブルーチン/メソッドに分割して管理（divide and conquer）する習慣をつけるのに有用だ。

```pl:t/metrics.t
use Test::Perl::Metrics::Lite -mccabe_complexity => 25, -loc => 100;
all_metrics_ok();
```

どの程度の `complexity` が妥当かは最終的には好みによると思うが、30 あたりから始めるとよい。なお `Test::Perl::Metrics::Simple` という同等モジュールもあるが、ひとまずこちらを推しておく。

既存のプロジェクトに放り込むと（たいていは）修正点が多くて大変なので、新規プロジェクトから徐々に導入することをお勧めする。


メソッド引数の型をチェックする
-------------------------

`Smart::Args` を使うと、`Moose` 的な型を元にサブルーチン/メソッド引数の型チェックができる。

```pl
use Smart::Args;

sub calc {
	args my $self,
		 my $p => { isa => 'Int', optional => 1 };
	...
}
```

`Moose` と書式を共通化できるので見通しがよい。作者は tokuhirom 先生。内部実装として `Mouse` を利用しているところを `Type::Tiny` など汎用性を高めてもらえれば実用したい。


autobox を使う
-------------

`autobox` モジュールはブラックマジック臭が漂うからか敬遠するひともいるが、思考の流れのままに処理を書けるのはコーディングミスを減らすチャンスにつながる。

```pl
use autobox::Core;

# 伝統的な書き方は、右からコードを追わないといけない
say join ', ', grep { $_ > 10 } map { $_ * 2 } 1 .. 10;

# autobox による自然な流れ
1->to(10)->map( sub { $_ * 2 } )->grep( sub { $_ > 10 } )->join(', ')->say;
```

ちなみにこういった方向性で perl そのものを拡張する [perl5i](http://search.cpan.org/~mschwern/perl5i/) というプロジェクトもある。`Moose` 環境下なら `Moose::Autobox` をどうぞ。

変数をイミュータブル（不変）にする
----------------------------

オブジェクトのフィールドならひとまず `Moose` を使えば済む。

```pl
has 'timeout' => (
	is => 'ro',    # readonly
	isa => 'Int',
	default => 15,
);
```

加えてメソッド内で一時的に使う変数もイミュータブルにできれば、関数型言語的アプローチを自らに強制できるので、うまく使えば状態管理が明快になりバグを減らせると期待できる。

`Data::Lock` を使えばあとから変更できない変数を定義できる。次の例では、10 を代入しようとすると実行時エラーとなる。

```pl
use Data::Lock qw(dlock);

dlock my $sv = 42;
$sv = 10;    # 再代入不可！
```

```:stderr
Modification of a read-only value attempted at ./dlock.pl line 15.
```

`Readonly` モジュールを含め類似モジュールはいくつかある。`Data::Lock` は XS で内部のフラグを立てる実装なので実行時の速度ペナルティはほぼ無視できる。また `Readonly` モジュールと比べるとわずかだが簡潔に書ける上に、オブジェクトごとイミュータブルにできる点もおもしろい（pod 参照）。ただし対象はリファレンスを含むスカラー値のみ。

#### Attribute::Constant

`Data::Lock` に同梱される `Attribute::Constant` を使うと生 Array/Hash にも対応できる。

```pl
my @av : Constant( value1, value2, ... );
my %hv : Constant( key => value, key => value, ... );
```

ただし上記のように「生の」値を渡す必要があり、あとからロックすることはできない。

```pl
my @array = 1 .. 10;
my @av : Constant( @array );    # 空になってしまう
```

ともに作者はハッカー/ブロガーとして有名な弾氏だが、実験的実装の意味合いが強そうなので本番系での使用を検討する際には吟味したほうがいいかもしれない。

真偽値型を導入する
---------------

`boolean` で真偽値型を Perl にも。

```pl
use boolean;

my $face_is_handsome = true;
do &something if isTrue($guess);
```

何よりコードが読みやすくなるし、「Perl には true/false が無いんだぜ」などと言われなくなる。作者は重鎮 Ingy döt Net 氏。

私も昔は利用していたが今は利用していない。ほとんどの場合は問題ないが、たとえば `Text::Xslate` などのテンプレートエンジンに true/false 値（実体はオブジェクト）をそのまま渡して制御構文の判定値として使うと動作がおかしくなることがあったため。標準でない型を常用するのはそれなりにリスクがある。

集合型を導入する
--------------

`Set::Object` で集合型を Perl にも。

```pl
use Set::Object qw(set);

my $set = set();
$set->insert( qw(apple orange banana) );

$union          = $set1 + $set2;
$intersection   = $set1 * $set2;
$difference     = $set1 - $set2;
$symmetric_diff = $set1 % $set2;
```

集合型とは一意な値の集まりで、その要素が重複していないことが保障される入れ物。配列と違い順序はない。たまに Perl で配列（同士）を `uniq` したり `union` するにはという FAQ を見かけるが、集合型を使うとプログラムの見通しがよくなる。

XS で実装されているので高速だがスレッドセーフではない。`MooseX::Types::Set::Object` もある。

サブルーチンリファレンスに名前を付ける
-------------------------------

`Sub::Name` を使ってサブルーチンリファレンスに名前を付けると、例外が発生した場所を特定しやすくなる。

通常だと、次のようにどれも `__ANON__` と表示され区別がつかない。

```pl
use Carp;

my $foo = sub { croak "oh!" };
my $bar = sub { $foo->() };
$bar->();
```

```:stderr
oh! at ./sub.pl line 37.
	main::__ANON__() called at ./sub.pl line 38
	main::__ANON__() called at ./sub.pl line 40
```

そこで `Sub::Name` を使うと、スタックトレースに固有の名前を表示できるので階層が深い場合にデバッグしやすくなる。

```pl
use Carp;
use Sub::Name;

my $foo = subname foo => sub { croak "oh!" };
my $bar = subname bar => sub { $foo->() };
$bar->();
```

```:stderr
oh! at ./sub.pl line 35.
	main::foo() called at ./sub.pl line 36
	main::bar() called at ./sub.pl line 37
```

コードそのものは少し見にくくなるので、ここぞという時にのみ使うのがよさそうだ。


コメント行をデバッグに活用する
-------------------------

`Smart::Comments` を使えば、コメント行を拡張してデバッグメッセージを埋め込んだり進行状況を表示したりいろいろできる。直接コードの質に影響するわけではないが、うまく使えば心理的な負担を下げることができるかもしれない。

```pl
use Smart::Comments;

### got: $var

for (my $i=0; $i<$MAX_INT; $i++) {   ### Working===[%]     done
	do_something_expensive_with($i);
}
```

まとめ
-----

* Perl も少しなら他言語っぽく拡張できる。
* 自分のスタイルに合わせていくつかの手法を導入できれば、コード品質を向上できるかもしれない。