1. 1
赤松 祐希 @ukstuido
RailsDevCon2010
Rails プロジェクトを成功させるために
現場ができること

2. 2
自己紹介

3. 3
名前： 赤松 祐希
a.k.a ukstudio
仕事： Rails プログラマ（フリー
→y.akamatsu@ukstudio.jp
Rails は 1.2.6 ぐらいの頃から

4. 4
WEB+DB Vol.56
コーディングの基礎知識
http://gihyo.jp/magazine/wdpress/archive/2010/vol56

5. 5
成功とはなんぞや

6. 6
お客さんが満足
と仮定

7. 7
お客さんが満足する
ためには提供した
ソフトウェアが価値を
もたらさなければ
ならない

8. 8
要望
コード（ソフトウェア )
価値

9. 9
要望
コード（ソフトウェア )
価値
どれだけ迅速かつ
高品質に行えるか

10. 10
迅速
かつ
高品質

11. 11
動くだけじゃダメ

12. 12
技術的負債
TechnicalDebt

13. 13
小さな負債は代価を得て
即座に書き直す機会を
得るまでの開発を加速する。
危険なのは借金が返済され
なかった場合である。品質の
良くないコードを使い続ける
ことは借金の利息としてとら
えることができる。

14. 14
増える利子と負債
http://www.flickr.com/photos/tracy_olson/61056391/

15. 15
なぜ増えるのか ?

16. 16
” 開発を加速する”

17. 17
迫る納期
増える要求
変わる仕様

18. 18
コードの臭い

19. 19
技術的負債を
持ちこまないために

20. 20

21. 21
みなさんテスト
書いてますか ?

22. 22
テストを書かない
誘惑

23. 23
その裏では負債が
貯まっている

24. 24
テストがないコード
＝ 変更時に困る
＝ 負債

25. 25
無駄のない
設計手法

26. 26
必要最小限の
機能を
ストレスなく
提供する

27. 27
技術的負債の大きな
要因の「依存性」を
排除できるのは
大きい

28. 28

29. 29
コードを後から
改善できる唯一の
方法

30. 30
息を吸うように
リファクタリング

31. 31
返せる負債は
すぐ返す

32. 32
後で返そうと思っても
その時は大抵
別のタスクに
追われている

33. 33
すぐに返せない負債

34. 34
開発プロセスに
組込む
例 : 未解決の負債の解決に
週の 20% をあてる

35. 35
バージョン管理

36. 36
変更を恐れない為に

37. 37
日付管理自体が
負債

38. 38
TDD もやってる
バージョン管理も
導入した

39. 39
現実はそう甘くない

40. 40
既存テストコードが
リファクタリングを
妨げる

41. 41
あるコードを修正した
らテストコードが
落ちまくったでござる

42. 42
テストの資産価値

43. 43
上位のテストで
動作を保証し
下位の自由度を
高める

44. 44
リファクタリングを
支えるテスト

45. 45
極論を言うと
Cucumber のテスト
が通っていれば
Rspec/UnitTest は
全部捨てられる
TDD のテンポを考えれば現実的ではないけど

46. 46
TDD では書きたい
ことしか書けない

47. 47
設計手法

48. 48
設計能力に
依存する部分は
どうしてもある

49. 49
Ruby on Rails
RailsDevCon ですし

50. 50
Skinny Controller,
Fat Model
http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model

51. 51
まだまだ Controller に
数百〜数千行レベルの
ロジックが書かれてるの
をみかける

52. 52
とてもじゃないが
テストが書けない

53. 53
とは言え、モデルに
引きずられすぎ感も
なくはない

54. 54
責務で考える

55. 55
Rails らしさ

56. 56
Rails の機能を
どれだけうまく
使えるか

57. 57
•(named_)scope
•plugin
•migration
•routes
•etc...

58. 58
Rails らしさを共有で
きていれば開発メン
バーでの無駄が減る
コーディング規約にも似たような効果が

59. 59
とりあえず
RailsGuides は
読もう

60. 60
そろそろまとめ

61. 61
技術的負債は開発の
足を遅めるので
貯めこむべきでは
ない

62. 62
逆に負債を抱えて
足を早めるのもあり
納期が存在するので

63. 63
負債はコードだけ
ではない

64. 64
使われない機能

65. 65
使われない機能にも
維持コストはかかる

66. 66
営業ベースで
考えたとき、
機能数を
増やしがち

67. 67
お客さんの要求を理
解していないため
可能性のある限りの
機能を増やしてしまう

68. 68
今のプロジェクトで
どれだけの負債があ
るか考えてみよう

69. 69
技術的負債を 0 に
しても成功するとは
限らない

70. 70
技術的負債を
減らすと見えてくる
課題もある

71. 71
ご静聴ありがとう
ございました