1
赤松 祐希 @ukstuidoRailsDevCon2010
Rails プロジェクトを成功させるために現場ができること
3
名前: 赤松 祐希a.k.a ukstudio
仕事: Rails プログラマ(フリー→[email protected]
Rails は 1.2.6 ぐらいの頃から
4
WEB+DB Vol.56コーディングの基礎知識
http://gihyo.jp/magazine/wdpress/archive/2010/vol56
7
お客さんが満足するためには提供した
ソフトウェアが価値をもたらさなければ
ならない
8
要望
コード(ソフトウェア )
価値
9
要望
コード(ソフトウェア )
価値
どれだけ迅速かつ高品質に行えるか
12
技術的負債TechnicalDebt
13
小さな負債は代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは借金が返済されなかった場合である。品質の良くないコードを使い続けることは借金の利息としてとらえることができる。
14
増える利子と負債
http://www.flickr.com/photos/tracy_olson/61056391/
17
迫る納期増える要求変わる仕様
19
技術的負債を持ちこまないために
21
みなさんテスト書いてますか ?
23
その裏では負債が貯まっている
24
テストがないコード= 変更時に困る= 負債
26
必要最小限の機能を
ストレスなく提供する
27
技術的負債の大きな要因の「依存性」を
排除できるのは大きい
29
コードを後から改善できる唯一の
方法
30
息を吸うようにリファクタリング
32
後で返そうと思ってもその時は大抵別のタスクに追われている
34
開発プロセスに組込む
例 : 未解決の負債の解決に週の 20% をあてる
38
TDD もやってるバージョン管理も導入した
40
既存テストコードがリファクタリングを
妨げる
41
あるコードを修正したらテストコードが落ちまくったでござる
43
上位のテストで動作を保証し下位の自由度を
高める
44
リファクタリングを支えるテスト
45
極論を言うとCucumber のテストが通っていればRspec/UnitTest は全部捨てられるTDD のテンポを考えれば現実的ではないけど
46
TDD では書きたいことしか書けない
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
とは言え、モデルに引きずられすぎ感も
なくはない
56
Rails の機能をどれだけうまく
使えるか
57
•(named_)scope•plugin•migration•routes•etc...
58
Rails らしさを共有できていれば開発メンバーでの無駄が減る
コーディング規約にも似たような効果が
59
とりあえずRailsGuides は
読もう
61
技術的負債は開発の足を遅めるので
貯めこむべきではない
62
逆に負債を抱えて足を早めるのもあり
納期が存在するので
65
使われない機能にも維持コストはかかる
66
営業ベースで考えたとき、機能数を
増やしがち
67
お客さんの要求を理解していないため可能性のある限りの機能を増やしてしまう
68
今のプロジェクトでどれだけの負債があ
るか考えてみよう
69
技術的負債を 0 にしても成功するとは
限らない
70
技術的負債を減らすと見えてくる課題もある
71
ご静聴ありがとうございました