Okayama Ruby Kaigi01 nomura laboratory

1. ～入門から慣れるまで～
2011年8月26日
三原 俊介

2. 自己紹介
三原 俊介 （みはら しゅんすけ）
Twi*erID
@asaborake
(1)
岡山の大学でグループウェアを研究中
(2)
Rails歴
(A) 研究室に入り初めてRailsに触れる
(B)
Railsを元にしてWebフレームワークを勉強
(C)
使い始めて2年半
そろそろ慣れてきたって言っても恥ずかしくない！
はず...
(D)
研究室でRailsを利用して研究成果物を作成
勉強してきたことを共有
2

3. 今回の内容
第一条 モデルの作成は慎重にするべし!
第二条 テストしやすいコードを心がけるべし!
第三条 国際化は多国語未対応でも使うべし!
第四条 ビジネスロジックはモデルに書くべし!
第五条 安易な継承をするべからず!
3

4. 今回の内容
第一条 モデルの作成は慎重にするべし!
第二条 テストしやすいコードを心がけるべし!
第三条 国際化は多国語未対応でも使うべし!
第四条 ビジネスロジックはモデルに書くべし!
第五条 安易な継承をするべからず!
4

5. 事例
機能の追加と拡張を(場当たり的に)続けてきた
統一性がないモデルが多く存在
例1) フラグを管理するカラム名
english，is_english，english_flag
例2) 省略の使い方
ML?モデルとMailinglist?モデル．abbrevとabbreviation
例３) 同じもの別の名称
? Filterモデルと?Scopeモデル，noteとdescription
リファクタリングすることを決める
Railsにはマイグレーションがあるから簡単にやれるだろう
そんなふうに考えていた時期が僕にもありました
5

6. トラブル
ビューやコントローラを大量の修正箇所が!
一見動くけど，実はデータが変更されていない!
[原因]
Conven@on
over
Configura@onのために，モデルに関連する名前
は，ビューとコントローラ内に大量に使用されている
モデル名とカラム名のリファクタリングに伴なう修正点が
アプリケーション中に散在していた
6

7. 教訓
マイグレーションがあっても簡単にモデルの変更はできない
モデルを作る際は慎重に
あとで名前に手を加えるのは大変
テストも重要だと認識！
7

8. 今回の内容
第一条 モデルの作成は慎重にするべし!
第二条 テストしやすいコードを心がけるべし!
第三条 国際化は多国語未対応でも使うべし!
第四条 ビジネスロジックはモデルに書くべし!
第五条 安易な継承をするべからず!
8

9. 事例
モデルのリファクタリングを通してテストの重要性に気がつく
Rails（Ruby）はテストコードで動作を保証しないと，スペルミスを
していても例外を発生させず動くことがよくある
意図しない挙動を見つけるのが手間
意図した通りに動いていることを保証する仕組みが必要
Cucumber(受け入れテスト用ツール)導入
9

10. トラブル
Cucumberでは一部のページのテストができない!
[原因]
CucumberではCapybara(Rackアプリケーションのテストツール)
を利用してテストを実行
JavaScriptを利用したページ遷移はテストができない
JavaScriptがoffの時にページ遷移する手段がない
10

11. 教訓
Rubyはテストコードによって動作を保証するもの
テストを書くこと前提でコードを書く
（１）JavaScriptを多用しすぎない(Unobtrusive
JavaScript)
（２）RESTを意識したページ遷移をする
11

12. 今回の内容
第一条 モデルの作成は慎重にするべし!
第二条 テストしやすいコードを心がけるべし!
第三条 国際化は多国語未対応でも使うべし!
第四条 ビジネスロジックはモデルに書くべし!
第五条 安易な継承をするべからず!
12

