Convention Over Configuration

1

生産性UPの秘訣

Masayuki KimuraNaoki Takezoe

Shota Onishi

appendix

オープニングトーク&Spring　 17:20～17:30Ruby on Rails　17:30～17:45Seasar2 17:45～18:00最後に

profile

2

• 木村　真幸（Masayuki　Kimura）– 株式会社DTS　シニア・プロジェクトマネージャ

• 技術支援、開発プロセス定義、フレームワーク開発、IDE開発、講師等

– 課外活動• 注目のJavaフレームワーク詳細解説（ITPro）

• “使える”Eclipseプラグイン徹底攻略（ITPro）

• StrutsIDEコミッタ• 著書「まるごとEclipse!　Vol.1」（発行：インプレスコミュニケーションズ）

生産性に関する数字

3

0

2

4

6

8

10

12

14

16

18

tcl rexx python perl Java C++ C

• プログラミングに要する時間（h）

参考：http://page.mi.fu-berlin.de/　　　　prechelt/Biblio/jccpprt_computer2000.pdf

出展：「JavaからRubyへ」著Bruce A.tate 訳角谷信太郎

1131,161設定行数

1,1643,293コード行数

Ruby on RailsJava

• コード量の違い

JUnit

1weekStruts

1weekSpring + iBATIS

Java EE

3day独自フレームワーク

1weekJava

期間コース名

• 教育コスト

• コミュニケーションコスト（n=人）

n(n-1)/2出展：「人月の神話」著Frederick Phillips,Jr. Brooks

結局、 生産性っ て・ ・ ・

And there‘ s busi ness val ue i n fun

- after al l moti vati on i s a

major factor i n programmer　 producti vi ty.

-- Marti n Fowl er

そして、 楽しさにはビジネス価値があり ます

- 結局、 モチベーショ ンこそがプログラマの

生産性を左右するのです。

-- マーチン・ ファ ウラー

モチベーションを下げる作業

5

XML地獄

なぜXML地獄が生まれたか

6

• DI（Dependency Injection）

オブジェクト

オブジェクトオブジェクト

オブジェクト間の関連をハードコーディング→密結合

DIコンテナなし

DIコンテナがオブジェクトの関連を管理→粗結合

DIコンテナありオブジェクト

オブジェクトオブジェクト

DIコンテナ

• ex) Springでの実現例

<!-- 以下を１セットにして、延々と同じような記述が繰り返えされる --><bean id="sampleController" class="sample.arid.SampleController" autowire="byType" /><bean id="player" class="sample.arid.SampleLogicImpl" autowire="byType" />

Convention Over Configuration

7

• 設定より規約（Convention)という考え方– 適切な規約を守れば、面倒な設定をしなくても、

フレームワークが自動的に適切な設定をしてくれるという考え

– 概念的なもので、それぞれのフレームワーク等によって、形態は異なる

• Ruby on Railsが広めた標語– Ruby on Railsだけでなく、様々なフレームワーク

に影響を及ぼした

CoCのメリット・デメリット

8

• メリット– 規約を覚えれば、定型的な作業が免除される

– 慣れれば慣れるほど生産性が上がる

• デメリット– 複雑・非直感的な規約は覚えきれない

– 動作させてみるまで、分からない

主流な３つのフレームワーク

9

• Spring–世界的にデファクトなDIコンテナ

• Ruby on Rails–圧倒的な開発効率を誇るWebアプリケーション開

発のためのWebフレームワーク

• Seasar2– 開発者の使い勝手を最重要視した国産のDIコン

テナ

Spring Framework

10

Bean定義ファイル書きたいですか？

Springを使っている技術者様に問いたい

Arid POJOs

• SpringでCoCを実現するフレームワーク– POJOs IN ACTIONの著者Chris Richardson氏– Seasar2のAutoRegisterに近いイメージ

<!– パッケージ名を指定するだけ --><arid:define-beans package="sample.arid" autowire="byType"/>

<!-- 以下を１セットにして、延々と同じような記述が繰り返えされる --><bean id="sampleController" class="sample.arid.SampleController" autowire="byType" /><bean id=“sampleLogic" class="sample.arid.SampleLogicImpl" autowire="byType" />

11

Spring summary

• Arid POJOs– SpringでCoCを利用する場合、唯一の手段

–過度のカスタマイズは逆に生産性を落とす

– Spring IDEの補完は無い

• Spring2.1（2007/08/22時点 M3）– JRuby対応により、設定地獄から抜け出せる可能性はある

• 現状は、JRuby実装のBeansがDIできるとか・・・

12

主流な３つのフレームワーク

• Spring–世界的にデファクトなDIコンテナ

• Ruby on Rails–圧倒的な開発効率を誇るWebアプリケーション開

発のためのWebフレームワーク

• Seasar2– 開発者の使い勝手を最重要視した国産のDIコン

テナ

13

• 名前：大西正太

• （株）アスタリクス所属

