Pull to refresh

Comments 29

Из статьи складывается впечтатление, что Apex это язык для обучения программированию. Но ведь это же не так?
Apex — это язык для разработки логики на платформе CRM Salesforce. Но экосистема обучения Apex выстроена так, что язык легко осваивать.
Apex это песочница аля 1c язык.
Его учить не надо если вы не планируете программировать на Salesforce!

Пусть откроют исходники Apexa\ может тогда кто-то захочет писать на нем!
Именно так, спасибо за дополнение. Apex ограничен этой платформой.
Salesforce — это ведущая CRM в мире. В России рынок пока небольшой, но работы всё-таки больше чем специалистов. Есть возможность запрыгнуть в первый вагон и стать одним из первых разработчиков на растущем российском рынке.
Не советую брать этот apex. Пробовал. Платформа макаронная. SQL код вперемешку с основным кодом это жесть хаха.
А работу найдёте только на salesforce. Язык этот только для одной платформы. Вы не получите норм вакансию на java зная лишь этот apex.

Зачем выбирать ограниченную платформу в ущерб себе?
Да, мне тоже смесь Java и SQL синтаксисов режет глаза. Логичнее тогда уж, как было в FoxPro. Там хоть синтаксис единый для всего: для запросов данных, для их отработки и для интерфейсов.
Там еще и IDE номальную нужно прикручивать через одно место. И код по дефолту не через VCS перекидывается, а с помощью пакетов с энва на энв. Очень «удобно» мерджить и отслеживать ревизии
Не совсем так. Точнее, совсем не так. Код выгружается в source control и прекрасно мерджится. Вот с метаданными в SObjects все не так радужно.

А так, из плюсов Apex
1. Прекрасный тулинг (SFDX, плагин для VSCode, IlluminatedCloud 2 для Idea)
2. Великолепная OO база данных
3. Кодировать можно хоть на iPad

Из минусов
1. Apex был форкнут с Java 6. 15 лет прогресса в Java-мире прошли мимо. Язык кажется outdated. Конечно, не на столько outdated как Go, но все-таки
2. Невозможность нормальной работы с бинарными данными. Даже zip расзиппить — это либо в браузере через JS, либо через Base64 представление
Ни к чему не призываю. Освещаю свой опыт.
Моё мнение: Salesforce растет семимильными шагами, параллельно растет потребность в разработчиках. Поэтому без хлеба не останетесь :)
обычная java не просто так является одним из самых популярных. Переходите к нам )
просто порог входа для apex разработчиков ниже…
В статье не описан такой важный момент, что форсовый разработчик скорее всего работает не только с бэком, но и с фронтом.

Не понял комментаторов выше, которые транслируют очевидную мысль, мол, apex годится только для разработки внутри salesforce. Об этом ведь и написано в заключении. Другое дело, что внутри их экосистемы есть несколько векторов развития, поэтому при наличии скиллов работу можно найти даже в России, а уж при наличии английского — и за ее пределами.
Спасибо за комментарий.
В статье делал упор именно на бэкенд разработке для Salesforce — т.е. именно на Apex.

Вы правы насчет фронтенда: понятие Salesforce-разработчик шире, чем Apex-разработчик. Salesforce разработка включает в себя не только Apex, но и HTML, CSS, JavaScript на фронтенде.
А как, кстати в Apex workflow делается? В смысле если надо что-то считать на сервере, потом спросить пользователя, потом что-то в зависимости от его ответа опять считать на сервере, опять спросить пользователя и т.д. То есть существует разделение на клиент и сервер? Где клиентские действия (типа открытия формы или сообщения), можно выполнять только на клиенте (или другими словами с сервера обращаться к клиенту).
Не на самом Apexе, а средствами платформы. Тут есть 3 варианта:
1. Родной Flow. По сути дела визуальный workflow
2. Vlocity OmniScript, часть предпоследнего приобретения Salesforce. Этот компонент еще и формбилдер предоставляет
3. Ну и при желании на смеси Apex и Visualforce/LWC можно свое workflow написать, если очень хочется
А можно пример кода где-нибудь увидеть? Что-то вроде, при нажатии кнопки, проверить если инвойсе сумма больше 100, спросить у пользователя поручителя, проверить что у поручителя лимит не превышен, спросить у пользователя подтверждение, перевести инвойс в следующий статус.
Мне кажется APEX это тупиковый путь — он хорош для выполнения каких-либо простых задач, и совершенно не подходит для выполнения сложных задач.
Как пример — надо было мне сделать «lead routing», правила «роутинга» были описаны в кастомных записях, так чтобы обычные пользователи могли их менять. В APEX коде эти записи транслировались в некие правила и меппиги на основе которых и происходило назначение lead owner. Изначально правила были простые и все работало, потом правила начали усложняться, их объем вырос в несколько раз, добавился нечеткий поиск и т.д.
Как итог пару раз в день я вижу: Apex CPU time limit exceeded.

