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

А что, АБАПерам мало платят? Или читать бумажную литературу западло?


Смех смехом, но из трех разных проектов ни про один не могу сказать, что там разработчики писали грамотный код. При этом, в прошлой жизни (до САПа) работал с двумя замечательными программистами, у которых учился и благодаря опыту совместной деятельности с которыми я теперь считаю возможным критиковать других.
Я не утверждаю, что безгрешен и все знаю. В САПе есть уникальные технологии, которые требуют дительного изучения. Но, извините, писать репорты можно и нужно по правилам, чтобы легче было модифицировать код. И для этого не обязательно использовать объектный подход.

Насчет привычек Абаперов обсирать чужой код. Скольких абаперов не видел - у всех одно и тоже. Даешь им посмотреть чью то программу, пару минут они с высоко задранными бровями смотрят, а затем стандартная фраза - "какой м... это написал? Неужели нельзя было - тра та та та тата...."
Это к подходу программировать (или кодировать - как вам там больше нравиться).
Шаманы блин

Я например, Фаулера Рефакторинг прочитал задолго до того как стал АБАПером, и еще кучу книг... по шаблонам проектирования такие как "банда четырех" и шаблоны проектирования в Java...

но увы не все задачи в АБАПе эффективно можно решать с помощью ООП и ООД ... особенно када короткие сроки и весь код уже написан...
просто все переписывать надо .... а времени нет ... поэтому приходиться иногда выкручиваться созавать классы хотя на 90% уверен что пользоваться будешь только сам...

и, кстати, я знаю несколько хороших АБАП программистов которые не читали ничего из выше описаного но очень успешно применяют ООП в своих разработках...

Надо использовать сильные стороны языка а не слабые! (С) Larry Wall

см. вакансии- требуется "Старший Консультант ABAP"

Я занимаюсь програмингом под САП с 2003, ну просто это выгодно пока, я просто люблю программировать.....

За это время встретил только несколько людей из своего круга, кто понимает, что такое рефакторинг кода, что такое паттерны проектирования, что такое процесс разработки программного продукта как такового со всеми атрибутами итерациями тестированием(нормальным тестированием)…. От сюда делаю вывод грамотных спецов в этой области еще мало, самоучек “недопрограмистов” навалом.
Любой программист в первую очередь не тупой робот, который перебивает, спеку какого то постановщика, за частую полного бездаря и дилетанта, а творец, программа не набивается под копирку она создается и проектируется в уме программиста и от его знаний и квалификаций будет во многом зависеть результат и качество готового продукта.

Я конечно не беру в пример простейшие шаблонные задачи на 3 часа которые практически реализуются встроенными средствами.

Всегда приятно, что твой код начинают юзать другие люди, которые на него случайно наткнулись и оценили, для меня это, например самое приятное.

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

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

Мне сейчас пофиг на модуль, мне достаточно глянуть на те транзакции и интерфейсы, чтобы понять, что нужно сделать и как сопрячь или извлечь данные, модуль знать вообще не обязательно(просто опыт = скорость не более), система не асемблер всю логику можно вытянуть из нее самой.

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

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

Так, что технарь(программист) это круто господа, мне нравится моя работа, когда говорят абапер имея ввиду, что то близкое к кодеру, для меня это как оскорбление.

ЗЫ
Сори за очепятки и прочее.

для тех кто тут все еще в танке OOP FTW

... после чего (уже втихушку) пишут "свой" код методом Ctrl-C, Ctrl-V...

прощаем за 9 "я"

Как консультант могу сказать - функциональность системы точно и исчерпывающе специфицирована только на языке ABAP4 Так что /h forever!

Увы, к сожалению, корявого кода написано очень и очень много

А по поводу Ctrl-C, Ctrl-V, так это только стандартные куски, одинаковые для всех программ можно передрать, написание которых заново - это изобретание велосипеда...
И здесь непрофильное базовое образование играет далеко не последнюю роль...

вот вот ... а реюзинг на что ???

О! Особенно прикольно, когда копипастеры стандартных транзакций после очередного пакета обнаруживают этот реюзинг в "своем" коде

Когда я работал на внутреннем проекте, у нас не существовало разделения абапер/консалт. Разграничение шло по модулям. Если человеку дают модуль - он должен с ним работать: знать и внедрять функционал, писать юзер-экзиты, отчеты, недостающие функции. Первое, что получал "студент" - книжку кречмера и саповские курсы по его модулю))

если не секрет, то сколько человек работало в системе и сколько было модулей / консультантов? работа заключалась в поддержке и развитии системы или ее первоначальном внедрении?

Да, я слышала идею от одного гениального ПМ-а - "всех консультанов следует научить абапить, тогда вообще не нужны отдельные абаперы".