実務に役立つ基礎知識

不具合修正手順

• 現象を確認する
  再現する手順を見つける。
  再現しないと安易に結論付けるのは禁止。
  考えられるあらゆるケースを試してみてそれでも再現しないときだけ”再現しない”という言葉を使う。
  理想は100%再現する手順を見つける。再現率が高ければ高いほど確実な修正が可能になる。

• 不具合原因調査
  何が原因で問題が発生するのかをソースコードを読んだり、ログを仕込んだり、リモートデバッグをして探す。
  　「推測」→「実験」→「結果の考察」を原因がわかるまで繰り返す。

機能追加手順

• 顧客がどういう目的（なぜ必要なのか？）でこの機能を要望してきたのかをきちんと理解した上で設計する
  この作業が一番重要！
  顧客と設計者のイメージが違うと作り直しになる可能性大。作り直す時間ほど無駄なものはない。
  画面構成などは仕様を事前に顧客へ提示して同意を取れればよりよい。

• どのクラス、どのメソッドに機能を追加するか考える

共通手順

• テスト仕様書の作成
  想像力を働かせてあらゆるケースを想定する
  何を確認したらこの不具合が直ったと判断できるか？（不具合）
  機能をきちんと理解して仕様を満たしているかを確認する（機能追加）
  修正したことによる他への影響はないか？

• レビュー（テスト項目に不足がないか誰かに確認してもらう）

• 既存処理をきちんと理解した上でどのファイルのどこを直すのかをまとめる

• レビュー（修正方法が適切か誰かに確認してもらう）

• コーディング

• レビュー（コーディング内容に問題がないか誰かに確認してもらう）

• テスト仕様書に書かれている項目をテスト
  この修正に関して一番詳しいのはソフトを修正したあなた自身。
  一番詳しいあなたが確認を怠れば客先で問題が発覚することになる。
  第三者検証で見つけられるのは”凡ミス”か”運よく見つけられたこと”だけ。
  あなたが”最後の砦”と自覚しよう。

• 第三者テスト（不具合が直っているか誰かに確認してもらう）

• テストがOKだったら修正をコミット

• Redmineのチケットの進捗率を100%に設定しステータスを終了にする