• CMS on RailsなOSS「Rubricks」コミッタ– http://rubricks.org/

• BizcaというSaaSグループウェア開発– http://bizca.jp/

自己紹介

14

O/Rマッピングの記述を比較

【CoC有】Rails

【CoC無】一昔前のJava

※局所的に

これを見てください

15

• テーブル名はモデル名の複数形にする

• 主キー名は「id」にする

• 外部キー名は「関連テーブル名単数形_id」にする

• 交差テーブル名は「テーブルA_テーブルB」にする

MEMBERSテーブル

id

ITEMS　テーブル

id

member_id

GROUPSテーブル

id

MEMBERS_GROUPSテーブル

id

member_id

group_id

Itemクラス Member　　クラス

Members Groupクラス

Groupクラス

RailsのO/Rマッピング規約

16

• 勝手にモデル名の複数系のテーブルとマッピングされる

• カラム名と同名のメソッドが勝手にモデルに追加される

• 関連テーブルを簡単に芋づる式に引っ張れる

いきなりAppからテーブルにアクセスできるようになっている

class Item < ActiveRecord::Baseend

規約を守ると・・・

17

その他のRailsの規約

• Controller– ＵＲＬとコントローラ名/メソッド名を一致させる

– http://xxxx.com/controller名/action名

• Ｖｉｅｗ– Ｖｉｅｗテンプレートとアクション名を一致させる

– displayアクション⇔display.rhtml

Strutsのような紐付けＸＭＬがいらない

18

• 今のJavaはそんなにひどくない

• JavaもCoC対応してきている– S2とか

• 後でたけぞうさんが説明してくれます

– Springとか• 木村さんが説明してくれました

念のため

19

• 実際にO/Rマッピングしてみます

Demo

20

Step数で100倍の差が出る(?)（冒頭のサンプル）

App全体での差ではない　・局所的なもの

生産性10倍(?)（Rails登場時のうたい文句）

Step数はそれに近いが…　・ステップ数は1/9になった　　簡単な書籍管理システムで測定　・Javaにはコード生成がある　　XMLやアクセッサ　・要件定義やテストは同じ工数

CoC/Railsの触れ込みと実際

21

• 変更に強い– モデル情報をDBスキーマで一元化

– DBが変わっても煩わしい作業が少ない• 紐付けXMLの変更やアクセッサの変更がない

• ツールでの再ジェネレートは必要ない

モチベーションも低下しづらい

ではどこにメリットがあるのか

22

• アジャイル開発– 「設計書」よりも「現物主義」の開発スタイル

– 「動く現物」をラウンドロビン的に改善していく

– テーブルもどんどん作り変えていく

• アジャイルとCoCは相性がいい– アジャイルのキーワード「変化ヲ抱擁セヨ」

– CoC/Railsは変更に強い

– どんどん現物を改善していける

CoCとアジャイル

23

• 既存システムには適用しづらい• 規約に従わないテーブルには設定が必要に

• 使えない機能が出てきたりする

• 製品の都合でCoCできないことがある• Oracleのテーブル名は30byteまで

• CUSTOMER_SUPPORT_PERSON_CUSTOMER_SUPPORT_GROUPS(47byte)

• 複数系⇔単数形が分かりづらい• PERSON People⇔ とか

• シンプルでない規約が悪影響を及ぼす例

• 切り替えは可能

Rails/CoCの罠

24

• なぜCoCはRailsで有名になったのか？

• Rubyが優れたCoCの実現に向いているから– Rubyのダイナミックさ

– 動的なメソッド追加

–静的型付言語には真似しきれない

–当分はCoCのリーダーはRubyだと思う

最後に

25

主流な３つのフレームワーク

• Spring–世界的にデファクトなDIコンテナ

• Ruby on Rails–圧倒的な開発効率を誇るWebアプリケーション開

発のためのWebフレームワーク

• Seasar2– 開発者の使い勝手を最重要視した国産のDIコン

テナ

26

自己紹介

• 竹添 直樹（たけぞう）

• NTTデータ先端技術勤務

• Seasarプロジェクトでコミッタをしています

• 著書– Eclipseプラグイン開発徹底攻略（共著）

–入門Wiki

27

Seasar2とは

• 国産のDIコンテナ– http://www.seasar.org/– オープンソース

–日本語コミュニティの存在

28

Seasar2の特徴

• 設定やコードを減らすための様々な工夫–利用者の使い勝手を重視

• スクリプト言語とJavaの良い部分を融合– Javaの安全性

– スクリプト言語のサクサク感

• 強力な開発支援ツール– Eclipseプラグインを提供

29

Seasar2の生産性

• 5.5ヶ月で1000画面！

– Seasar2ファミリーを徹底活用• Seasar 2.3 / S2JSF / S2Dao

– 1画面=1クラスのアーキテクチャ• コードジェネレータとの相性が良い

• 設計と実装のずれが少ない

