トラブルに強いWebアプリケーション

個人的にですが、Webアプリケーションを作るときに注意していることです。

URLとクラスのマッピング

URLとそこで操作するクラスの名称を一致させたり、似た名前にしておくと色々よい事があります。

ユーザ情報を表示するURL

 http://example/user/akihito/profile

ユーザ情報を取得するクラス(ユーザ情報を表示するときに使用)

 user = new User('akihito');
 user.profile.age;
 user.profile.email;

つまりURLとクラスがマッピングするように設計しておくわけです

 /user/akihito/prfile  <=>  user(akihito).profile
 # ユーザ情報の更新
 /user/akihito/prfile/update  <=>  user(akihito).profile.update({age=>99})
 # ユーザの削除
 /user/akihito/delete  <=>  user(akihito).delete()

こうしておくとトラブルやバグに遭遇したときに問題箇所が特定しやすくなります。
また、update,deleteの名称をURLに含めることで更新系の操作を別サーバに振り分ける布石にもなります。

例外処理

例外処理には例外オブジェクトを使用することをお勧めします。
PHPであれば標準のException,try,catch、PerlであればException::Class,eval,$EVAL_ERROR($@)があります。フレームワークが提供している例外クラスを使うのもいいですね。

下層のクラスで"throw Exception"しておけば、上層クラスで補足することができます。例外処理を標準化して、チーム全体で統一したエラー処理を行うようにしておきましょう。

ログ

参照系の操作なのにPOSTメソッドを使ってクエリーをアクセスログからなくしてしまうのは非常に残念なことです。

 http://example/search
 http://example/search?q=hoge

例外処理のエラーメッセージや場合によってはPOSTメソッドのクエリーをエラーログ等に吐き出しておくのもいいですね。ユーザの動きが非常に追いやすくなります

セッション

セッションに入れた値は可読性が失われます。また経路によってセッションデータを書き換えるような設計はトラブルの元になります。
自分はセッションに何を入れるかは、どちらかといえば慎重派です。小さいセッションで最大の効果を得られるようにすべきです。

まとめ

トラブルやバグには必ずあります、少なくすることはできますが、なくなる事はないです。
遭遇したときに問題箇所を特定し修復できるように事前に準備しておくことが、トラブルに強いWebアプリケーションだと思います。