Недостатки платформы Force.com [закрыто]

В настоящее время мы рассматриваем возможность использования платформы Force.com в качестве нашей платформы разработки, и продавцы и веб-сайт force.com полны причин, по которым это лучшая платформа в мире. Тем не менее, я ищу некоторые реальные недостатки использования такой платформы.

Вот 10, чтобы вы начали.

1. Apex - это проприетарный язык. Кроме плагина force.com Eclipse, здесь практически нет инструментов, таких как рефакторинг, анализ кода и т. Д.
2. Apex был смоделирован на Java 5, которая, как считается, отстает от других языков, и без инструментов (см. №1) может быть довольно громоздкой.
3. Развертывание по-прежнему выполняется вручную с большим количеством ошибок и ручных действий. Эта ситуация постепенно улучшается со временем, но вы будете разочарованы, если привыкли к автоматическому развертыванию.
4. Apex не хватает пакетов / пространств имен. Все ваши классы, интерфейсы и т.д. находятся в одной папке на сервере. Это делает код намного менее организованным, а имена классов / интерфейсов обязательно длинными, чтобы избежать конфликтов имен и обеспечить контекст. Это одна из моих самых больших жалоб, и я бы не стал свободно строить на force.com только по этой причине.
5. IDE force.com, также известная как плагин force.com eclipse, невероятно медленная. Сохранение любого файла, будь то файл класса, текстовый файл и т. Д., Обычно занимает не менее 5 секунд, а иногда и до 30 секунд в зависимости от того, сколько объектов, типов данных, файлов классов и т. Д. Находится в вашей организации. Сохранение также является блокирующим действием, требующим не только компиляции, но и полной синхронизации вашего локального проекта с сервером. На порядки медленнее, чем Java или .NET.
6. Сообщество онлайн-разработчиков не кажется очень здоровым. Я заметил, что многие сообщения на форуме остаются без ответа или нерешенными. Я думаю, это может иметь какое-то отношение к программному обеспечению для форумов, которое использует salesforce.com, что, кажется, довольно отстойно.
7. DSL доступа к данным в Apex оставляет желать лучшего. Он даже отдаленно не конкурирует с такими, как (N) Hibernate, JPA и т. Д.
8. Разработка приложения на Apex / VisualForce - это упражнение в проектировании ограничений регулятора. Легко, половина времени программиста тратится на попытки оптимизации, чтобы избежать многочисленных ограничений регулятора и других ошибок, таких как ограничения состояния представления visualforce. Можно было бы возразить, что если вы с самого начала напишете эффективный код, у вас не будет этой проблемы, что до некоторой степени верно. Однако во многих случаях у вас есть веские причины для выполнения более x запросов в сеансе или перебора более чем x записей и т. Д.
9. Цикл save-> compile-> run очень медленный, особенно. когда это связано с архивированием и загрузкой всего пакета статических ресурсов просто для того, чтобы сделать что-то вроде проверки незначительного изменения CSS или javascript.
10. В общем, боль молодой, только что развивающейся платформы без преимуществ открытого исходного кода. У вас нет возможности проверить и / или исправить ошибки в платформе. Они говорят разместить это на своей IdeaExchange. Да, удачи с этим.

Заявление об ограничении ответственности / раскрытие информации. У размещенной платформы, такой как force.com, есть множество преимуществ. Force.com регулярно улучшает платформу. Мне в нем много чего нравится. Я зарабатываю на force.com

Я вижу, что вы получили некоторые ответы, но я хотел бы повторить, сколько времени уходит на то, чтобы обойти различные ограничения регулятора на платформе. Как бы мне ни нравилась платформа на определенных уровнях, я бы очень, очень, категорически не рекомендовал ее как общую платформу для разработки приложений. Он отлично подходит как супер настраиваемое и расширяемое приложение CRM, если вы этого хотите. Хотя их маркетинг исключительно хорош в продвижении идеи Force.com как общей платформы разработки, он еще даже отдаленно не близок.

Эффективность наличия стабильной платформы и избежания серьезных проблем с производительностью и стабильностью легко теряется, пытаясь обойти ограничения, на которые ссылаются люди. У платформы так много ограничений, что это сводит с ума. Эти ограничения не являются высокими лимитами, которые вы достигнете, когда у вас будет много пользователей, вы достигнете их почти сразу.

Хотя обычно существуют методы их обхода, очень сложно придумать стратегии, позволяющие их избежать, пока вы также пытаетесь разработать бизнес-логику своего реального приложения.

