レガシーコードでTDD力を高めよう #agilesamurai
•
13 likes•4,278 views
Agile Samurai Base Camp 2013.12.08(Sun) で事例発表した際の資料です。
レガシーコードでTDD力を高めよう #agilesamurai
- 1. レガシーコードで TDD力を高めよう!! Agile Samurai Base Camp Re:TDD 2014/4/20
- 2. @PoohSunny ● 海外チームと新サービスの立ち上 げに奮闘中。 ● 『レガシーコード改善ガイド』が座 右の書 ● 「テストがないコードはレガシー コードだぁっ！！」ってのがちょっ と前まで口癖
- 8. レガシーコード ● 一部の変更が全てに影響 ○ ジェンガ / スパゲッティ ○ 動いているコードに触るな！ ○ Edit ＆ Pray(変更して祈る) ● テストが書きにくい構造 ○ 実践しようにも...
- 11. 今日の話の対象 ✕ レガシーコードをTDDで 改善しよう ○ レガシーコードで自分の TDD力高めよう ○ 実現までの時間が結構かか る ○ 仲間が必要 ○ 「TDDから」が最適解とは限り ません
- 12. レガシーコードって？
- 13. 私の出会ったレガシーコード ● これはEclipseの画面の右端です。 ● 行数を想像してみてください ○ Javaです。 ○ ざっと数万行です（てへぺろ） ● 青→とある変数にカーソルを当ててみた ○ 長寿の変数
- 14. 私の出会ったレガシーコード（フィクションです） public void legacyMethod(boolean flag1, boolean flag2, HttpServletRequest request){ String code = (String) request.getAttribute("code"); String action = (String) request.getAttribute("action"); List<TargetData> datas = new TargetDataDAO().getTargetData(code); if (action == "1") { if (datas != null && datas.size() != 0) { for (TargetData data : datas) { if ((data.getId() != null && !data.getName() == "") || data.getId == null) { request.setAttribute("data", data); } } 引数が多い！ DBアクセスが近 い ワイド画面でも足 りないifネスト 継ぎ足しされた秘 伝のif条件
- 15. 一体どうTDDしろと... ● どこからテスト書く？ ● いつテスト書く？ ● テストが先かリファクタが先か問題 ○ テストがしやすいように内部構造を変える
- 16. 私が（当時）考えたこと ● テスト書こうとしてバグるのはダメ！ ○ モチベーション下がる ○ 変更が怖くなる ○ 痛みを伴うのはしんどい！ ● まずは小さいところから ○ 大胆な構造改革は仲間が増えてからやろう ● 美味しそうなところをやる
- 18. 手順（引用） 1. 手元で不具合を再現させる。 2. コードを注意深く調べ、不具合を発生させている 最小の部分を絞り込む。 3. 最小レベルで不具合を再現させ、不具合が修 正されたら通るような自動テストコードを書く。 4. 3.で書いたテストコードを実行し、落ちることを確 認する。
- 20. 手順（対レガシーコード） 1. 手元で不具合を再現させる 2. コードを注意深く調べ、不具合を発生させている 最小の部分を絞り込む 3. 最小部分をくくりだす。 4. くくりだした部分にテストを書く。 5. テストを書いたところをリファクタリングする。 6. 最小レベルで不具合を再現させ、～以下同じ
- 22. 最初はif条件文にやるとやりやすい if ((data.getId() != null && !data.getName() == "") || data.getId == null) { if (shouldSetAttribute(data)) { (略) public void shouldSetAttribute(TargetData data){ return (data.getId() != null && !data.getName() == "") || data. getId == null; }
- 23. テストを書いてリファクタリング if (shouldSetAttribute(data)) { public void shouldSetAttribute(TargetData data){ return (data.getId() != null && !data.getName() == "") || data.getId == null; } public void shouldSetAttribute(TargetData data){ if (data.getId == null) return true; return !"".equals(data.getName()) }
- 24. 効果 ● 多くのフィードバックを得られる ○ 名付けはメソッド名は適切？ ○ もっとテストしやすい引数にできない？ ○ もっと読みやすくできない？ ● バグったところはまたバグりやすい ○ 「あなたのこのまえの修正、デグレ起こしてるっぽ いですよ（ドヤッ）」
- 25. 悩ましいポイント ● 大きいメソッドだと難しい ○ 本当に不安な部分にテコ入れできない ● モチベーション管理が難しい ○ 誰かが地雷を踏むまでは一定時間かかる ○ それまで効果があるのかが見えにくい
- 26. 対策：もっと大くくりでテストできない？ ● DBアクセスがいっぱいあってしんどい？ => DBアクセスしてテストしてみたら？ ● 画面からの情報が多くてしんどい？ => 画面の自動テストしてみたら？
- 27. 結果 ● 頑張ればテストは書ける！状態 ○ 安心・健康 ○ 仲間が増える（社内） ○ より大きな構造改革 ● スキルアップ ○ 知らないことをもっと知りたい！という好循環 ○ 仲間が増える（社外）