salesforce force.com

salesforce - Desventajas de la plataforma Force.com



(9)

Actualmente estamos analizando el uso de la plataforma Force.com como nuestra plataforma de desarrollo y los vendedores y el sitio web force.com están llenos de razones por las cuales es la mejor plataforma del mundo. Lo que estoy buscando, sin embargo, son algunas desventajas reales para usar una plataforma de este tipo.

Aquí hay 10 para que comiences.

  1. Apex es un lenguaje propietario. Además del plugin Eclipse de force.com, hay poca o ninguna herramienta disponible, como refactorización, análisis de código, etc.
  2. Apex se modeló en Java 5, que se considera que está rezagado respecto de otros lenguajes, y sin herramientas (ver n. ° 1), puede ser bastante engorroso.
  3. La implementación sigue siendo bastante manual con muchos errores y pasos manuales. Esta situación está mejorando lentamente con el tiempo, pero te decepcionará si estás acostumbrado a tener implementaciones automatizadas.
  4. Apex carece de paquetes / espacios de nombres. Todas sus clases, interfaces, etc. viven en una carpeta en el servidor. Esto hace que el código esté mucho menos organizado y los nombres de clase / interfaz sean necesariamente largos para evitar conflictos de nombres y proporcionar contexto. Esta es una de mis mayores quejas, y no elegiría libremente construir en force.com solo por esta razón.
  5. El "Force.com IDE", también conocido como Force.com eclipse plugin, es increíblemente lento. Guardar un archivo, ya sea un archivo de clase, archivo de texto, etc., generalmente toma al menos 5 segundos y, a veces hasta 30 segundos, dependiendo de cuántos objetos, tipos de datos, archivos de clase, etc. se encuentren en su organización. Guardar también es una acción de bloqueo, que requiere no solo compilación, sino una sincronización completa de su proyecto local con el servidor. Órdenes de magnitud más lenta que Java o .NET.
  6. La comunidad de desarrolladores en línea no parece muy saludable. Me he dado cuenta de que muchas publicaciones del foro quedan sin respuesta o no resueltas. Creo que esto puede tener algo que ver con el software del foro que usa salesforce.com, que parece ser muy malo.
  7. El acceso a datos DSL en Apex deja mucho que desear. Ni siquiera es remotamente competitivo con jugadores como (N) Hibernate, JPA, etc.
  8. Desarrollar una aplicación en Apex / VisualForce es un ejercicio de ingeniería de límites del gobernador. Se gasta fácilmente la mitad del tiempo del programador tratando de optimizar para evitar los numerosos límites del gobernador y otros obstáculos, como los límites del estado de la vista visual. Podría argumentarse que si escribe un código eficiente para empezar, no tendrá este problema, que es cierto hasta cierto punto. Sin embargo, hay muchas veces que tiene razones válidas para realizar más de x consultas en una sesión o recorrer más de x registros, etc.
  9. El ciclo de guardar-> compilar-> ejecutar es extremadamente lento, esp. cuando se trata de comprimir y cargar todo el paquete de recursos estáticos solo para hacer algo como probar un CSS menor o un cambio de javascript.
  10. En general, el dolor de una plataforma joven, incipiente sin los beneficios de ser de código abierto. No tiene forma de validar y / o corregir errores en la plataforma. Dicen que lo publiquen en su IdeaExchange. Si buena suerte con eso.

Descargos de responsabilidad / Divulgaciones: hay muchos beneficios para una plataforma alojada como force.com. Force.com regularmente mejora la plataforma. Hay muchas cosas al respecto que me gustan. Gano dinero construyendo en force.com

Aquí hay algunas cosas que puedo darle después de pasar un poco de tiempo desarrollando en la plataforma en la última quincena más o menos:

  1. No hay API RESTful. Tienen una API basada en jabón a la que puedes llamar, pero no hay forma de hacer verdaderas llamadas relajadas

  2. No hay una forma simple de tomar sus SObjects y convertirlos a objetos JSON.

  3. Las páginas de fuerza visual están bien hasta que quieras personalizarlas y luego todo un mundo de dolor.

  4. Las páginas de fuerza visual deben estar vinculadas a SObjects; de lo contrario, no hay forma de que funcionen los campos de entrada estándar como datepicker o select list.

  5. El plugin eclipse está bien si quieres trabajar solo, pero si quieres trabajar en un equipo grande con el plugin Eclipse, olvídalo. No maneja la sincronización hacia y desde el servidor, se cuelga y no es realmente útil en absoluto.

  6. ¡NO HAY DEBUGGER! Si desea depurar, se depurará literalmente mediante sentencias de system.debug. Este es probablemente el mayor problema que he encontrado

  7. Su modelo "MVC" no es realmente MVC. Está mucho más cerca de los formularios web de ASP.NET. Sus puntos de vista están estrechamente relacionados no solo con los modelos sino también con los controladores.

  8. Almacenar una gran cantidad de documentos no es factible. Necesitamos almacenar más de 100gb de documentos y se nos cita una figura ridícula. Hemos decidido implementar nuestro almacenamiento de documentos en la infraestructura amazons S3

  9. Aunque el lenguaje está basado en Java, no es Java. No puede importar ningún paquete externo o biblioteca. Además, las bibliotecas base que están disponibles son muy limitadas, así que nos hemos encontrado implementando un montón de cosas externamente y luego exponiendo esos bits como servicios que son llamados por force.com

  10. Puede llamar a servicios externos basados ​​en SOAP o REST, pero el cuerpo del mensaje está limitado a 100kb, por lo que es muy restrictivo en lo que puede llamar.

