Ruby on Railsで変わるエンタープライズ開発の現場株式会社万 … · Ruby on Rails 知っている使ったことがある自社システム受託開発案件

Ruby on Railsで変わるエンタープライズ開発の現場

株式会社万葉　大場寧子2009.4.9 QCon Tokyo 2009

2009年4月9日木曜日

Ruby on Rails✓知っている✓使ったことがある✓自社システム✓受託開発案件


今日のテーマ

Railsをエンタープライズで普通に使う


Railsの採用•本当に使える？•メリット•リスク•成功させるコツ


自己紹介

•大場寧子•Award on Rails 2006 大賞

•株式会社万葉2009年4月9日木曜日

小槌アカウント間で連携する

Web家計簿


Rails歴•2006～2009•15人くらいまでのチームで開発

•SNS、旅行、EC、業務系など


逆引きクイックリファレンス

•RoR開発の実践逆引き辞典•毎日コミュニケーションズ•532p•3675円


２つの視点

•経営者•プログラマ


ビジネス寄り

•JavaからRubyへ•元々軽量言語が好きだったわけではない


Railsは本当に使える？


プログラマの主張

Rubyは楽しい


警戒される

楽しい = 怪しい


リスク


リスク

•Ruby大丈夫？•エンジニア確保？•楽しいだけじゃ困る


楽しさとリスク•楽しくない言語Ｘに関するリスク

•楽しい言語Ｙに関するリスク


楽しさとリスクはあまり関係ない！


楽しさの前に

•楽しさは結果である•結果には理由がある


理由はつながっている


経営者がRailsを使う３つの理由


早いリリース

•約束されている•期待できる


早いリリースの実現度

成功

失敗

システムの規模・複雑さ

スキル＆

ノウハウ


早いリリースが期待できる理由

•コード量が少ない•コンパイルを待たない


コードが少ない

•Rubyの特徴•人間志向•型宣言なし


Rubyは柔軟

•壁を迂回しない•本質を書くだけ


ある種の言語


悲観的性悪説

高い堅牢な壁2009年4月9日木曜日

Rubyの風景


楽観的性善説自由


Railsは少ないコードで書ける


Railsとコード量

•豊富な機能•規約の活用•DRY


DRY•Don’t Repeat Yourself

•同じことをあちこちに書かない


Ruby × Rails•打鍵数が少ない•把握すべきコードの絶対的文字数が少ない

•時間的に有利！2009年4月9日木曜日

コンパイルを待たない

•書いたコードがそのまま実行される

•すぐ確認できる2009年4月9日木曜日

コンパイルを待つのは辛い•思考の中断•待ち時間にほかのことを始める


集中がとぎれる•フロー状態•中断されると、再開に15分かかる

Tom DeMarco & Timothy Lister “Peopleware - 2nd Edition Productive Projects and Teams”


Rubyなら•最小限のコードで•素早く確認しながら•動くものが早く出来上がる


ビジネス価値

•すばやく立ち上げる•プロトタイピング


安く開発


本当に？

•ある程度YES


安く開発の成功度成功

失敗

システムの規模・複雑さ

スキル＆

ノウハウ


少人数での開発少人数でも

開発体制、手順とRailsの組み合わせで大規模開発に匹敵できる


誤解

Javaで作るのと同じようにRubyで作ったら安くなる


安さの源Ruby、Railsの生産性Railsのコストパフォーマンスを追求プログラマが楽しい

×　単価

※注）脳内イメージです2009年4月9日木曜日

Railsの生産性は、ある種の領域で高い


イメージコストRailsの恩恵

完璧さよくある要件2009年4月9日木曜日

変更に強い


変更に強いことのビジネス価値

•ニーズへの素早い対応•小さく始めて育てる•システムの寿命を長く


変更に強い理由

•Ruby•Rails•文化


Ruby

•変更を阻害する壁が低い

•読みやすく書ける2009年4月9日木曜日

Rails•DRY•どこに何が書いてあるべきか決まっている

•DBの管理がしやすい2009年4月9日木曜日

RDBのくびきからの解放


文化

•変更を嫌がらない•どんどん変える•進化が早い


ただし特性を活かすか殺すかで結果が変わる


ほかのメリット•環境構築が簡単•エンジニアが育つ•カスタマイズできる•複雑なものを作るのに向く


