JJUG CCC 2013 Springへ参加まとめ

日本Javaユーザーグループ主催のクロスコミュニティカンファレンス 2013 Spring（通称：JJUG CCC 2013 Spring）へ参加してきました。 因みに、午後からのみの参加です。

日時: 2013年5月11日（土） 9:30-20:05（開場9:15）

場所: ベルサール西新宿（東京都新宿区西新宿4-15-3住友不動産西新宿ビル3号館）

Java EE 6 から Java EE 7 に向かって

Java エヴァンジェリスト、寺田さんの発表です。

  • JavaEEの歴史
  • JavaEE6
    • JavaEE6 のテーマ
      • 拡張性
        • 外部FWの設定が容易
          • web-fragment
      • プロファイル
        • JavaEEのサブセットを提供
        • Web開発するなら、WebProfileを利用すれば、必要なものだけロードしてくれる
      • Pruning：仕様の削減
    • EJBコンテナをJavaSEから呼び出し可能
      • 組み込みで動くのでテストが可能
    • 実行環境も軽量化 3 - 4秒で起動
  • JavaEE7
    • JavaEE7のテーマ
      • シンプル化
      • HTML5対応
    • 新機能
      • Concurrency
      • Batch
      • JavaAPI for JSON
        • Streaming API
          • Json内の個々の文字列ハンドリングが細かく指定可能
        • Object Model API
          • Builderを使って簡単にJSONを生成可能
      • WebSocket
    • アップデート
      • EL3.0
        • ラムダ式が実行可能
        • コレクションに対してLINQ式がかける
          • オブジェクトに対してのみのクエリ。DBには投げていない！
            • Viewでロジック書きすぎると可読性悪くなるので、使いどころあるのかな？微妙。
      • JMS 2.0

Java Small-Object Programming

Starrignt & Stormの長谷川 裕一さんによるDDD関連の話です。

1 S-OPとはなにか

  • 小さい部品でアプリケーションを作ろう
  • 背景
    • テストや変更の容易性、可読性の悪いアプリケーションの多さ
    • FWの定番化
    • DDDや9つのルール等の登場
  • S-OPの実現
    • オブジェクトを小さく作る
    • FWの有効活用

2 アプリケーションの現状

  • ビジネスロジックが理解しづらい
    • メソッドの行数が多い etc
  • ビジネスの変更がシステムに与える影響は、ビジネスロジックの変更である。
  • S-OPは何を解決するか
    • 上記の問題を解決するため、可読性が良く、変更容易性の高いシステムにする

3 Javaの抱える問題

  • JavaはSmallTalkと比較して、純粋なオブジェクト指向ではない
  • 構文の冗長性
    • 例)Employeeクラス等、2つの属性を持つクラスで合っても複数のメソッドを記述しなければならない
  • Validation処理が複数のクラスに散らばってしまう

4 S-OPの実現

  • プリミティブ・文字列をラップしてクラスにする(フィールドクラス)

    • 例）Priceクラス
      • Priceに関するルールを知っている

    • 例) Codeクラス

      • Codeに関するルールを知っている

    • 先程のEmployeeクラスの場合も、nameとかcodeとかを一つのクラスにすることで処理を纏めることが可能。

      • Employeeクラスに対してValidationのアノテーションをつければ良い？
        • Controller等で、name, codeをEmployeeから離れて独自に扱う事があるからそれでは冗長になる。

    • フィールドクラスを利用するメリット

      • フィールド名が分散する事が無いので検索が便利
        • 例）商品コードがString shohinCode, String sc...
      • 修正は常に一箇所

    • フィールドクラスを利用するデメリット

      • ヒープを圧迫する
      • 多すぎると可読性が下がる

  • 不必要なSetter-Getterは記述しない

    • 本当に必要かを考える
    • 例) 倉庫の場合、set在庫はおかしいよね
      • 1から在庫をセットするのは文脈的におかしい。増やしたり減らしたりする方が文脈的には正しい。

  • フレームワークを利用する

    • Lombokで@Dataを利用すると、setter, getter, toString等を裏側で生成してくれるので、見た目がすっきりする
    • Springで例外、try-catch、loging等のコードを省略

