… а лучше оно потому, что если его придерживаться, то порядок увеличивается, а беспорядок уменьшается.

С практической точки зрения порядок можно увеличивать до момента, когда он уже начинает вредить “поворотливости”.

 

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

Для себя я выделил шесть основных уровней для борьбы с энтропией исходного кода. Переходить к следующему следует только после освоения уроков предыдущих уровней.

Большим вопросом является кому и сколько уровней надо освоить – это каждый коллектив решает для себя.

1. Основные объекты

Как минимум практически всегда вырабатываются внутренние подходы к именованию главных объектов разработки (программы, транзакции и так далее) – иначе уж совсем бардак наступает.

Ну например:

• для транзакций ZAANNN, где AA – модуль, а NN – порядковый номер
• для программ ZAA_FFFF_TTTT или ZAUUNNNN, где буковки что-то да значат

 

2. Вспомогательные объекты

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

• пакеты
• таблицы и элементы словаря
• группы функций, классы
• инклюды общего пользования

 

3. Структура и дизайн

Требуют или согласования, или ориентировки на “образцы” такие технические ньюансы:

• Деление программ на инклюды
• Подходы к формированию селективных экранов
• Подходы к выдаче информации
• Принципы обработки промежуточных результатов

 

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

Например, для отчётов следует всегда выделять следующие блоки:

• выборка
• обработка
• вывод
• действия

Кроме прочего, можно выделить соглашение по именованию подпрограмм, например:

[действие]_[объект]

Здесь действие – это некоторый глагол (get, select, update, check, delete и так далее), а объект – это сущность, над которой выполняются действия.

4. Технические решения

Использование параллельных технических решений для продуктивных версий приветствоваться не должно.

В качестве примера можно взять такую распространённую фишку как “Экспорт в Эксель”. Так даже и здесь всегда есть простор, где разгуляться фантазии.

Во-первых, использование технического движка. Например:

• ZWWW
• abap2xlsx
• собственный движок
• прямое OLE, или обёртка вокруг него

Во-вторых, место вызова также может быть разным:

• Кнопка экспорта на селективном экране
• Кнопка экспорта в выводной форме

В-третьих, место хранения шаблона также может отличаться:

• SMW0
• Папка на компьютере пользователя
• Файл на сервере

 

5. Кодировка – внешняя красота

Вот посмотришь на чужие программы – столько разного насмотришься…

• отсутствие внятной системы отступов;
• бессмысленные короткие названия на длинных участках кода;
• смешение локальных и глобальных переменных;
• куски непонятно зачем закомментированного текста;
• и даже простое отсутствие комментариев может сбивать с толку…
• длинные смысловые блоки

 

Каждый программист пишет в меру собственного разумения, да и сам я совсем не безгрешен – однако пытаюсь работать над собой.

Можно обратиться к этой статье в качестве одного из образцов Nomen est Omen — ABAP Naming Conventions.

6. Кодировка – духовное наполнение

Перечень работ, которые в фоновом режиме надо выполнять:

• Рефакторинг – простая переработка кода; код следует делать понятным, разбивать на логические блоки, сложные блоки преобразовывать к простым  и так далее…
• Оптимизация – оптимизация скорости выполнения; это может понадобиться уже в продуктивном режиме
• Улучшение – если пользователь мотивированно расскажет, то почему бы не выполнить его пожелания. Сбор данных обратной связи от пользователя в процессе продуктивной работы никогда лишним не бывает.
• Вычленение – если сначала некоторые внутрипроектные решения могут быть объединены в одно, затем они могут быть вынесены на межпроектный уровень.
• Комментирование – бывает, что комментарии пишутся не в процессе написания кода. Если программа отлежится пару недель, то становится виднее, где ещё требуются комментарии.
• Документирование – любая продуктивная разработка должна иметь документацию.
• Зачистка — кроме рабочего кода в системе следует выявлять продукты экспериментов, тестовые программы и подобный мусор. Всё это надо периодически вычищать и управлять $TMP пакетом.
• Дополнительное внимание при зачистке надо уделять неактивным программам. Бывает, что у разработчика накапливается целый шлейф неактивных объектов.

Смотрите для примера статьи из серии Ревизия кода.