環境構築が簡単•フルスタック•DBツール、テストの仕組み、ログ、国際化etc


これだけ

> rails MyApp


エンジニアが育つRailsには

開発に関して良いとされる

プラクティスが詰め込まれている


Railsを学ぶと

良いとされている開発の考え方を同時に学べる


エッセンスの例•MVC•DRY, CoC•O/R Mapping•TDD, BDD


カスタマイズ

フレームワークに不満があれば

自分でカスタマイズ


複雑なものを作るのに向く


軽量言語の一般的イメージ•手軽•簡単なもの向き•複雑なものは無理


Rubyは

•オブジェクト指向•構造化しやすい•複雑化に耐える


イメージコスト

複雑さ2009年4月9日木曜日

メリットの１つ

•プログラマが楽しい


ポール・グレアム

素晴らしい仕事をするには、それをするのに無理をする必要がないほどに好きなことを何か見つければいいからだ。

「How to Do What You Love - 好きなことをやるには」http://www.naochan.com/deprecated/2006/01/19/


情熱2009年4月9日木曜日

Rails のリスク


Railsのリスク

•高負荷•可用性•速度


工夫できる

•分散•shared-nothing 方式


COOKPAD


頻繁なバージョンアップ


ついて行く？

•作業が発生•新しい不具合•知識が固定化しない


困る点•日本語の書籍や情報が追いつかない

•プラグインが死亡するリスク


エンジニアの調達


認定試験

•Ruby技術者認定試験•2007年10月に開始


Rails活用のツボ


取捨選択•80%達成で満足する•レールに乗る•こだわりは追求する


戦略的な選択コストRailsの恩恵

完璧さよくある要件2009年4月9日木曜日

開発手法•アジャイル•リズミカルに積み上げる

•テスト駆動開発2009年4月9日木曜日

レイヤーで担当者を分けない


レイヤーで分けると

•設計する人•実装する人•ビジネスロジックを書く人•画面まわりを書く人•テストする人


せっかくRailsなのに


Railsでは

•設計と実装が地続き•行ったり来たりする•それが効率的


レイヤーごとに分断するのは大きなロス


どうするか•機能で分担•全員、設計からテストまで担当

•すべて他人と共有2009年4月9日木曜日

開発体制の例•ペアで開発する•４人くらいまでを１ユニットとして、ユニットを増やす

•担当を固定化しない2009年4月9日木曜日

文化

•良い名前をつける•コードをDRYにする•多様性


名前づけ•時間をかけてよい•皆で決める•もっといい名前があったら変える


DRY

•日常的に目指す•２回目が重要


多様性•強制はRubyの柔軟性・楽しさを殺す

•方向を決め、やり方には多様性を持たせる


変更しやすくする

•DRY•名前•適切なところに書く•シンプルなほうを選ぶ


変更しやすくする

•適切な単体テスト•変更を歓迎する文化•git, SVN等を使う


変更しやすくする•リリース工程の自動化•継続的インテグレーション

•CruiseControl2009年4月9日木曜日

リスクへの目配り


パフォーマンス•セッションの使い方•キャッシュを意識する•ActiveRecord•分散


情報の入手•書籍•インターネット•英語で調べる•コミュニティ参加


バージョンアップ

ついていく2009年4月9日木曜日

バージョンアップ•速くなる•コードが少なくなる•最新の技術•最新の考え方


ついていかないと•サポートされない•新しいRailsやプラグインの生産性が得られない

•技術力の相対的な低下2009年4月9日木曜日

問題は•バージョンアップすべきか？

•バージョンアップするためにどうするか？


準備する•合意を作っておく•バージョンアップ作業を計画にいれておく

•テストを書いておく2009年4月9日木曜日

覚悟する

•いざとなったらRailsのコードを追う


まとめ•Ruby、Railsを企業で活用するには

•新しい考え方、スタイル•始まっています


Documents

Ruby on Railsで変わる エンタープライズ 開発の現場 株式会社万 … · Ruby on Rails 知っている 使ったことがある 自社システム 受託開発案件

Ruby on Railsで変わるエンタープライズ開発の現場株式会社万 … · Ruby on Rails 知っている使ったことがある自社システム受託開発案件