С какими проблемами я столкнулся:
1. Трансляция «человеческих» записей во внутренние правила для роутинга отъедают порядочную часть «Maximum CPU time». Изменяются эти правила довольно редко — так что логично было хранить их где то заранее подготовленными, но в APEX не возможно создать что-то, что переживет контекст транзакции. Время жизни статических структур — это время жизни транзакции. В итоге я воспользовался Cache.Org, который в свою очередь тоже ни чего не гарантирует.
2. Лимиты на ресурсы действуют на всю транзакцию целиком. В SalesForce были установленны 3rd-party пакеты которые так же потребляют ограниченный «CPU time».
developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm

Сейчас я рассматриваю перенос ресурсоемких задач из APEX в микросервисы (API лимит позволяет). Heroku connect предоствляет БД с двусторонней синхронизацией с SalesFoce, но я пока не понял сколько это стоит.

Apex – это на 90% Java. Вы с легкостью сможете понимать Java-код после разработки на Apex

Это или какая-то очень старая версия, может 1.4 или максимальна упрощенная 1.5. Да тут нет даже дженериков!

Покрытие кода юнит-тестами на 75% – обязательное условие для переноса этого кода на PROD-среду. Поэтому вы с самого начала учитесь создавать тест-классы.

За годы работы я повидал много кода и чаще всего я вижу:
1. Юнит тесты нацеленные просто на покрытие кода, без каких либо Assert
2. Или подобные конструкции

static void testCoverage() { 

        Integer c = 0;
        c++;
        c++;
        ... // тут может быть несколько тысяч строк 
        c++;

    } 

Кстати еще один вопрос, а как в SalesForce Apex с прикладными абстракциями вроде Ledger'ов? Они в языке, в виде стандартизированных библиотек или вообще на разработчике? И как с визуальным программированием этих и других прикладных абстракций? Конструкторами или кодом в основном все делается (имеется в виду на практике, а не в презенташках)?

Бросилось в глаза:


`
public Integer decreaseVolume(Integer amount) {


    volume -= amount; 

    if (volume < 0) { 

        volume = 0; 

    }   

    return volume; 

}     `

А здесь не будет переполнения типа и вместо нуля — максимум? Зачем так рисковать? Почему не


`public Integer decreaseVolume(Integer amount) {


    if (volume - amount <= 0) { 
        volume = 0; 
    }   else {
volume -= amount; 

}


    return volume; 

}     `

Если язык не просто так похож на Java — то не будет. При изначально неотрицательном volume после вычитания может получиться минимум -2147483647, который всё ещё влезает в Integer.

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

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


Кстати, ваш вариант (volume - amount <= 0) тоже мог бы быть подвержен переполнению, правильная проверка выглядит как volume <= amount.

Да, вы абсолютно правы про вариант. А типы данных тут не совсем явно видны, отсюда и у меня ошибка.
Раз уж про Salesforce зашла речь, может вы в курсе — почему SF генерирует кривые эксель-файлы? (по умолчанию у них тип файла «веб-страница (*.htm; *.html), хотя расширение по факту XLS.
Не каждый просмотрщик может такую бяку открыть (телефон ругается), и приходится просто на компьютере пересохранять файл в нормальной типизации.
Если вы про Salesforce Reports, то ни разу не сталкивался с ошибкой формата. Всегда стабильно выгружается CSV или XLS
Причина данной проблемы — комплексная. Виноваты и Salesforce, и Microsoft.
Фактически SF экспортирует HTM-файл, но добавляет ему расширение XLS.
(Результат расследования тут: skalolaskovy.ru/salesforce/565-file-format-dont-match-with-extension-xls )
Интересно, можно ли это исправить?

три года спустя интересно как чувствует себя рынок SF и спецы, вкатившиеся в этот приклад. SAP уже вовсю импортозамещают чем только могут, но объёмы ещё огромные. года на три минимум хватит

Sign up to leave a comment.