こんにちは、ねこねこです。
今回は、Salesforce の開発時のアンチパターンについて少し紹介します。
トリガー（Trigger）について
Salesforce では、オブジェクトに対して「トリガー（Trigger）」を定義できます。
トリガーは、特定のオブジェクトに対するデータ操作（挿入、更新、削除など）が発生した際に実行されるApexコードです。
Trailhead などでも、トリガーはよくサンプルコードとして紹介されていますね。
トリガーは便利です。
しかし、このトリガーを安易な気持ちでホイホイと定義してしまうと、後で痛い目に遭う場合があります。
実行順序に注意
Salesforceのトリガーはその実行順序が保証されていません。
複数のトリガーが同じオブジェクトに対して存在する場合、それらがどの順番で実行されるかは予測不可能です。
これは、予期せぬ挙動やデータの状態不整合を引き起こす可能性があります。
必ず、トリガーを設定する場合は1オブジェクトに対して1つまでにしましょう。
これは、実行順序を気にしなくて良い場合でも、原則守るべきです。
再帰的実行のリスクに注意
トリガーは冒頭で紹介したように、レコードの更新時に発火させることができます。
あるトリガーが発火すると、そのトリガー内でのデータ操作によって別のトリガーが再帰的に発火することがあります。
これは無限ループを引き起こす可能性があり、システムのパフォーマンスに影響を及ぼしかねないだけでなく、深刻な不具合を引き起こす可能性があります。
トリガーは簡潔な処理にとどめ、複雑なビジネスロジックを組み込むのは避けましょう。
例えば、積上集計項目でもレコードは更新されてトリガーが発火してしまいます。思わぬ場面でトリガーが動作することは常に意識すべきです。
管理の難易度の上昇
トリガーにビジネスロジックを多く含むほど、その管理が難しくなります。
コードが散在することで可読性が低下し、新たな機能の追加や既存の機能の修正が難しくなることがあります。
新規に Salesforce を導入する場合や、新しいオブジェクトに全く新しい機能を構築する場合は、初回は確かに便利でしょう。
しかし、保守・メンテナンスを続けていくうちに、「ここを変えるとこのトリガーに影響してしまう。」「この標準機能の設定でもオブジェクトが内部的に更新されるからトリガーが動作するのか。」といった、思わぬ影響が生じてきます。
トリガーがあるせいで安易に追加機能を実装できないばかりか、簡単な機能なのにテスト工数が肥大化して、お客様もベンダーもハッピーになれないという事態に陥りかねません。
テストの困難さ
前章にも通ずる内容でしょう。
ビジネスロジックがトリガー内に埋め込まれていると、単体テストが行いにくくなることがあります。
依存関係が多くなると、一部の変更が他の部分に影響を与え、予期しないバグを引き起こす可能性があります。
ひとこと
トリガーは簡単な機能を自動化する際には真っ先に思いつくソリューションでしょう。
しかし、その先のメンテナンス性も考慮して、本当に実装すべきかどうかを検討すべきです。
コメント