Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Salesforce 大規模開発で留意するトピック集
Search
CLB
April 19, 2021
0
1.1k
Salesforce 大規模開発で留意するトピック集
【オンライン開催】Salesforce Developers Meetup #25 でのスライド資料です。
CLB
April 19, 2021
Tweet
Share
More Decks by CLB
See All by CLB
Salesforce Functions (Java)で実装はどう変わるか
altyjp
0
430
Featured
See All Featured
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
720
Optimising Largest Contentful Paint
csswizardry
33
2.9k
Raft: Consensus for Rubyists
vanstee
136
6.6k
Imperfection Machines: The Place of Print at Facebook
scottboms
265
13k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.2k
Measuring & Analyzing Core Web Vitals
bluesmoon
4
130
The Language of Interfaces
destraynor
154
24k
Rails Girls Zürich Keynote
gr2m
94
13k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
Transcript
Salesforce 大規模開発 で留意するトピック 集 Sato Ryo @ Team spirit inc.
自己紹介 Sato Ryo です。 仕事: チームスピリット で チームスピリット EX を開発しています。
バックエンド(業務処理の開発担当)です。 Salesforce歴 2 年くらいの初心者です。 趣味: ネコ、サバゲー、キャンプなどなど。
チーム スピリット とは? https://www.teamspirit.com/ja-jp/lp/ex/
内容 Salesforce の大規模開発で直面した問題や生産性を上げる為の トピックを紹介します。 パッケージの分割を最初から行う SFDX開発でのクラスの管理方法 テストコードでSFオブジェクトは利用しない方が良い?
20万件のワナ
パッケージ分 割を最初から 行う 理由 Apex コードの文字数は6MB までの制限がある。 パッケージのアップグレードに失敗する恐れがある。
パッケージ の アップグレードインストール時にインス トール時のバックアップ領域が不足することがあり、 「 Dependent class is invalid and needs recompilation」など のエラーが発生する。 こうなると時の運でインストールができるかできないか が決まる。 経験的に、3MBを超えたあたりからパッケージの分割を考え た方が良い。
こんな感じで小ネタを挟んでいきたいと 思います。 次はSFDX でリポジトリをすっきりさせる 小技です。
SFDX開発で のクラスの管 理方法 Apexクラスが増えてくると、classes/ に Apex クラスが増えて いきません? ←ここが厚くなる
SFDX開発で のクラスの管 理方法 実はフォルダ分けして配置することができます。 Java とは違い、Apex はフォルダの位置を変更しても問題なく 動作します。
次:テストコードの書き方
テストコード でSFオブジェ クトは利用し ない方が良 い? テストコードでこのようなコードを書く例はありませんか? @isTest static void
fooTest() { TestData__c data = new TestData__c(); data.value = 'test val 1’; insert data; String actual = getfoo(); System.assertEquals(data.value, actual); }
テストコード でSFオブジェ クトは利用し ない方が良 い? SFのテストオブジェクトは他のテストと共用です。 その為、前述のテストは並列実行時にエラーが発生すること があります。
並列実行は解除することができますが、直列実行となる為、 その分時間がかかります。 https://developer.salesforce.com/docs/atlas.ja- jp.apexcode.meta/apexcode/apex_testing_best_practices.htm
テストコード でSFオブジェ クトは利用し ない方が良 い? isTest(isParallel=true)を利用するとそのテストクラスは並列実行 が有効になります。 リポジトリパターンを利用してテスト時はMockのリポジトリを
利用するなど、SFオブジェクトに依存しないテストを作ること も大切です。 @isTest(isParallel=true) private class fooTest { @isTest static void fooTest() { MockedData data = new MockedData(); data.value = 'test val 1’; String actual = getfoo(); System.assertEquals(data.value, actual); } }
ラスト、本番中に発覚しやすいバグ です。
20万件のワナ Q. 以下のSOQL, 問題点が分かりますか? SELECT Id FROM Account WHERE Name
!= ''
20万件のワナ 先ほどの SOQL、非セレクティブSOQLです。
20万件のワナ 非セレクティブ SOQL(効率の悪いSOQL)であり、前述の SOQLは テーブルフルスキャンが発生する。 フルスキャンの結果、スキャンが必要なレコードが20万件を 超えると System.QueryException
が発生する。 レコードの数が増えることによって発覚するバグで、本番環 境で発生しやすいバグと言える。
20万件のワナ セレクティブSOQLの条件(公式ドキュメントから抜粋) セレクティブ SOQL クエリ条件クエリ検索条件の 1 つがイン デックス付き項目にあり、そのクエリ検索条件によって結果 となる行数がシステム定義のしきい値より少なくなる場合、
そのクエリはセレクティブです。SOQL クエリのパフォーマ ンスは、WHERE 句に使用される 2 つ以上の検索条件がその 条件を満たす場合に改善されます。 選択度しきい値は、初めの 100 万件のレコードの 10%、それ 以降のレコードの 5% 未満の、最大 333,333 件です。インデッ クス付き標準項目であるクエリ検索条件がある場合など一部 の状況では、しきい値が高くなる場合があります。また、選 択度しきい値は変化します。 https://developer.salesforce.com/docs/atlas.ja- jp.apexcode.meta/apexcode/langCon_apex_SOQL_VLSQ.htm
20万件のワナ SOQL 実行計画 を確認して、フルスキャンになる物がないか 確認しよう。 やり方 1. Help >
Preferences で Enable Query Plan を有効化 2. Query タブの Query Plan をクリック
20万件のワナ 上級者編 Nullが入るとフルスキャンになる。 public List<Account> getAccountByIds(List<Id> accountIds){ return [SELECT
Id FROM Account WHERE Id IN :accountIds]; }
ありがとうございました!