Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
1
赤松 祐希 @ukstuido
RailsDevCon2010
Rails プロジェクトを成功させるために
現場ができること
2
自己紹介
3
名前: 赤松 祐希
a.k.a ukstudio
仕事: Rails プログラマ(フリー
→y.akamatsu@ukstudio.jp
Rails は 1.2.6 ぐらいの頃から
4
WEB+DB Vol.56
コーディングの基礎知識
http://gihyo.jp/magazine/wdpress/archive/2010/vol56
5
成功とはなんぞや
6
お客さんが満足
と仮定
7
お客さんが満足する
ためには提供した
ソフトウェアが価値を
もたらさなければ
ならない
8
要望
コード(ソフトウェア )
価値
9
要望
コード(ソフトウェア )
価値
どれだけ迅速かつ
高品質に行えるか
10
迅速
かつ
高品質
11
動くだけじゃダメ
12
技術的負債
TechnicalDebt
13
小さな負債は代価を得て
即座に書き直す機会を
得るまでの開発を加速する。
危険なのは借金が返済され
なかった場合である。品質の
良くないコードを使い続ける
ことは借金の利息としてとら
えることができる。
14
増える利子と負債
http://www.flickr.com/photos/tracy_olson/61056391/
15
なぜ増えるのか ?
16
” 開発を加速する”
17
迫る納期
増える要求
変わる仕様
18
コードの臭い
19
技術的負債を
持ちこまないために
20
21
みなさんテスト
書いてますか ?
22
テストを書かない
誘惑
23
その裏では負債が
貯まっている
24
テストがないコード
= 変更時に困る
= 負債
25
無駄のない
設計手法
26
必要最小限の
機能を
ストレスなく
提供する
27
技術的負債の大きな
要因の「依存性」を
排除できるのは
大きい
28
29
コードを後から
改善できる唯一の
方法
30
息を吸うように
リファクタリング
31
返せる負債は
すぐ返す
32
後で返そうと思っても
その時は大抵
別のタスクに
追われている
33
すぐに返せない負債
34
開発プロセスに
組込む
例 : 未解決の負債の解決に
週の 20% をあてる
35
バージョン管理
36
変更を恐れない為に
37
日付管理自体が
負債
38
TDD もやってる
バージョン管理も
導入した
39
現実はそう甘くない
40
既存テストコードが
リファクタリングを
妨げる
41
あるコードを修正した
らテストコードが
落ちまくったでござる
42
テストの資産価値
43
上位のテストで
動作を保証し
下位の自由度を
高める
44
リファクタリングを
支えるテスト
45
極論を言うと
Cucumber のテスト
が通っていれば
Rspec/UnitTest は
全部捨てられる
TDD のテンポを考えれば現実的ではないけど
46
TDD では書きたい
ことしか書けない
47
設計手法
48
設計能力に
依存する部分は
どうしてもある
49
Ruby on Rails
RailsDevCon ですし
50
Skinny Controller,
Fat Model
http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model
51
まだまだ Controller に
数百〜数千行レベルの
ロジックが書かれてるの
をみかける
52
とてもじゃないが
テストが書けない
53
とは言え、モデルに
引きずられすぎ感も
なくはない
54
責務で考える
55
Rails らしさ
56
Rails の機能を
どれだけうまく
使えるか
57
•(named_)scope
•plugin
•migration
•routes
•etc...
58
Rails らしさを共有で
きていれば開発メン
バーでの無駄が減る
コーディング規約にも似たような効果が
59
とりあえず
RailsGuides は
読もう
60
そろそろまとめ
61
技術的負債は開発の
足を遅めるので
貯めこむべきでは
ない
62
逆に負債を抱えて
足を早めるのもあり
納期が存在するので
63
負債はコードだけ
ではない
64
使われない機能
65
使われない機能にも
維持コストはかかる
66
営業ベースで
考えたとき、
機能数を
増やしがち
67
お客さんの要求を理
解していないため
可能性のある限りの
機能を増やしてしまう
68
今のプロジェクトで
どれだけの負債があ
るか考えてみよう
69
技術的負債を 0 に
しても成功するとは
限らない
70
技術的負債を
減らすと見えてくる
課題もある
71
ご静聴ありがとう
ございました
Upcoming SlideShare
Loading in …5
×

Railsプロジェクトを成功させるために現場ができること -Railsdevcon2010

4,960 views

Published on

Railsプロジェクトを成功させるために現場ができること -Railsdevcon2010

  1. 1. 1 赤松 祐希 @ukstuido RailsDevCon2010 Rails プロジェクトを成功させるために 現場ができること
  2. 2. 2 自己紹介
  3. 3. 3 名前: 赤松 祐希 a.k.a ukstudio 仕事: Rails プログラマ(フリー →y.akamatsu@ukstudio.jp Rails は 1.2.6 ぐらいの頃から
  4. 4. 4 WEB+DB Vol.56 コーディングの基礎知識 http://gihyo.jp/magazine/wdpress/archive/2010/vol56
  5. 5. 5 成功とはなんぞや
  6. 6. 6 お客さんが満足 と仮定
  7. 7. 7 お客さんが満足する ためには提供した ソフトウェアが価値を もたらさなければ ならない
  8. 8. 8 要望 コード(ソフトウェア ) 価値
  9. 9. 9 要望 コード(ソフトウェア ) 価値 どれだけ迅速かつ 高品質に行えるか
  10. 10. 10 迅速 かつ 高品質
  11. 11. 11 動くだけじゃダメ
  12. 12. 12 技術的負債 TechnicalDebt
  13. 13. 13 小さな負債は代価を得て 即座に書き直す機会を 得るまでの開発を加速する。 危険なのは借金が返済され なかった場合である。品質の 良くないコードを使い続ける ことは借金の利息としてとら えることができる。
  14. 14. 14 増える利子と負債 http://www.flickr.com/photos/tracy_olson/61056391/
  15. 15. 15 なぜ増えるのか ?
  16. 16. 16 ” 開発を加速する”
  17. 17. 17 迫る納期 増える要求 変わる仕様
  18. 18. 18 コードの臭い
  19. 19. 19 技術的負債を 持ちこまないために
  20. 20. 20
  21. 21. 21 みなさんテスト 書いてますか ?
  22. 22. 22 テストを書かない 誘惑
  23. 23. 23 その裏では負債が 貯まっている
  24. 24. 24 テストがないコード = 変更時に困る = 負債
  25. 25. 25 無駄のない 設計手法
  26. 26. 26 必要最小限の 機能を ストレスなく 提供する
  27. 27. 27 技術的負債の大きな 要因の「依存性」を 排除できるのは 大きい
  28. 28. 28
  29. 29. 29 コードを後から 改善できる唯一の 方法
  30. 30. 30 息を吸うように リファクタリング
  31. 31. 31 返せる負債は すぐ返す
  32. 32. 32 後で返そうと思っても その時は大抵 別のタスクに 追われている
  33. 33. 33 すぐに返せない負債
  34. 34. 34 開発プロセスに 組込む 例 : 未解決の負債の解決に 週の 20% をあてる
  35. 35. 35 バージョン管理
  36. 36. 36 変更を恐れない為に
  37. 37. 37 日付管理自体が 負債
  38. 38. 38 TDD もやってる バージョン管理も 導入した
  39. 39. 39 現実はそう甘くない
  40. 40. 40 既存テストコードが リファクタリングを 妨げる
  41. 41. 41 あるコードを修正した らテストコードが 落ちまくったでござる
  42. 42. 42 テストの資産価値
  43. 43. 43 上位のテストで 動作を保証し 下位の自由度を 高める
  44. 44. 44 リファクタリングを 支えるテスト
  45. 45. 45 極論を言うと Cucumber のテスト が通っていれば Rspec/UnitTest は 全部捨てられる TDD のテンポを考えれば現実的ではないけど
  46. 46. 46 TDD では書きたい ことしか書けない
  47. 47. 47 設計手法
  48. 48. 48 設計能力に 依存する部分は どうしてもある
  49. 49. 49 Ruby on Rails RailsDevCon ですし
  50. 50. 50 Skinny Controller, Fat Model http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model
  51. 51. 51 まだまだ Controller に 数百〜数千行レベルの ロジックが書かれてるの をみかける
  52. 52. 52 とてもじゃないが テストが書けない
  53. 53. 53 とは言え、モデルに 引きずられすぎ感も なくはない
  54. 54. 54 責務で考える
  55. 55. 55 Rails らしさ
  56. 56. 56 Rails の機能を どれだけうまく 使えるか
  57. 57. 57 •(named_)scope •plugin •migration •routes •etc...
  58. 58. 58 Rails らしさを共有で きていれば開発メン バーでの無駄が減る コーディング規約にも似たような効果が
  59. 59. 59 とりあえず RailsGuides は 読もう
  60. 60. 60 そろそろまとめ
  61. 61. 61 技術的負債は開発の 足を遅めるので 貯めこむべきでは ない
  62. 62. 62 逆に負債を抱えて 足を早めるのもあり 納期が存在するので
  63. 63. 63 負債はコードだけ ではない
  64. 64. 64 使われない機能
  65. 65. 65 使われない機能にも 維持コストはかかる
  66. 66. 66 営業ベースで 考えたとき、 機能数を 増やしがち
  67. 67. 67 お客さんの要求を理 解していないため 可能性のある限りの 機能を増やしてしまう
  68. 68. 68 今のプロジェクトで どれだけの負債があ るか考えてみよう
  69. 69. 69 技術的負債を 0 に しても成功するとは 限らない
  70. 70. 70 技術的負債を 減らすと見えてくる 課題もある
  71. 71. 71 ご静聴ありがとう ございました

×