Inconvénients de la plate-forme Force.com [fermé]

Nous envisageons actuellement d'utiliser la plate- forme Force.com comme plate - forme de développement et les vendeurs et le site Web force.com regorgent de raisons pour lesquelles il s'agit de la meilleure plate-forme au monde. Ce que je recherche, cependant, ce sont de réels inconvénients à utiliser une telle plate-forme.

En voici 10 pour commencer.

1. Apex est un langage propriétaire. À part le plugin force.com Eclipse, il y a peu ou pas d'outils disponibles tels que la refactorisation, l'analyse de code, etc.
2. Apex a été modelé sur Java 5, qui est considéré comme à la traîne par rapport aux autres langages, et sans outillage (voir # 1), peut être assez lourd.
3. Le déploiement est encore assez manuel avec de nombreux pièges et étapes manuelles. Cette situation s'améliore lentement avec le temps, mais vous serez déçu si vous avez l'habitude d'avoir des déploiements automatisés.
4. Apex manque de packages / d'espaces de noms. Toutes vos classes, interfaces, etc. vivent dans un dossier sur le serveur. Cela rend le code beaucoup moins organisé et les noms de classe / interface nécessairement longs pour éviter les conflits de noms et fournir du contexte. C'est l'une de mes plus grandes plaintes, et je ne choisirais pas librement de m'appuyer sur force.com pour cette seule raison.
5. L'IDE "force.com", alias le plugin force.com eclipse, est incroyablement lent. L'enregistrement d'un fichier, qu'il s'agisse d'un fichier de classe, d'un fichier texte, etc., prend généralement au moins 5 secondes et parfois jusqu'à 30 secondes en fonction du nombre d'objets, de types de données, de fichiers de classe, etc. dans votre organisation. L'enregistrement est également une action de blocage, nécessitant non seulement une compilation, mais une synchronisation complète de votre projet local avec le serveur. Des ordres de grandeur plus lents que Java ou .NET.
6. La communauté des développeurs en ligne ne semble pas très saine. J'ai remarqué que de nombreux messages du forum restent sans réponse ou sans réponse. Je pense que cela peut avoir quelque chose à voir avec le logiciel de forum utilisé par salesforce.com, qui semble assez nul.
7. L'accès aux données DSL dans Apex laisse beaucoup à désirer. Ce n'est même pas à distance compétitif avec des modèles comme (N) Hibernate, JPA, etc.
8. Le développement d'une application sur Apex / VisualForce est un exercice d'ingénierie des limites du gouverneur. On passe facilement la moitié du temps du programmeur à essayer d'optimiser pour éviter les nombreuses limites du gouverneur et d'autres pièges tels que les limites d'état d'affichage de Visualforce. On pourrait soutenir que si vous écrivez un code efficace pour commencer, vous n'aurez pas ce problème, ce qui est vrai dans une certaine mesure. Cependant, vous avez souvent des raisons valables de faire plus de x requêtes dans une session, ou de parcourir plus de x enregistrements, etc.
9. Le cycle de sauvegarde -> compilation -> exécution est extrêmement lent, esp. lorsqu'il s'agit de compresser et de télécharger l'intégralité du bundle de ressources statiques juste pour faire quelque chose comme tester un changement mineur CSS ou JavaScript.
10. En général, la douleur d'une plate-forme jeune et naissante sans les avantages d'être open source. Vous n'avez aucun moyen de valider et / ou de corriger les bogues de la plateforme. Ils disent de le publier sur leur IdeaExchange. Ouais, bonne chance avec ça.

Clauses de non-responsabilité / divulgations: Une plate-forme hébergée telle que force.com présente de nombreux avantages. Force.com améliore régulièrement la plateforme. Il y a plein de choses que j'aime à ce sujet. Je gagne de l'argent grâce à force.com

Je vois que vous avez obtenu des réponses, mais je voudrais réitérer le temps perdu à contourner les différentes limites du gouverneur sur la plate-forme. Autant que j'aime la plate-forme à certains niveaux, je la déconseillerais fortement, fortement, catégoriquement en tant que plate-forme générale de développement d'applications. C'est génial en tant qu'application CRM super configurable et extensible si c'est ce que vous voulez. Bien que leur marketing soit exceptionnel pour promouvoir l'idée de Force.com en tant que plate-forme de développement générale, il n'est même pas encore proche.

L'efficacité d'avoir une plate-forme stable et d'éviter de gros problèmes de performances et de stabilité est facilement gaspillée en essayant de coder autour des limites auxquelles les gens se réfèrent. Il y a tellement de limites à la plate-forme que cela devient complètement exaspérant. Ces limites ne sont pas des limites haut de gamme que vous atteindrez une fois que vous aurez beaucoup d'utilisateurs, vous les atteindrez presque immédiatement.

Bien qu'il existe généralement des techniques pour les contourner, il est très difficile de trouver des stratégies pour les éviter pendant que vous essayez également de développer la logique métier de votre application réelle.

Pour vous donner une idée simple de la non-convivialité de l'environnement pour les développeurs, prenez le "manque d'environnement de débogage" mentionné ci-dessus. C'est pire que ça. Vous ne pouvez voir que 20 des demandes les plus récentes adressées au serveur dans les journaux de débogage. Ainsi, au fur et à mesure que vous développez dans l'application, vous devez créer une demande de débogage "Nouvelle", sélectionnez votre nom, cliquez sur "Enregistrer", revenez à votre application, actualisez la page, cliquez sur votre onglet de débogage, essayez de trouver la requête qui hébergera votre journal de débogage, appuyez sur "trouver" pour rechercher le texte que vous recherchez. C'est comme dix clics pour regarder une sortie de débogage. Bien que cela puisse sembler anodin, ce n'est qu'un exemple du peu d'attention et de considération accordée à l'expérience du développeur.

Tout ce qui concerne la plate-forme de développement est une réflexion après coup. C'est remarquable pour ce que c'est, mais un PITA total pour la plupart. Si vous ne savez pas exactement ce que vous faites (comme si vous êtes certifié et avez une compréhension très intime d'Apex), cela vous prendra facilement 10 à 20 fois plus de temps que dans un autre environnement. quelque chose qui semble être ridiculement simple, si vous pouvez même réussir du tout.

Les limites du gouverneur sont en effet si mauvaises. Vous avez une combinaison de différentes limites (requêtes de base de données, lignes renvoyées, "instructions de script", futurs appels, légendes, etc.) et vous devez savoir exactement ce que vous faites pour les éviter. Par exemple, si vous avez un champ «formule» de cumul calculé sur un objet et que vous avez un déclencheur sur un objet enfant, il exécutera les déclencheurs d'objet parent et les comptera par rapport à vos limites. Des choses comme ça ne sont pas évidentes tant que vous n'êtes pas passé par le processus douloureux d'essayer et d'échouer.

Vous essaierez une chose pour éviter une limite, et en frapperez une autre dans un jeu sans fin de "frapper une limite". Au cours du processus, vous devrez réorganiser radicalement l'ensemble de votre application et de votre approche, ainsi que réécrire tout votre code de test. Vous devez avoir une couverture de code de test de 75% pour être déployé en production, ce qui est en fait une très bonne chose, mais combiné avec toutes les autres limites, c'est très lourd. Vous atteindrez en fait les limites du gouverneur en écrivant votre code de test qui ne se présenteraient pas dans les scénarios d'utilisation normaux, mais qui vous empêcheront d'atteindre la couverture.

Cela sans parler de toute une série d’autres problèmes. L'emballage n'est pas ce que vous attendez. Vous ne pouvez pas empaqueter votre application et la livrer aux utilisateurs sans intervention et configuration utilisateur importantes de la part de l'administrateur de l'organisation. L'AppExchange est une blague totale, et ils ont même commencé à charger 5K juste pour que votre application soit répertoriée. L'importation avec le chargeur de données est nul, surtout si vous avez des déclencheurs. Vous ne pouvez pas exporter toutes vos données en une seule étape qui inclut vos relations de manière à pouvoir être facilement réimportées dans une autre organisation en une seule étape (par exemple une organisation de développement). Vous ne pouvez actualiser un bac à sable qu'une fois par mois à partir de la production, sans exception, et vous ne pouvez pas inclure vos données dans une actualisation par défaut, sauf si vous avez appelé votre responsable de compte pour déverrouiller cette fonctionnalité. Vous pouvez' t supprimer en masse les données dans les objets personnalisés. Vous ne pouvez pas modifier les noms de vos packages. Certaines choses peuvent prendre de nombreusesjours pour terminer après que vous les ayez demandés, comme une sauvegarde des données avant de déployer une application, sans rapport d'avancement en cours de route et sans grande indication de la date exacte de l'exportation. Étant donné qu'il existe des problèmes de synchronisation des données s'il existe des relations entre les données, il existe de graves problèmes d'intégrité des données dans la mesure où il n'existe pas de "transaction" qui puisse exporter de nombreux objets en une seule étape. Il existe probablement des outils commerciaux pour faciliter une partie de cela, mais ceux-ci ne sont pas à la portée des développeurs normaux qui n'ont peut-être pas un budget énorme.

Tout le reste que les autres ont dit ici est vrai. L'enregistrement d'un fichier peut parfois prendre entre cinq secondes et une minute.

Je ne veux pas être aussi négatif parce que la plate-forme est très cool à certains égards et qu'ils essaient de faire des choses dans un environnement multi-locataires que personne d'autre ne fait. C'est un environnement très innovant et puissant à certains niveaux (j'aime beaucoup VisualForce), mais donnez-lui encore un an ou deux. Ils s'associent à VMware, peut-être que cela conduira à donner aux développeurs un peu plus un parc plutôt qu'une cellule de prison pour travailler.

Voici quelques éléments que je peux vous donner après avoir passé pas mal de temps à développer sur la plate-forme au cours des quinze dernières semaines environ:

1. Il n'y a pas d'API RESTful. Ils ont une API basée sur le savon que vous pouvez appeler, mais il n'y a aucun moyen de faire de vrais appels reposants

2. Il n'y a pas de moyen simple de prendre leurs SObjects et de les convertir en objets JSON.

3. Les pages de force visuelle sont correctes jusqu'à ce que vous vouliez les personnaliser, puis c'est tout un monde de douleur.

4. Les pages de force visuelle doivent être liées à SObjects, sinon il n'y a aucun moyen de faire fonctionner les champs d'entrée standard tels que le sélecteur de date ou la liste de sélection.

5. Le plugin eclipse est ok si vous voulez travailler seul, mais si vous voulez travailler dans une grande équipe avec le plugin eclipse, oubliez-le. Il ne gère pas la synchronisation vers et depuis le serveur, il se bloque et ce n'est pas vraiment utile du tout.

6. IL N'Y A PAS DE DÉBUGUEUR! Si vous voulez déboguer, il est littéralement débogué par des instructions system.debug. C'est probablement le plus gros problème que j'ai trouvé

7. Leur modèle "MVC" n'est pas vraiment MVC. C'est beaucoup plus proche des formulaires Web ASP.NET. Vos vues sont étroitement liées non seulement aux modèles mais également aux contrôleurs.

8. Il n'est pas possible de stocker un grand nombre de documents. Nous avons besoin de stocker plus de 100 Go de documents et on nous a cité un chiffre ridicule. Nous avons décidé d'implémenter notre stockage de documents sur l'infrastructure Amazons S3

9. Même si le langage est basé sur java, ce n'est pas java. Vous ne pouvez pas importer de packages ou de bibliothèques externes. De plus, les bibliothèques de base disponibles sont très limitées, nous nous sommes donc retrouvés à implémenter un tas de choses en externe, puis à exposer ces bits en tant que services appelés par force.com

10. Vous pouvez appeler des services SOAP ou REST externes, mais le corps du message est limité à 100 Ko, donc il est très restrictif dans ce que vous pouvez appeler.

En toute honnêteté, s'il y a des avantages potentiels à développer sur quelque chose comme la plate-forme force.com, pour moi, vous ne pouvez pas utiliser la plate-forme force.com pour de véritables applications au niveau de l'entreprise. Au mieux, vous pouvez écrire des applications de base de style crud, mais une fois que vous vous déplacez dans quelque chose de compliqué à distance, je l'éviterais comme la peste.

Wow, il y a beaucoup de choses ici dont je ne savais même pas qu'il s'agissait de limitations - après avoir travaillé sur la plate-forme pendant quelques années.

Mais juste pour ajouter d'autres choses ...

La raison pour laquelle vous n'avez pas de débogueur ligne par ligne est précisément parce qu'il s'agit d'une plate-forme multi-tenant. Du moins, c'est ce que dit SFDC - il semble qu'à l'ère de la programmation riche en threads, ce n'est pas vraiment une excuse, mais c'est apparemment la raison. Si vous devez écrire du code, vous avez "System.debug (String)" comme débogueur - je me souviens avoir eu des outils de débogage de serveur plus sophistiqués dans Java 1.2 il y a environ 12 ans.

Une autre chose que je déteste vraiment dans le système est le contrôle de version. Le framework Spring n'est pas utilisé pour ce à quoi Spring est généralement utilisé - il s'agit vraiment plus d'un outil de configuration dans SFDC que d'un contrôle de version. SFDC fournit un contrôle de version ZERO.

Vous pouvez vous retrouver coincé pendant des jours à faire quelque chose qui semble ridiculement facile, comme, par exemple, la planification d'un rapport SFDC à exporter vers un fichier CSV et à envoyer par courrier électronique à une liste de destinataires ... Eh bien, le moyen le plus simple de le faire est créer un objet personnalisé avec un champ personnalisé, avec une règle de workflow et un modèle de courrier électronique Visualforce ... puis pour le code, vous devez écrire un composant Visualforce qui transmet les données du rapport au modèle de courrier électronique Visualforce en tant que pièce jointe et vous écrivez APEX anonyme calendrier de code - mise à jour du champ de l'objet personnalisé ... Pour les développeurs SFDC, c'est presque une tâche quotidienne ... essayer de rassembler environ cinq technologies différentes pour faire des tâches qui semblent si simples ... Et cela peut causer des maux de tête de gestion et les tensions aussi - En règle générale, vous le découvrirez après avoir reçu une suggestion de faire quelque chose qui ne fonctionne past travailler dans la communauté des utilisateurs (comme quelqu'un l'a déjà dit), puis essayer beaucoup de choses qui, après les avoir développées, vous trouveriez qu'elles ne fonctionnent tout simplement pas pour une raison étrange - comme "vous ne pouvez pas planifier un Page VisualForce ", ou" vous ne pouvez pas appeler getContent à partir d'un contexte planifiable "ou pour une autre raison obscure.

Il y a tellement, beaucoup de petits pièges exaspérants sur la plate-forme SFDC, qu'une fois que vous savez POURQUOI ils sont là, cela a du sens ... mais ce sont encore de très mauvaises limitations qui vous empêchent de faire ce que vous devez faire. Voici quelques-uns des miens;

1. Vous ne pouvez pas obtenir des informations sur le propriétaire de l'enregistrement «prêtes à l'emploi» sur à peu près n'importe quel type d'enregistrement - vous devez écrire un déclencheur qui lie le propriétaire lors de la création de l'enregistrement à l'enregistrement que vous insérez. Pourquoi? Réponse courte car un propriétaire peut être soit une "personne", soit une "file d'attente", et les deux sont des entités radicalement différentes ... Cela a du sens, mais cela peut littéralement bouleverser un projet.

2. Modèle de sécurité exaspérant. Exemple: l'autorisation "Gérer les rapports publics" est très différente de "Créer et personnaliser des rapports" et cela vaut essentiellement pour tout sur la plate-forme ... en particulier les dossiers de tout type.

3. Comme mentionné, le support est pratiquement inexistant. Si vous êtes un individu extrêmement autonome, ou avez beaucoup de ressources SFDC, ou avez beaucoup de temps et / ou un gestionnaire très indulgent, ou êtes en charge d'un système SFDC qui fonctionne bien, vous êtes plutôt bien forme. Si vous n'êtes dans aucune de ces positions, vous pouvez vous retrouver dans de graves problèmes.

SFDC est une proposition commerciale très séduisante ... pas d'empreinte d'équipement, assez bonne sécurité, prix fixe, pas d'infrastructure, ET vous obtenez un CRM basé sur le Web avec un traitement par lots et programmé ... Mais comme l'ont dit les autres affiches, c'est vraiment une augmentation considérable de l'apprentissage du développement, et si vous optez pour le conseil, je pense que le prix le plus bas que j'ai vu était de 200 $ l'heure.

Salesforce a tendance à s'intégrer à d'autres choses des années après que certaines technologies soient devenues courantes - JSON et jquery viennent à l'esprit ... et si vous avez d'autres infrastructures communes avec lesquelles vous souhaitez faire une intégration, comme JIRA, attendez-vous à payer beaucoup plus, et ils peuvent être assez bogués.

Et comme l'une des autres affiches mentionnées, vous vous battez constamment contre les limites du gouverneur qui peuvent simplement vous rendre fou ... une pièce jointe ne peut PAS être> 5 Mo. Période. Et parfois <3 Mo (si encodé en base64). Dix appels HTTP dans une classe. Période. Il existe des dizaines de limites de gouverneur publiées, et beaucoup d'autres ne le sont pas que vous trouverez sans aucun doute et que vous voudrez simplement quitter votre bureau en hurlant.

J'aime vraiment, VRAIMENT la plate-forme, mais croyez-moi - cela peut être une maîtresse vraiment cruelle.

Mais pour être juste envers SFDC, je dirais ceci: le plus gros problème que je trouve avec la plate-forme n'est pas la plate-forme elle-même, mais les attentes gargantuesques de presque quiconque voit la plate-forme, mais ne s'y développe pas ... et ces personnes ont tendance à occuper des postes de grande autorité dans les organisations commerciales; marketing, ventes, gestion, etc. ils ne le font pas et ne le feront pas.

EDIT:
Juste pour ajouter aux commentaires de lomaxx sur le MVC; Dans la terminologie SFDC, ceci est étroitement lié à ce que l'on appelle le "état d'affichage" - et cela peut être vraiment bogué, en ce que ce qui est sur la page VF n'est pas ce qui est dans la classe contrôleur de la page. Donc, vous devez passer par des girations étranges pour synchroniser ce qui se trouve sur la page avec ce que le contrôleur va écrire à SF lorsque vous cliquez sur votre bouton "Enregistrer" (ou faites votre appel HTTP ou autre) ... mec, c'est ennuyeux .

Je pense que d'autres personnes ont couvert les inconvénients plus en profondeur, mais pour moi, cela ne semble pas utiliser le paradigme MVC ou prendre en charge beaucoup de réutilisation du code. Faire quoi que ce soit au-delà des simples applications est un exercice de frustration par rapport au développement d'une application en utilisant quelque chose comme ASP.Net MVC.

De plus, les outils, la couche de données et la frustration d'essayer de refactoriser le code ou de renommer des champs pendant le processus de développement n'aident pas.

Je pense qu'en tant que CMS, c'est plutôt cool, mais en tant que plate-forme pour les applications non CMS, cela n'a pas de sens pour moi.

Le modèle de sécurité est également très très restrictif ... mais ce n'est pas le pire. Vous ne pouvez pas actuellement affirmer si un utilisateur a la capacité d'effectuer une action particulière.

Vous pouvez vérifier quel est leur rôle, mais vous ne pouvez pas vérifier si ce rôle dispose des autorisations nécessaires pour effectuer l'action en cours.

Pire encore est la réponse du support technique pour "essayer l'action et s'il y a une exception, attraper"

Considérant que Force.com est une plate-forme «cloud», sa capacité à agir en tant que client d'un service externe défini par WSDL est assez décevante. Voir http://force201.wordpress.com/2010/05/20/when-generate-from-wsdl-fails-hand-coding-web-service-calls/ pour ce que vous pourriez devoir faire.

Pour tout ce qui précède, je suis curieux de savoir comment la publication de VMforce, permettant au programmeur Java d'écrire du code pour Force.com, modifie les inconvénients ci-dessus?

http://www.zdnet.com/blog/saas/vmforcecom-redefines-the-paas-landscape/1071

J'imagine qu'ils essaient de résoudre ces problèmes. Chez dreamforce, ils ont mentionné qu'ils essayaient de ramener les limites du gouverneur à seulement 4. Je ne sais pas quels sont les détails. Ils ont une API REST pour un accès anticipé et ont acheté heroku, un développement ruby ​​dans le cloud. Ils ont divisé la base de données, avec database.com afin que vous puissiez faire tout votre développement Web et vos appels db en utilisant database.com.

Je suppose qu'ils essaient de le rendre aussi agnostique que possible. Mais pour le moment, ce ne sont que des annonces et un accès anticipé, donc comme leurs déclarations Safe Harbor, n'achetez pas sur ce qu'ils disent, uniquement sur ce qu'ils ont actuellement.