Ну тогда зачем нужны АБАПеру-программисту (которых большинство) консультанты? Зачем им кто-то пишет спецификации?
Настроили стандарт, выгоняем консультантов и зовем программистов, они вникают в бизнес-процесс, ставят задачу себе и реализуют.

По теме - специалисты везде разные, кто-то "программист", кто "кодировщик". В логистике я как абапер знаю кучу таблиц и процессов, но под HR не писал - кодировщик.
Разработки еще тестить надо... причем это иногда могут делать даже стажеры. Поэтому вопрос Абапер программист или нет считаю просто некорректным. А специалист по С++ кодер или программист?

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

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

Как вообще можно назвать программистом человека, который знание таблиц считает главным критерием оценки своей работы?

Позволю себе не согласиться с мнением большинства так называемых "программистов". У меня вообще вызывает шок то, как АБАПеры пишут программы (ибо программированием это назвать тяжело). Откуда они пришли в САП? Какое у них базовое образование? Нежели все ассемблером занимались?

Мне довольно часто приходится вносить изменения в чужой код. Без слез не взглянешь. Люди лабают(!!именно ЛАБАЮТ!!) код, не имея представления о базовых принципах программирования. О проектировании вообще никто не слышал, аббревиатура RUP вызывает недоумение. О процессе разработки в среде САП можно защитить не одну диссертацию. Она просто создана для коллективной разработки. Если этой мощью пользоваться должным образом, то можно реализовать главные мечты объектно-ориентированной технологии - повторное использование и отсутствие дублирующегося кода. На практике одни и те же SELECTы кочуют из программы в программу, а то и в одной и той же встречаются несколько раз.
А как вам понравится код, где данные выбираются и по каким-то правилам преобразовываются, причем эти правила размазаны на несколько INCLUDEов с кучей IFов. Потом вызывается экран с ALV-grid, чтобы все это показать, но вместо этого в PBO модуле опять идут какие-то циклы, селекты, IFы, и только в самом конце вызывается SET_TABLE_FOR_FIRST_DISPLAY. Да, этим можно гордиться, типа "Я сам все с нуля, консультант - лох, даже ТЗ не дал". Но как это поддерживать??? Базовые принципы никто не отменял будь то объектно-ориентированный или стандартный (устаревший?) функциональный подход. Всем читать Фаулера "Рефакторинг"

Так что, извините. Я пока не встречал грамотных программистов на АБАП - одни только лабальщики.

PS. Сам я АБАПер, при этом являюсь консультантом. У САПеров есть две должности: программист и бизнес-аналитик, но когда речь идет о проекте у клиента, то все они становятся консультантами.

Valerius - согласен на все 100.

Функциональный подход никогда не устареет......
Программы в 8 select-ов с разницей в 1 букву действительно утомляют
А вот про ООП - уже появляются вот такие творения:
http://www.melikyan.com/dalshe/articles/oop.html

Не смотря на все достоинства ABAP-а и самой среды - считаю ее не удобной......


Лучше ссылку (только не на озоны и иже с ними). Гугл хоть и рулит - но жалко времени на поиски......


А сколько Вы их видели ?

IMHO, вышесказаное относится не только к коду, который пишется в рамках проекта внедрения - если "анализировать код по запаху", то стандартый зачастую просто смердит невыносимо Естественно, дописанные поверх "заплатки" воздух тоже не озонируют...

Так Вы сам - тоже лабальщик или это фраза из серии "все в ..., один я в белом"?

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

Да абапер просто производная от названия языка. Обычный язык - осваивается в 2 дня. Так что абапер, ИМХО, типа слесарь, умеющий работать ключом 10 на 12.
Правильнее, (ИМХО, опять же) абапер это - программист умеющий, кроме всего прочего, писать ещё и на этом несчастном языке.

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

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

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

Вроде выяснили, что Программист = Кодировщик + Постановщик.
(думаю, что ни одно из 3 определений обидным не является)
[/quote]
Молочник - это молоковоз или спецалист по молоку? - обсудим тему? [/quote]
Что такое "молочница" могу тебе объяснить, но только не здесь...

Вроде выяснили, что Программист = Кодировщик + Постановщик.
(думаю, что ни одно из 3 определений обидным не является)

Что такое "молочница" могу тебе объяснить, но только не здесь...

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



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

[ужасы про разработку на САПе поскипаны]



А вообще, насколько бы компетентными не были программисты в этой системе, главными все равно останутся консультанты - от них все зависит.