PerlのWeb開発の初心者のためのTips

( -> プレゼンモード

目次

追記

感想いただきました。よい補足になっていると思うので、こちらも併せて。


Agenda


デバッグのしやすいコードを書く


デバッグのしやすいコードとは


デバッグしにくいコード - 1つの関数が巨大

sub main {
    my $result;

    # ...
    # 処理 A を何十行にもわたってする
    # ...

    # ...
    # 処理 B を何十行にもわたってする
    # ...

    # ...
    # 処理 C を何十行にもわたってする
    # ...

    return $result;
}

関数を切り分ける

sub func {
    do_A();

    do_B();

    do_C();

    return $result;
}

sub do_A { ... }
sub do_B { ... }
sub do_C { ... }

テストのしやすいコードを書こう

よくテストされた、ちいさなパーツをくみあわせて、ソフトウェアをつくるのがバグのすくないソフトウェアを短期間でくみたてるよい方法

tokuhiromさん

Web開発で疎結合なコードにするコツ


保守しやすいコードを書く

引数の順番で混乱しやすいサブルーチンをつくらない

sub send_mail {
    my ( $from, $to, $subject, $body, ... ) = @_;
    ...
}

send_mail( $arg1, $arg2, $arg3, $arg4, ... );

代わりに:引数に名前付きハッシュを使う

send_mail(
    from    => $from,
    to      => $to,
    subject => $subject,
    body    => $body,
    ...
);

sub send_mail {
    my ( %args ) = @_;
    my $from    = $args{from};
    my $to      = $args{to};
    my $subject = $args{subject};
    my $body    = $args{body};
    ...
}

ミスを想定した工夫を入れる

バリデーション

警告をだしてくれるのはまだいい方で、間違った値を黙ってそのまま使うというのが一番やっかいです。それくらいなら、初めからはっきりと「値が間違っている」といって例外を吐いてくれた方がデバッグしやすいのではないでしょうか。

Re: バリデーションはどの位置で必要か - Islands in the byte stream
use Data::Util qw(is_string);

sub validate {
    my $str = shift;
    die "Not a string: $_" unless is_string($str);
    ...
}

使う側のミスを想定した関数に

send_mail(
    form => $from, # <- Typo!!!!!!
    ...
);

sub send_mail {
    my ( %args ) = @_;
    my $from = $args{from}; #=> undef が代入される
    ...
}
sub send_mail {
    my ( %args ) = @_;
    my $from = delete $args{from};  # deleteを使う
    my $to   = delete $args{to};
    ...

    die "Unknown param: $_" foreach keys %args;
}

同じことを繰り返さない

車輪の再発明を避ける


使い方を調べる時間をなくす


同じ単語やコマンドを入力する時間を短縮する


ボトルネックの解消

文字化け

コンテキスト

正規表現

リファレンス


Print Debug Tips

Print デバッグは最後の手段

ときどき、いざ問題を解決せん、ということで、頭で考えて大体の当たりを付ける前に、突然デバッガーを起動して色々なところにブレークポイントを置いてみたり、プロファイラーを起動したり、ソースコード間を行ったり来たりしてディスプレイの前で腕を組んで首を傾げ、一向に開発が進まない、という人がいる。

もしこういうはまり方をしやすい人がいたら、その人に対するアドバイスとして、一度ツールを使うのをやめてみることを提案したい。

はまった時にまず最初に行うことは、ツールを立ち上げることではなく、「どの辺りに問題があるのか」について、頭で考えて当たりをつけることだ。そして、その関連箇所のソースコードを読んで処理内容を確認することだ。

プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ

Data::Dumper

データ構造のままDump

use Data::Dumper;
warn Dumeper($data);
# $VAR1 = {
#           'human' => 'Dan Moroboshi',
#           'transform' => 'glasses',
#           'power' => [
#                        'Emerium Beam',
#                        'Eye Slugger',
#                        'Wide Shot'
#                      ],
#           'name' => 'Ultra Seven'
#         };

Carp

use Carp qw(cluck confess);
confess例外
cluck警告に留める

Devel::SimpleTrace


おわりに:参考資料