これは何か?
- 技術的負債になりえそうなコードに出会ったときにどう対応するかについて書いてある
技術的負債とは？
- 今後の開発体験を悪化させたり、非機能要件的に問題があるソースコードのこと
技術的負債に対するアプローチ
以下の順番で対応する
- まずはとにかく可視化
- 負債をグルーピング
- 負債の影響範囲から優先順位づけ
PHASE1. まずはとにかく可視化
- チケットとしてはすでに報告されていたり、duplicatedになってしまったり、invalidになるかもしれないけど、とにかくカジュアルにリファクタリング用のチケットを起票する
- 負債解消を後回しにした場合、その該当するPRに対して、リファクタリングイシューから必ずリファレンスしておく（どこで具体的につらかったのか後で対応する人がわかるようにするため）
- ツールとかは別になんでもいいが、ミニマムでやるのであればGithub IssueやPull Requestレベルでまとめておくとよい。
PHASE2. 負債をグルーピング・関連付け
- 関連する負債に関しては、PRやイシューに対してリファレンスをつける
- あえてそのPR内で対応しなかった理由があると、なぜそれが負債として残っているのかわかっているとよい。
PHASE3. 負債の影響範囲から優先順位づけ
負債として、以下の観点で優先づけることが多い。
- 報告数の多いチケット -> 開発チーム全体での開発体験が損なわれているチケットの可能性が高い
- 最もリファレンスされているチケット -> 問題の根本要因の可能性が高い。
ここも、PHASE1を最初からやっておけば、優先順位づけがしやすくなる。
技術的負債を減らすうえで大事なこと
①とにかく、負債を可視化すること
問題点が可視化されていれば、対応することができるが、問題が認識できない状況であれば
そもそも対応ができない。
よって、負債の匂いを感じるコードを見つけたら、負債解消を先送りにするのであれば必ずイシューを起票し、リファクタリングタグをつけておくこと。いつ対応するかは一切考えなくてもよい。
後でチケットのリファレンス数や、同じ問題がどれくらい起票されるかで、つらみ度がわかる。
チケットの起票がないと、優先順位をつけづらいので、対応が後回しになる可能性が非常に高い。
②どんなに小さな問題でも、起票しておくこと。
意外にその時は「まあ起票するほどでもないか、」と思っても、後で優先順位つけておくときに実はすぐ対応する必要がある可能性がある。起票時は優先順位はいったんつけずに、とにかく可視化、可視化をしておくことが重要。どんなに小さな問題でも、起票しておくこと。
③PRのレビュー時、負債であることをレビュワーに認識してもらうこと
コードレビューを受ける際も、負債を残しておく意思決定をしているか明示的に書いてあれば、レビュワーがその技術的負債に対して、突っ込むべきかどうかの議論に時間をかけなくても済む。よって、レビューを受ける前に負債解消を後回しにしたことを明示的に記載しておくべき。