出展:ITPro「HTML画面をそのまま仕様書に」，5カ月で1000画面を構築した就職サイトPuffの高速開発手法

http://itpro.nikkeibp.co.jp/article/COLUMN/20070214/261859/

30

Seasar2のCoC的な機能

• AutoRegister– コンポーネントを自動登録する仕組み

• S2Dao– AOPを活用したデータアクセスフレームワーク

• Chura– CoCを活用したフルスタックフレームワーク

31

AutoRegister～コンポーネントの自動登録～

32

AutoRegister• DIコンテナでは依存性を管理するコンポーネントを設定ファ

イルに記述する必要がある

• コンポーネントを設定ファイルに記述するのは面倒！

• 命名規約に従ってコンポーネントを自動登録

<component class="org.seasar.framework.container.autoregister.FileSystemComponentAutoRegister"> <initMethod name="addClassPattern"> <arg>"examples.jsf.logic.impl"</arg> <arg>".*LogicImpl"</arg> </initMethod></component>

examples.jsf.logic.implパッケージの*LogicImplクラスを自動的に登録

33

S2Dao～CoCベースのデータアクセスフレームワーク～

34

S2Daoの実装例(1)• インターフェースを作成するだけでOK• 命名規約や引数、戻り値に従ってSQLが実行時に

自動生成される

public interface EmployeeDao { // 挿入 public void insert(Employee employee); // 更新 public void update(Employee employee); // 削除 public void delete(Employee delete); // 主キーを指定して1件取得 public Employee select(int employeeId); // 全件取得 public Employee[] selectAll();}

35

S2Daoの実装例(2)• 明示的にSQLを記述することももちろん可能

• DAOクラス名_DAOメソッド名.sql• SQLのコメントを使用して可変クエリを実現

SELECT emp.*, dept.dname dname_0, dept.loc loc_0 FROM emp, deptWHERE empno = /*empno*/7788 AND emp.deptno = dept.deptno

パラメータ埋め込みの例

SELECT * FROM emp WHERE job = /*job*/'CLERK' /*IF deptno != null*/AND deptno = /*deptno*/20/*END*/

可変クエリの例

36

Chura～CoCを活用したフルスタックフレームワーク～

37

Chura• CoCを活用したフルスタックフレームワーク

• ２種類の開発スタイル– 開発生産性を重視「Super Agile」

• Teeda Extension• S2Dao

– Java標準を重視「Easy Enterprise」• JSF（Teeda）

• JPA（Kuina-Dao）

• 開発ツール「Dolteng」– Churaを具現化するEclipseプラグイン

38

Dolteng ～ ツールで規約を見える化

• CoCやDIの欠点– 規約を覚える必要がある

– 動かしてみないとわからない

ツールによるサポート

id属性の命名規約によってJavaクラスとマッピング

アイコン表示でマッピングされていることを可視化

39

HOT Deploy ～動作確認を効率化

ソースコードを修正

APサーバを再起動

ひたすら待つ…

動作確認

OK!!

ダメだったら最初に戻る

HOT Deployなし HOT Deployあり

ソースコードを修正

動作確認

OK!!

ダメだったら再度修正

素早い開発サイクルを実現

40

Seasar2のまとめ

41

Seasar2のまとめ

• スクリプト言語とJavaのいいところ取り– スクリプト言語の迅速な開発スタイル

– Javaによる静的な型チェック

• CoCの欠点をカバー–ツールで規約の間違いを予防する（Dolteng）

– 動作確認に要する時間の短縮（HOT Deploy）

42

是非お試しください

• The Seasar Project(Webサイト)– http://www.seasar.org/

• Seasar-user(利用者向けメーリングリスト)– https://ml.seasar.org/mailman/listinfo/seasar-user

• Seasar Conference 2007 Automn– http://event.seasarfoundation.org/sc2007autumn/

43

最後に：CoCまとめ

• Spring– Arid　POJOsの適用がポイント

• Ruby on Rails– Rubyのダイナミックさで強力なCoCを実現

– 制約事項を把握し、アジャイル手法とセットで

• Seasar2– スクリプト言語とJavaのいいところ取り

– ツール等によってCoCの欠点をカバー

44

最後に：Ruby on Railsの現状と展望

• 実案件での開発実績がたまっていない

• 良くも悪くもアジャイル手法と良くマッチする– アジャイル手法は大規模開発には厳しい一面

– コミュニケーションや迅速性に重きを置くため、客先常駐や、時間単金での仕事となりやすい

• 10年前のJavaと同じ事を言われている–遅い、技術者が、お客が・・・つまり・・・？

45

最後に：Javaの現状と展望

• 最も無難な選択肢–超大規模～小規模、Web系、組み込み・・・

• Java屋の人口の多さ– 技術者確保の容易さ（国内外問わず）

• 性能速度– 生産性10倍でも性能xx倍はちょっと・・・

• 顧客に対する認知度は抜群

46

ご清聴

ありがとう

ございました