13. 事例
Cucumberではシナリオを利用してテストを実行
Scenario:
メンバの作成:正常系
When
"新規登録"リンクをクリックする
And
以下の項目を入力する:
|
member_name
|
岡大
三郎
|
|
member_login_name
|
saburo
|
|
member_mail_address
|
saburo@exmaple.com
|
And
"作成"ボタンをクリックする
Then
/successfully
created/と表示されていること
Scenario:
計算機の作成:正常系
When
“新規追加"リンクをクリックする
And
以下の項目を入力する:
|
machine_name
|
岡大PC
|
|
os
|
Windows
Vista
|
And
"
create"ボタンをクリックする
Then
/正しく登録されました/と表示されていること
13

14. トラブル
表示されている文字に統一性が無い!
例1) 新規作成画面のsubmitボタン => 「作成」「登録」「Create」
例2) Productモデルのcodeカラム
一覧画面では，「コード」
詳細画面では，「商品コード」
新規作成画面では，「製品番号」
[原因]
(1) 対応する日本語を決めずに実装
(2) 様々なタイミングで様々な人がviewのファイルを追加
14

15. 教訓
国際化(i18n)は多国語未対応でも使うほうが良い
i18nとは
Rails 2.2から導入された国際化を支援する機能
config/locales/translation_ja.yml
ja:
common:
word:
create:
“作成"
activerecord:
attributes:
product:
code:
“商品コード”
15

16. 今回の内容
第一条 モデルの作成は慎重にするべし!
第二条 テストしやすいコードを心がけるべし!
第三条 国際化は多国語未対応でも使うべし!
第四条 ビジネスロジックはモデルに書くべし!
第五条 安易な継承をするべからず!
16

17. 事例
Railsを使ってショッピングアプリケーションを作成
（１）Productモデルを作成
（２）ShopコントローラにProductを操作するsellアクションを作成
ポイントカード機能を付けよう
（３）Cardモデルを作成
（４）sellアクションにCardモデルを操作する処理を追加
特売日機能を付けよう
（５）Calenderモデルを作成
（６）sellアクションでCalenderモデルを参照して割引処理
予約販売機能を付けよう
（７）sellアクションをコピペして・・・
やってしまいがち
17

18. トラブル
コントローラに手を加えるとデータの整合性が
崩れる!
単体テストでデータの整合性がテストできない!
コードの再利用がしづらい!
[原因]
コントローラに多くのデータの整合性を取る処理が記述
ActiveRecordを利用すると，データベースのオブジェクトのように
扱えるため，複数のモデルの複数のカラムを操作する処理をコン
トローラに書きがちになる
18

19. 教訓
整合性を処理するビジネスロジックはモデル側に実装する
MVCモデルに沿った形でRailsを利用
データの整合性はモデルが管理
モデルに比べてコントローラは頻繁に手を加える
手を加えた影響が広範囲に広がらないように
19

20. 今回の内容
第一条 モデルの作成は慎重にするべし!
第二条 テストしやすいコードを心がけるべし!
第三条 国際化は多国語未対応でも使うべし!
第四条 ビジネスロジックはモデルに書くべし!
第五条 安易な継承をするべからず!
20

21. 事例
文書管理システムを作成
扱う文書の種別
(A)日報
(B)検討資料
(C)議事録
(1) 文書(Document)モデルを作成
(2) 文書モデルを継承して、種別のモデルを作成
単一テーブル継承(SIT)を使ってきれいにコードが書ける
・・・と喜んでいました
21

22. トラブル
間違えて「提出資料」としてアップロードした文
書を，「議事録」に変更することができない!
[原因]
単一テーブル継承（STI）が便利なので，振る舞いの違いを安易に
継承を利用して実装したこと
22

23. 教訓
「継承よりも委譲」の原則を守る
＜例の場合＞
文書モデルとして生成し，委譲 Mix-in(プラグイン)を利用して種別
の振る舞いを変える
23

24. まとめ
第一条 モデルの作成は慎重にするべし!
第二条 テストしやすいコードを心がけるべし!
第三条 国際化は多国語未対応でも使うべし!
第四条 ビジネスロジックはモデルに書くべし!
第五条 安易な継承をするべからず!
参考になるものがあれば幸いです
ご清聴ありがとうございました
24