ホーム > PHP > 書評「PHP逆引きレシピ」

書評「PHP逆引きレシピ」

  • 2009 年 8 月 10 日 18:02
  • PHP

お久しぶりです。
もうすっかり夏ですね。僕といえばバリ島で結婚式を挙げてきました。楽しかったです。
これのおかげで割りとハードな毎日を送っているためブログの更新などは余りできませんが、忘れないであげて下さい。

さて、著者の鈴木憲治様よりPHP逆引きレシピをご献本頂きました。ありがとうございます。

以下書評。

「直接的な関数の組み合わせでプログラムを”組み立てる”」という PHP のスタンスにおいて最も重要なのは「目的に応じた答えを知る事」であると言えます。そのような視点から見ると本書はこれ以上ないほどに”実践的”です。
目的に対する方法を引く事ができ、その方法に関連する他の方法に対してもインデクシングされているばかりか、PHP バージョンごとの差異やメジャーなレンタルサーバに依存する問題なども詳解されているため、本書とパソコンと「ウェブアプリを作りたい」という目的意識さえあれば作れてしまう程です。

それだけに留まらずセキュリティに関しての広範な対策方法や、PHP で書かれたオープンソースソフトウェアの基本的な利用法も解説されており、さらには PDF、画像、グラフなどの生成方法といった「PHP をベースとしたシステムの利用」についても言及されているため、これはもう「答えのフルコース」だと言えるでしょう。

しかしながら残念な点もいくつかあります。
@ によるエラー抑制に始まり、参照渡しを「混乱しやすいから」という乱暴な理由で推奨していなかったり === ではなく == での評価がほとんどだったりと、初心者向けだからこそ肌感覚で培って欲しい「PHP のだめなところ」に関する言及がとても少なく、本書だけで学べてしまうが故に、本書だけを参照してコーディングしていると早い段階で「あれ?なんでこうなるの?」と戸惑う場面に出くわすでしょう。
特に、セオリーとされている mb_strlen() や htmlspecialchars() に文字コードを渡す事が書かれていない点は大きな穴です。

しかし本書は数多く出版されている PHP 本の中でも「決定版」と言えるほど完成しており、PHP での開発を生業とする企業ならば新入社員用の教科書として必携の一冊であると言えるでしょう。

と、まとめるとこんな感じです。
折角なので残念なところの補足をいくつか。

@によるエラー抑制

これは大変まずい事です。自己満足的なプログラムならば良いとしても、割と実践的な事が書かれているだけにビジネス用途で作ったようなプログラムでこれを使ってはいけません。
@でエラー抑制すると遅くなるとか、そんな事はどうでもいいんです。エラー抑制する代わりにハンドリングすれば似たような負荷がかかる事が多いですから。それよりも「@でエラー抑制をしているとエラーが表示されなくなる」というところにこそ問題があります。殴られても痛くないみたいな。出さないのがいいものはエラーであってエラーメッセージではないんです。

もし@で抑制している箇所に起因するバグがあった場合、追いかけるのは結構面倒くさいです。
「いくつかあたりをつけて探してみたけどそれっぽいところはない。じゃあちょっと@消してみようか」みたいなのはバッチリ二度手間です。
そんな事するくらいなら最初から@で抑制するんじゃなくて条件式なりなんなりでエラーのハンドリングをするべきです。

=== じゃなくて == を多用している

これもよくありません。基本的に == を使うべきではありません。== で評価するくらいなら型キャストしてしまって if( (int) $a === 5 ) というように書いた方がマシです。これと同じ理由で if( $a ) と言うような評価もよくありません。== を使わないよう癖つけるくらいでちょうどいいと思います。
評価する変数の型によって結果が違う評価式なんてのは気難しい人に様子を伺うようなものです。逆に == でしか評価できないような実装はそもそも設計に問題があります。

mb_strlen() や htmlspecialchars() に文字コードを渡す事

よく「PHP の mbstring の設定はこうした方がいい」なんつって mbstring.internal_encoding = utf-8 みたいな事を書いているような人がいますが、これも合理的じゃありません。そもそもプログラムごとに文字コードが違うし、リクエストに含まれる文字の文字コードだってバラバラです。それなのに PHP の設定としてサーバソフトウェア側で文字コードを制御するのは考慮しなければいけない点を増やすだけで全く持って非効率的です。そもそも文字コードを扱うレイヤーじゃないです。
大体 web アプリを作るときにはアプリで扱う文字コードを決めて、その文字コード以外の文字コードで送られてきたリクエストははじくのが前提ですから、そのアプリで解釈すべき文字コードは(原則的には)1種類です。
htmlspecialchars() のシノニムで h() を作るのも今ではセオリーで本書にも書かれていますが、第二引数だけではなく第三引数まで書かないと意味がありません。

<?php
define( 'SITE_ENCODE', 'utf-8' );
h( $var ){
  return htmlspecialchars( $var, ENT_QUOTES, SITE_ENCODE );
}
?>

みたいな。

大体 utf-8 な文字を mb_strlen() 辺りで図ろうとしても文字コード指定してるか mbstring.internal_encoding で utf-8 が指定されていないと正しい結果を返しません。mbstring.internal_encoding は前述の通り文字コードを制御するようなレイヤーにある設定ではないので、消去法的に考えるとマルチバイト系の文字列関数にはきちんと文字コードも渡してあげるのがモアベターです。

でも結局は全部 PHP の設計に起因する問題なんですよね。
これらのつかみにくい設計に関するノウハウまで求めるのは酷かもしれませんが、web デザイナーが css ハックを必要とするようにこういった情報も必要なんじゃないんでしょうか。

