Force.com プラットフォームの欠点 [終了]

https://stackoverflow.com/questions/1664503

12-09-2019
|

質問

現在、の使用を検討しています。フォースドットコム当社の開発プラットフォームとしてのプラットフォーム、営業担当者、および Force.com Web サイトには、これが世界最高のプラットフォームである理由がたくさんあります。ただし、私が探しているのは、そのようなプラットフォームを使用することの実際の欠点です。

解決

まずはここで 10 を紹介します。

Apex は独自の言語です。Force.com Eclipse プラグイン以外には、リファクタリングやコード分析などの利用できるツールはほとんどありません。
Apex は他の言語に比べて遅れていると考えられている Java 5 をモデルとしており、ツール (#1 を参照) がないと非常に扱いにくい場合があります。
導入は依然としてかなり手動で行われており、多くの注意点や手動手順が必要です。この状況は時間の経過とともに徐々に改善されていますが、自動展開に慣れている場合はがっかりするでしょう。
Apex にはパッケージ/名前空間がありません。すべてのクラス、インターフェイスなど。サーバー上の 1 つのフォルダーに存在します。これにより、コードがあまり整理されなくなり、名前の衝突を避け、コンテキストを提供するためにクラス/インターフェイス名が必然的に長くなります。これは私の最大の不満の 1 つであり、この理由だけで Force.com 上に構築することを自由に選択するつもりはありません。
「force.com IDE」、別名force.com eclipseプラグインは信じられないほど遅いです。クラスファイル、テキストファイルなど、ファイルの保存には、オブジェクト、データ型、クラスファイルなどの数に応じて、通常少なくとも 5 秒、場合によっては最大 30 秒かかります。あなたの組織内にいます。保存はブロックアクションでもあり、コンパイルだけでなく、ローカルプロジェクトとサーバーとの完全な同期も必要になります。Java や .NET よりも桁違いに遅い。
オンライン開発者コミュニティはあまり健全ではないようです。フォーラムの投稿の多くが未回答または未解決のままであることに気付きました。これは、salesforce.com が使用しているフォーラムソフトウェアと関係があるのではないかと思いますが、これはかなりひどいようです。
Apex のデータアクセス DSL には、まだ改善の余地がたくさんあります。(N)Hibernate、JPA などとの競合性さえありません。
Apex/VisualForce でのアプリの開発は、ガバナ制限エンジニアリングの演習です。プログラマの時間の半分は、多数のガバナ制限や、visualforce ビューステート制限などのその他の問題を回避するための最適化に費やされます。最初から効率的なコードを作成していれば、この問題は起こらないと主張することもできますが、それはある程度真実です。ただし、セッション内で x 個を超えるクエリを実行したり、x 個を超えるレコードをループスルーしたりする正当な理由がある場合がよくあります。
特に、保存 -> コンパイル -> 実行のサイクルは非常に遅いです。CSS や JavaScript の小さな変更をテストするなどの目的で、静的リソースバンドル全体を圧縮してアップロードする必要がある場合。
一般に、オープンソースであることの利点がなければ、生まれたばかりのプラットフォームには痛みがあります。プラットフォームのバグを検証したり修正したりする方法はありません。彼らはそれを IdeaExchange に投稿するように言います。はい、頑張ってください。

免責事項/開示事項:Force.com などのホスト型プラットフォームには多くの利点があります。Force.com は定期的にプラットフォームを強化しています。それについては好きなものがたくさんあります。Force.com を構築してお金を稼いでいます

他のヒント

いくつかの答えが得られたようですが、プラットフォーム上のさまざまなガバナ制限を回避するためにどれだけの時間が無駄になっているかを繰り返したいと思います。私はこのプラットフォームを一定のレベルでは気に入っていますが、一般的なアプリケーション開発プラットフォームとしては、このプラットフォームを強く、強く、断固として推奨します。それが必要な場合は、非常に構成可能で拡張可能な CRM アプリケーションとして最適です。彼らのマーケティングは、一般的な開発プラットフォームとしての Force.com のアイデアを推進する点で優れていますが、まだそれに近づいていません。

安定したプラットフォームを使用し、パフォーマンスと安定性に関する大きな問題を回避する効率は、人々が言及する制限を超えてコーディングしようとすると簡単に無駄になってしまいます。プラットフォームには制限が多すぎて、完全にイライラしてしまいます。これらの制限は、多くのユーザーがいる場合に到達するハイエンドの制限ではなく、ほぼすぐに制限に達します。

通常、これらを回避するテクニックはありますが、実際のアプリケーションのビジネスロジックを開発しようとしているときに、それらを回避する戦略を見つけ出すのは非常に困難です。

この環境が開発者にとっていかに不親切であるかを簡単に理解するには、上で言及した「デバッグ環境の欠如」を考えてみましょう。それよりもひどいです。デバッグログには、サーバーに対する最新のリクエストが最大 20 件までしか表示されません。したがって、アプリケーション内で開発しているときは、「新しい」デバッグリクエストを作成し、名前を選択して「保存」を押し、アプリに戻り、ページを更新し、クリックしてデバッグタブに戻り、デバッグログを格納するリクエストで、「検索」を押して、探しているテキストを検索します。デバッグ出力を見るのに 10 回クリックするような作業です。些細なことのように思えるかもしれませんが、これは開発者のエクスペリエンスにどれほど配慮や考慮が払われていないのかを示す一例にすぎません。

開発プラットフォームに関するすべては、後から付け加えられたものです。それは驚くべきことですが、ほとんどの場合、合計PITAです。自分が何をしているのか正確にわかっていない場合 (認定資格を持っていて、Apex についてよく理解している場合など)、別の環境で行う場合に比べて、簡単に 10 ～ 20 倍以上の時間がかかります。たとえ成功できたとしても、それは途方もなく簡単なことのように思えます。

ガバナ制限は確かにそれほど悪いです。さまざまな制限 (データベースクエリ、返される行、「スクリプトステートメント」、将来の呼び出し、コールアウトなど) の組み合わせがあるため、知っておく必要があります。 その通り これらを避けるためにあなたがしていること。たとえば、オブジェクトに計算ロールアップの「式」フィールドがあり、子オブジェクトにトリガーがある場合、親オブジェクトのトリガーが実行され、それらが制限に対してカウントされます。そのようなことは、挑戦しては失敗するという苦痛なプロセスを経るまでは明らかではありません。

「限界を突破する」という終わりのないゲームで、1 つの限界を回避するために 1 つのことを試み、別の限界に達することになります。その過程では、すべてのテストコードを書き直すだけでなく、アプリ全体とアプローチを大幅に再構築する必要があります。あなた しなければならない 実稼働環境にデプロイするために 75% のテストコードカバレッジがあり、これは実際には非常に良いことですが、他のすべての制限と組み合わせると、非常に負担がかかります。通常のユーザーシナリオでは発生しないテストコードを作成すると、実際にはガバナ制限に達することになりますが、その場合はカバレッジを達成できなくなります。

それは言うまでもなく、他の多くの問題です。梱包はあなたが期待しているものではありません。組織の管理者による大幅なユーザー介入と設定がなければ、アプリをパッケージ化してユーザーに配信することはできません。AppExchange はまったくの冗談であり、アプリをリストに掲載するためだけに 5,000 円も請求し始めています。データローダーを使用したインポートは、特にトリガーがある場合には面倒です。1 つのステップで別の組織 (開発組織など) に簡単に再インポートできるように、リレーションシップを含むすべてのデータを 1 つのステップでエクスポートすることはできません。本番環境からサンドボックスを更新できるのは、例外なく月に 1 回のみです。また、アカウントエグゼクティブに連絡して機能のロックを解除しない限り、デフォルトではデータを更新に含めることはできません。カスタムオブジェクト内のデータを一括削除することはできません。パッケージ名は変更できません。物事によっては、多くの時間がかかる場合があります日々アプリをデプロイする前のデータのバックアップなど、要求後に完了する必要があります。途中で進捗状況レポートがなく、エクスポートがいつ行われたのか正確に把握できません。データ間に関係がある場合、データの同期性の問題が発生することを考えると、単一のステップで多数のオブジェクトをエクスポートできる「トランザクション」のようなものが存在しないという点で、データの整合性に関する重大な問題が発生します。おそらく、これの一部を容易にする商用ツールがいくつかありますが、これらは多額の予算を持たない通常の開発者には手の届かないものです。

ここで他の人が言ったことはすべて真実です。ファイルの保存には 5 秒から 1 分かかる場合があります。

このプラットフォームはある意味非常に優れており、マルチテナント環境で他の誰もやっていないことをやろうとしているので、私はそれほど否定的になるつもりはありません。これは非常に革新的な環境であり、いくつかのレベルでは強力ですが (私は実際に VisualForce がとても気に入っています)、もう 1 ～ 2 年待ってください。彼らはVMwareと提携しており、おそらくそれは開発者に刑務所ではなく、もう少しベビーサークルのような作業を提供することにつながるだろう。

ここ 2 週間ほど、このプラットフォームでの開発にかなりの時間を費やした私が皆さんにお伝えできることをいくつか紹介します。

RESTful API はありません。呼び出し可能な SOAP ベースの API はありますが、真の RESTful 呼び出しを行う方法はありません。
SObject を取得して JSON オブジェクトに変換する簡単な方法はありません。
Visual Force ページは、カスタマイズするまでは問題ありませんが、その後は大変な作業になります。
Visual Force ページは SObject にバインドする必要があります。そうしないと、日付ピッカーや選択リストなどの標準入力フィールドを機能させることができません。
Eclipse プラグインは、一人で作業する場合には問題ありませんが、Eclipse プラグインを使用して大規模なチームで作業する場合は忘れてください。サーバーとの同期を処理できず、クラッシュしてしまい、まったく役に立ちません。
デバッガはありません!デバッグしたい場合は、文字通り system.debug ステートメントによってデバッグされます。おそらくこれが私が見つけた最大の問題です
彼らの「MVC」モデルは実際には MVC ではありません。これは ASP.NET Web フォームに非常に近いものです。ビューはモデルだけでなくコントローラーにも密接に結合されています。
大量の文書を保管することは現実的ではありません。100 GB を超えるドキュメントを保存する必要があるのですが、とんでもない数字が引用されました。ドキュメントストレージを amazons S3 インフラストラクチャに実装することにしました
たとえ言語が Java ベースであっても、それは Java ではありません。外部パッケージやライブラリをインポートすることはできません。また、利用できる基本ライブラリは非常に限られているため、多くのものを外部に実装し、それらのビットをforce.comによって呼び出されるサービスとして公開していることがわかりました。
外部の SOAP または REST ベースのサービスを呼び出すことはできますが、メッセージ本文は 100 kb に制限されているため、呼び出せる内容は非常に制限されます。

正直に言うと、force.com プラットフォームのようなもので開発することには潜在的な利点がありますが、私にとって、force.com プラットフォームを真のエンタープライズレベルのアプリケーションに使用することはできません。せいぜい、基本的な粗末なスタイルのアプリケーションをいくつか書くことができますが、一度複雑なものに移行すると、私はそれを疫病のように避けるでしょう。

うわー、このプラットフォームで数年間働いてきた私には、制限があることさえ知らなかったことがたくさんあります。

ただし、他にもいくつか追加します...

行ごとのデバッガーがない理由は、それがマルチテナントプラットフォームであるためです。少なくとも SFDC はそう言っています。スレッドが豊富なプログラミングのこの時代では、それはあまり言い訳にならないようですが、どうやらそれが理由のようです。コードを記述する必要がある場合は、デバッガとして「System.debug(String)」を使用します。約 12 年前には、Java 1.2 でより高度なサーバーデバッグツールがあったことを覚えています。

私がこのシステムに関して本当に嫌いなもう 1 つの点は、バージョン管理です。Spring フレームワークは、Spring が通常使用される用途には使用されません。実際には、バージョン管理というよりも SFDC の構成ツールとして使用されます。SFDC はゼロのバージョン管理を提供します。

たとえば、SFDC レポートを CSV ファイルにエクスポートして受信者のリストに電子メールで送信するようにスケジュールするなど、非常に簡単に思えるはずの作業に何日も行き詰まることがあります。そうですね、これを行う最も簡単な方法は、ワークフロールールと Visualforce メールテンプレートを使用して、カスタム項目を持つカスタムオブジェクトを作成することです。次に、コードについては、レポートデータを Visualforce 電子メールテンプレートに添付ファイルとしてストリーミングする Visualforce コンポーネントを作成し、カスタムオブジェクトのフィールド更新をスケジュールする匿名の APEX コードを作成する必要があります...SFDC 開発者にとって、これはほぼ毎日の作業です...非常に単純に見えるタスクを実行するために、約 5 つの異なるテクノロジを組み合わせようとしています...そして、これは管理者の頭痛や緊張を引き起こす可能性もあります。通常、ユーザーコミュニティで機能しないことを行う提案を受けて (すでに誰かが言ったように)、多くのことを試した後でこれに気づきます。それらを開発しても、「VisualForce ページをスケジュールできない」、「スケジュール可能なコンテキストから getContent を呼び出すことができない」、またはその他の難解な理由など、奇妙な理由で機能しないことがわかるでしょう。。

SFDC プラットフォームには、非常に多くの、気が狂うほどの小さな落とし穴があるため、それらがなぜそこにあるのかを知れば、それは理にかなっています...しかし、それらは依然として、やるべきことを妨げる非常に悪い制限です。これが私の一部です。

ほとんどすべての種類のレコードについて、「すぐに」レコード所有者情報を取得することはできません。レコードの作成時に所有者を挿入するレコードにリンクするトリガーを作成する必要があります。なぜ？所有者は「人」または「キュー」のいずれかであり、この 2 つは大きく異なるエンティティであるため、簡単に答えます...それは当然ですが、プロジェクトを文字通りひっくり返す可能性があります。
狂気のセキュリティモデル。例：「公開レポートの管理」権限は「レポートの作成とカスタマイズ」とは大きく異なり、基本的にプラットフォーム上のすべてに当てはまります...特にあらゆる種類のフォルダー。
前述したように、サポートは基本的に存在しません。あなたが非常に自給自足の個人であるか、SFDC リソースを豊富に持っているか、時間がたっぷりあるか、非常に寛容なマネージャーを持っているか、または正常に動作している SFDC システムを担当している場合は、かなり良い状態にあります。形。これらのいずれの立場にも属さない場合は、深刻な問題に陥る可能性があります。

SFDC は非常に魅力的なビジネス提案です...設備の設置面積がなく、セキュリティが非常に優れており、固定価格で、インフラストラクチャが不要で、バッチ可能でスケジュール可能な処理を備えた Web ベースの CRM が得られます...しかし、他の投稿者が言ったように、これは開発学習においてはかなりの強化であり、コンサルティングを利用する場合、私が見た中で最も安い料金は 1 時間あたり 200 ドルだったと思います。

Salesforce は、いくつかのテクノロジーが普及してから何年も経ってから他のものと統合する傾向があります。JSON や jquery が思い浮かびます...また、JIRA などの統合を希望する他の一般的なインフラストラクチャがある場合は、多額の追加料金が発生することが予想され、非常にバグが多い可能性があります。

そして、他の投稿者の 1 人が言及したように、あなたは常にガバナー制限と戦っていて、気が狂ってしまう可能性があります...添付ファイルは 5MB を超えることはできません。期間。また、場合によっては 3MB 未満になることもあります (base64 エンコードの場合)。クラス内の 10 個の HTTP コールアウト。期間。公開されている知事の制限は数十ありますが、そうでないものも多く、間違いなく見つけて叫びながらオフィスから逃げ出したくなるでしょう。

私はこのプラットフォームが本当に本当に気に入っていますが、信じてください。それは本当に残酷な愛人になる可能性があります。

しかし、SFDC に対して公平を期すために、私はこう言いたいと思います。このプラットフォームに関して私が感じている最大の問題は、プラットフォームそのものではなく、プラットフォームを目にするものの、そのプラットフォームで開発したことのないほぼすべての人が抱く巨大な期待です。そしてそれらの人々は、ビジネス組織において大きな権威のある地位に就く傾向があります。マーケティング、販売、管理など。大規模な切断が発生し、毎日混乱が生じたり、混乱が生じたりする可能性があります。これはすべて、この素晴らしいプラットフォームが奇妙な問題を抱えていて、何千人もの人々が、うまくいかないのになぜうまくいくのか、理解しようと毎日苦労しているからです。」 t.

編集：
MVC に関する lomaxx のコメントに追加します。SFDC の用語では、これは「ビューステート」として知られるものと密接に関連しています。また、VF ページにあるものは次のとおりであるため、非常にバグが多い可能性があります。ないページのコントローラークラスに含まれるもの。そのため、「保存」ボタンをクリックしたとき (または HTTP コールアウトなどを行ったとき)、ページ上の内容とコントローラーが SF に書き込む内容を同期するには、奇妙な回転を経る必要があります。うざいよ。

私は他の人々がより深く欠点をカバーしていると思いますが、私には、すべてで、コードの再利用の方法で、MVCパラダイムを使用するか、または多くをサポートしていないようです。単純なアプリケーションを超えて何かをするには、ASP.Net MVCのようなものを使用してアプリケーションを開発するに比べて欲求不満の練習です。

さらに、ツール、データ層とコードをリファクタリングや開発プロセス中にフィールドの名前を変更しようとしているのフラストレーションは役立ちません。

私はそれはかなりクールだCMSとして考えるが、非CMSアプリケーションのためのプラットフォームとして、それは私には意味がありませんです。

セキュリティモデルも非常に非常に制限的である...しかし、これは最悪の部分ではありません。現在、ユーザーが特定のアクションを実行する能力を持っているかどうかを断言することはできません。

あなたが彼らの役割は何であるかどうかを確認することができますが、その役割は、現在のアクションを実行する権限を持っているかどうかをチェックすることはできません。

さらに悪い「行動をしようとすると例外がありますならば、それをキャッチ」への技術サポートからの応答がある

「クラウド」プラットフォームは、Force.comをされて考慮すると、外部のWSDL定義のサービスをクライアントとして動作する能力はかなりがっかりです。 HTTPを参照してください。：あなたがすることに終わるかもしれない何のため//force201.wordpress.com/2010/05/20/when-generate-from-wsdl-fails-hand-coding-web-service-calls/する

上記のすべてに、私は、Javaプログラマは、Force.comのためのコードを記述することができVMforceのリリースでは、上記の欠点をどのように変化するか？

好奇心

http://www.zdnet.com/ブログ/繧/ vmforcecom-再定義-のPaaS-風景/ 1071 の

私は、彼らがこれらの問題に対処しようとしていると思います。 dreamforceで、彼らは私たちが、私は詳細が何であるかわからないだけ4にガバナ制限をドロップしようとしている述べました。彼らは、早期アクセスのためのREST APIを持っている、と彼らはクラウドでRuby開発であるHerokuのを買いました。あなたは上のすべてのあなたのWeb開発を行うことができますので、彼らはdatabase.comで、データベースを分割し、あなたのDBはdatabase.comを使用して呼び出します。

私は、彼らはそれをできるだけ依存しないようにしようしていると思います。彼らのセーフハーバーステートメントのみ、彼らが現在持っているものに、彼らの言うことには購入しないようなので、しかし、今これらに関する権利は全て発表や早期アクセスされています。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow