第五部アジャイルなプログラミング 株式会社コネクトスターサービス開発者向け読書会   越川 直人
これはなに• アジャイルサムライ読書会• 第5部を読んだ前提で議論する資料
第五部     今回は12と13をやります。• 12.ユニットテスト:動くことが分かる• 13.リファクタリング:技術的負債の返済• 14.テスト駆動開発• 15.継続的インテグレーション:リリースに備える
問答無用で実践すべき   プラクティス• ユニットテスト• リファクタリング• テスト駆動開発(TDD)• 継続的インテグレーション
12.ユニットテスト:動くことが分かる
デグレードの例デグレードとは、ソフトウェア開発において、プログラムを手直しした際に修正部分以外の個所で不整合・不具合が発生したり、バージョン管理の手抜かりなどによって以前の状態に戻ってしまい、修正済みだったバグが再発したりすること
デグレードの例• 「バグだ と勘違い」したのが問題• なんでそう思ったんだろう? testがない!• 修正されたバグが二度とコードに現れ ないようにするためには? testを書こう!
テストを書く• テストとは何か ブラウザで検証するアレ excelシートに⃝、ו どんなイメージがあるか 辛い、面倒くさい、コツコツ
テストを書く• 今までどうやってきた? みんなでがんばった!、アルバイト?       だめだね
本来のテスト• バグを修正する前に、失敗するテストを書く• 自動化して簡単に実行できる• とはいえブラウザでのテストは必要だよね!• 見た目はむしろ目で見たほうがイイ!
テストコードを   たくさん書くと?• 素早いフィードバックが得られる• 極めて低コストにリグレッションテストを 実行できる• デバッグ時間を大幅に削減できる• 自信を持ってデプロイできる (サーバへ上げる時に祈ってませんか?)
どこまで書けばいいの?• ソフトウェアがちゃんと動いていると 確信を持つに足るだけのテストを書 き、労力に見合ったテストになってい ることを判断する基準が「危なっかし い所をすべてテストする」だ• カバレッジは100%を目指すべきか
カバレッジは100%を目指すべきか• 程よいところまでやろう!• リーンにやるには?• MVPなところは必ず書く• 改修の生産性が一番よいところまで!• エンジニアの精神衛生を保つ
testで実感したこと• 機能を足した時に、古い機能のtestが落 ちた!• めっちゃいいな、と思った。• 新しいエンジニアが加わった時!
危なっかしい箇所とは?     みんなで考えよう• 決済周り• 複雑な処理
レガシーコード• なにそれ• レガシーコード改善ガイド を読もう
引用:レガシーコード改善ガイド• レガシーコードとは、単にテストのない コードである
引用:レガシーコード改善ガイド• テストのないコードは悪いコードである。 どれ だけうまく書かれているかは関係ない。 どれだ け美しいか、 オブジェクト指向か、 きちんと カプセル化されているかは関係ない。 テストが あれば、 検証しながらコー...
13.リファクタリング: 技術的負債の返済
技術的負債• コードのコピーアンドペースト• 手抜き、ハック、重複により技術的負 債はたまってく• 組織で共有されない知識や、複雑すぎ て変更が難しいコードも
リファクタリングで技術的負債を返済する
リファクタリング• 外部からみたソフトウェア全体の振る 舞いを変えることなく、少しずつ継続 的に設計を改善していく手順• 振る舞いを変えることないことを担保 する = テスト• テストがない状態ではリファクタリン グは不可能
技術的負債の影響• もし君が変更しづらく、仕事として楽し めないソフ トウェアを書いてしまったと しよう。もし、後になってその機能を更 新したり、 新機能を追加したりといった せっかくの機会がめぐってきたとする。 その時にどんな気分になるだろう...
リファクタリング     の仕方• 一日を通じてたゆまず、継続的にリ ファクタリングする• 技術的負債の返済は後になればなるほ ど難しくなる
リファクタリングのポイント• 変数やメソッド に適切な名前がついて いるかを確かめる• 似ている箇所をメソッドに抽出してみ たらどうだろう?
大掛かりな リファクタリング• 外部要因によって変更が発生して、自 分たちでも対処が必要だと判断したな ら、そのリファクタリングを他のユー ザーストーリーと同様に扱おう• プロジェクトの終了は近いか?• 少しずつやれないか?
テスト駆動開発の実例• C#の例、普段見慣れない• rubyのコードで実感したい• sinatraみんな書いたことあるよね• というわけで以下の実例を見せますhttps://github.com/ppworks/rspec_sample
KPT    http://kpt-it.herokuapp.com/9fdaa76993f04b532d3d8604baaefcb5
サービス開発者の読書会 #8「アジャイルサムライ」2012.6.12
Upcoming SlideShare
Loading in...5
×

サービス開発者の読書会 #8「アジャイルサムライ」2012.6.12

471

Published on

サービス開発者の読書会 by ConnectStarで行なっているアジャイルサムライ読書会。

