Разработка программ в SAP экосистеме отличается от других областей программирования набором определенных особенностей, в ту или иную сторону меняющих повседневную рутину программиста. Одна из них - собственно место ABAP разработчика в мире SAP системы, его компетенции и ответственности, взаимоотношение с другими уровнями цепочки, доставляющей готовый продукт клиенту.

Дисклеймер: если вы работаете в SAP SE, SAP Labs или дочерей компании, это не про вас. Частично

У программиста, ведущего разработку на языке ABAP, существует набор обстоятельств, некоторые “но”, которые усложняют или, по крайней мере, делают более запутанной ежедневную деятельность. Я бы назвал эти “но” бременем ABAP разработчика, которое он вынужден нести, особенно если сравнивать с другими популярными сегодня направлениями разработки, как веб бэкенд или фронтенд, энтерпрайз разработка на популярных языках вроде Java, или мобильные приложения. Немного иначе дела обстоят в игрострое, в железе и встроенных системах, в хайлоаде, но я не буду рассматривать их в сравнении, потому что считаю их достаточно специфическими областями с точки зрения общих практик.

Чтобы рассказать подробнее, что я понимаю под бременем ABAP разработчика, я разделю это понятие на несколько частей.

Бремя ограничений

Одна из основных проблем в ABAP разработке с моей точки зрения - положение разработчика в самом процессе разработки и принятии решений.

С одной стороны, сап поставляет свои продукты готовыми и покрывающими 80%-90% бизнес-процессов предприятия. Таким образом, все архитектурные решения уже приняты за вас. Использование базы данных, способ коммуникации между модулями, организация самих модулей, выбор подходов и парадигм, тестирование, интерфейсы - все это уже реализовано разработчиками сап или их партнерами.

Далее в дело идут аналитики и консультанты, которые принимают решения за остальные 10%-20%. Редко, когда крупные архитектурные решения в сап разработках доходят то непосредственно программистов. Хорошо, когда в проекте есть архитектор, понимающий техническую специфику и имеющий значительный опыт. Но по факту в большинстве проектов этого нет.

С другой стороны, для реализации задач, сильно выходящих за рамки процессов, входящих в стандартную поставку сап, клиент чаще всего выбирает разработку вне сап инфраструктуры, или по крайней мере не на ABAP. И это, в целом, верное решение, потому что реализовать такие задачи с нуля в отрыве от десятилетиями накапливаемых практик и особенностей сап систем намного проще, чем иначе.

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

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

Это приводит к тому, что часто даже люди с пяти(+)летним опытом разработки не имеют понимания об архитектуре, абстракциях, паттернах, принципах разработки, SoC и модульности. Часто в проектах люди не хотят пытаться как-то качественно улучшить производимый продукт, и пишут манускрипты спагетти-кода, а на предложения смотрят с недоумением. Конечно, это касается далеко не всех, а многих лишь в некоторой степени, однако в сравнении с другими программистскими экосистемами это довольно сильно бросается в глаза.

Бремя ответственности

Предыдущая особенность порождает и другую. С одной стороны, у разработчика часто нет возможности напрямую общаться с клиентом, чтобы полноценно понять его нужды. Обычно это происходит через несколько посредников, как, например, консультанты, менеджеры и другие. Причем взаимодействие это обычно происходит в одностороннем порядке, то есть разработчику спускаются сверху некоторые требования к конечному продукту или процессу, при этом не объясняется почему и зачем это должно быть реализовано именно так.

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

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

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

После реализации разработка отправляется в лучшем случае в тест, а в худшем - прямиком в продуктив. А дальше начинается интересное.

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

• Не так работает, как думал клиент? - ваша программа работает неправильно, переделайте;
• Консультант не подумал о том, что сап так не работает, пообещал клиенту, а от замечаний разработчика отмахнулся? - ваша программа работает неправильно…
• Тестирование было номинальным или не было вовсе, и все сломалось? - ваша программа…
• Пока проект делали клиент решил, что ему нужно другое? - …

Конечно, в целом это проблема организации коммуникаций в проекте и рабочего процесса в целом. Да и не только для сапа она специфична, везде такое можно встретить. Но из-за специфики разработок в сап-мире, эта проблема иногда проявляется особенно ярко.

Бремя изоляции

