railsプロジェクトを成功させるために現場ができること -railsdevcon2010
TRANSCRIPT
1
赤松 祐希 @ukstuidoRailsDevCon2010
Rails プロジェクトを成功させるために現場ができること
2
自己紹介
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 RailsRailsDevCon ですし
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
ご静聴ありがとうございました