Salesforce 設計 チェックリスト(古い)

• トリガは極力利用しない。
  • トリガ処理が連鎖して無限ループしないように管理しないといけない。
  • エラーが発生してもどの処理でトリガが動作したのかデバッグしずらい。
  • エラーハンドリングがしにくい。画面からのデータ更新とバッチからのデータ更新ではエラー時の処理を変えたい。
  • トリガを動作させたい場合と動作させたくない場合をいちいち意識して作り込まないといけない。
  • テストクラスでtoo many soqlやtoo many codeが起きても、場所を特定しずらい。
  • トリガに処理を持たせると、トリガ処理を修正する際の影響範囲が見えずらいので、トリガを外したくても外せなくなる。
  • 管理パッケージ化するならインストール先のトリガも考慮しないといけない。標準オブジェクトの標準項目は特に。
  • 1組織に複数のプロジェクトで開発したものが同じオブジェクトを使っていたりすると、他のプロジェクトで作成したトリガも動作してしまう。
  • トリガ発動元データだけを変更する処理なら、トリガにしてもいいと思う場合もある。エラーハンドリングしずらいけど。
• クラスを設計するとき、機能毎にあまり依存しないようにしたほうがよい。デプロイするとき、バッチに依存するクラスはデプロイ出来ないため。DIみたいな作りが理想。
• Javaみたいにパッケージでクラスを分けられないから、クラス名の命名規則が大事
• Apex処理はエラーになっても再実行すれば問題ないような設計できるようにする。1回で処理できる処理なんてtoo many codeやtoo many dmlで限界があるので、必然的に分割してバッチ処理するしかない。
• ループ内でクエリを発行せずに一括処理されているか
• @isTest(SeeAllData=true)は使わない。テストクラスの中でテストデータを作成する。
• Apexの変数宣言でget functionの中では処理は行わない。固定値以外。多用するとgetter内で他の変数のgetterが連鎖して呼ばれたりと訳が分からなくなる。毎回getterが呼ばれるのでステップ数も増加する。
• SObject型のput(), get()はあまり使わない。
• CustomObj.CustomId_cと書いて間違っていればコンパイルエラーで気付くが、SObject.get('CustomId_c')のようにプロパティを文字列でハードコードしてしまうと、実行してエラーにならないとスペルミスに気付けない。
• あとメソッドを呼んでいるわけなのでステップ数増加の原因にもなる。
• 1メソッドでif文の階層でどんどん深くすると、あとでテストコードを書くとき大変苦労するので、1メソッド内の処理は短く、何層も深くif文を書かない。
• セキュリティチェックはマメにやっておいた方が良い。
• トリガはなるべく使用しない。プログラムが大きくなるとどの処理に影響が及ぶか分からなくなるし、トリガ内で他のオブジェクトを変更するなどで処理が連鎖して管理できなくなる。WFも同じ。
• データ設計は、1つのオブジェクトに大量に データが 作られるような設計は行わない。件数が増えないことが大事。大量にデータが入るオブジェクトへの検索は相当気を使わないと、 10万件エラーであとで検索できなくなってしまう。
• with sharingは使うなら全てのクラスで使うべきだし使わないなら全てのクラスで外したほうがいい。全てのクラスで統一しないとバグのもとになる。
• Apexのバージョンによる動作保障は３年までっていうのを意識する。
• Apexクラス名やフィールド名をstringで扱わない。SObjectTypeやSObjectFieldを使う。
• ガバナ制限テストを行っているか
• 例外処理してもエラーで終了すると全てのデータがロールバックされるとドキュメントに書いてあるが、catchして後続処理を行うとロールバックしない。
• DML処理をなるべく一連処理の最後で行うことで、データロック時間の短縮に努めているか
• 画面からの入力値はエスケープしているか(String#escapeSingleQuotes()等)
• バッチ処理でのデータ変更は所有者も変更したほうがよい。最後どのバッチで処理されたデータなのかが分からなくなる
• @ReadOnlyアノテーションを意識して設計する
• sobjectの処理は全部複数を処理することを前提とする。例えば findById(string) ではなく findByIds (string[]) とか。 insert や update処理も。
• トリガを使うなら、データの整合性はトリガに管理させる。各プログラムで各々実装するのではなく、整合性処理はトリガに集約する。
• 特に標準オブジェクトに必須項目にしたいときは、レコードタイプを作って入力規則で対応するようにする。
• abstractクラスを作るならvirtualクラスにする。テストコードが書けないから。
• virtualはなるべく全てのメソッドにつけたほうが、いざパッケージ後にvirtualつけようとしても遅い。あとgetter/setter変数はオーバーライドできないので、やっぱり使わない方がいいと思う。
• 積み上げ集計項目でレコード数の合計で集計しないほうがいい。ストレージでデータ件数が多くなって件数を減らすことを考慮しないといけないときに困る。データ件数が増えるとずっとこれに悩まされる。数値項目として持っておいたほうがよい。