Чтобы дать вам простое представление о том, насколько среда неприятна для разработчиков, возьмите «отсутствие среды отладки», о которой говорилось выше. Это еще хуже. В журналах отладки вы можете видеть только до 20 самых последних запросов к серверу. Итак, по мере разработки внутри приложения вам необходимо создать «Новый» отладочный запрос, выбрать свое имя, нажать «Сохранить», вернуться к своему приложению, обновить страницу, вернуться на вкладку отладки, попытаться найти запрос, который будет содержать ваш журнал отладки, нажмите "найти", чтобы найти текст, который вы ищете. Это как десять щелчков мышью, чтобы посмотреть результат отладки. Хотя это может показаться тривиальным, это просто пример того, как мало внимания и внимания уделяется опыту разработчика.

Все, что связано с платформой разработки, - это второстепенная мысль. Это примечательно тем, что есть, но по большей части это полная PITA. Если вы точно не знаете, что делаете (например, если вы сертифицированы и очень хорошо разбираетесь в Apex), это легко займет у вас в 10-20 раз больше времени, чем в другой среде. то, что кажется, было бы до смешного простым, если бы вы вообще могли добиться успеха.

Ограничения губернатора действительно настолько плохи. У вас есть комбинация различных ограничений (запросы к базе данных, возвращаемые строки, «операторы сценария», будущие вызовы, выноски и т. Д.), И вы должны точно знать , что вы делаете, чтобы их избежать. Например, если у вас есть вычисляемое сводное поле «формула» для объекта и у вас есть триггер для дочернего объекта, он выполнит триггеры родительского объекта и посчитает их с вашими пределами. Подобные вещи не очевидны, пока вы не пройдете через болезненный процесс попыток и неудач.

Вы попробуете одно, чтобы избежать одного предела, и достигнете другого в бесконечной игре «Ударьте предел». В процессе вам придется кардинально изменить архитектуру всего приложения и подхода, а также переписать весь тестовый код. Для развертывания в производственной среде у вас должно быть 75% покрытия тестового кода, что на самом деле очень хорошо, но в сочетании со всеми другими ограничениями это очень обременительно. Вы фактически достигнете ограничений регулятора, написав свой тестовый код, который не подойдет в обычных пользовательских сценариях, но помешает вам достичь покрытия.

Это не говоря уже о целом ряде других проблем. Упаковка - это не то, что вы ожидаете. Вы не можете упаковать свое приложение и доставить его пользователям без значительного вмешательства пользователя и настройки со стороны администратора организации. AppExchange - это полная шутка, и они даже начали взимать 5K, чтобы ваше приложение было в списке. Импорт с помощью загрузчика данных - отстой, особенно если у вас есть триггеры. Вы не можете экспортировать все свои данные за один шаг, включая ваши отношения, таким образом, чтобы их можно было легко повторно импортировать в другую организацию за один шаг (например, в группу разработчиков). Вы можете обновлять песочницу только один раз в месяц из рабочей среды, без исключений, и вы не можете включать свои данные в обновление по умолчанию, если вы не позвонили руководителю своей учетной записи, чтобы разблокировать эту функцию. Вы можете' • массовое удаление данных в пользовательских объектах. Вы не можете изменить имена своих пакетов. Некоторые вещи могут потребовать множествадней для завершения после того, как вы их запросили, например, резервное копирование данных перед развертыванием приложения, без отчета о ходе выполнения и отсутствия особого представления о том, когда именно был произведен экспорт. Учитывая, что существуют проблемы синхронности данных при наличии взаимосвязей между данными, существуют серьезные проблемы целостности данных, поскольку не существует такой вещи, как «транзакция», которая может экспортировать множество объектов за один шаг. Вероятно, существуют некоторые коммерческие инструменты для облегчения некоторых из них, но они недоступны для обычных разработчиков, у которых может не быть огромного бюджета.

Все остальное, что здесь говорили другие люди, правда. Иногда для сохранения файла может потребоваться от пяти секунд до минуты.

Я не хочу быть таким негативным, потому что платформа в некотором смысле очень крутая, и они пытаются делать то, что в многопользовательской среде не делает никто другой. Это очень инновационная среда и мощная на некоторых уровнях (на самом деле мне очень нравится VisualForce), но дайте ей еще год или два. Они сотрудничают с VMware, и, возможно, это даст разработчикам больше манежа, чем тюремной камеры.

Вот несколько вещей, которые я могу вам дать, потратив немало времени на разработку платформы за последние две недели или около того:

