• Save
They Call It Enterprise For A Reason (Kanji Version)
Upcoming SlideShare
Loading in...5
×
 

They Call It Enterprise For A Reason (Kanji Version)

on

  • 692 views

Dreamforce 2010 Presentation: Salesforce and Force.com have a great reputation: easy to configure, fast to develop with, and marketed with an "anyone can do it" paradigm—all true. But just ...

Dreamforce 2010 Presentation: Salesforce and Force.com have a great reputation: easy to configure, fast to develop with, and marketed with an "anyone can do it" paradigm—all true. But just because something is easy and fast doesn\'t mean it should be treated in a cavalier manner. In other words, just because you can put 500 validation rules on an object doesn\'t mean you should. This session will focus on bringing best practices for enterprise systems to bear when developing on the Force.com platform. Join us to learn about using a standards-based approach to coding, data modeling, and architecting as well as separation of concerns, test-driven development, and more.

Statistics

Views

Total Views
692
Views on SlideShare
685
Embed Views
7

Actions

Likes
0
Downloads
1
Comments
0

2 Embeds 7

http://www.linkedin.com 6
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

They Call It Enterprise For A Reason (Kanji Version) They Call It Enterprise For A Reason (Kanji Version) Presentation Transcript

  • エンタープライズプラットフォームとしての Force.com
    開発者向けセッション
    Don Robins
    Outformations, Inc.
    www.outformations.com
  • エンタープライズの大きさとは
    1
  • どれが正解?
    2
    画像所有権 –www.cygnus-x1.net : Monte R. Johnjulio
  • 「大きい」とはどの程度の規模を指すのか
    • こんな経験がありませんか…?
    • 総ユーザ数 > 100、>500、>1k
    • インテグレーションポイントの総数 > 1、>5、>10
    • その他のベンチマーク:
    • 標準 + カスタムオブジェクトの総数
    • カスタムワークフローの総数
    • トリガ、クラス、VF の総数
    • レコード総数
    3
  • 「大きい」とはどの程度の規模を指すのか
    • こんな経験がありませんか…?
    • すでに不在の前任者の先例に従った
    • 自分の組織において、理解に苦しむようなことに遭遇した
    • 変更作業の過程で既存の機能を壊してしまった
    4
    • 大規模なSalesforce.com や Force.com の実装には 異なったアプローチ が必要:
    • 発想の転換の必要性
    • その理由と方法
    • マーケティングメッセージを調整する必要あり:
    「…とても簡単です!」
    目的: 私の見方・考え方を共有
    5
    画像所有権 – Apple, Inc.
  • 目的: 皆さんに持ち帰ってもらいたいこと
    • 考え方: (What)
    • 規模 : 複雑性 : 依存性 : リスク
    • 理解: (Why)
    • 複雑性の管理が必要な理由
    • アイデア: (How)
    • アプローチを変える
    • 期待の管理方法を変える
    • 新たな基準、プラクティス、メソッドを適用
    6
  • 自己紹介
    • 有限会社アウトフォーメーションズの共同経営者兼 主幹コンサルタント
    • 25 年以上の経験
    • チーフアーキテクト、開発チームメンターおよびトレーナー
    • セールスフォース認定開発者、およびアジャイル認定スクラムマスター
    • 業務内容
    • カスタムソフトウェアソリューション
    • アジャイルビジネスコンサルティング
    • 開発者向けメンターリングと研修
    • あらゆる規模、形態、業界のクライアント対象
    私たちは Force.com でお客様のクラウド移行をお手伝いすることに情熱を注いでいます
    7
  • エンタープライズの意味
    • 多数のオブジェクト:
    • ユーザ、機能、画面、レポート
    • 多数の複雑性:
    • セキュリティ、ビジネスルール、作業の流れ、レポーティング、アウトプット 
    • インターナショナリゼーションにおける多数の課題点:
    • 複数にわたるロケール、通貨、時間帯に由来する問題
    • 多数のインテグレーションポイント:
    • その他のクラウドシステム、ERPデータベースなど
    • そして、無数に存在するデータ
    8
    画像所有権 – Wenger
  • 「セールスフォース開発はとても簡単!」
    • セールスフォース・ドットコムのマーケティングメッセージ:
    • 設定が「簡単」
    • 開発が「迅速」
    • 「誰にでもできる」
    • 「ソフトウェア不要」
    • すべて本当のこと - セールスフォースが私たちを惹き付ける理由
    • ただし、マーケティングメッセージを調整する必要あり:
    • これらはセールスフォースに当てはまることだが、複雑なシステムには該当しない
    9
    画像所有権 – Quantum360.co.uk
  • 「大規模」に伴う課題
    • 複雑になりがち
    • 複雑性が無秩序な形で増大
    • 増大する複雑性から依存性が発生
    • すべてを追跡することがさらに困難に
    • システム要素の結合化が進むことが多い
    • 変更が意図しない影響を引き起こす
    • 技術的負債が増える
    • 結果的にその代価を支払うことに
    • どうやって? いつ? そのコストは? 予想が不可能!
    10
    画像所有権 – OpenORB.sourceforge.net
  • 技術的負債とは
    「...行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果」
    11
    画像所有権 – my.digitalface.ca
  • 行き当たりばったりの変更 = 技術的負債
    12
  • 技術的負債のシナリオ
    • 「単純な」変更が必要になり、変更要求を受ける
    • 簡単なソリューションで対応し、問題をすばやく「解決」
    • ソリューションによって、相互接続された別の可動部分が追加される
    • これがやがて何度も繰り返されることになる…
    • APEX ロジックの重複が発生することも
    • 後で「修復」「改良」するつもり - でも、「後で」はいつになってもやってこない!
    • 複雑性の増大によって、予期しなかった依存性が発生
    • 変更が意図せぬ影響をもたらす
    • 新規コードを導入しようとするとテストが失敗しはじめる
    • 展開と実装にたいする変更が阻まれる
    • 最後には、システム自体が崩壊することに…
    13
    画像所有権 – my.digitalface.ca
  • 技術的負債の例
    • 「あともう 1 つだけ が必要」
    • 「バリデーションルールをもう 1 つだけ追加…」
    • 「フィールドをもう 1 つだけ追加…」
    • 依存性を確認せずにピックリストの値を変更
    • APEX に無秩序な変更を加える
    • 新規トリガを追加
    • クラスを膨れ上がらせる
    • 重複する (またはその可能性のある) ロジック新たに追加
    • 後になってから影響が表面化 – さて、どう対応するか
    14
    画像所有権 – my.digitalface.ca
  • 開発用ベストプラクティスの適用
    • Salesforce.com をエンタープライズ級の製品として認識
    • 複雑なシステムをサポート: システムは後で必ず複雑になる!
    • 全員それぞれに相応しい期待を設定
    • ずさんなアプローチでは後でしわ寄せが
    • エンタープライズソフトウェア開発のためのプラクティスを習得しよう
    • 複雑なアプリケーション開発を支援
    • 長年の実績、期間を経て進化
    • スケーラビリティを許容し、複雑性の増大を管理
    • Salesforce に完全適用が可能
    • コンフィギュレーションとプログラミングの両方に適用 
    15
    画像所有権 – consulting-plus.com-au
  • 開発基準の適用
    • 導入する基準を設定 – 適正な基準ならその類を問わない
    • 以下の作業においてチーム全員が遵守する必要がある:
    • 設計
    • データモデリング
    • コンフィギュレーション
    • コーディング
    • 設定が許可されているユーザ全員にも徹底させる
    • リスクを可視化し、全員にたいする期待を設定
    • 目的が明確だと受け入れやすい
    16
    画像所有権 – consulting-plus.com-au
  • 命名規則の適用
    • 宣言型プログラミングの命名パターンを設定
    • カスタムオブジェクトやフィールドのネーミングには配慮して
    • キャプション vs. フィールドネーム
    • ユーザ vs. プログラマ
    • プログラミング構成要素についても同様
    • 関連クラスの集まりに命名パターンを使用
    • トリガ、クラス、ページ、構成要素を名称別に整理
    • テスト対象のクラス名に基いて、テストクラスを命名
    • 例: MyPageController and MyPageController_Test
    • 並び方を工夫して検索し易いように
    17
    画像所有権 – www.squidtank.com
  • 複雑さをできる限り縮減
    • 「可能だから」という理由だけで、「する」必要はない:
    • 1 個のオブジェクトに何百ものフィールドを追加しない
    • 1 個のオブジェクトに多数の検証ルールは不要
    フィールド、ルール、複雑さが縮減するにつれて、
    パフォーマンス、ユーザビリティ、保全性が増す
    • 複雑さを管理する必要性を理解
    18
    画像所有権 – www.emergebuzz.com
  • 予想される依存性を分析
    • よく考えてクリックすること!
    • Do: 変更要請にたいしてはユーザと分析・精査
    • 変更要請を安易に受け入れない
    • 明確なビジネスバリューがあることを確認
    • Do:可能なオプションを提示してユーザと検討
    • 依存性とリスクに関する理解を共有
    • 代替案を提供してプロトタイプを作成
    • Don’t:次のような主張にたいして譲歩しない:
    • 「セールスフォースなんだから、簡単にできるはずだ!」
    • Don’t:「クリック」ですむ場合はコードを作成しない
    19
    画像所有権 – planebuzz.com
  • 辿ってきた「道筋」を残す(宣言型)
    • 文書化によって伝達を図る
    • 複雑性と依存性を「見える状態」にしておく
    • 書込み用メタフィールドを利用
    • 全オブジェクトに関して説明とヘルプを書き込む
    • 検証ルール、承認、ワークフロー等
    • 明確に記述
    • 極端に長すぎないように
    20
    画像所有権 – www.legaljuice.com
  • 辿ってきた「道筋」を残す(APEX)
    • APEX コードのコメントは簡潔明瞭に。ただし:
    • コメントの使用は慎重に
    • 更新されていないコメントが誤解を生む場合も
    • 「何が」「どのように」については言及しない
    • 理由を述べること
    • APEX コードの制限事項を知る
    21
    画像所有権 – consulting-plus.com-au
  • 辿ってきた「道筋」を残す(APEX)
    • 命名規則とパターンに統一性をもたせる
    • メソッド、プロパティおよび変数はセルフドキュメント方式で
    • プロパティは内包する/相当する要素に関連付けて命名
    • 長い名称が相応しい場合も
    22
    画像所有権 – www.legaljuice.com
  • アーキテクチャルアプローチの適用
    • 設計原則を用いて複雑性の管理に役立てる:
    • コンサーンの分離(SoC)
    • 単一責任の原則 (SRP)
    • 重複を防ぐ (Don’t Repeat Yourself/DRY)
    • 正しいコーディングプラクティスを使用することで保全性を確保
    • セルフドキュメンティングコード
    • 文字列リテラルを避ける(ピックリストでなく、定数や列挙定数を使用)
    • 使用するメソッドやクラスにたいして定期的にリファクタリングを
    • メソッドやクラスを軽量に保つ
    • コーディングは「簡素さ」ではなく「分かりやすさ」にフォーカス
    23
    画像所有権 – www.squidtank.com
  • アーキテクチャルアプローチの適用
    • エンタープライズコーディングパターンの利用
    • 複雑さの管理のために設計
    • 一貫性のある枠組みを提供するので何がどこにあるか明瞭
    • 後で必要になったときにも探しやすい
    • モジュラーアプローチの適用(APEX)
    • 再利用性を促進: 冗長なコードを減らす
    • データアクセスサービス: SOQL と DML ロジックをカプセル化
    • ドメインマネージャ: ドメインロジックをカプセル化
    • ユーティリティライブラリ: 再利用可能な機能
    • サービスライブラリ: 再利用可能なサービス
    24
    画像所有権 – consulting-plus.com-au
  • 例: コンサーンの分離
    • 単なるモデル/ビュー/コントローラ (MVC) に限定したSoCではない
    • 包括的なアーキテクチャルアプローチ
    • モジュール化されたコードコンポーネントを作成
    • 可能な限りロジックのデカップリングを図る
    • トリガやコントローラの下にビジネスロジックを組み込む
    • APEX を ファーストクラスの OOP 言語として扱う
    • 各 APEX クラスモジュールにテストクラスを作成
    • 全般的にさらにテスタブルに
    25
    画像所有権 – blogofpaul.merecomplexities.com
  • VisualForce のビュー
    トリガ
    ルール
    ヘルパーロジック
    SOQL
    DML
    典型的なアーキテクチャ
    コントローラ
    アクションナビゲーション
    ルール
    ヘルパーロジック
    SOQL
    DML
    トリガ
    テスト
    コントローラ
    テスト
    26
    画像所有権– outformations.com
  • モジュール化したアーキテクチャ
    VisualForce のビュー
    トリガ
    トリガ
    テスト
    コントローラ
    コントローラ
    テスト
    サービス
    サービス
    テスト
    マネージャ
    テスト
    マネージャ
    リポジトリ
    リポジトリ
    テスト
    ユーティリティ
    ユーティリティ
    テスト
    27
    画像所有権 – outformations.com
  • コードを確実にテストする
    正直に答えてください。あなたにはこういった経験がありませんか?
    • APEX クラスを書いた後で、テストを書いた
    • テストカバレッジが充分でないことに気付かなかったため展開に失敗した
    • 複数の APEX クラスやトリガにたいして、単一のテストクラスを使用した
    28
    画像所有権 – consulting-plus.com-au
  • コードを確実にテストする
    開発者の多くは、後になってからテストを書く= 誤ったアプローチ:
    展開に必要になってからカバレッジを拡大
    プログラミングと並行して、テストを書く=正しいアプローチ:
    • テストを使ってロジックを開発
    • テストを使ってロジックを証明
    • コードベースを用いてテストカバレッジを拡げる
    • 全テストを定期的に実施
    テスティングは単にコーディングを進めるためのものではない !
    29
    画像所有権 – consulting-plus.com-au
  • 意図を持ったコーディング
    • テスト駆動開発とは (TDD)
    • コーディングと並行してテストを書くことで、ロジックの開発を助ける
    • 「エマージェントデザイン(創発的設計)」の概念を利用
    • TDD のアプローチは「意図を持ったコーディング」を支援
    • 「何をコーディングしているのか」を常に意識して
    • 作業の無駄とコードの膨大化を避ける
    • 回帰テストのためのパワフルなテスト一式
    • 変更にたいして安全性と「安心」を提供
    • 開発したアプリケーションには何年間も管理が必要
    • コード作成 = 20% vs. コードの保守 = 80%
    30
    画像所有権 – consulting-plus.com-au
  • アジャイルプロジェクト管理手法の適用
    プロダクトバックログを作成して管理
    • 優先順位/価値の一番高い項目
    短期間単位の繰り返し型作業(スプリント)
    • タイトなフィードバックループ
    チームが完了できるタスクのみにコミット
    • 現実的で維持可能なペース
    チームはプロジェクトオーナーと日次に連絡をとる
    • 進捗と障害にたいする可視性
    最後にデモと反省をおこなう
    • 繰り返しによって開発作業が改善・加速化され、予測性が向上
    31
    画像所有権 – consulting-plus.com-au
  • アジャイルアプローチで得られる利点
    • ビジネスバリューの提供を促進
    • ビジネス視点による優先順位付けを強要
    • 可視性を維持して、障害を日次で定義・管理
    • 真の問題点を摘出 (往々にして、原因はテクノロジ以外)
    • チームの生産性とデリバリ能力を向上
    • チーム作業能力の向上、加速化が進み、予測性が増す
    • ユーザによるタイムリーなフィードバックを確保=進捗状況が管理可能
    • 煩雑な変更管理を支援
    • 不要な機能を減らし、無駄を排除 = コスト削減
    • 変更は不可避。抵抗ではなく、前向きに受け止める姿勢で。
    32
    画像所有権 – consulting-plus.com-au
  • まとめ
    • ユーザとマネージャの期待を管理
    • 課題を正確に理解させる
    • プラットフォームの管理と活用法を学ぶ
    • 逆にプラットフォームに管理されないように
    • エンタープライズプラットフォームにはエンタープライズアプローチを適用
    • スケーラビリティを見据えて構築されたプラットフォーム‐ これが Force.com を使用する理由
    • Force.com がエンタープライズ用と呼ばれるわけはそこにある … この点を忘れずに
    33
    画像所有権 – www.infovark.com
  • ここで時間をいただいて…
    セッションにたいする質問表にお答えください。
    さらなる情報の充実と今後の取り組みに役立てたいと思います。
    34
    画像所有権 – www.eizie.org
  • 質問の問合せ先
    • セッションの後か
    • ランチのときに
    • チャッター(または LinkedIn)で直接ご連絡ください
    • あるいは、Eメールで: dbr@outformations.com
    • 当社ウェブサイト: http://www.outformations.com
    • 後ほど、チャッターに関連リンクと情報を掲載します
    • チャッターフィードに質問を投稿してください
    35
    画像所有権 – www.clipartof.com
  • Don Robins
    Outformations, Inc.
    www.outformations.com