Platformデベロッパーの勉強をして意外だったこと3選
こんばんは、きゃらめるです。
滑り込み11月記事2本目です!笑
今日は、1記事にするほどの量はないけど残しておきたい、Platfomデベロッパーの試験で意外だったことを、3つまとめてみました。
ガバナ制限の制限値
多分、デベロッパー試験の中でちゃんと理解できていないとマズそうな部分第一位かもしれないですよね。。
そんな大事なところですが、試験勉強をするまでSOQLとDMLで別々に制限されていることを知りませんでした。
ガバナ制限としては以下のような制限があります。
# | 制限内容 | 制限値 | Limitsクラスの使用数確認メソッド |
---|---|---|---|
1 | SOQLクエリの実行回数 | 100 | getQueries() |
2 | SOQLクエリで取得できたレコードの総数 | 50,000 | getQueryRows() |
3 | DMLステートメントの実行回数 | 150 | getDMLStatements() |
4 | DMLステートメントで処理されたレコードの総数 | 10,000 | getDMLRows() |
※1トランザクションあたりの件数
このうちの、1と3の回数を合わせて100回を超えてはいけない、2と4を合わせて50,000件を超えてはいけない、だと思い込んでいました;
そもそも、SalesforceはDB操作を、レコードのデータに「影響を及ぼさないもの」「影響を及ぼすもの」に分けていて、前者がSOQLクエリ、後者がDMLなんですね。
SOQLの返り値
SOQLの返り値の型って5種類もあるんですね!
# | 型 | 備考 |
---|---|---|
1 | sObject[] | 一般的なやつ。0件の時は空になる(nullではない)。 |
2 | sObject | レコード件数が1件の時に使用可。0件でも複数件でもエラーになる。 |
3 | Integer | SELECTされる項目リストが「COUNT()のみ」の場合に使用する。 |
4 | AggregateResult[] | 集計関数を使用している場合はこれを使う。 |
5 | AggregateResult | SELECTされる項目リストが「COUNT(項目名)」の場合は、3ではなくこちらを使う。 |
2,3,5が驚きでした…。
特に3,5については、COUNTに引数を渡すか渡さないかで使える返り値が変わるのがややこしいですね;
AggregateResultであれば、COUNT()もCOUNT(項目名)の場合も受け取れるのかと思っていたのですが、そうではないようです。
COUNT()をAggregateResultで受け取ろうとすると普通にエラーになります。注意です。
リリース時のテストカバー率
単体テストコードでのカバー率が75%以上でなければリリースできないという知識はありましたが、ここでも思い違いがありました。
リリースに必要なカバー率は「コードの全量」に対するカバー率であり、「1つのApexクラス」に対してのカバー率は追っていない、というところです。
私は今まで、1つでもテストカバー率75%未満のApexクラスがあればリリースできない、と思っていました。
実際そんなことはなく、クラスAとクラスBとクラスCがあれば、クラスAがカバー率75%を下回っていたとしても、A, B, C合わせて75%あれば問題なかったのです。
テスト問題で上記を問われていたら、危うく落としてました;
おわりに
今回の記事で伝えたかったことがあります。それは、資格勉強もやっぱり大事、ということです。
私は前職で3年間、Salesforceの開発担当として手を動かしてきたわけですが、上記を知らなくても開発はできていました。
それは、ほとんどが安全な方に倒れる形で勘違いをしていたからです。
例えば、全てのApexコードのカバー率を75%以上にしても、テストのカバー率が高くて悪いことはないので、特に今まで問題になったことがなかったのです。
ただ、勘違いで無駄な制約を増やした分、時間を使ってしまっているのは確かです。その分、他に時間を割いた方がいいことだってあったはずです。
ガバナ制限に必要以上に怯えて、なんとかSOQLやDMLの発行を抑えられないかと躍起になって、当時のマネージャーに「そんな複雑に悩まなくても…」と言われたこともありました。
また、SOQLのCOUNT()の件は普通に使ったことがなかったのですが、結構ハマりポイントなのではないかと思っています。
これは他の資格の勉強をしている時にも感じたことなのですが、勉強を進めるほど「あの時のあの問題、これで解決できたのでは?」「あの部分の設定、今の私の知識ならもう少しいい感じにできた or もっと早く解決できた」と思うことがたくさん出てくるんです。
苦労した・時間がかかっただけならまだいいんです。自分の知識にはなっているはずなので。
ただ、実装を諦めた部分が少なからずある、というところが問題です。解決できた課題を解決できていないので。
私の前職はユーザ企業だったので、Salesforceの資格試験を受けることに意味を感じてはもらえませんでした。
そういう企業さん、たくさんあると思いますし、そんな中で働いていらっしゃる方もたくさんおられると思います。
会社から補助が出ない、情報も入ってこない中、試験の有料講座や試験を自腹で受けるのはかなり怖いです。情けないですが、私は無理でした。
今、Salesforce主催の無償ウェビナーで、各資格のポイントスタディのコースを実施しておられますね。
www.salesforce.com
現職に入社早々、認定アドミンのウェビナーも受けましたが、業務でなんとか学び取ってきたことがどんどん繋がるように理解できて、もう感動を覚えたくらいです笑
今回のデベロッパー資格も、無償ウェビナーで学ばせていただきました。体系的に学べる、という点が本当に分かりやすいです。
前職時代の私のような担当者の方には、是非ともこちらに出てみて欲しいです!!
ということで、資格勉強するのはいいぞ!という話でした!
来月はアドベントカレンダーに参加しますので、そちらの更新がメインになると思います!頑張ります!