アジャイルサムライ読書会、第8回、第9回はアジャイルなプログラミングについてです。テスト駆動開発・リファクタリングなどの重要さと難しさを共有しました。 私達の読書会は、サービス開発に関わる人（プランナー/プログラマー/デザイナーなど誰でも）がよりよいサービス開発のあり方について、お題になった本を通じて、共通認識をもったり知識を交換したり、建設的に議論したりする場です。 2012年4月からは「アジャイルサムライ」を読んでいます。

1. サービス開発者の読書会
アジャイルサムライ
第五部 アジャイルなプログラミング
2012.5.12 株式会社コネクトスター

2. これはなに
• アジャイルサムライ読書会
• 第５部を読んだ前提で議論する資料

3. 第五部
今回は12と13をやります。
• 12.ユニットテスト：動くことが分かる
• 13.リファクタリング：技術的負債の返済
• 14.テスト駆動開発
• 15.継続的インテグレーション：リリースに備える

4. 問答無用で実践すべき
プラクティス
• ユニットテスト
• リファクタリング
• テスト駆動開発(TDD)
• 継続的インテグレーション

5. 12.ユニットテスト：
動くことが分かる

6. デグレードの例
デグレードとは、ソフトウェア開発にお
いて、プログラムを手直しした際に修正
部分以外の個所で不整合・不具合が発生
したり、バージョン管理の手抜かりなど
によって以前の状態に戻ってしまい、修
正済みだったバグが再発したりすること

7. デグレードの例
• 「バグだ と勘違い」したのが問題
• なんでそう思ったんだろう？
testがない！
• 修正されたバグが二度とコードに現れ
ないようにするためには？
testを書こう！

8. テストを書く
• テストとは何か
ブラウザで検証するアレ
excelシートに⃝、×
• どんなイメージがあるか
辛い、面倒くさい、コツコツ

9. テストを書く
• 今までどうやってきた？
みんなでがんばった！、アルバイト？
だめだね

10. 本来のテスト
• バグを修正する前に、失敗するテストを書く
• 自動化して簡単に実行できる
• とはいえブラウザでのテストは必要だよね！
• 見た目はむしろ目で見たほうがイイ！

11. テストコードを
たくさん書くと？
• 素早いフィードバックが得られる
• 極めて低コストにリグレッションテストを
実行できる
• デバッグ時間を大幅に削減できる
• 自信を持ってデプロイできる
(サーバへ上げる時に祈ってませんか？）

12. どこまで書けばいいの？
• ソフトウェアがちゃんと動いていると
確信を持つに足るだけのテストを書
き、労力に見合ったテストになってい
ることを判断する基準が「危なっかし
い所をすべてテストする」だ
• カバレッジは100%を目指すべきか

13. カバレッジは100%を目指すべきか
• 程よいところまでやろう！
• リーンにやるには？
• MVPなところは必ず書く
• 改修の生産性が一番よいところまで！
• エンジニアの精神衛生を保つ

14. testで実感したこと
• 機能を足した時に、古い機能のtestが落
ちた！
• めっちゃいいな、と思った。
• 新しいエンジニアが加わった時！

15. 危なっかしい箇所とは？
みんなで考えよう
• 決済周り
• 複雑な処理

16. レガシーコード
• なにそれ
• レガシーコード改善ガイド
を読もう

17. 引用：レガシーコード改善ガイド
• レガシーコードとは、単にテストのない
コードである

18. 引用：レガシーコード改善ガイド
• テストのないコードは悪いコードである。 どれ
だけうまく書かれているかは関係ない。 どれだ
け美しいか、 オブジェクト指向か、 きちんと
カプセル化されているかは関係ない。 テストが
あれば、 検証しながらコードの動きを素早く
変更できる。 テストがなければ、 コードが良
くなっているのか悪くなっているのかが本当に
は分からない。

19. 13.リファクタリング：
技術的負債の返済

20. 技術的負債
• コードのコピーアンドペースト
• 手抜き、ハック、重複により技術的負
債はたまってく
• 組織で共有されない知識や、複雑すぎ
て変更が難しいコードも

21. リファクタリングで
技術的負債を返済する

22. リファクタリング
• 外部からみたソフトウェア全体の振る
舞いを変えることなく、少しずつ継続
的に設計を改善していく手順
• 振る舞いを変えることないことを担保
する = テスト
• テストがない状態ではリファクタリン
グは不可能

23. 技術的負債の影響
• もし君が変更しづらく、仕事として楽し
めないソフ トウェアを書いてしまったと
しよう。もし、後になってその機能を更
新したり、 新機能を追加したりといった
せっかくの機会がめぐってきたとする。
その時にどんな気分になるだろうか? ちっ
ともわくわくしないんじゃないだろう
か。そんな ことじゃだめなんだ

24. リファクタリング
の仕方
• 一日を通じてたゆまず、継続的にリ
ファクタリングする
• 技術的負債の返済は後になればなるほ
ど難しくなる

26. リファクタリングのポイント
• 変数やメソッド に適切な名前がついて
いるかを確かめる
• 似ている箇所をメソッドに抽出してみ
たらどうだろう?

27. 大掛かりな
リファクタリング
• 外部要因によって変更が発生して、自
分たちでも対処が必要だと判断したな
ら、そのリファクタリングを他のユー
ザーストーリーと同様に扱おう
• プロジェクトの終了は近いか?
• 少しずつやれないか?

28. テスト駆動開発の実例
• C#の例、普段見慣れない
• rubyのコードで実感したい
• sinatraみんな書いたことあるよね
• というわけで以下の実例を見せます
https://github.com/ppworks/rspec_sample

29. KPT
http://kpt-it.herokuapp.com/
9fdaa76993f04b532d3d8604baaefcb5