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