はじめに
HTML5でのアプリケーション開発は、エンタープライズ向けアプリケーションでも当たり前のようになってきました。これはSalesforceにおけるアプリケーション開発でも同じです。
Salesforceでのアプリケーション開発はVisualforce/Apexで行うというのが数年ほど続いてきたので、HTML5つまりJavaScriptを主体とするアプリケーション開発にはなれていないベンダーも多数あるかと思います。自分は創業当時からJavaScriptでのSPA(Single Page Application)をメインプロダクトに据えた会社を運営しており、Salesforceのパートナーとしても長いことやっていますので、このあたりのノウハウは比較的多い方です。そのためこのエントリはそれなりに説得力を持ってお届けできるとは思います。
真っ先に行うべきこと
もしあなたがSalesforce上でモダンなJavaScriptアプリケーション開発を行うことになったときに、まずもってこれだけは外せない、といえるのは以下です。
- ビルド環境を整えること
Salesforceに限らずではありますが、今日においてこれを行わないSPA開発は早々に破綻します。ビルド方法にはいろいろありますが、2015年現在おすすめのビルド環境は以下になります。
- ビルドツール: Grunt/gulp
- パッケージマネージャ: npm(+ browserify), 補助的にBower
Salesforceでの開発に慣れた方には見慣れない単語かもしれません。ビルドといえばAntだろ、Force.com Migration ToolだってAntじゃないか、mvnはどうした、という方はまず出自が違うことを認識しなければなりません。
上記のツールはすべてNode.jsの資産です。好きとか嫌いとかにかかわらず、現在のHTML5/SPAのフロントエンド開発にはNode.jsはもう必須のツールになっています。JavaがいいだとかRubyが好きだとかの話ではもう無いのです。フロントエンド開発に関するほぼすべてのツールがNode.jsを前提としています。これを使わないのは一周遅れになることを余儀なくされるのは間違いありません。
アンチパターン
Salesforce上でのモダンなアプリケーション開発を目指すときに「やってはいけないこと」を挙げたほうがよりインパクトがあるでしょう。実際、これから挙げる事項は多くのSalesforceデベロッパーには多少なりとも心当たりがあるかもしれません。
静的リソースにJavaScriptのソースコードをそのまま置く
ソースコード＝実行ファイルとしてJavaScriptを見るのは、JavaScriptがアプリケーションの添え物であった牧歌的な古き良き時代の話です。HTML5/SPAが全盛の今、JavaScriptは完全にアプリケーションの根幹となる主役です。
1ファイルのJavaScriptソースコードにすべてのアプリケーションコードを分割せずにだらだらと書いていたりしませんか？あるいは複数のJavaScriptファイルを読み込む<script src="">タグをHTML内にいくつも記述していませんか？これらはアンチパターンの典型です。
2015年のJavaScriptは事前にビルドするのが当たり前です。数年前のプラクティスをそのままでいてはいけません。ソースコードは別に管理しましょう。静的リソースにはビルド済みのJavaScriptをデプロイするようにします。
3rd PartyのJavaScriptファイルをダウンロードして静的リソースにを自分でアップロードする
SPAの開発は対象が巨大になるため、ほとんどの場合、オープンソースライセンスで提供されている3rd PartyのJavaScriptライブラリをアプリケーションに組み入れて使うことになるでしょう。しかしここでパッケージマネージャーを使わないのは問題です。
思えば、今までバージョン管理やアップデートのことを考えないまま開発できていたのは幸運でした。jQueryで少し画面を書き換えるぐらいで、所詮JavaScriptは添え物でよかったからです。
でもこれからはそうは行きません。JavaScriptのパッケージマネージャとして npm、ないしはBowerを使いましょう。npmを使う場合は必然的にbrowserify/webpackなどを併用することになります。browserifyを使った場合は、ビルドされたコードの中に3rd partyのスクリプトコードも組み込まれた状態で追加されますので、そのまま静的リソースにデプロイすればOKです。Bowerを使った場合でも、インストールしたパッケージをzip圧縮して静的リソースとしてデプロイするタスクをGrunt/gulpのスクリプトに記述しておけば一瞬です。
Salesforceの開発コンソールで全て済ませようとする
Cloud9 IDEのようにエディタも含めて全部クラウド側で開発環境が成立するのはおそらく近い未来ではありますが、2015年現在はまだ開発はみなさんの手元のPC上で行うべきものです。Salesforceの開発コンソールにそこまで期待するのは時間の無駄というものです。特にJavaScriptの開発に関してはなにもしてくれません。適当なコードのテストくらいならまあいいですが、プロダクトレベルの開発は到底できません。まずもってVCSの欠如が致命的です。
Lightningの開発のデモを見てると開発コンソールでやっていたりするので、それでもいいのかと思いがちですが、無謀です。今すぐにローカルの開発環境を整えましょう。
Eclipse (Force.com IDE) を使う
ローカルで開発環境？ならばIDEだよね、と思いがちですが、ことJavaScriptに関しては、このIDEは何もしてくれません。
もちろんSalesforceでサーバサイドを開発する以上、Apexは避けられないことが多いですが、フロントエンドの開発にはもっと別のものを使ったほうがよいでしょう。エディタとしては近年Sublime Textが人気あるようです。MavensMateもいいですが、これも必須ではありません。ApexやVisualforceページの開発はさておき、少なくともJavaScriptのビルドや配布はGrunt/gulp経由で行うことになるからです。
ちなみにForce.com IDEでついでにフロントエンドの開発までやっていると、前述の「静的リソースにJavaScriptのソースコードをそのまま置く」アンチパターンが必然的に起こります。これも使うべきでない理由のうちの1つです。
常にSalesforceにデプロイして開発する
Salesforceには永久無料のDeveloper Editionがあるので、開発者一人ひとりが開発テスト用のインスタンスを持っていることは別に少なくありません。僕も2006年にSalesforceを初めて使った時には、なんとすばらいしい環境だろうと感動したものです。
でも、データベーススキーマとかサーバロジックの開発とかはともかくとして、フロントエンドの開発においては、適切にサーバサイドとはインターフェースを切って開発するべきです。具体的には、フロントエンドのコードはすべて手元のローカル環境でのプレビューおよびテストが可能な環境を整えるべきでしょう。
もしあなたの開発したJavaScriptがSalesforce上でしか動かないようになっているのだとしたら、それは危険信号です。密結合はテストのしにくさに繋がります。テストされないコードはバグの温床というだけでなく、アプリケーションの変更に対する強烈なネガティブフィードバックになり、敏捷さを失います。
フロントエンドコードの自動テストなんてのは夢物語だ、実施コストに合わない、という意見をお持ちの方もいるかと思います。たしかにそういう面はあります。でも問題は、そういったフロントエンドのコードの中にも自動テスト可能な部分が多数あるにも関わらず、それらが一緒に混ぜ合わされてしまっている点です。
Salesforceの開発に慣れていると、ソースコードの保存ごとにサーバへのデプロイを待つ、というのが当たり前になっている人もいます。Apexコードはともかく、フロントエンドの開発でもそれを受け入れてよしとしているのだとすると、明らかに時間をロスしているといえるでしょう。
Salesforce.com 社の公式見解を鵜呑みにする
これもあたりまえですが、どんなに会社同士のパートナー関係が密であっても、ベンダーからの情報を闇雲に信じるべきではありません。バッドノウハウをベストプラクティスと言いくるめらているのでは、という疑いは常に持つべきです。あと、ベンダー側に悪意はなくてもセンスの問題があります。センスの問題はセンスの問題なので突っ込みづらいのですが、究極は自分を信じるしかありません。そのためにもやはり情報は広く収集すべきです。
勘違いしてほしくないのは、盲目的に信じることと、自分で調べた上で判断を下してそれでも選ぶこととは、まったく別物だということです。あまり好ましいとは思いませんが、開発の現場にも政治的理由は多々ありますし、それに僕らが作っているのはビジネスアプリケーションです。
まとめ
以上はもちろん個人の主観がかなり入っていますので、まあその点は割り引いてみてください。少なくともうちはそういう感じでやってますよ、というだけの話です。
ただ、Salesforceのパートナー、とくにISVパートナーの中で、ある程度意思決定に携われる人、プロダクトアーキテクトあるいはそれに準じる人は、一度は持って欲しい視点かと思います。