Agile Samurai Base Camp 2013.12.08(Sun) で事例発表した際の資料です。

1. レガシーコードで
TDD力を高めよう!!
Agile Samurai Base Camp Re:TDD
2014/4/20

2. @PoohSunny
● 海外チームと新サービスの立ち上
げに奮闘中。
● 『レガシーコード改善ガイド』が座
右の書
● 「テストがないコードはレガシー
コードだぁっ！！」ってのがちょっ
と前まで口癖

3. はじめに
今日一日おつかれさまー！

4. 挙手！
今日TDDを体感してみて
「明日からTDDやってみたい
なー」
って思った人！

5. 挙手！
今日TDDを体感してみて
「明日から現場でTDDできそう
だ！」
って思った人！

6. 実践できる？
現場でいきなり
使うのは
なかなか難しい
なんで？

8. レガシーコード
● 一部の変更が全てに影響
○ ジェンガ / スパゲッティ
○ 動いているコードに触るな！
○ Edit ＆ Pray(変更して祈る)
● テストが書きにくい構造
○ 実践しようにも...

9. このままではイベントの目的が...
テスト駆動開発はソフトウェアの質を確
実に向上させ、日々の成果に直結し
ています。これもエンジニアひとりから
明日から始めることができます。
Agile Samurai Base CampのHP

10. というわけで今日は
レガシーコードでもTDDの実践するに
はどうしたらいいのか、
という最初の一歩の話しまーす
（経験談）。

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. 私が（当時）考えたこと
● テスト書こうとしてバグるのはダメ！
○ モチベーション下がる
○ 変更が怖くなる
○ 痛みを伴うのはしんどい！
● まずは小さいところから
○ 大胆な構造改革は仲間が増えてからやろう
● 美味しそうなところをやる

17. オススメパターン
不具合に
テストを書いて
立ち向かう
和田 卓人

18. 手順（引用）
1. 手元で不具合を再現させる。
2. コードを注意深く調べ、不具合を発生させている
最小の部分を絞り込む。
3. 最小レベルで不具合を再現させ、不具合が修
正されたら通るような自動テストコードを書く。
4. 3.で書いたテストコードを実行し、落ちることを確
認する。

19. 手順（引用）
5. 不具合を修正する。
6. 3で書いたテストコードが通ることを確認する。
7.既存の全てのテストを実行し、不具合修正が他
の部分を壊していないことを確認する。

20. 手順（対レガシーコード）
1. 手元で不具合を再現させる
2. コードを注意深く調べ、不具合を発生させている
最小の部分を絞り込む
3. 最小部分をくくりだす。
4. くくりだした部分にテストを書く。
5. テストを書いたところをリファクタリングする。
6. 最小レベルで不具合を再現させ、～以下同じ

21. TDDしたい箇所をくくりだす。
● スプラウトメソッド、とか呼ばれる手法
○ メソッドの抽出リファクタを実行してみる
○ そこにテストを書く

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. 結果
● 頑張ればテストは書ける！状態
○ 安心・健康
○ 仲間が増える（社内）
○ より大きな構造改革
● スキルアップ
○ 知らないことをもっと知りたい！という好循環
○ 仲間が増える（社外）

28. まとめ（言いたかったこと）
● レガシーコードでも、工夫次
第でTDDできるよ！
● もし悩みがあれば、みんなで
共有しよう！

29. 駆け足すぎた？
質問お待ちしてます！
（もっと突っ込んで話したいこともあったし、質
問してもらえるとそういうのにも答えられたりす
るかと。）

30. みんな無理せずレガシーコード改善やろうぜ！
おしまい。
質問お待ちしていますー！