- 初見の処理系(ライブラリ操作)などは休日などで最小パターンを確認しておくこと。実務で何時間も悩むと非常にストレスがたまる
- テーブル設計命。あとで終えるようにトレースができるような値を入れておくこと。
- 複雑な処理ほどテストやトレース(あとで動きをどうおったら楽か)を中心に考える。テストやトレースで考えるべき点として、
1.コード自体を細かく分けて、検証しやすくする
2.重要になる値、コード値やその情報のキーとなる値(例えば伝票番号など)は必ずテーブルにも入れ、ログにも吐く。
3.デバッグオプション的なものを充実させる。 - 例外系を中心に考える。まずはどんなエラーが起こるかを想定し、そこから正常系の動作を考える。
- リリースまでにチェックリストを用意し、「考えなくても必要工程がすむようにする工夫」を行う。
- テストが難しいもの(メール受信)ほどテストを最初に考える。どうテストをするかで組む。
- 複雑な処理になってくると、コードをかくスキルだけでは対応できない。ドキュメントなどある程度プログラムを可視化する処理が必要になってくる。
- ユーザーに頼んで本番環境の中にダミーユーザーとして入れてもらう事。検証が難しいパターンは大体においてデータの特殊性が絡んでいることが多い。
- 「テストしておいて下さい」ではユーザーはテストをしない。イニシアティブをとって、テストが運ぶような(例えば一部の処理のみ実運用でやってもらう)手続きを取ること。
- テストデータをうまく作るスキルを普段から身につけておくこと。fakerのようなライブラリでもいいし、うまく本番からデータを持ってこれるようにする。
- エラー通知のライブラリ(Sentryなど)を入れる。
- できればメンテ時間をあらかじめ組み込み、ユーザーがさわれない時間を作ってもらえると検証が簡単になる。
- ログをおうプログラムがあってもいいぐらい、ログのトレースは重要。
- サーバーが違うと正確なトレースができないので、ステージング環境をできれば用意しておく。
- サーバー環境、バージョン情報の違いに注意。
- 運用段階に入り、忘れかけた頃に障害が発生して仕様を忘れていることが多いので、すぐに検証できる方法を用意しておく(ドキュメント整理、本番と近い作業環境やDB、SQLログ、本番環境に常駐しているユーザー)
小〜中規模程度のWEBアプリ作成で気をつけるべきこと
投稿日:
執筆者:matsumoto