PCとかネットとか
2008.08.14
5月23日の「ご無沙汰してます。」でも書いたように、ここしばらくLAMP（Linux＆Apache＆MySQL＆PHP）での開発作業を行っています。何を開発しているのかはまだナイショですが、この数ヶ月でいろいろと感じたことがあるので、自分のための備忘録として記録しておきたいと思います。（それにしても「ご無沙汰してます。」って、ひどいタイトルですね。我ながらびっくり。）2008.08.14
基本的にはPHPでのプログラミングが主軸になるのですが、Webプログラミングというのは、想像以上に難しいです。難しいというのは、言語仕様が難しいとか、動作が複雑だとか、概念的に難解といったことではありません。あまりに融通無碍な世界であるため、自分に対して適切な「枷」をかけなければならない点が、難しいなあと感じているのです。しかもどのような「枷」をかけるべきなのか、ひととおりやってみないとわからない。PHPにはいくつもフレームワークが存在しますが、「確かにフレームワークが必要だなあ」と思います。でも私自身は、既存のフレームワークを使う気はないんですけどね。
というわけで、この数ヶ月で、プログラミングスタイルを何度も変更しています。
まず最初は書籍のサンプルコードを参考にしながら、フォームを使った会員登録画面を作ってみたのですが、いきなり違和感を感じることになってしまいました。まあ、サンプルコードにありがちな、HTMLとPHPが完全に混在しているコードだったのですが、これではメンテナンスができない、という感じだったのです。PHPって、動くコードを書くのは簡単なんだけど、メンテナンス性を維持したコードを書くのは、なかなか一筋縄ではいきませんね。
まず言語仕様に問題があります。宣言無しで変数を使うことができ、型付けが非常に緩やかなので、どこでどのような名前の変数を使ったのか、別にドキュメントを残しておかないとわからなくなります。これは「手軽に使える」というスクリプト言語のメリットでもあるのですが、将来の変更を前提にしてプログラミングを考えると、大きなデメリットになります。まあ、ドキュメンテーションをきちんと行えばいいわけですが。でも「ソースそのものをドキュメントにする」という、昔のC言語の発想を引きずっている私としては、ちょっと不満だったりします。変数の頭にすべて「＄」を付けるというルールは「なるほどなあ」と感心したりもしているのですが。このルールがあれば、予約語とバッティングすることもないですしね。
それからWebプログラミングの場合、まずHTMLありき、というのも厄介です。つまりMVCで言えば、何も考えずにプログラミングを進めていくと、どうしてもView主導型になってしまうのです。これもプログラムの見通しを悪くします。まずプログラム構造全体をControl主導型にし、その下にデータモデルとViewが配置されるようなイメージにしないと、なかなか見通しのいいプログラムになりません。そのためには自分でプログラム構造のルールを厳格に決め、そのルールを自分で徹底的に守る必要があります。
昔のX/Motifのプログラミングでは、このあたりが比較的扱いやすかったような気がします。私の時代は自分で無限ループのメインルーチンを記述し、そこに画面要素とそこで発生するイベントの定義を挿入、さらにコールバックルーチンを別途用意する、という手法が一般的だったような気がします。主役はあくまでもプログラム本体で、画面要素はオブジェクトとして扱えたのです。しかしPHPの場合、イベントは画面遷移を伴うのが一般的です。Ajaxを使えばオブジェクト的に扱えますが、そうでなければ個々の画面要素をPHPからコントロールすることはでませんよね。たぶんできないと思う。（弱気）
それから画面遷移時の変数の扱いも厄介です。一般的な変数は画面遷移時にすべて解放されてしまうため、スーパーグローバル変数を使わないとステートを引き継げません。例えばフォームに何か入力させ、「OK」ボタンで次の画面に遷移するといった処理を考えてみましょう。もしフォーム入力の内容に誤りがあれば、その内容を保持して元のフォーム画面を再表示すると共に、エラーメッセージを表示したいところです。しかしいったん次の画面に遷移してから元の画面を呼び出すと、フォームフィールドの内容は消えてしまいます。フォームフィールドの内容を次のコントロールに伝達するPOST変数も消えています。最初はフォーム画面の次の画面の中にhidden型のinput要素を記述し、POST変数を維持するようにコーディングしていたのですが、どうもしっくりきません。今ではSESSION変数にフォームの内容を保持し、不要になった時点でunsetしています。でもこれが最善の方法なのか、まだ確信が持てていない状況です。
というわけで、6月にはコントロールとビューを完全分離するための方法をいろいろと試行し、7月には「だいたいこんなもんだろう」という形を決めています。単純な方法なのですが、ひとつのプログラム（コントロール）の処理を、前処理（主にSESSION変数の確保とPOST/GET変数からの引継）、イベントハンドリング、画面表示用のデータセットの作成、画面表示、後処理、という5つの部分に分け、画面表示のコードをコントロール内に記述しないようにしているのです。画面表示はそれぞれひとつの関数として定義してあり、その内部にHTMLが記述されています（XHTMLと自信を持っていえないところが悲しい）。さらにひとつの画面を構成する機能ディビジョンは、「disp_○○_box.php」という関数にして、画面表示関数から呼び出すようにしました。こうすると画面表示の記述がものすごく短くなり、構造が明確になります。
画面表示に必要な情報も、最初はグローバル変数やスーパーグローバル変数を画面表示関数の中でそのまま参照していたのですが、これもメンテナンス性を損なう要因なので、引数渡しに変更しています。まあこれは当たり前の措置ですね。前述の「画面表示用のデータセットの作成」の部分でこの引数を作成し、画面表示関数の呼び出しのところで使用するわけです。ひとつの機能ディビジョンに対しては、ひとつのデータセットを引き渡します。もちろんこのデータセットは配列です。それも単純な配列ではなく、C言語の構造体のようなものです。C言語と違うのは、配列の要素の識別を文字列で行っている点でしょう。連想配列って便利ですね。コードの可読性も高くなるし。
関数の戻り値をどう扱うかも悩み所ですね。関数に引き渡す情報は引数、戻り値は関数そのものの値、というのが妥当だと思うのですが、引数の一部をリファレンス渡しにしてそこに戻り値をセットするというのも、自由度が高くなるので捨てがたい。どちらにするか結構揺れていて、何度も関数を書き直していたんですが、今では「関数の値を戻り値にする」という、ごく当たり前の方法に落ち着いています。引数をリファレンス渡しにすると、自由度は高まるんですが、可読性が落ちるような気がするんですよ。まあこのあたりは、趣味の世界かもしれませんけどね。でも可読性をいかに高めるかは、プログラミングで最も重要なことではないのかなあ。そんな気がします。
現時点で、MySQLのテーブル数が29、定義済みのファンクション（関数）の数が70ちょっとになっていますが、メンテナンス性はかなり上がりました。トレースログやタイムログのテーブル＆関数も作り、ログ取得関数を各関数に仕込んでいるので、デバッグもしやすいです。もちろんシンタックスエラーや未定義インデックスがあれば、PHPそのものがワーニングを画面に表示してくれますが、PHPのエラーが出ている間は「まだまだだめじゃん」ということ。本当のデバッグは、インタープリタからのエラーが出なくなってから始まるんですよね。
CSSとJavaScriptの勉強も本格的に始めました。CSSは他のサイトの記述を参考に「まあこんなもんかな」というレベルで適当に記述していたのですが、どうも根本的な誤解があったようなので、標準テキストを頭から読むことにしました。恥ずかしながら、かなり間違った使い方をしていたようです。JavaScriptはDOMのコントロールに使う予定です。もちろんAjaxの使用も考えています。CSSハックやJavaScript使用不可の環境との互換性をどうするかも、今後基本方針を決めなければなりませんね。
ということで、まだ道のりは長そうなのですが、ボチボチやっています。できあがったら公開するつもりなので、乞うご期待。
ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
