（随時追記中・・・）
コーディング（共通）
- 変数名、メソッド名は分かりやすく
- エラーチェックはメソッドの先頭で行い、エラーがあればその場で適切なメッセージを出し、returnする
- プログラム自体の戻り値は正常終了した場合は0、それ以外の場合は1以上を返す
- 長い処理時間が見込まれる場合は、カーソルを砂時計に
また、await/asyncを利用して応答なし状態にならないようにする。
コーディング（C#、VB.NET）
- 文字列結合はStringBuilderを使う
- DataTableを編集する場合は、BeginLoadData、EndLoadDataを使う
- DataRowを編集する場合は、BeginEdit、EndEditを使う
- VB.NETで開発するときには、「Option Strict On」「Option Explicit On」を行う
- VB.NETで開発するときには、namespaceを記述する（名前がかぶってしまうのを防ぐ）
- VB.NETで開発するときには、Moduleは利用しない。Classを利用する
（Module内でPublicで宣言してしまうと、どこからも参照可能になりカオスになる） - MessageBoxなど、多くの場所で利用する処理は直接呼び出さず、ラッパーを作って利用する。こうすることにより、仕様が変わった際に１か所だけ修正すれば済む、また、ほぼ似てるけど少し違う実装が存在する、などの問題を防げる。
テスト
- 複数同時アクセス、大量アクセスを試す
- タブキー押下でのタブ順移動
動作が遅い
- ログファイル出力が過剰でないか
- ウィルス対策ソフトの監視対象になっていないか
- ネットワーク、プロキシーは適切か
- メモリが不足していないか
- 他のソフトが動作していないか
- （DB）物理ファイルの拡張が起こっていないか
リリース
- 不具合改修版をリリースするときには、プログラム入れ替えの他、不具合に起因してDBに保存されたままになっている異常データの修復も忘れない。
タスクスケジューラ
- ログオンユーザーの違いにより、動作が変わる可能性あり
- 直接プログラムを呼び出さず、batファイルからプログラム呼び出しを行う。その際にカレントディレクトリを指定する
バッチ
- 目的、引数の説明などを簡潔にバッチファイルの先頭に記述する
設定変更
- 本番機でいきなり設定変更しない。本番機に影響の出ない検証機にて、設定変更し、動作確認を行う。また、その設定変更を行う際には手順書を作成して、本番機の設定変更の際に利用する。
- 設定を変更する際。設定画面の場合は画面キャプチャを、設定ファイルの場合はファイルを取っておく。こうすることで、どこを変えたかが追える。また、バージョンアップした際に、どの部分を変更すればよいかがわかりやすくなる。（設定ファイルの場合はWinMergeなどでDiffを取れるような状態にしておくことが望ましい）
PostgreSQL
- １日１回、VACUUM ANALYZEする
- 月１回、REINDEX、CLUSTERする
運用監視
- 停電などで機器が本来の手順でシャットダウンされなかった場合、電源を入れなおしても復旧しない場合がある。（UPSの利用）
- サービスが落ちていないかの監視が必要かを検討する（死活監視）
- 障害が発生したと同時にメールサーバも落ちてしまい、落ちたことすら分からなくなってしまう、などの事態が発生しないかを考慮する
- DB、ログサイズの日々の増加量を確認する