保守作業をやっていて自分なりに気付いたことを、
あまりに当たり前かもしれないが、
自分には忘れないようにするために、あえて書く。
- 改訂対応における気付き
- 改訂テーマの要件定義ができたら、詳細設計書・結合テスト仕様書(単体テスト仕様書)の作成を行う。これらのドキュメントのレビュー完了後、テストデータの作成を行う。→プログラムの修正を行ってから、テストデータを作成するとなると、修正することがぶれる可能性がある。
- 緊急の障害対応・リリースにおける気付き
- 全体として、慌てず焦らず迅速に。
- 緊急障害時の対応が求められた場合(サービスが停止した)、真の原因調査の前に、サービスの停止を復旧させる暫定処置を最優先とする。
- 暫定処置のために修正プログラムをリリースする前に、緊急リリース時の手続きを明確にしておく。特に、緊急連絡体制や承認ルートを、まずは明らかにしておきたい。
- 簡単な暫定処置ほど修正〜テスト〜リリースまでの手順を確実に踏む。(たとえば、単体テストのみ、実施して検証終了ではなく、結合テストもしくはシステムテストまでこなす)
- システムを理解する上での気付き
- 全体像の把握から入る。自分は詳細設計書は信用できんと勝手に決め付けてしまい、プログラムの把握をメインにしたらよくわからなくなった。具体的には、下記のとおり。
- 業務フロー
- 機能関連図・機能一覧・画面遷移図・システム運用マニュアル
- 各サブシステムの概要設計書・DBレイアウト
- 詳細設計書・単体テスト仕様書・(CRUD表が個人的にはあるとうれしいと思った)
- プログラム
- 開発環境についての気付き
- 理想としては、開発機・評価機・本番機の3つを完備。ないようであれば、発注元に交渉してでも環境については、神経質になったほうがいい。
- 一から開発環境機の立ち上げをやると、個人的にはシステム概要がわかっていいと思った。しかし、前提条件として、システム規模が小さかったらというのがある。
「まるごと理解!保守開発」という
今の自分に参考になる特集がされてあったので、読んでみる。
きっと今の自分の状況のヒントがあるだろうから。