Honestamente, si bien hay beneficios potenciales para desarrollar en algo así como la plataforma force.com, para mí, no se podía usar la plataforma force.com para aplicaciones de nivel empresarial verdaderas. En el mejor de los casos, podrías escribir algunas aplicaciones básicas de estilo crud, pero una vez que te muevas en algo remotamente complicado, lo evitaría como la peste.

Creo que otras personas han cubierto las desventajas con más profundidad, pero para mí, no parece utilizar el paradigma MVC o apoyar mucho en el camino de la reutilización del código en absoluto. Hacer algo más allá de las aplicaciones simples es un ejercicio de frustración en comparación con el desarrollo de una aplicación que utiliza algo como ASP.Net MVC.

Además, las herramientas, la capa de datos y la frustración de intentar refactorizar el código o cambiar el nombre de los campos durante el proceso de desarrollo no ayudan.

Creo que como CMS es genial, pero como plataforma para aplicaciones que no son CMS, no tiene sentido para mí.

El modelo de seguridad también es muy restrictivo ... pero esta no es la peor parte. Actualmente no puede afirmar si un usuario tiene la capacidad de realizar una acción en particular.

Puede verificar cuál es su rol, pero no puede verificar si ese rol tiene permisos para realizar la acción actual.

Aún peor es la respuesta del soporte técnico para "probar la acción y si hay una excepción, atraparla"

Supongo que están tratando de resolver estos problemas. En dreamforce mencionaron que estamos tratando de reducir los límites del gobernador a solo 4. No estoy seguro de cuáles son los detalles. Tienen una API REST para acceso temprano, y compraron heroku, que es un desarrollo ruby ​​en la nube. Se dividen en la base de datos, con database.com para que pueda hacer todo su desarrollo web y sus llamadas a bases de datos usando database.com.

Supongo que están tratando de hacerlo lo más agnóstico posible. Pero ahora mismo, todos estos son anuncios y acceso anticipado, por lo que sus declaraciones de puerto seguro no compran según lo que dicen, solo en lo que tienen actualmente.

Vaya, hay muchas cosas aquí que ni siquiera sabía que eran limitaciones, después de trabajar en la plataforma durante algunos años.

Pero solo para agregar algunas otras cosas ...

La razón por la que no tiene un depurador línea por línea es precisamente porque es una plataforma de múltiples usuarios. Al menos eso es lo que SFDC dice, parece que en esta era de programación rica en subprocesos, eso no es una gran excusa, pero aparentemente esa es la razón. Si tiene que escribir código, tiene "System.debug (String)" como depurador. Recuerdo tener herramientas de depuración de servidor más sofisticadas en Java 1.2 hace 12 años.

Otra cosa que realmente odio sobre el sistema es el control de versiones. El marco Spring no se usa para lo que se suele usar Spring: en realidad se trata más de una herramienta de configuración en SFDC que de control de versiones. SFDC proporciona el control de versión ZERO.

Puede encontrarse atrapado durante días haciendo algo que debería parecer tan ridículamente fácil, como, por ejemplo, programar un informe SFDC para exportarlo a un archivo CSV y enviarlo por correo electrónico a una lista de destinatarios ... Bueno, la forma más fácil de hacerlo es cree un objeto personalizado con un campo personalizado, con una regla de flujo de trabajo y una plantilla de correo electrónico de Visualforce ... y luego para el código necesita escribir un componente de Visualforce que transmita los datos del informe a la plantilla de correo electrónico de Visualforce como un archivo adjunto y escriba APEX anónimo programación de código actualización de campo del objeto personalizado ... Para los desarrolladores de SFDC, esto es casi una tarea diaria ... intentar juntar cinco tecnologías diferentes para hacer tareas que parecen tan simples ... Y esto puede causar dolores de cabeza en la administración y tensiones también: por lo general, descubriría esto luego de recibir una sugerencia para hacer algo que no funciona en la comunidad de usuarios (como alguien dijo) y luego probar muchas cosas que, después de desarrollarlas, encontrar que simplemente no funcionan para algunos o razón de dd-ball - como "no se puede programar una página de VisualForce", o "no se puede llamar a getContent desde un contexto programable" o algún otro motivo arcano.

Hay muchos, muchos enloquecedores gotcha en la plataforma de SFDC, que una vez que sabes POR QUÉ están ahí, tiene sentido ... pero siguen siendo muy malas limitaciones que te impiden hacer lo que tienes que hacer. Aquí hay algo mío;

  1. No se puede obtener la información del propietario del registro "de fábrica" ​​prácticamente en ningún tipo de registro; debe escribir un activador que vincule al propietario al crear el registro con el que está insertando. ¿Por qué? Respuesta corta porque un propietario puede ser una "persona" o una "cola", y las dos son entidades drásticamente diferentes ... Tiene sentido, pero puede convertir un proyecto literalmente al revés.

  2. Modelo de seguridad enloquecedor Ejemplo: el permiso "Administrar informes públicos" es muy diferente de "Crear y personalizar informes" y básicamente va para todo en la plataforma ... especialmente carpetas de cualquier tipo.

  3. Como se mencionó, el soporte es básicamente inexistente. Si usted es una persona extremadamente autosuficiente, o tiene muchos recursos de SFDC, o tiene mucho tiempo y / o es un administrador que lo perdona, o está a cargo de un sistema de SFDC que funciona bien, usted está bastante bien. forma. Si no estás en ninguna de estas posiciones, puedes encontrarte en un problema profundo.

SFDC es una propuesta de negocios muy seductora ... sin huella de equipo, muy buena seguridad, precio fijo, sin infraestructura, Y obtiene CRM basado en web con procesamiento programable y procesable ... Pero como dijeron los otros carteles, es realmente un gran aumento en el aprendizaje de desarrollo, y si vas con la consultoría, creo que el precio más bajo que he visto fue de $ 200 / hora.

Salesforce tiende a integrarse con otras cosas años después de que algunas tecnologías se vuelvan un lugar común. JSON y Jquery vienen a la mente ... y si tiene otras infraestructuras comunes con las que desea hacer una integración, como JIRA, espere pagar mucho más. y pueden ser bastante problemáticos.

Y como uno de los otros carteles mencionados, usted está constantemente luchando contra los límites del gobernador que pueden volverlo loco ... un archivo adjunto NO puede ser> 5 MB. Período. Y a veces <3MB (si está codificado en base64). Diez llamadas de HTTP en una clase. Período. Hay docenas de límites de gobernador publicados, y muchos que no son los que sin duda encontrará y solo quiere salir corriendo de su oficina gritando.

Realmente, REALMENTE me gusta la plataforma, pero créanme, puede ser una amante realmente cruel.

Pero, para ser justos con SFDC, diría lo siguiente: el mayor problema que encuentro con la plataforma no es la plataforma en sí misma, sino las enormes expectativas que casi cualquier persona que vea la plataforma, pero que no haya desarrollado, tiene ... y esas personas tienden a ocupar puestos de gran autoridad en las organizaciones empresariales; marketing, ventas, administración, etc. Se producen enormes desconexiones y se corre la cabeza, o se amenaza con rodar todos los días, todo porque hay una gran plataforma con extraños errores y miles de personas que luchan diariamente para entender por qué las cosas deberían funcionar cuando simplemente no lo hacen y no lo harán.

EDITAR:
Solo para agregar a los comentarios de lomaxx sobre MVC; En la terminología de SFDC, esto está estrechamente relacionado con lo que se conoce como el "estado de vista", y puede ser muy defectuoso, ya que lo que está en la página de VF no es lo que está en la clase de controlador para la página. Entonces, tienes que hacer giros extraños para sincronizar lo que está en la página con lo que el controlador va a escribir en SF al hacer clic en el botón "guardar" (o hacer una llamada HTTP o lo que sea) .... hombre, es molesto .

Veo que ha obtenido algunas respuestas, pero me gustaría reiterar cuánto tiempo se desperdicia para sortear los diversos límites del gobernador en la plataforma. Por mucho que me guste la plataforma en ciertos niveles, lo recomendaría enfáticamente, altamente, en contra de que sea una plataforma de desarrollo de aplicaciones general. Es genial como una aplicación CRM súper configurable y extensible si eso es lo que quieres. Si bien su comercialización es excepcional al impulsar la idea de Force.com como una plataforma de desarrollo general, aún no está remotamente cerca.

La eficiencia de tener una plataforma estable y evitar grandes problemas de rendimiento y estabilidad se desperdicia fácilmente al intentar codificar los límites a los que se refieren las personas. Hay tantos límites en la plataforma que se vuelve completamente enloquecedor. Estos límites no son límites de alta gama que alcanzará una vez que tenga muchos usuarios, los alcanzará casi de inmediato.