1. Нет RESTful API. У них есть API на основе мыла, который вы можете вызывать, но нет способа сделать настоящие успокаивающие вызовы

2. Нет простого способа взять их объекты SObject и преобразовать их в объекты JSON.

3. Страницы визуальной силы в порядке, пока вы не захотите их настроить, и тогда это целый мир боли.

4. Страницы Visual Force должны быть привязаны к объектам SObject, в противном случае нет возможности получить стандартные поля ввода, такие как datepicker или список выбора, для работы.

5. Плагин eclipse подходит, если вы хотите работать самостоятельно, но если вы хотите работать в большой команде с плагином eclipse, забудьте об этом. Он не обрабатывает синхронизацию с сервером и с сервером, он дает сбой и совершенно бесполезен.

6. ОТЛАДЧИКА НЕТ! Если вы хотите отлаживать, это буквально отлаживается с помощью операторов system.debug. Это, наверное, самая большая проблема, которую я нашел

7. Их модель «MVC» на самом деле не является MVC. Это намного ближе к веб-формам ASP.NET. Ваши представления тесно связаны не только с моделями, но и с контроллерами.

8. Хранить большое количество документов невозможно. Нам нужно хранить более 100 ГБ документов, и нам назвали смешную цифру. Мы решили реализовать хранилище документов в инфраструктуре amazons S3.

9. Несмотря на то, что язык основан на java, это не java. Вы не можете импортировать какие-либо внешние пакеты или библиотеки. Кроме того, доступные базовые библиотеки сильно ограничены, поэтому мы обнаружили, что реализуем кучу вещей извне, а затем выставляем эти биты как службы, которые вызываются force.com.

10. Вы можете вызывать внешние службы на основе SOAP или REST, но тело сообщения ограничено 100 КБ, поэтому это очень ограничивает то, что вы можете вызывать.

Честно говоря, хотя разработка на платформе force.com имеет потенциальные преимущества, я считаю, что вы не сможете использовать платформу force.com для настоящих приложений корпоративного уровня. В лучшем случае вы могли бы написать несколько простых приложений в грубом стиле, но как только вы перейдете к чему-то отдаленно сложному, я бы избегал этого, как чумы.

Вау - здесь есть много ограничений, о которых я даже не подозревал - после нескольких лет работы над платформой.

Но просто чтобы добавить еще кое-что ...

Причина, по которой у вас нет построчного отладчика, заключается именно в том, что это мультитенантная платформа. По крайней мере, это то, что говорит SFDC - похоже, что в наш век программирования с большим количеством потоков это не является оправданием, но, видимо, причина в этом. Если вам нужно писать код, у вас есть «System.debug (String)» в качестве отладчика - я помню, что около 12 лет назад в Java 1.2 были более сложные инструменты отладки сервера.

Еще одна вещь, которую я действительно ненавижу в системе, - это контроль версий. Фреймворк Spring не используется для того, для чего обычно используется Spring - на самом деле это скорее инструмент конфигурации в SFDC, чем контроль версий. SFDC обеспечивает нулевой контроль версий.

Вы можете застрять на несколько дней, делая что-то, что должно показаться до смешного простым, например, планирование отчета SFDC для экспорта в файл CSV и отправки электронной почты списку получателей ... Ну, самый простой способ сделать это - создать настраиваемый объект с настраиваемым полем, с правилом рабочего процесса и шаблоном электронной почты Visualforce ... а затем для кода вам нужно написать компонент Visualforce, который передает данные отчета в шаблон электронной почты Visualforce в виде вложения, а вы пишете анонимный APEX обновление поля расписания кода настраиваемого объекта ... Для разработчиков SFDC это почти ежедневная задача ... попытка собрать вместе около пяти различных технологий, чтобы выполнять задачи, которые кажутся такими простыми ... И это может вызвать головную боль управления и напряженность тоже - как правило, вы узнаете об этом после того, как получите предложение сделать что-то, что неt работать в сообществе пользователей (как кто-то уже сказал), а затем пробовать много вещей, которые после их разработки вы обнаружите, что они просто не работают по какой-то странной причине - например, «вы не можете запланировать VisualForce page », или« вы не можете вызвать getContent из планируемого контекста »или по какой-то другой загадочной причине.

На платформе SFDC так много, много сводящих с ума мелких ошибок, что как только вы узнаете, ПОЧЕМУ они там, это имеет смысл ... но они все еще очень плохие ограничения, которые мешают вам делать то, что вам нужно. Вот некоторые из моих;

