【教訓集】

(随時追記中・・・)

コーディング(共通)

  • 変数名、メソッド名は分かりやすく
  • エラーチェックはメソッドの先頭で行い、エラーがあればその場で適切なメッセージを出し、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など、多くの場所で利用する処理は直接呼び出さず、ラッパーを作って利用する。こうすることにより、仕様が変わった際に1か所だけ修正すれば済む、また、ほぼ似てるけど少し違う実装が存在する、などの問題を防げる。

テスト

  • 複数同時アクセス、大量アクセスを試す
  • タブキー押下でのタブ順移動

動作が遅い

  • ログファイル出力が過剰でないか
  • ウィルス対策ソフトの監視対象になっていないか
  • ネットワーク、プロキシーは適切か
  • メモリが不足していないか
  • 他のソフトが動作していないか
  • (DB)物理ファイルの拡張が起こっていないか

リリース

  • 不具合改修版をリリースするときには、プログラム入れ替えの他、不具合に起因してDBに保存されたままになっている異常データの修復も忘れない。

タスクスケジューラ

  • ログオンユーザーの違いにより、動作が変わる可能性あり
  • 直接プログラムを呼び出さず、batファイルからプログラム呼び出しを行う。その際にカレントディレクトリを指定する

バッチ

  • 目的、引数の説明などを簡潔にバッチファイルの先頭に記述する

設定変更

  • 本番機でいきなり設定変更しない。本番機に影響の出ない検証機にて、設定変更し、動作確認を行う。また、その設定変更を行う際には手順書を作成して、本番機の設定変更の際に利用する。
  • 設定を変更する際。設定画面の場合は画面キャプチャを、設定ファイルの場合はファイルを取っておく。こうすることで、どこを変えたかが追える。また、バージョンアップした際に、どの部分を変更すればよいかがわかりやすくなる。(設定ファイルの場合はWinMergeなどでDiffを取れるような状態にしておくことが望ましい)

PostgreSQL

  • 1日1回、VACUUM ANALYZEする
  • 月1回、REINDEX、CLUSTERする

運用監視

  • 停電などで機器が本来の手順でシャットダウンされなかった場合、電源を入れなおしても復旧しない場合がある。(UPSの利用)
  • サービスが落ちていないかの監視が必要かを検討する(死活監視)
  • 障害が発生したと同時にメールサーバも落ちてしまい、落ちたことすら分からなくなってしまう、などの事態が発生しないかを考慮する
  • DB、ログサイズの日々の増加量を確認する

役立つ法則