Кто как оценивает работу абапера?

Вот несколько мнений о работе человека (я ни с кем не знаком наверно, так что ничего личного)





Главный критерий скорее всего такой - сделанная разработка работает правильно и оптимально быстро. Все довольны.
Проходит какое-то время и необходимо что-то изменить/добавить в разработку. Разработчика по тем или иным причинам нет. Задание дается другому человеку, которому приходиться разбираться в чужих кодах(ох и неблагодарное занятие). Что происходит дальше?
1. Новый разработчик легко и непринужденно разбирается в чужом коде и добавляет все изменения
2. Разбирается с большим скрипом, попутно делая кучу других ошибок
3. Разобратся не может вообще и приходит к выводу, что проще написать заново, чем разбиратся
4. .....

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

Ну так кто как оценивает работу АБАПера

ну можно в рублях
можно в евро
можно в долларах

разные по разному оценивают...

А еще работу абапера можно оценить в Джоулях.
Соответственно, оценив работу, выполняемую абапером в единицу времени, можно прикинуть МОЩНОСТЬ абапера...

А если поделить Работу на Силу - получим длину рабочего пути.

лучше оценивать Производительность:

Число строк кода (операторов) на ABAP / секунды.

Ой, а что такое АВАР - секунды?

не

ABAP - секунды

а число строк кода разделить на секунды!

Ну тогда нужно вводить еще и КПД

Работу абапера надо оценивать в деньгах, причём обильно... А то если оценивать не обильно, абапер возьмёт, да и уволится...

В конечном итоге работу абапера оценивает админ по производительности его (абапера) шедевров

А у нас все не так...
Работает, скажем, внешний АВАРер (типа Outsourcing). Сделал программу, написал документацию, оформил 5 рабочих дней (40 часов) плодотворной работы.
Далее "контроль качества" - сидит некто и смотрит на следующее:
1) грамотность - это, грубо говоря, соответствие логики работы идеологии и принципам построения системы. Поясню - чтобы не было COMMIT'ов в замещениях, чтобы были блокировки в диалогах ведения (самописных, естественно), чтобы SELECT'ы были заточены оптимально и т.п.
Причем проверка эта делается не одним человеком (один всегда может что-то недосмотреть) - первый раз при переносе, второй - при закрытии периода (под оплату).
2) производительность - уровень АВАР-разработчика известен, число выставленных часов известно. Далее "гуру" решает, сколько бы он провозился с такой задачей. Делаем скидку на уровень разработчика, его занятость, трудолюбие и исполнительность.
Если все ОК, то склоняем голову в почтительном "АХ", иначе - предлагаем снизить стоимость работ. Потому, что он в инете постоянно лазит по порносайтам; слишком много времени тратит на "углубленное изучение проблемы", вместо того, чтобы спросить совета у других членов команды и т.п. Обычно такие споры заканчиваются в кабинетах начальства - наше дело аргументировать свою точку зрения.

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

Для своих разработчиков - песня такая же, только денег им платят меньше

В общем, вот так оно у нас и происходит, собственно. Может, неправильно, но надежно

Да, забыл сказать - конечно, админы помогают вылавливать пропущенные ляпы по производительности. Тут либо их (админов) успокаивают, что так и должно быть, либо напрягаем извилины и рекомендуем исправить так-то и так-то прогу.
Ну, и последнее - "опасные" вещи (типа System Modification, RWIN'а, работы с памятью и т.п.) взяты под строгий контроль тех двух типов, которые всем заправляют. Такие "фишки" делают только они после тщательного исследования и вердикта о невозможности сделать по-другому.

А ты где работаешь?

Спасибо, примерно это и хотел услышать. А то народ тут начал веселиться в начале , строки делим на секунды и т.д. Тоже в принципе неплохо, но все же не в тему

Именно такой подход и позволил в конечном итоге видеть очень прияственную картину в SAP EarlyWatch Alert :
"Expensive SQL Statements
The analysis of your system's SQL statement cache found no significant problems."

РУСАЛ - внутренний проект.
До этого - консалтинг, Юникон, 5.5 лет (БРАЗ, ВСК, СНГ, ТНК, СУАЛ, ну и по мелочи...). Я - АВАР-программист.