これからSalesforce開発に携わる人へ

## はじめに

本記事はワタシが業務で係わったApex + Visualforceを使ったアプリケーション開発を中心にした内容になっています。
そのため、ガチのSalesforce開発とは異なりますので、よしなによろしくお願いします。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33505/7f0a0693-f545-4db9-4c48-b3865aef01e5.png" width="10%">

---

## Salesforceを開発する上であったほうがよいテクニカルスキル

実はSalesforceでApex + Visualforceのアプリケーション開発は、通常のWebアプリケーションの開発経験があれば、そこまで苦労しません。
Apexはオブジェクト指向のプログラミング言語で、Javaに大変似ています。
Visualforceは、標準コンポーネントもありますが、HTMLやCSS、JavaScriptも動作しますので、フロントエンドスキルはそこまでずれません。

開発面は、思った以上に難しくないのです。

私がSalesforceでアプリケーション開発をする上で、１番苦労したのが開発よりも設計でした。

---

## 設計において最初に考えるべき事

Salesforceには様々な権限セットが存在します。

* ロール
* プロファイル
* 公開グループ
* 共有ルール

組織やゲストユーザ、アクセス権限など、Salesforceのアプリケーション開発を行う上で、最低でも上記の４つは理解していないと、いざ開発したアプリケーションは使い物にならなりません。

---

## できるだけSalesforce既存の機能を使う

Apexを使うことでSalesforceに関わる機能は、ほとんど実装することができます。
しかしApexは実行ユーザによって権限レベルが変わるため、実装内容によってはアクセス権限エラーが発生します。
それを解決するために `without sharing` を使ってシステム権限で実行できますが、それだとセキュリティホールになりかねません。

Salesforceには `ワークフロールール` や `プロセスビルダー` など便利な既存機能がいくつもあります。
そちらを使うことで、アクセス権限の管理をSalesforce側に委ねることで、セキュリティ対応や影響範囲の割り出しをおこなうことができます。

Apexで解決するのではなく、まずはSalesforceの既存機能を使う方針で設計してください。

---

## ガバナ制限を意識する

Apexで開発をすると必ず [ガバナ制限](https://developer.salesforce.com/docs/atlas.ja-jp.210.0.apexcode.meta/apexcode/apex_gov_limits.htm) というものを考慮する必要があります。

ガバナ制限とは...
> Apex はマルチテナント環境で実行するため、Apex ランタイムエンジンは、回避 Apex コードまたはプロセスが共有リソースを独占しないよう制限事項を強制します。一部の Apex コードが制限を超える場合、関連付けられたガバナは、処理できない実行時例外を発行します。
引用元：Apex 開発者ガイド

簡単に説明すると、１回の実行で可能な処理数を制限しているものです。
本番と違い開発用のSandboxだとオブジェクトのデータ量が少ない場合があります、ガバナ制限を意識しないと本番環境で例外が発生するという事に遭遇するかもしれません。
もちろん、レコードの成長速度も考慮しないと、いつの日か例外が発生するかもしれません。

---

## ER図を駆使しよう

SalesforceでApex開発をすると、必ずカスタムオブジェクトを作成するかどうかという選択を迫られます。

Salesforceにおけるオブジェクトは、オブジェクト間で参照することができるため、複雑になりがちです。
またレコードタイプによって、同じオブジェクトでも使う項目等を分けることができます。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33505/a5401ba6-451d-f690-ddf3-9329b7539c82.png" width="60%">
テーブル設計として考えると、一般的なアプリケーションも同じですが、Salesforceにおいてもオブジェクト設計は必要になります。

---

## 業務フロー図を作成しよう

Salesforceは巨大なオブジェクトを複数持ったアプリケーションです。
アプリケーション開発をしても、実際に使う側の業務フローによって紐付けるアクセス権限や共有設定は変わってきます。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33505/3a75a93a-a9ba-bcbe-5dcc-604743e851d3.png" width="60%">
どのタイミングで、なんのオブジェクトに、どのような内容で更新するのか。
その結果、どんなSalesforceの機能が動くのか。

開発するアプリケーションを整理し、いかなる業務フローにも耐えられるシステムを作るには、業務フロー図が最適だと思いました。

---

### 以上が設計！ いっぱい設計！！

---

## Apex開発はテスタビリティを意識せよ

Salesforceはリリース作業（変更セット）をする上で、テストコードを実行するようになっています。
そのため、作成するApexクラスにおいては、かならず単体テストの実行が必要になります。

そのため１つのクラスや処理で複雑な実装をせず、テスタビリティを考慮した実装にしたほうが理想です。

---

### 以上で開発終わり！

---

### フロントエンド側も忘れずに...

---

## Visualforceは標準のコンポーネントでもうまく行かない場合がある

VisualforceやComponentsでフロントエンドを開発する場合、標準のコンポーネントを活用するのが当たり前になっています。
しかし実際には想定した通りに動作しない場合があります。

[Columns headers for apex:column within apex:repeat with an apex:pageBlockTabe](https://developer.salesforce.com/forums/?id=906F000000097gzIAA)

こちらを読んで貰えれば分かると思いますが、テーブルの行をループを使って作る際、標準のコンポーネントを使うと正しく表示されない場合があります。
こういった際は、標準コンポーネントにこだわらず、素直にHTMLやJavaScriptを使って実現してください。

---

## まとめ

通常のWebアプリケーションの開発も設計が重要なのは変わりません。
しかし、Salesforce開発は実行するユーザのロールやプロファイルによってオブジェクトなどのアクセス権限等が変わってきます。

これまでのアプリケーション開発の経験以上に、影響範囲や考慮を意識すべきプラットフォームですね。
しかしSalesforce開発になれることで、エンジニアとしてスキルアップするのは間違いなしだと思います。