5 9つのルール

  • 1つのメソッドにつきインデントは1段階までにすること
  • else句を使用しないこと
  • すべてのプリミティブ型と文字列型をラップすること
  • 1行につきドットは1つまでにすること
  • 名前を省略しないこと
  • すべてのエンティティを小さくすること
  • 1つのクラスにつきインスタンス変数は2つまでにすること
  • ファーストクラスコレクションを使用すること
  • Getter/Setter/プロパティを使用しないこと
  • S-OPにDDDのパターンを利用する
  • DDDを実施しないとS-OPにならない？
  • S-OPはトランザクションスクリプトに不向き？
    • ドメインロジックが余り無い場合にも、S-OPは使える
      • フィールドクラスでValidationをすると、使い回しが効く

6 DDDからDSLへ

  • 単純なプログラムであればDSLで自動生成で高速開発可能
    • プレゼンテーション
    • DBアクセス
  • 最低限必要なフィールドクラス等の基本的なコンポーネントはDSLで生成する
    • 開発者はこれをライブラリとして利用する。

JIRA開発の舞台裏 ～世界19,000社で使われる課題管理システムはどのように開発されているのか？

  • JIRAの解説

  • JIRAの開発

    • 年間3回のリリース
    • 開発メンバ
      • 74人
        • Devが8割

  • PM : Confluenceの利用によるストーリ管理

    • ペルソナ機能の利用
      • 利用者に関する情報を管理
        • 利用者がどの様な課題を持っているか？
        • 利用者はどの様なスキルセットを持っているか？
      • 個別の機能から始めるのではなく、ストーリを作る
        • JIRAの価値は何か？
          • ConfluenceはSNSプラットフォームなので、フィードバックが得られる

  • Design : Atlassian Design Guidelineの作成（共通のデザインコンポーネント）

    • 開発者は見た目を気にしなくてもよくなった
    • Keynoteのテンプレートも作った
      • プレゼンなどでページのモックも作り易い

  • Dev : Gitへの移行(Stashというアトラシアンツールへの移行)

    • SVNのころはブランチ、マージへの恐怖心が有った
      • Gitでマージがし易くなった
        • rebaseがあるからってこと？
    • プルリクエスト
      • コードレビューの仕組みを活かす
    • トレーサビリティ

  • QA : Quality AssuranceからQuality Assistanceへ

    • テスティングノートの作成
      • テストの時に必要なガイドライン
      • ペアテスティング
        • Devと協力して品質を保証していく
    • 9ヶ月リリース -> 2週間へ短縮

失敗から学ぶAPI設計

  • いいライブラリとは

    • コストパフォーマンス高い
    • 機能が豊富
    • 品質高い
    • コミュニティが活発
    • 拡張しやすい
    • 使いやすい

  • Twitter4JのAPI

  • Twitter4Jの開発指針

    • シンプルにYAGNI
      • クラス数は極力少なく
      • インタフェースは使わない
        • インタフェースが分からない初心者にも優しく
      • 拡張ポイントはなるべく少なく
        • 柔軟さ < 使いやすさ の重視
      • なるべくImmutableに
      • クラス継承はさせない(final)
        • finalじゃないクラスはモッククラスとして使いたい場合のみ
      • strategyパターンはやらせない
        • 分かりづらいから
        • 認証の部分で使っているくらい？
    • Twitter4Jの拡張ポイント
      • 認証
      • ログ
      • httpクライアント
      • 非同期ディスパッチャ
    • デザインパターンを適用しない
    • IDEの補完を活かせるように
      • なるべく同一パッケージに
      • 一般的すぎるクラス名にしない
    • IDEの補完がいき過ぎないように
      • 使うべきでないクラス名を異様にする
        • z_T4JInternal***
          • zを付けてるのはIDEの補完で一番最後に来るようにしてる
    • 互換性維持の苦労
      • APIが増える
      • レスポンススキーマが変わる
      • 認証方式が変わる
      • 要素が増える
    • 互換性維持のために大事なこと

    • パッケージ訳の失敗

      • twitter4j.*
      • twitter4j.api.*

      • twitter4j.auth.* ...

      • パッケージ分けし過ぎると

        • クラスが見つけられない

        • blogのコード例をコピペしても動かない(import文が無いので）

        • 解決策

          • コードの見通しの問題であればパッケージ分けしない
          • ソースコードフォルダを移動する

    • API設計の失敗

      • new Twitter()
        • 使いやすいが、モッククラスを作れないからテストしづらい
      • インタフェース + ファクトリの導入
      • Sigletonを返すstaticメソッドを導入

        Twitter twitter = TwitterFactory.getInstance();

  • 参考図書

    • Effective Java
    • Practical API Design

参加してみて

始めてのJJUG CCCだけど、参加してよかった！しかし、セミナの醍醐味は懇親会にあるので、次回は是非参加せねば。