初見の処理系(ライブラリ操作)などは休日などで最小パターンを確認しておくこと。実務で何時間も悩むと非常にストレスがたまるテーブル設計命。あとで終えるようにトレースができるような値を入れておくこと。複雑な処理ほどテストやトレース(あとで動きをどうおったら楽か)を中心に考える。テストやトレースで考えるべき点として、1.コード自体を細かく分けて、検証しやすくする2.重要になる値、コード値やその情報のキーとなる値(例えば伝票番号など)は必ずテーブルにも入れ、ログにも吐く。3.デバッグオプション的なものを充実させる。例外系を中心に考える。どんなエラーが起こるかを想定し、そこから正常系の動作を考える。リリースまでにチェックリストを用意し、「考えなくても必要工程がすむようにする工夫」を行う。テストが難しいもの(メール受信)ほどテストを最初に考える。テストをするかで組む。複雑な処理になってくると、コードをかくスキルだけでは対応できない。ドキュメントなどある程度プログラムを可視化する処理が必要になってくる。ユーザーに頼んで本番環境の中にダミーユーザーとして入れてもらう事。検証が難しいパターンは大体においてデータの特殊性が絡んでいることが多い。「テストしておいて下さい」ではユーザーはテストをしない。イニシアティブをとって、テストが運ぶような(例えば一部の処理のみ実運用でやってもらう)手続きを取ること。テストデータをうまく作るスキルを普段から身につけておくこと。fakerのようなライブラリでもいいし、うまく本番からデータを持ってこれるようにする。エラー通知のライブラリ(Sentryなど)を入れる。できればメンテ時間をあらかじめ組み込み、ユーザーがさわれない時間を作ってもらえると検証が簡単になる。ログをおうプログラムがあってもいいぐらい、ログのトレースは重要。サーバーが違うと正確なトレースができないので、ステージング環境をできれば用意しておく。サーバー環境、バージョン情報の違いに注意。コメントをキャンセルメールアドレスが公開されることはありません。ついてリーダブルコードシリーズ第2段、名称について。コードにおいては名称がとても大切で、正しい命名づけなどはなかなか難しいです。以下に大事で重要だと思ったポイントを。OSに対する命令文を不正に紛れ込ませて攻撃させる手法。その2前回のエントリーのように、データとロジックを一体で考えるのは、処理状の有効性のみならず、よりユーザー側に近い処理をかくということにもつながります。...テストプロセスに関して日々是テスト。以前にかいたエントリーなどは下記参照。