1. Вы не можете получить информацию о владельце записи «из коробки» практически для любой записи - вам нужно написать триггер, который связывает владельца при создании записи с записью, которую вы вставляете. Зачем? Короткий ответ, потому что владельцем может быть либо «человек», либо «очередь», и это два совершенно разных объекта ... Имеет смысл, но может перевернуть проект буквально с ног на голову.

2. Безумная модель безопасности. Пример: разрешение «Управление общедоступными отчетами» сильно отличается от «Создавать и настраивать отчеты», и оно в основном относится ко всему на платформе ... особенно к папкам любого типа.

3. Как уже упоминалось, поддержки практически нет. Если вы чрезвычайно самодостаточный человек, или у вас много ресурсов SFDC, или у вас много времени и / или очень снисходительный менеджер, или вы отвечаете за систему SFDC, которая работает нормально, вы в довольно хорошем состоянии. форма. Если вы не занимаетесь ни одной из этих позиций, вы можете оказаться в большой беде.

SFDC - очень соблазнительное бизнес-предложение ... без оборудования, довольно хорошая безопасность, фиксированная цена, без инфраструктуры, И вы получаете веб-CRM с возможностью пакетной обработки и планируемой обработкой ... Но, как говорили другие плакаты, это действительно довольно активный рост обучения развитию, и если вы обратитесь к консультанту, я думаю, что самая низкая цена, которую я видел, составляла 200 долларов в час.

Salesforce имеет тенденцию интегрироваться с другими вещами спустя годы после того, как некоторые технологии стали обычным явлением - на ум приходят JSON и jquery ... и если у вас есть другие общие инфраструктуры, с которыми вы хотите выполнить интеграцию, например JIRA, ожидайте много дополнительных затрат, и они могут быть довольно глючными.

И, как упоминалось в одном из других плакатов, вы постоянно боретесь с ограничениями губернатора, которые могут просто свести вас с ума ... вложение НЕ может быть> 5 МБ. Период. А иногда <3 МБ (если кодируется base64). Десять вызовов HTTP в классе. Период. Существуют десятки опубликованных ограничений губернатора, и многие из них не являются такими, которые вы, несомненно, найдете и просто захотите с криком выбежать из офиса.

Мне очень, ДЕЙСТВИТЕЛЬНО нравится платформа, но поверьте мне - это может быть одна очень жестокая госпожа.

Но честно по отношению к SFDC, я бы сказал следующее: самая большая проблема, с которой я сталкиваюсь с платформой, - это не сама платформа, а гигантские ожидания, которые испытывает почти любой, кто видит платформу, но не разработал ее ... и эти люди, как правило, занимают руководящие должности в деловых организациях; маркетингу, продажам, менеджменту и т. д. Происходят огромные разрывы связи, и головы крутятся или угрожают откатиться каждый день - все потому, что есть эта отличная платформа со странными проблемами, и тысячи людей ежедневно пытаются понять, почему все должно работать, когда они просто этого не делают и не будут.

РЕДАКТИРОВАТЬ:
просто чтобы добавить к комментариям lomaxx о MVC; В терминологии SFDC это тесно связано с тем, что известно как «состояние просмотра» - и это может быть действительно ошибочным, поскольку то, что находится на странице VF, не является тем, что находится в классе контроллера для этой страницы. Итак, вам нужно совершить странные колебания, чтобы синхронизировать то, что на странице, с тем, что контроллер собирается записать в SF, когда вы нажимаете кнопку «сохранить» (или делаете HTTP-запрос или что-то еще) .... чувак, это раздражает .

Я думаю, что другие люди рассмотрели недостатки более подробно, но мне кажется, что он не использует парадигму 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/, чтобы узнать, что вам, возможно, придется делать.

Ко всему вышесказанному мне любопытно, как выпуск VMforce, позволяющий Java-программисту писать код для Force.com, меняет указанные выше недостатки?

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

Думаю, они пытаются решить эти проблемы. В dreamforce они упомянули, что мы пытаемся снизить лимит губернатора до 4. Я не уверен в деталях. У них есть REST API для раннего доступа, и они купили heroku, который представляет собой облачную разработку ruby. Они разделили базу данных с помощью database.com, чтобы вы могли выполнять всю свою веб-разработку и свои вызовы db с помощью database.com.

Думаю, они пытаются сделать это как можно более агностическим. Но прямо сейчас это все объявления и ранний доступ, так что, как их заявления Safe Harbor, не покупаются на том, что они говорят, только на том, что у них есть в настоящее время.