Автор Тема: Top 10 SAP Coding Practices for SAP  (Прочитано 7923 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 762
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
Top 10 SAP Coding Practices for SAP
« : Август 16, 2011, 07:49:03 pm »
Цитировать
Коллега бойца Salai Sivaprakash из "Deloitte Inc", по этой ссылке: You are not allowed to view links. Register or Login типа спросил, какими признаками должен обладать код, чтобы считаться "правильным" или "красивым". Ну и боец долго думал и пришел к некотрму списку который оказался более сложным, так как речь шла только о "коде" и не включала в себя другие аспекты связанные с общими принципами построения и написания программ (анализ, проектирование, проверки и т.д.). Думаю это нужно разделить и такое деление должно помочь как
начинающим, так и может быть полезным для других разработчиков, которые занимаются анализом кода.

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

Таким образом, без каких-либо претензий к автору, лучшая 10-ка правил от Salai Sivaprakash (в произвольном порядке).
И по ходу с моими комментариями, а как же без своих 5 копеек :-)

Цитировать
Гибкий и расширяемый: Код должна быть гибким и расширяемым. Например, использование динамически формируемых элементов текста, с помощью настраиваемых таблиц (например, TVARV), а не жестко заданных литералов и т.д.
В общем я так понял суть в том, что если вы можете управлять логикой своей программы используя параметры заданные или с экрана пользователем или записанные в собственных настроечных таблицах, то это будет кошерно и правильно. Простой пример у вас один завод и вы во всех программах просто задаете его код в тексте программ. Далее если через некоторое время в системе появится еще один завод, то это приведет к полному анализу и переписыванию всех уже работающих программ. Если же вы изначально напишите программу с использованием настраиваемых таблиц, то все изменения будут заключаться только в добавлении еще одной записи в таблицу настройки, таким образом ваша программа становиться гибкой и расширяемой.
 
Цитировать
Современный: Код должен использовать только текущие технически правильные конструкции и не должен содержать морально устаревших операторов/инструкций, устаревших объявлений типов, устаревших функций (например, вызов диалога который отмечен как устаревший, пример POPUP_TO_CONFIRM_STEP - You are not allowed to view links. Register or Login) и т.д. Рекомендуется ипользовать SAP-рекомендуемые методы.
Ну что сказать, наверное данное правило очень полезное с точки зрения дальнейшей поддежки и миграций системы на новые версии. Хотя что касается функций именно вызова диалога, то я бы рекомендовал обращать внимание не на них, а на функции BAPI, которые отмечены как устаревшие, вот их то как раз использовать точно не рекомендуется, проблемы могут быть очень существенными. А функции диалогов, то фигня, их сам SAP хоть они и устаревшие использует и в хвост и в гриву.
 
Цитировать
Стандартные правила именования: Все программы и объекты должны быть названы в пространстве имен клиентов, Имена должны быть дифференцированными для местных и переносимых объекты. Программы, объекты и код компонентов (подпрограмм, методов, переменных и т.д.) должны соответствовать соглашениям об именах определенных в SAP IT-командах, а также должны следовать стандартной практике именования в SAP.
Ну пространство имен клиентов знают все это Z, хотя и тут уже не все красиво, так как функции идут уже с Z_ поля в расширении таблиц с ZZ, ну и т.д. Немного меньше тех кто знает про Y и кажется вообще практически нет тех кто знает про... ну короче кому надо найдут на форуме :-). В общем, первая часть правила и так вынуждает вас технически называть начальные имена объектов правильно, по другому вам не даст сделать система. Что же касается второй части, по формированию имен после символа, в пространстве имени клиента, то тут уже есть варианты. В общем виде ну скажем если это внутренние таблицы внутри программ, то на данный момент SAP рекомендует их начинать с признака LT_ типа Local Table, кстати раньше они начинались с I_ типа Internal table ну и т.д. Мое личное мнение не важно какую систему формирования имен вы используете (например общеизвестная вергерская система), главное чтобы вы ее использовали и ваши программы станут кошерными.
 