Еще одной характерной чертой является изоляция мира разработки на ABAP от остального IT мира. Разработчиков ABAP редко можно увидеть на IT-конференциях, на кухне за чашкой кофе редко можно услышать обсуждение IT-статей, применение лучших практик программирования или классических паттернов может вызвать недоумение и даже неодобрение.

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

Во-вторых, сап сам очень сильно изолировал свою технологию от современных подходов к программированию. Многие архитектурные решения были приняты десятки лет назад, когда подходы, являющиеся де-факто стандартом сегодня, только зарождались, поэтому почти на каждый технический вопрос сап дает свой, часто уникальный ответ. Поэтому мы имеем собственную систему управления версиями (TMS), когда все используют Git; когда все использовали Ангуляр, у нас был вебдинпро, когда все пересели на Реакт и Вью, мы пересели на Фиори, когда все используют нормальные логгеры, мы используем бизнес лог, который не предназначен для технической информации. Когда везде есть опенсорс, в сапе чтобы накатить пакет с гитхаба, нужно неделю настраивать окружение. Вместо нормальной документации в открытом доступе у нас есть куцый хелп и платные курсы и книги с остальной информацией.

В-третьих, в ABAP обычно не переходят люди из других технологий (разве что из 1С). Я знаю разнообразные примеры, но для большинства ABAP является первым ЯП. Поэтому новичкам неоткуда получить представление о современном положении дел в программировании, а опытные коллеги имеют несколько устаревшие знания и навыки ввиду описанных выше причин. Это скорее вина сап, нежели самих разработчиков, потому что тяжело писать одновременно на каких-то других языках кроме ABAP, так как стек практически полностью отличается.

Бремя технологий

Последняя, но не менее значимая (а возможно и самая важная) проблема - закрытость технологий сап для остального мира. Сап имеет огромное количество внутренних технических решений, инструментов, фреймворков, подходов и смежных областей, на экспертное овладение которыми может потребоваться 5-10 лет. Однако все они крайне мало применимы вне сап, большинство из них никогда и нигде не пригодятся, если вы захотите заниматься разработкой в другой области.

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

В сап же иначе. По опыту работы с другими ЯП (как Python, Go, Elixir) могу сказать, что из сап пригождается разве что навык построения архитектуры, полученный на больших Z-проектах, и опыт использования БД, и то, семантики OpenSQL не хватает, для написания сложных запросов, приходится изучать конкретную БД и ее особенности. Конечно, большую роль играют софтскилы, а при работе в сап экосистеме вы, вероятно, очень хорошо разовьете различные навыки взаимодействия и работы в непростых условиях.

Конечно, хоть и с запозданием около трех-пяти лет, сап вводит в ABAP и тренды современной разработки. Уже сегодня мы видим, что графический интерфейс полноценно отделен от логики, база данных получила широкие возможности по моделированию, тестирование стало намного более простым, а сетевое взаимодействие - более легким и интуитивным. С версии 7.4 язык получил очень много свежего и полезного функционала, не без влияния других языков. Однако, это происходит все еще довольно медленно, и как можно видеть сегодня на примере новых продуктов компании, основные силы по внедрению новых технологий сосредоточены вне ABAP стека.

Все это выливается в то, что разработчик очень сильно замкнут в рамках технологий, с которыми он работает. Опыт извне сап очень ограниченно применим (хотя опыт программирования на других языках очень помог мне в понимании того, как строить намного более качественные структуры кода в ABAP). При этом и опыт работы в сап, который может обеспечить вам отличную позицию ABAP разработчика, будет мало оценен, если вы решите заняться разработкой в другом направлении.

По опыту это иногда даже отпугивает рекрутеров, кто-то, вероятно, думает, что это что-то вроде 1С, хотя это, конечно же, не так. ABAP, несмотря на коболовские корни, является богатым ООП-языком, позволяющим полноценно реализовывать самые сложные задачи в области автоматизации бизнес-процессов.

Итог и перспектива

На сегодняшний день ситуация с ABAP все еще довольно удручающая. Большим плюсом можно назвать появление Fiori, что привнесло в сап экосистему много современных технологий и подходов. Также сегодня активно развивается облачное направление (RESTful ABAP), в котором планируются совершенно новые концепции по управлению данными в программе и более современные подходы по работе с кодом, но пока попробовать эту технологию довольно сложно, да и реальная область применения еще не ясна.

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