Практически любое соглашение об именовании лучше его отсутствия

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

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

 

В любом проекте формируется группа 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 пакетом.
  • Дополнительное внимание при зачистке надо уделять неактивным программам. Бывает, что у разработчика накапливается целый шлейф неактивных объектов.

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

Добавить комментарий

Ваш адрес email не будет опубликован.