Цитировать
Простой, понятный и документированный: Код должен читаться, т.е. быть хорошо построенным для восприятия. Код должен быть узнаваем и построен с помощью общепринятых правил программирования. Код должне быть документирован, все изменения, история, и т.д. должны находится в коде. При этом следует проявлять осторожность и удалять любые избыточные и устаревшие комментарии.
Ну что тут сказать, что читаться это да... помниться как-то один мой друг программу на языке Паскаль отформатировал в виде 72 символа в строке, 60 строк на лист (бумагу на распечатке кода уж точно с экономил не мало). Компилятору то было все равно, а вот тому, кто этот код принимал, думаю человек порадовался креативности автора. А вообще, в системе есть кнопка структурной печати, так вот очень рекомендую ее использовать, хотя заметил такую особенность, в энхансментах структурное форматирование пока не работает. Что касается комментариев, то комментируйте ход алгоритма работы, а не действия операторов кода, то что оператор:
Код: You are not allowed to view links. Register or Login
WRITE: / 'Сумма строк:', l_count.
Выводит сумму строк таблицы комментировать точно не нужно, это и так ясно из самой команды, а поэтому такой комметарий попадет в разряд мусора/избыточного комментирования, хотя если вы индус и вам платят по строчно, то конечно вам будет виднее.

Цитировать
Оптимизация: Код должен быть написан и построен для оптимальной работы с учетом как текущей и будущей функциональности, нагрузки и объема обрабатываемых данных. Это значит, что нужно использовать наиболее
подходящие методы программирования, чтения базы данных, работы с файлами (чтение на запись / чтение всех и т.д.), работы с внутренними таблицами и т.д.
Оптимизация вещь очень многогранная, так что боец конечно круто написал про "будущее" оптимальное функционирование, может дождемся расшифровки, как он сам это представляет. А то, как это представляют находящиеся на данном форуме изложено тут: You are not allowed to view links. Register or Login

Цитировать
Многократное использование и модульность: Код должне быть разработаны с учетом лучшей модульность для простоты обслуживания, а также повторного использования частей кода (подпрограммы, классы, функции и т.д.)
С этим не спорю, хотя именно к коду это правило уже мало относится, это как по мне уже относится к "аспектам связанным с общими принципами построения и написания программ", чего товарищ Salai Sivaprakash, обещал в данном случае избегать, но видно увлекся и таки вставил данный пункт.
 
Цитировать
Эффективное использование памяти: Код должен быть построен для оптимального использования памяти - как например если вам не нужные все записи файла или таблицы, то читайте только то с чем будете работать. Так же избегайте чтения записей по строчно, а читайте сразу весь блок необходимый для работы.
Как по мне автор повторяется, так как это фактически правило относящееся к  оптимизации, я бы просто написал, на пару пунктов выше "Оптимизация производительности и использования памяти", но тогда похоже пунктов было бы 9, а это уже не красиво... как там любят говорит попадание в десятку, это круче чем в девятку. Мнения по оптимизации опять же изложены тут: You are not allowed to view links. Register or Login, так что повторяться не будем.
 
Цитировать
Надежность: Код должен быть надежным, иметь возможность отлова всех ошибок времени выполнения.
В языке C, тут обычно рассуждают про использование переменной без выделения под нее памяти, в ABAP актуальным будет отлов разных арифметических ошибок, ошибок конвертации и т.д. а то ж пользователи SAP-а такие пугливые как видят АВАР-динамическую ошибку, впадают в состояние не стояния. Поэтому хороший ABAP-программист заботиться о пользователях и не доводит свою программу до дампов, так пугающих клиента.

Цитировать
Проверенный: Код должен быть проверен, должны быть рассмотрены общие семантические ошибки, используя расширенные проверки программы и кодирование общих руководящих принципов (сокращения глобальных переменных, использование локальные переменные и параметров, обеспечивать поддержку Юникода и т.д.)
Если кратко, то проверяйте программу используя транзакция SLIN, поверьте вы увидите в ней много нового и интересного. Как минимум добивайтесь, чтобы при расширенной проверке небыло критических предупреждений. Все остальное уже по вкусу. Если честно, то запустите расширенную проверку для любой стандартной программы SAP и думаю ваша самооценка сильно возрастет, так как сам SAP, похоже, точнее его абаперы практически ничего сами не знают про SLIN. Ну что ж... тогда вы будете круче :-) Лично я, если есть время, то делаю расширенную проверку своих программ, а так как чаще его нет, то... но мне можно я ведь не абапер  ::)

Цитировать
Обновляемый: Код должен быть совместим для обновления, в том числе должна быть Unicode совместимость, избегайте устаревших функций и т.д.
Ну это тоже дело, такое.. в годах наверное 80-х, кто ж знал про этот юникод?! А сейчас, ну старые системы еще есть и много, а новые, мне сложно представить смысл установки ECC 6.0 в версии без юникода, хотя может на SAP денег хватило, а на сервера похоже нет. В общем виде это правило тоже повтор к правилу "Код должен быть современным", так как если он современный, то значит что он явно с поддержкой юникода, без использования  устаревших конструкций и т.д. Так что данное правило тоже не зачет! :-) и в итоге их осталось 8 или даже 7. если убрать правило про модульность.