今回は第五部のアジャイルなプログラミングの前半です。

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
471
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Transcript of "サービス開発者の読書会 #8「アジャイルサムライ」2012.6.12"

    1. 1. 第五部アジャイルなプログラミング 株式会社コネクトスターサービス開発者向け読書会 越川 直人
    2. 2. これはなに• アジャイルサムライ読書会• 第5部を読んだ前提で議論する資料
    3. 3. 第五部 今回は12と13をやります。• 12.ユニットテスト:動くことが分かる• 13.リファクタリング:技術的負債の返済• 14.テスト駆動開発• 15.継続的インテグレーション:リリースに備える
    4. 4. 問答無用で実践すべき プラクティス• ユニットテスト• リファクタリング• テスト駆動開発(TDD)• 継続的インテグレーション
    5. 5. 12.ユニットテスト:動くことが分かる
    6. 6. デグレードの例デグレードとは、ソフトウェア開発において、プログラムを手直しした際に修正部分以外の個所で不整合・不具合が発生したり、バージョン管理の手抜かりなどによって以前の状態に戻ってしまい、修正済みだったバグが再発したりすること
    7. 7. デグレードの例• 「バグだ と勘違い」したのが問題• なんでそう思ったんだろう? testがない!• 修正されたバグが二度とコードに現れ ないようにするためには? testを書こう!
    8. 8. テストを書く• テストとは何か ブラウザで検証するアレ excelシートに⃝、ו どんなイメージがあるか 辛い、面倒くさい、コツコツ
    9. 9. テストを書く• 今までどうやってきた? みんなでがんばった!、アルバイト? だめだね
    10. 10. 本来のテスト• バグを修正する前に、失敗するテストを書く• 自動化して簡単に実行できる• とはいえブラウザでのテストは必要だよね!• 見た目はむしろ目で見たほうがイイ!
    11. 11. テストコードを たくさん書くと?• 素早いフィードバックが得られる• 極めて低コストにリグレッションテストを 実行できる• デバッグ時間を大幅に削減できる• 自信を持ってデプロイできる (サーバへ上げる時に祈ってませんか?)
    12. 12. どこまで書けばいいの?• ソフトウェアがちゃんと動いていると 確信を持つに足るだけのテストを書 き、労力に見合ったテストになってい ることを判断する基準が「危なっかし い所をすべてテストする」だ• カバレッジは100%を目指すべきか
    13. 13. カバレッジは100%を目指すべきか• 程よいところまでやろう!• リーンにやるには?• MVPなところは必ず書く• 改修の生産性が一番よいところまで!• エンジニアの精神衛生を保つ
    14. 14. testで実感したこと• 機能を足した時に、古い機能のtestが落 ちた!• めっちゃいいな、と思った。• 新しいエンジニアが加わった時!
    15. 15. 危なっかしい箇所とは? みんなで考えよう• 決済周り• 複雑な処理
    16. 16. レガシーコード• なにそれ• レガシーコード改善ガイド を読もう
    17. 17. 引用:レガシーコード改善ガイド• レガシーコードとは、単にテストのない コードである
    18. 18. 引用:レガシーコード改善ガイド• テストのないコードは悪いコードである。 どれ だけうまく書かれているかは関係ない。 どれだ け美しいか、 オブジェクト指向か、 きちんと カプセル化されているかは関係ない。 テストが あれば、 検証しながらコードの動きを素早く 変更できる。 テストがなければ、 コードが良 くなっているのか悪くなっているのかが本当に は分からない。
    19. 19. 13.リファクタリング: 技術的負債の返済
    20. 20. 技術的負債• コードのコピーアンドペースト• 手抜き、ハック、重複により技術的負 債はたまってく• 組織で共有されない知識や、複雑すぎ て変更が難しいコードも
    21. 21. リファクタリングで技術的負債を返済する
    22. 22. リファクタリング• 外部からみたソフトウェア全体の振る 舞いを変えることなく、少しずつ継続 的に設計を改善していく手順• 振る舞いを変えることないことを担保 する = テスト• テストがない状態ではリファクタリン グは不可能
    23. 23. 技術的負債の影響• もし君が変更しづらく、仕事として楽し めないソフ トウェアを書いてしまったと しよう。もし、後になってその機能を更 新したり、 新機能を追加したりといった せっかくの機会がめぐってきたとする。 その時にどんな気分になるだろうか? ちっ ともわくわくしないんじゃないだろう か。そんな ことじゃだめなんだ
    24. 24. リファクタリング の仕方• 一日を通じてたゆまず、継続的にリ ファクタリングする• 技術的負債の返済は後になればなるほ ど難しくなる
    25. 25. リファクタリングのポイント• 変数やメソッド に適切な名前がついて いるかを確かめる• 似ている箇所をメソッドに抽出してみ たらどうだろう?
    26. 26. 大掛かりな リファクタリング• 外部要因によって変更が発生して、自 分たちでも対処が必要だと判断したな ら、そのリファクタリングを他のユー ザーストーリーと同様に扱おう• プロジェクトの終了は近いか?• 少しずつやれないか?
    27. 27. テスト駆動開発の実例• C#の例、普段見慣れない• rubyのコードで実感したい• sinatraみんな書いたことあるよね• というわけで以下の実例を見せますhttps://github.com/ppworks/rspec_sample
    28. 28. KPT http://kpt-it.herokuapp.com/9fdaa76993f04b532d3d8604baaefcb5
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×