影響範囲調査をする技術

2024年 4月17日

社内LTで話した資料です。

Transcript

1. 影響範囲調査をする技術 🔥時間・能⼒的制約を⾔い訳にしない🔥
2. 🌸新卒のみなさん🌸 🌸⼊社おめでとうございます🌸
3. ▪ たかはしことみ ▪ 2023年3⽉⼊社 / 京都から札幌にきました︕ ▪ Swiftばかり書いてます
4. TikTokしています🍤 いいね と フォロー 待ってます 🥰💓
5. 🍤 ⾔いたいこと 🍤
6. 場当たり的な調査、ダメ︕︕︕ ⼩さい歩みでドキュメント化を⾏おう︕︕
7. 幅優先探索は良いぞ ^ - ^
9. ある⽇のわたし ▪ 「新しい機能の追加か〜」 ▪ 「影響範囲調べなきゃ」 ▪ 「よし、問題なさそうだな。コミット して、マージしてっと……」
10. ~数⽇後~
11. お客さん「バグがあったんですけど💢」
13. 別の⽇のわたし ▪ 「新しいバグ上がってるな」 ▪ 「原因の調査しなきゃ。」
14. 別の⽇のわたし ▪ 「… このコード読むの、初めてじゃないな」
16. 🍤きょうの議題🍤 なぜ、影響範囲の調査漏れは発⽣するんだろう なぜ繰り返し同じ箇所を調査しているんだろう → 効果的な影響範囲調査をする⽅法を考える︕
17. なぜ、影響範囲の調査漏れは発⽣するんだろう => 調査結果が不⼗分・信頼性がない
18. なぜ繰り返し同じ箇所を調査しているんだろう => 以前実施した調査を信⽤していないから
19. 「調査の結果に不安がある」点で 通じ合っている。
20. 信頼性が持てる 調査⽅法を考えたい︕︕︕︕
21. 現状分析
22. 開発において ありがちな課題
23. ▪อकੑ͕ߴ͘ͳ͍ίʔυ ▪λΠτͳ޻਺ ▪࣮૷ऀͷίʔυಡղೳྗͷෆ଍ ▪࢓༷ॻɾઃܭॻ͕ଘࡏ͠ͳ͍
24. 精神的に圧迫されがち😭
25. 調査の時、何してるんだっけ。
26. ある⽇のわたし ▪ 「まずは全体像理解したいな〜(メモ書き)」 ▪ 「この関数条件分岐多すぎ…︖」 ▪ 「全部丁寧に読むと⽇が暮れちゃうな(ここで記録 を諦める)」 ▪ 「あ、ここ変えれば期待値になりそう︕」
28. ▪調査の⽅法が毎回バラバラ ▪調査結果の残し⽅にムラがある ▪調査に無駄が多い
29. 調査の⽅法が毎回バラバラ
31. 幅優先探索
33. 調査している関数内に新たな関数が現れても， 個々の関数ごとに最後まで調査する
35. 幅優先探索の利点 ▪「根本原因の究明」と「変更箇所の特 定」および「影響 を受ける箇所の特 定」を別々に、順に実施することがで きる ▪どこまで・何をしたのか管理しやすい
36. 時間がかかりそう︖
37. 最初は理解しようとしてはいけない
38. 構造図を作ることを⽬的にする
39. 理解してから図にするのではなく、 単純に構造図に落とす
40. 構造図の作成は1関数あたり1分
42. 要するにマインドマップ
43. これなら1関数あたり1分で調査できそう︕
44. ▪調査の⽅法が毎回バラバラ ▪調査結果の残し⽅にムラがある ▪調査に無駄が多い
45. 調査結果も残すことができる︕︕︕︕
46. 調査の粒度に無理がないから、 残されたドキュメントを信⽤できる︕
47. こんなこと、バグ調査してる時にして いられるか︖︖︖︖︖︖
48. おっしゃる通りです。
49. もう少しだけ話を聞いてほしい。
50. 過去も調査した経験のある箇所を 調査し直す時、何が起こっているのか
51. ・⾃分の認識が正確か不安… ・ソースコードの全体を把握して調査で きていない ・ソースコード事態が複雑だから誤読し ていそう
52. 部分理解 ▪ 仕様書や設計書が準備されていない or 古い => ソースコードに依存することになりがち ▪ ソースコードに依存し、理解を⾏う => 思い込み・勘違い・理解不⾜ が発⽣しがち
53. 認識の領域にある問題を ⾃分で発⾒することはむずかしい。
54. ソースコードに依存した状態から 徐々に脱却を図る => 実は近道︖
55. 条件分岐が複雑なソースコードを読む VS フローチャートを読む フローチャートを読む⽅が、楽。
56. ・過去も調査した箇所を再度実施する事 態が発⽣ => ドキュメントを整備しよう︕ 幅優先探索は良いぞ ^^^^^^^^
57. 調査を⾏う⽬的に⾃覚的になろう
59. 事前調査 ・依頼内容を理解するために実施 ・構造や動作の把握に徹する ・構造図を作成する
60. 変更箇所調査 ・変更要求を実現するために必要な 変更箇所を特定する調査
61. 影響調査 ・変更により影響が及ぶ箇所を特定 する調査 ・変更箇所調査の後に実施
62. 変更箇所調査は分割してもいいかも。
63. όάௐࠪͷ৔߹ 
    ࣄ৅͕ൃੜ͍ͯ͠Δࠜຊతͳ໰୊ Λಛఆ͢Δ 
    ࠜຊతͳ໰୊Λ౿·͑ɺղܾࡦΛ ݕ౼͢Δ
64. なるべく早い段階で、 事前調査 (構造や動作の把握)を 実施できるとよさそう。
65. ドキュメントのおかげで 調査時間が削減された例を 振り返ってみる
66. 条件分岐が複数混⼊する関数をフロー チャートに起こした ▪条件分岐を俯瞰して把握できた ▪曖昧な箇所が⾃然に明確になった
67. 当該関数の中には、実装意図の分からな いコードが含まれていた。 フローチャートを起こすことで、意図の 分からないコードに注意を奪われること なく、フローに集中して関数を解釈でき るようになった。
68. BLE通信とAPI通信が混在するフロー をシーケンス図に起こした ▪⾮同期処理が含まれるコードは、追う のが⾟い ▪改修時に⼤幅な作業時間の削減が実現 された
69. 調査結果を残すべきタイミング ▪ 何度も参照される可能性が⾼く、かつ認知負荷が⾼い 処理 ▪ データの取得・参照・書き換えに関連するもの ▪ フローが複雑で、俯瞰して把握が困難 => メモを残したくなった時点でドキュメント化を検討
70. まとめ︓ ・⾃分が何のために・何を⽬標とし・ どの⼯程の調査を実施しているのか⾃ 覚する ・ドキュメントを作りましょう ・幅優先探索は良いぞ
71. iPhone DevSapporo
72. 旭川ゆるい勉強会
73. JMLT
74. ありがとうございました 🌸🍤