最近考えていること。バグを減らすためにコードレビューは必須だけど、いつ自分が最後の砦になるか分からんのだから、自力でバグに未然に気づく筋肉も鍛えていかないといけない。なんで、どうやったらそれができるのか考えている。
改修の規模の大小に関わらず、なにか改修したら、その周辺も含めて残さずテストする
- ある機能Aを改修したときに、Aのテストは誰でもやると思うけれど、Aを改修したことによって機能Bがバグっていたことに気づけず……ということが、あるある
- 特に改修が小規模であるほどこの手のバグは起きやすいように思う。「たったこれだけいじっただけなんだから、他の機能が壊れるなんて有り得ないだろ」と油断してしまう
- では「周辺」とはどの範囲を指すか？ これを考えるのが一番難しいし、この考慮漏れが個人的にバグの温床No.1。改修の影響範囲の考慮漏れを減らす方法が今のところ「経験の蓄積」以外思い浮かばなくてつらい。こればかりはベテランの人のレビュを受けることで嗅覚を磨いていくほかないのかなと思っている
図や表を書く。文章に起こす。人に説明する
- 複雑な仕様のものを作っていると、作業にのめりこんでいるうちにだんだん自分でも全体像がわからなくなってくる
- 分からなくなってるんだけど自分は全体を把握できてると思い込んでしまうところが厄介
- 今作っているものの客観的な仕様やテストケースを、とにかく脳内メモリに貯めずに文章や表や図にすること。言葉にすること
- 特に仕様を表にするのは、文章にするよりも地味に考慮漏れに気づきやすくていい
あと、レビューや検証早め早めに。