ここらへんの情報が無い以外は本当に素晴らしい書籍です。
僕みたいに受託で開発やってるような人間はクライアントから「社内でエンジニアを育てたい」的なお話をよく聞きますが、本書はそこらへんのニーズをバッチシ抑えてます。
逆引きリファレンスですが関数依存の構成ではなくユースケースに依存しているため、明確な目的意識が無くてもノウハウの蓄積に役立つとも思います。

以上。

コメント:3

通りすがり 2010 年 6 月 5 日

なるほど、私みたいにCや、C++で大規模開発していたものにはありがたいです。参考になりました。もともとCMMコンサルもやっていたので、理屈じゃない綺麗なコードではなく、資産価値の高いコードというものをつい考えてしまうのですが、phpはそのあたりどうなんでしょうかね?確かに===等、規約というかセオリーで資産価値は上がるのでしょうが、なんとなく違和感があるんですよね?なんででしょうか?なんかどっかに穴が開いているような?なんとなくphpの柔軟さに原因があるような気がするんですが…あ、すみません、要領を得ずに。

nic 2010 年 6 月 14 日

> 通りすがりさん

どうもどうもこんばんは。

理屈じゃない綺麗なコードではなく、資産価値の高いコードというものをつい考えてしまうのですが、phpはそのあたりどうなんでしょうかね?確かに=== 等、規約というかセオリーで資産価値は上がるのでしょうが、なんとなく違和感があるんですよね?なんででしょうか?なんかどっかに穴が開いているような?なんとなくphpの柔軟さに原因があるような気がするんですが

僕が感じている事は2つです。

  • システムの自由度と複雑さはトレードオフ
  • 目的意識の有無

自由度を上げればその分システムとしての受け皿は網羅的にならざるを得ません。
逆を返せば自由を求めなければ複雑なシステムは必要ないという事ですよね。
しかも IT におけるシステムは有機的な変化を求められるシーンが圧倒的に多いです。
このような事を考えるとプリミティブな部分はパッケージングされてしまっている方がいいと思うんです。最近のフレームワーク熱なんかはここらへんが起因してますよね。
それを少しフレームアウトすれば言語に行きつくんじゃないかと僕は思っています。

僕は自堕落な人間なので指先だけで完結するプログラミングという作業が好きです。
究極的に言えば指先も動かさずに脳内で言語化もされていないイメージ的な状態を脳波としてキャッチしてプログラムに落とし込むところまでやってほしいと思っています。それとはまったく別のレイヤーで知的好奇心を満たすためにアルゴリズムを学ぶ意思もあります。
両者はアンビバレントな感覚かもしれませんが、そもそも目的意識のベクトルが違うものなので僕の中では両立しています。
また、知る事によってさらに手を抜く事が出来るようにもなりますので3次元的に考えれば補完しあいすらすると思います。

要するに PHP みたいに合理的なプログラム言語を使うに当たって最低限理解すべきなのはその柔軟さだと思います。
「プログラムを作ってシステムを動かす」と言う根源的な目的をアルゴリズムの学習なしに達成できるわけですから。

これに連続する形でもう一つ思う事が「目的意識の有無」です。
「知らなくても動くシステムが組める」と言うのは強さがある半面使い手が脆くなりますよね。金持ちの家で育った子供みたいに小さなころから満たされていたら創造性に乏しくなるのは特別な事ではないと思います。
PHP にもこれが言えると思います。”PHP が柔軟だからこそ穴があるんじゃないか”と考えられているのは正にその辺りに起因してるんじゃないかと思います。
結局のところここの穴を埋めてくれるのは目的意識しかないんじゃないでしょうか。僕の場合は極度の負けず嫌いとこだわりがいい方向に作用してゼロから独学で学び続ける事が出来ていますが、ここらへんが人や仕事によっては「セキュアなプログラムを書く」だったり「大規模なリクエストにこたえるシステム」だったりするわけですよね。
このような目的意識がはっきりしていなければ PHP の柔軟さはかえって仇になるんだと思います。

結局のところ PHP の柔軟さは原動力であると同時に乗り手の成長を阻害するって事ですね。阻害とまでは行かないかな。「今のままでもいいや」って考えに陥りやすくなるというのかな。
だから「PHP で作られたシステムにはセキュリティホールが多い」なんていわれるんですよね。

ちょっと違うかもしれませんが、古代ローマなんかじゃ市民は働かなくても食べていけるほど都市が発展してしまったため、成長が止まり滅びたみたいな事が言われています。PHP も同じなんじゃないのかなと思います。大げさかもしれませんが。
そこのぬるま湯に甘んじるかどうかは言語が決める事じゃなくて、使う人が決める事なんじゃないでしょうか。その点こっちに考える余地を残してくれている PHP は僕にとってとても面白い言語です。

nic 2010 年 6 月 14 日

答えになってますかね?

コメントフォーム
入力した情報を記憶する

トラックバック:0

この記事のトラックバック URL
http://spais.jp/php/%e6%9b%b8%e8%a9%95%e3%80%8cphp%e9%80%86%e5%bc%95%e3%81%8d%e3%83%ac%e3%82%b7%e3%83%94%e3%80%8d/2009-08-10/trackback
トラックバックの送信元リスト
書評「PHP逆引きレシピ」 - SPaiS より

ホーム > PHP > 書評「PHP逆引きレシピ」

カテゴリー

ページの上部に戻る