問題が起こったらまず、ログを見る - My Headlineで、問題発生時にログを見たほうがよいと書いたが、ログの見方がわかっていなければ、やはり調査に時間がかかってしまう。 アプリケーションによっては複数のログがあるものもある。 たとえば、MySQLには、以…

システムを運用としていると、ある日突然画面が表示されなくなったり、処理時間が遅くなったりする。 昨日まで動いていたものが、突然動かなくなる理由として以下のようなことが考えられる。 (1)データ不正 (2)処理量増 (3)プログラムを誰かが書き換えられた…

昔、何かの本で読んだことがあるのですが、伊勢神宮の建物は二十年毎に作りかえている、ということが書いてありました。 なぜ、そうしているかというと定期的に作り変えることで、技術の継承を図っているらしいのです。 逆に作りっぱなしでそのまま百年とか…

保守開発では、まず対象となるプログラムの理解が必要になる。この理解のためにはプログラムを解析してもよいのだが、実際にプログラムを動かしてデバッグ文を途中でいれるなどして動作を確認したほうが早いし、正確。

大幅なプログラム修正を行う際に、本来修正するべきところとは別のところを修正してしまう"うっかり修正"をしてしまうことがあります。実際にあったことですが、if命令の==の部分を=に"うっかり修正"したことがありました。プログラムを一通り修正した後、テ…

保守開発において関数のINとOUTがログに記録されていると、解析に役に立つ。また、実行時間を記録しておくと後で性能調査を行う際に便利。 フラグのONとOFFで、ログに記録するしないが設定できるようにしておくとよい。

全体図 業務フロー 画面フロー 外部インターフェース データの内容と関連 現行システムの課題 機能毎の重要度 運用コスト 機能毎のソースコードのステップ数 ※ 見える化しすぎても失敗する。ほどほどに。

保守開発において、現在動いている部分は必ず保障しなければならない。しかし、設計書をもとにテスト仕様書を作成した場合でも、想定されていなかったバグが発生するケースは必ずあり、これらのバグはテスト仕様書に反映しておく。

全体を俯瞰できる資料 シーケンス図、クラス図 設計の意図を書いた資料 なぜ、こんな設計にしたのかが書かれた資料

是正保守 バグの修正はこれに含まれる。 予防保守 バグになりえる問題を探して、バグが表面化するまえに修正 適応保守 利用環境の変化（法改正、税率変更）や利用部門からの要望による修正。 完全化保守 性能や保守性を向上させる目的でソフト改善。

保守開発で、やるべきこと。 仕様を"完全に"理解するための調査 既存の機能が動作することを完全に保障しないといけない。 調べたことは資料にまとめる リファクタリングするべきか否か メンテナンス性の悪いプログラムはリファクタリングの可否を検討する。…

保守開発の見積もりを立てる上のポイントは以下の３つ。 調査の工数 どのように修正するか テストの工数 修正した部分だけテストするのではなく、既存の機能が動作することを保障しなければいけない。 最適化するかどうか ある修正を行う場合に、AとBのやり…

関数のインターフェース（パラメタ）や、処理内容を変更する場合、その関数を利用している箇所を全部調べて、影響を調査する。 インターフェースを変更する場合、デフォルト引数などを利用して、その関数を呼び出しているほかの箇所を修正しなくてもよいよう…