保守開発していての覚書


保守作業をやっていて自分なりに気付いたことを、
あまりに当たり前かもしれないが、
自分には忘れないようにするために、あえて書く。

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


「まるごと理解!保守開発」という
今の自分に参考になる特集がされてあったので、読んでみる。
きっと今の自分の状況のヒントがあるだろうから。

開発の現場 Vol.011

開発の現場 Vol.011