Всем привет.

Возникла ситуация когда код постоянно коменнтируется - переносится в продуктив - раскоментируется - переносится в продуктив и т.д.
Нужно каким-то правильным способом "включать/выключать" этот кусок кода.

Думаю в сторону Switch Framework, но незнаю подводных камней.
Буду признателен за любую подсказку, мат. часть и т.п.

Спасибо.

А что за кусок кода? Например с поверками в экзитах/бади практикуем такое - создаем настроечную табличку, консультант через нее управляет вкл/выкл проверок.

P.S. Switch Framework тоже интересен, не видел чтоб его прикручивали к своим разработкам, для таких целей.

Правильно разбейте код по программным единицам (и инклюдам)
Как пример:
Инклюд MV45AFZZ

Инклюд zz_order_check_one

Это метод класса, реализующего BADI.
Вариант таблицы из одного поля и одной строки с меткой "вкл\выкл" - не по душе.

ЗЫ: сижу. думаю. а если BADI позволяет(просто не помню) многократную реализацию то, решение очевидно.
ЗЫЫ: просто помимо куска кода, который надо "вкл\выкл" еще понаписано много чего.

Не понимаю как это поможет для "вкл\выкл" кусок кода без комментирования вызова перформы\инклюда и т.п.?

2 siga2: Switch framework скорее всего Вам не подойдет, в случае если надо чтобы работало по принципу "включил-выключил-включил-выключил". Эта технология нацелена больше на реализацию аддонов и индастрил солюшенов. Т.е. поставляется какая-то функциональность в выключенном состоянии, а потом - включается. Ранее, в системе была возможность отключения, но в более новых патч-левелах сап исключил эту возможность. Мотивировка на курсах приводилась следующая: свитч может включать в себя энханс таблицы или домена. Вы его сначала включили, затем в новые поля дописали значения (или в старые поля но с новыми , расширенными, значениями домена). Затем Вы хотите выключить свитч. И тут встает вопрос: а что теперь делать с набитыми значениями?
"Вкл/выкл" без комментария можно сделать через enchancement framework. Я думаю стоит попробовать добиться этого через явные enhancement point\section. Хотя мне кажется, что и там не получится одним движением переключить сразу для большого числа расширений (хотя стоит посмотреть на составные расширения. Но мне кажется, что они больше для структурирования, чем для общего управления).
По идее можно реализовать Вашу хотелку через BAdI. Но с точки зрения программирования, пихать в 1 интерфейс разнородную функциональность - не комильфо.

1.Если весь код разбит по отдельным задачам, то комментирование нужно только один раз - при одновременном появлении нескольких подпрограмм, инклюды и вызовы к которым нужно прописать в главной программе.
2.Для предотвращения проблем с вызовом подпрограмм при переносе служит дополнение IF FOUND к PERFORM.

Апну тему.
Планируется массовое обновление z-программ, разработок более 500. Рассматривается вариант с switch framework.
Взлетит или нет? Какие есть особенности? Какие недостатки?

При чем здесь switch framework?
Нужно просто правильно составить очередь переносов...

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

И как вам поможет switch framework, если вы сразу не разобьете проекты?
А если вы их разобьете на независимые объекты сразу, то зачем нужен switch framework, который нужен для того, чтобы активировать только нужные фрагменты кода/объекты репозитария?
Ведь вам нужно, чтобы все изменения перенеслись?

У нас подобный контроль реализован разделением прав разработчиков по пакетам разработок и разделением запросов по проектам (транзакция spro_admin).
В случае, если объекты разработки пересекались, то об этом становилось известно Администратору разработок, который разруливал ситуацию.
При переносе запросов с одинаковыми объектами, которые относятся к разным проектам, между запросами при деблокировании создавалась зависимость предшественник(предыдущий запрос с данным объектом в другом проекте)-текущий запрос.
При попытке переноса текущего запроса в продуктив система выдает сообщение, что есть предшествующий запрос в другом проекте.

Тем, что можно постепенно наполнять продуктив выключенными участками кода, а не нести за 1 раз несколько тысяч запросов.

При разработке новой функциональности данный подход будет полезен. При работе со схожими функциями - нет.

Данная технология в случае нескольких проектов имеет больше недостатков, чем преимуществ:
1. Не будет произведен реинжиниринг и унификация кода и объектов словаря данных для разных проектов
2. Увеличится время разработки и тестирования в среде разработки - придется все тестировать только по отдельности, причем в строго определенном порядке.


А кто просит нести их за один раз?
Неужели нельзя организовать последовательный перенос разработок по мере тестирования?