Si bien usualmente existen técnicas para evitarlos, es muy difícil encontrar estrategias para evitarlos mientras también intenta desarrollar la lógica comercial de su aplicación real.

Para darle una idea simple de cómo el desarrollador no es amigable con el medio ambiente, tome la "falta de entorno de depuración" mencionada anteriormente. Es peor que eso. Solo puede ver hasta 20 de las solicitudes más recientes al servidor en los registros de depuración. Entonces, mientras desarrolla dentro de la aplicación, debe crear una "nueva" solicitud de depuración, seleccione su nombre, presione "Guardar", vuelva a su aplicación, actualice la página, haga clic en la pestaña de depuración, intente encontrar la solicitud que alojará su registro de depuración, pulse "buscar" para buscar el texto que está buscando. Es como diez clics para ver un resultado de depuración. Si bien puede parecer trivial, es solo un ejemplo de cuán poco cuidado y consideración se le ha dado a la experiencia del desarrollador.

Todo sobre la plataforma de desarrollo es una idea de último momento injertada. Es notable por lo que es, pero un PITA total en su mayor parte. Si no sabe exactamente lo que está haciendo (ya que está certificado y tiene una comprensión muy íntima de Apex), le llevará fácilmente de 10 a 20 veces la cantidad de tiempo que lo haría en otro entorno. algo que parece que sería ridículamente simple, incluso si puede tener éxito.

Los límites del gobernador son realmente tan malos. Tiene una combinación de varios límites (consultas de bases de datos, filas devueltas, "declaraciones de script", futuras llamadas, textos destacados, etc.) y debe saber exactamente qué está haciendo para evitar esto. Por ejemplo, si tiene un campo de "fórmula" acumulativo calculado en un objeto y tiene un desencadenante en un objeto secundario, ejecutará los desencadenadores del objeto principal y los contará contra sus límites. Cosas como esa no son obvias hasta que haya pasado por el doloroso proceso de intentar y fracasar.

Intentarás una cosa para evitar un límite, y golpear a otro en un juego interminable de "golpear un límite". En el proceso, tendrá que volver a diseñar drásticamente toda su aplicación y enfoque, así como volver a escribir todo su código de prueba. Debe tener una cobertura de código de prueba del 75% para implementar en producción, lo que en realidad es algo muy bueno, pero combinado con todos los otros límites, es muy engorroso. De hecho, alcanzará los límites del gobernador al escribir su código de prueba que no aparecería en escenarios de usuario normales, pero eso le impedirá alcanzar la cobertura.

Eso sin mencionar toda una serie de otros problemas. El embalaje no es lo que esperas. No puede empaquetar su aplicación y entregarla a los usuarios sin una intervención y configuración significativa por parte del administrador de la organización. El AppExchange es una broma total, e incluso han comenzado a cargar 5K solo para obtener su aplicación en la lista. La importación con el cargador de datos es una mierda, especialmente si tiene algún disparador. No puede exportar todos sus datos en un solo paso que incluya sus relaciones de tal manera que pueda volver a importarlos fácilmente a otra organización en un solo paso (por ejemplo, una organización dev). Solo puede actualizar un sandbox una vez al mes desde la producción, sin excepciones, y no puede incluir sus datos en una actualización de manera predeterminada a menos que haya llamado a su ejecutivo de cuenta para desbloquear esa función. No puede eliminar datos en masa en objetos personalizados. No puedes cambiar los nombres de tus paquetes. Ciertas cosas pueden tardar varios días en completarse después de que las haya solicitado, como una copia de seguridad de datos antes de implementar una aplicación, sin informe de progreso en el camino y sin mucha información sobre cuándo exactamente se produjo la exportación. Dado que existen problemas de sincronicidad de datos si existen relaciones entre los datos, existen serios problemas de integridad de datos en el sentido de que no existe una "transacción" que pueda exportar numerosos objetos en un solo paso. Probablemente haya algunas herramientas comerciales para facilitar algo de esto, pero estos no están al alcance de los desarrolladores normales que pueden no tener un gran presupuesto.

Todo lo demás que las otras personas dijeron aquí es verdad. En ocasiones puede tomar entre cinco segundos y un minuto guardar un archivo.

No pretendo ser tan negativo porque la plataforma es genial en algunos aspectos y están tratando de hacer las cosas en un entorno de múltiples inquilinos que nadie más está haciendo. Es un entorno muy innovador y potente en algunos niveles (en realidad me gusta mucho VisualForce), pero dale uno o dos años más. Se están asociando con VMware, tal vez eso les dará a los desarrolladores un espacio de juego un poco más que una cárcel en la que trabajar.