[salesforce]Force.comプログラミングのベストプラクティス集

By |1月 12, 2011|salesforce, |

このエントリーをはてなブックマークに追加
Delicious にシェア

Jeff Douglasさんが、Force.com開発のベストプラクティスをまとめていました。

参考：Force.com Programming Best Practices

Apex

  • APEXは自由な記法で開発することができます。大文字小文字の区別もありませんし、タブ/スペースの利用も自由にできます。ただし、可読性を向上するためには、JAVA記法に沿って記述をして、タブの代わりに2つスペースを利用したほうが望ましいです。
  • 同期処理が不要な場合は、非同期処理 (@future annotation)を利用します。
  • 非同期処理の内容は、 “bulkified”されている必要があります。
  • APEXコード内で正しいエラーハンドリングを実装している必要があります。
  • SOSL/SOQLインジェクションを防ぐために、静的クエリ、変数バインディング、シングルクオートエスケープを利用する必要があります。
  • 大量レコードをクエリーする場合は、SOQL “for” loopを使いましょう。
  • 可能な場合はできるだけ、SOQLより高速なSOSLを使いましょう。
  • ガバナ制限を避けるために、APEX limit メソッドを使って、ガバナ制限の利用状況を確認しましょう。
  • ループ処理の中で、SOQL/SOSLクエリを使わないこと。
  • ループ処理の中で、DML処理を使わないこと。
  • ループ処理の中で、非同期処理を使わないこと。
  • APEXコード内に、SalesforceIDをハードコーディングして、それに依存した設計にしないこと。（レコードは組織の利用状況に応じて変更される場合もありますし、サンドボックスと本番組織でIDが異なる場合もあるからです。）

Triggers

  • 1オブジェクトに実装するのは1トリガまで。
  • トリガ内に複雑な処理を実装するのは避けましょう。単純化するために、トリガからの処理は外部のAPEXクラスに任せたほうが好ましいです。トリガーテンプレートが参考になります。
  • 全てのhelperクラスとメソッドはBulkifyしましょう。
  • トリガは “bulkified”されている必要があり、処理するレコード数は200レコードまでに制限されている必要があります。
  • DML処理を実行する場合は、レコードを一つ一つ処理するのではなく、配列にまとめて複数レコードを一度のDML処理で扱いましょう。
  • SOQLの”where”内で配列を使って、必要なレコードは一度のSOQLクエリで取得するようにしましょう。
  • トリガの命名規則には、対象のオブジェクト名を含む一貫性のある形式にしましょう。例： AccountTrigger

Visualforce

  • 選択リストはViauforceページ内にハードコーディングせずに、コントローラ内に記述しましょう。
  • JavascriptとCSSファイルは、キャッシュを有効活用するために、静的リソースに置きましょう。
  • CSSファイルはページ内の最上部に、JavaScriptは最下部に記述して、ページの読み込みを高速化しましょう。
  • ビューステートのサイズを縮小してページ読み込みを高速化するために、コントローラ内の変数でポストバックが不要なものは”transient”修飾子を付けましょう。
  • 配列の繰り返し表示が必要な場合は、 <apex:repeat> タグを使いましょう。
  • CDNへのコンテンツキャッシングを有効化するために、適切な場合は<apex:page> タグのcache属性を有効にしましょう。

Unit Testing

  • テストの命名規則には、対象のクラス名を含む一貫性のある形式にしましょう。例： Test_AccountTrigger
  • テストクラスには@isTestアノテーションを付けましょう。
  • テストメソッドは、対象組織の実際のレコードに依存しない形で、対象のメソッドで必要な全てのデータを生成する必要があります。
  • APEXコードが期待通り動作しているか検証するためにSystem.assertを使いましょう。
  • 全ての条件分岐をテストしましょう。
  • 条件分岐の成功/失敗の両方をテストしましょう。
  • トリガをテストする際には、200レコードを処理できるように “bulkified”されているか検証し、 “Too many SOQL queries: 21″ のエラーがでないようにしましょう。
  • ガバナ制限のテストをする際には、Test.startTestとTest.stopTestを使い、ガバナ制限の値はハードコーディングせずにAPEX limit メソッドを使うようにしましょう。
  • 共有ルールの検証をするために、System.runAs()を使って特定ユーザによる実行を検証しましょう。
  • テストはブラウザからSalesforceの画面上で行うのではなく、Force.com IDEから行いましょう。ブラウザ上からだとコードカバレッジを見間違ってしまう場合があります。
  • Force.com Security Source Scanner を使ってSalesforce組織のセキュリティチェックとコードチェックを行いましょう。 (e.g., Cross Site Scripting, Access Control Issues, Frame Spoofing)