サービス開発者の読書会 #8「アジャイルサムライ」2012.6.12
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 458 views

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

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

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

Statistics

Views

Total Views
458
Views on SlideShare
458
Embed Views
0

Actions

Likes
1
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \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

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

  • 第五部アジャイルなプログラミング 株式会社コネクトスターサービス開発者向け読書会 越川 直人
  • これはなに• アジャイルサムライ読書会• 第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