Zenn
😬

新卒エンジニアのときに知りたかった バグ修正

2024/11/12に公開
Android
iOS
Swift
新卒
新人
idea

概要

バグ修正は仕事の時間の少なくない割合を占めている。
しかし、その手順を教わることあまりない。
私が普段、バグ修正を行うときの手順とそのポイントをまとめた。

  1. なにがバグなのかを理解する
  2. バグを再現する
  3. バグの原因を探す
  4. バグを修正する
  5. PR reviewやQAを依頼する

想定読者

  • 新人としてプロジェクトに参加したばかりの人
  • バグ修正で、自分なりの手順を確立できてない人、より良い方法を探している人
  • 新人の教育などで、バグ修正の手順を教える必要がある人

WHOAMI

  • 新卒3年目のiOSアプリエンジニア

バグ修正の手順

バグ修正のタスクを振られたとき、以下の5ステップで行う。

  1. なにがバグなのかを理解する
  2. バグを再現する
  3. バグの原因を探す
  4. バグを修正する
  5. PR reviewやQAを依頼する

1. なにがバグなのかを理解する

まず最初に、何が想定動作で、何が実際の動作なのかを理解することが重要。
想定動作は仕様書などから知ることができる。
バグといわれているものは、想定された動作の可能性もある。（勘違いでバグとして報告されていることもある）

とるべき行動の例

  • バグチケットの中身を読む
  • 関連する仕様書を読む

2. バグを再現する

すでに、バグの原因の見当が付かもしれないが、その場合でも、バグの再現は重要。
バグを再現できないなら、バグが修正されかどうかを確かめることができない。

再現が難しい場合は、バグを報告した人に再現状況や発生頻度を尋ねる。
環境の違いが原因の場合もある（e.g. Networkの速さ、OSやアプリのVersion、端末の大きさ、特定のアカウント）

とるべき行動の例

  • 報告された再現手順で、バグを再現を試みる
  • バグを報告した人に再現手順を尋ねる

3. バグの原因を探す

バグの原因を探すときは、以下の3点に注意する。

  • 原因の切り分け
    • 「APIのレスポンスがUIに表示されない」というバグの原因箇所は、UI部分、API呼び出し部分、Backend側などさまざま考えられる。
    • 「APIの呼び出しは正しく行われているか」「APIのレスポンスは想定しているものか」などを調べ、原因箇所を絞り込む。
    • 原因の切り分けを繰り返し、できる限り絞りこむ。
  • 事実と予想の区別
    • 正しいことを確認した"事実"と、事実から推測した"予想"は異なるもの。混同してしまうと、バグの原因を探すのが困難になる。
    • 常に、なにが"事実"で、なにが"予想"なのかを意識する。
    • "予想"を検証し、"事実"を積み上げていくことで、原因に近付くことができる。
    • たとえば、「APIのレスポンスを表示する画面で、レスポンスが表示されない。APIの呼び出し箇所にバグの原因がある」という文では
      • 「レスポンスが表示されない」は事実だが、「APIの呼び出し箇所にバグの原因がある」というのは予想。
      • 「レスポンスは取得できているのに、UIに反映されてない」という可能性もある。
  • 変更履歴をさかのぼる
    • 原因にあたりがついたら、なぜそのコードが実装されのかを調査する。
    • そのコードが実装されたのには何か理由があるはず。その理由を調べずに修正すると、ほかのバグを引き起こす可能性がある。
      *「なぜフェンスが建てられたのか分かるまで、けっしてフェンスを壊してはならない」

とるべき行動の例

  • コードを読み、原因を探す
  • 原因を推測し、それを検証する
  • GitHubやGit commandなどを使用してコードの変更履歴を調べる

4. バグを修正する

原因が分ったら、コードを変更し、バグを修正する。

  • よりより解決策を考える
    • 1つのバグに対して、たいていの場合、複数の解決策が存在する。
    • その中から、「変更の大きさ」「実装の複雑さ」「ほかの箇所への影響の大きさ」「将来の保守性」などを考慮して、最適な解決策を選ぶ。
  • 他の機能に影響がないか確認する
    • バグ修正によって、ほかの機能にバグが発生してしまうことがある。
    • 変更箇所に関連した機能を調べ、影響がないことを確認する。
  • 再発を防ぐための対策を考える
    • バグを修正しただけでは、将来同じバグが再発する可能性がある。
    • 再発させないために、対策を考える。（e.g. UniteTestの追加、変更の理由をコードコメントに残す）

とるべき行動の例

  • 複数の解法を考え、利点や欠点を比較する
  • 影響がありそうな機能の動作をチェックする
  • 変更箇所のUnitTestを書く

5. PR reviewやQAを依頼する

  • 再現のために特定の条件や手順があるなら、Reviewerに共有する
  • バグの原因や、解決方法についての説明をPRに書く。 Reviewの理解の助けになるほか、将来のエンジニアが当時の判断理由を知る助けになる。
  • 影響が予想される箇所は、QAにテストを依頼する。

とるべき行動の例

  • PRの説明欄に再現手順を書く
  • バグの原因や解決方法について説明する
  • QAやReviewrに、影響がありそうな箇所を確認してもらう

さいごに

バグ修正の手順に正解はないが、自分なりの手順を確立するための、参考になれば幸いです。

Discussion