Префиксы-суффиксы. Какой инструмент лучше использовать чтобы избавиться от префиксов?

[mazzy]

начало обсуждения здесь
Префиксы-суффиксы. Как лучше? Стоит ли избавляться от них?

итог обсуждения подвел Владимир Максимов

теперь следующий вопрос.

предположим, принято решение "избавиться от префиксов - идентификаторов разработчиков" (оставить только название модуля, как в стандартной аксапте. при этом не потерять уже существущие данные).

какой инструмент лучше использовать, чтобы избавиться от префиксов при уже существующих данных?

=================
я провел эксперимент, взял отдельно стоящий проект (не ссылающийся на другие объекты) и провел переименование объектов (с сохранением id, чтобы сохранились данные).

в некоторых свойствах, ссылки переименовались правильно (например, переименование типа корректно обрабатывается)
в некоторых свойствах, ссылки не переименовались (например, переименование menuItem приводит к тому, что кое-где они правильно переименовываются, а кое-где остаются прежними. Например, в свойстве таблицы FormRef)


Выявление подобных ошибок заняло достаточно большое время.
А самое главное - выявление подобных ошибок переименования оказалось делом нетривиальным. Глобальная компиляция проходит, а ошибка проявляется в runtime. Спасали рекомендации Best Practice при компиляции. Но и они не выявили всех случаев.

Ну и замена в разных местах кода - тоже достаточно муторное занятие.

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

Во-первых, были глюки с сохранением идентификаторов. Не везде она их сохранила.
Во-вторых (и это главное) в результате переименования появились объекты с дублирующимися названиями (одинаковые таблицы, одинаковые поля, одинаковые формы).

Дублирующиеся поля категорически отказывались импортироваться в разные объекты. В результате, импорт проекта также превратился в достаточно муторную головоломку.

============
Вопрос:
какой инструмент и какую методику вы бы использовали, если бы перед вами стояла задача "избавиться от префиксов - идентификаторов разработчиков"?

Заранее спасибо.

[Poleax]

Нанять человечка пусть сидит долбит ручками

[mazzy]

Цитата:

Сообщение от Poleax

Нанять человечка пусть сидит долбит ручками

и такой вариант рассматривается.
вопросы - как именно "долбит"? и как проверить, что он "надолбил" без ошибок?

[Андре]

Цитата:

и как проверить, что он "надолбил" без ошибок?

Разработать сценарии тестирования. Для периодического выполнения тестов по разработанному сценарию тестирования можно нанять еще одного человека

[mazzy]

Цитата:

Сообщение от Андре

Разработать сценарии тестирования.

Ок. Каков критерий полноты этих сценариев? Как убедиться, что в результате не появилось ошибок, если даже Рекомендации компилятора не дают гарантии?

===========
Так, ребяты, не надо меня убеждать, что это работа и за работу надо платить. Надо. Будет оплачена.

Просто очень не хочется заставлять людей выполнять тупую работу "от забора и до обеда".
Однако если нет другого способа, то будем заставлять. И будем оплачивать.

===========
Я спрашиваю, каков наиболее оптимальный способ?
(Один из возможных вариантов - не убирать префиксы, пусть проги мучаются с ними)

[Андре]

Цитата:

Ок. Каков критерий полноты этих сценариев?

Покрытие всех возможных вариантов использования функционала на n%. Значение n вы выбираете сами в зависимости от ваших возможностей по организации тестирования и лояльности ваших клиентов (насколько они готовы терпеть возможные проблемы при ошибках).

Цитата:

Как убедиться, что в результате не появилось ошибок

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

mazzy, ты ищешь простой и легкий путь, но его здесь не будет. Можно лишь растянуть эти затраты во времени используя рефакторинг.

[Владимир Максимов]

Цитата:

Сообщение от mazzy

Во-вторых (и это главное) в результате переименования появились объекты с дублирующимися названиями (одинаковые таблицы, одинаковые поля, одинаковые формы).

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

1. Если удаление префикса не приводит к дублированию имен, то удаляем префикс
2. Если удаление префикса приводит к дублированию имен, то
2.1. Переносим префикс в конец имени делая из него суффикс
2.2. Сообщаем пользователю о возникшей коллизии, чтобы он пересмотре логику использования данного объекта

============================

Вообще-то, насколько я понимаю, в самом общем виде задача ставится так:

как переименовать объект, чтобы все ссылки на него также переименовались.

Как мне кажется, в общем случае, полностью автоматическими средствами этого не сделать. Далеко не все ссылки на объект можно изменить автоматически. Например, в коде метода. Т.е., в общем случае, часть ссылок будет переименована автоматически, но останется некая часть, которую придется выискивать и переименовывать вручную. Вопрос только в пропорциях.

Лично я сделал бы следующее:

1) Перекрестные ссылки. Где используется объект.
2) Поиск по тексту внутри методов на случай, например, прямых SQL-запросов к серверу или обращение через _args.caller()
3) Дополнительный Job для поиска по свойствам, которые не учитываются в перекрестных ссылках и не могут быть найдены по тексту метода или средствами стандартного поиска (не знаю, FormRef, например, стандартный поиск найдет?)

Фиксирую все найденные места использования. Переименовываю объект и повторяю цикл для нового имени. Далее сравниваю полученные списки использования и вручную корректирую те места, где "автомат" не справился.

==========================

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

[mazzy]

Цитата:

Сообщение от Владимир Максимов

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

можно и так

Цитата:

Сообщение от Владимир Максимов

Вообще-то, насколько я понимаю, в самом общем виде задача ставится так:

как переименовать объект, чтобы все ссылки на него также переименовались.

ага.

Цитата:

Сообщение от Владимир Максимов

Как мне кажется, в общем случае, полностью автоматическими средствами этого не сделать. Далеко не все ссылки на объект можно изменить автоматически. Например, в коде метода.

про код - понятно.
у меня конечно были надежды на синтаксическое переименование... но что-то мне совсем не понравилось как оно работает. может чего не понимаю.

Цитата:

Сообщение от Владимир Максимов

Т.е., в общем случае, часть ссылок будет переименована автоматически, но останется некая часть, которую придется выискивать и переименовывать вручную. Вопрос только в пропорциях.

Ага.

Цитата:

Сообщение от Владимир Максимов

Лично я сделал бы следующее:

1) Перекрестные ссылки. Где используется объект.
2) Поиск по тексту внутри методов на случай, например, прямых SQL-запросов к серверу или обращение через _args.caller()
3) Дополнительный Job для поиска по свойствам, которые не учитываются в перекрестных ссылках и не могут быть найдены по тексту метода или средствами стандартного поиска (не знаю, FormRef, например, стандартный поиск найдет?)

Перекрестные ссылки - найдут.
Поиск - только расширенный по свойствам, а не по методам.

Цитата:

Сообщение от Владимир Максимов

Фиксирую все найденные места использования.

Вручную?!

Цитата:

Сообщение от Владимир Максимов

Переименовываю объект и повторяю цикл для нового имени. Далее...

Т.е. рекомендуешь итерационный подход? когда имена меняются один за другим.
В принципе я склоняюсь к этому же.

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

Цитата:

Сообщение от Владимир Максимов

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

Э-э-э... Не одна Аксапта, не одна. Она даже не центр вселенной.
Она всего лишь одна из баз. Связанная с кучей сервисов.

[Владимир Максимов]

Цитата:

Сообщение от Владимир Максимов

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

Цитата:

Сообщение от mazzy

Э-э-э... Не одна Аксапта, не одна. Она даже не центр вселенной.
Она всего лишь одна из баз. Связанная с кучей сервисов.

Хм... Но ведь если ты будешь переименовывать объекты Axapta, то другие сервисы все-равно должны измениться. Под эти новые имена. И какая разница, останутся ли в Axapta старые имена или нет?

[sukhanchik]

Вообще-то я больше склоняюсь к мысли Владимира Максимова:

Цитата:

Сообщение от Владимир Максимов

1) Перекрестные ссылки. Где используется объект.
2) Поиск по тексту внутри методов на случай, например, прямых SQL-запросов к серверу или обращение через _args.caller()
3) Дополнительный Job для поиска по свойствам, которые не учитываются в перекрестных ссылках и не могут быть найдены по тексту метода или средствами стандартного поиска (не знаю, FormRef, например, стандартный поиск найдет?)

Единственное - не очень понятный п.3 из его алгоритма. FormRef ссылается на пункт меню, а в отличие от тех же классов - названия пунктов меню хранятся текстом - т.е. надо будет ручками (кодом) менять название во всех местах. А перекрестные ссылки, начиная с 4.0 вроде как уже дают полную информацию, включая пункты меню.
В п.2 конечно неплохо добавить еще использование [Sys]Dict* классов и вариантов тупого прописывания названия объектов в коде обычным текстом.

Еще есть момент. Была у меня таблица DEV_SuperTable. Хочу ее переименовать в (к примеру) LedgerSuperTable. Очевидно, что я должен переименовать попутно:
1. Форму DEV_SuperTable (если есть). Необязательно, но по-хорошему - я должен переименовать все датасорсы (помимо исправления ссылок), чтобы на таблицу LedgerSuperTable не указывал датасорс DEV_SuperTable. Это потянет изменение в коде ссылок на этот датасорс.
2. Пункт меню DEV_SuperTable (если есть, причем - если я его не переименую - у меня могут быть проблемы при переходе к основной таблице). В самом пункте меню еще нужно изменить ссылку на форму
3. Теперь надо не забыть про сложные составные имена. Типа DEV_SuperPuperTable и DEV_SuperNotPuperTable. А также про DEV_LedgerSuperTable. Надо решить - как их нужно будет переименовывать

Надеюсь - названия таблиц/полей не используются в хранимых процедурах, ОЛАП-кубах/отчетах, Reporting Services и прочих сторонних системах (кстати - ужас - на что толкает нас МС - отказ от использования перекрестных ссылок - т.к. внешние использования таблиц/полей, а теперь еще и Query в Visual Studio - естественно не будут учтены перекрестными ссылками)

Поэтому - я наверное склоняюсь к правилу 20/80. Т.е. переименовать 80% объектов за 20% усилий. Просто пойти по перекрестным ссылкам. Если объект можно переименовать (проверяется возможность создания объекта в АОТ с таким именем) - то согласно перекрестным ссылкам переименовать объект и ссылки на него. Без заморочек с датасорсами и сложными названиями.
Дальше вывести - список - чего осталось. Оценить масштабы бедствия. Что-то действительно руками (возможно) быстрее сделать.
Масштабы бедствия не должны быть большими - иначе бы функциональность перекрестных ссылок была бы не показательна.
Также вряд ли будет много пересечений со штатным функционалом. Обычно пересечения могут быть на наиболее используемых таблицах типа InventTable, Может даже InventTrans. Но вряд ли напишут "свой" класс с названием типа AddressEngineKernelInternational_RU.

Еще можно датасорсы переименовать. Но это уже следует делать вторым проходом - когда уже переименованы сами объекты. Тут нужно не забыть "прошерстить" все контролы на форме и все обращения типа DEV_SuperTable_ds, DEV_SuperTable_q, DEV_SuperTable_qr

[mazzy]

Цитата:

Сообщение от sukhanchik

Еще есть момент. Была у меня таблица DEV_SuperTable. Хочу ее переименовать в (к примеру) LedgerSuperTable. Очевидно, что я должен переименовать попутно:
1. Форму DEV_SuperTable (если есть). ....
2. Пункт меню DEV_SuperTable ...
3. Теперь надо не забыть про сложные составные имена. Типа DEV_SuperPuperTable и DEV_SuperNotPuperTable. ...

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

Как выполнить переименование?

Хотя... Щас писал и подумал... А ведь если у нас есть таблица соответствий, то в ней можно и дубли отследить. ДО переименования. А затем выполнить замену в текстовом файле...

Мысль интересная.

[sukhanchik]

Цитата:

Сообщение от mazzy

А ведь если у нас есть таблица соответствий, то в ней можно и дубли отследить. ДО переименования. А затем выполнить замену в текстовом файле...

Ээээ а ведь так и штатный апгрейд 3.0 -> 4.0 по выравниванию полей проходил. Т.е. составлялся список полей к выравниванию, после чего производилось выравнивание.

[gl00mie]

Цитата:

Сообщение от mazzy

Не проблема написать. На лиспе, на си-шарп... да хоть на X++. КАК? Я ж и спрашиваю про инструмент и/или методику

Снова хочется вспомнить статью Джоэла Спольски "Где грязь, там и деньги" (цитировалась тут). Нет у этой сложной задачи простого и ясного решения - нужно повозиться, найти все "частные случаи" - тогда, может, появится полуэвристическая методика, которая, впрочем, не факт что будет работать на 100% в других условиях. За эту "возню в грязи" клиент и платит деньги хотя если по результатам родится некий инструмент, облегчающий решение таких задач, то будет здорово.

Цитата:

Сообщение от sukhanchik

Поэтому - я наверное склоняюсь к правилу 20/80. Т.е. переименовать 80% объектов за 20% усилий. Просто пойти по перекрестным ссылкам. Дальше вывести - список - чего осталось. Что-то действительно руками (возможно) быстрее сделать.

Полностью поддерживаю.

Цитата:

Сообщение от lev

так разве при заходе в аксапту, синхранизация выполняется автоматически

Часть таблиц - синхронизируется автоматически, см. \Classes\Application\syncApplTables, вызываемый в \Classes\Application\new. А еще вроде таблицы синхронизируются перед сравнением, вызываемым из формы импорта проектов.

Цитата:

Сообщение от mazzy

Хотя... Щас писал и подумал... А ведь если у нас есть таблица соответствий, то в ней можно и дубли отследить. ДО переименования. А затем выполнить замену в текстовом файле...

Замена в текстовом файле - штука небезопасная, потому что одно имя может оказаться подстрокой другого, т.е. как минимум нужно переименовывать в режиме поиска слова целиком или использовать регулярные выражения, и все равно может оказаться, что переименование безопасно проводить лишь в определенной последовательности, а не произвольно. Это схоже с проблемами скриптов обновления данных при переходе на новый SP/версию - в руководстве по их написанию акцентируют внимание на требовании к т.н. идемотентности.

PS. Вспоминаются давнишние рассуждения касаемо дефрагментации RecId (в частности, эти) - мне кажется, между этими задачами, если не вдаваться в технические детали, довольно много общего...

[mazzy]

Цитата:

Сообщение от gl00mie

Снова хочется вспомнить статью Джоэла Спольски "Где грязь, там и деньги" (цитировалась тут). Нет у этой сложной задачи простого и ясного решения - нужно повозиться, найти все "частные случаи" - тогда, может, появится полуэвристическая методика, которая, впрочем, не факт что будет работать на 100% в других условиях. За эту "возню в грязи" клиент и платит деньги хотя если по результатам родится некий инструмент, облегчающий решение таких задач, то будет здорово.Полностью поддерживаю.

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

Вернемся таки к методике.
Похоже она таки есть. И сводится к замене в текстовом XPO-файле.

Предлагаю на обсуждение черновой вариант:
0. Подготовительная фаза
0.1. выгружаем строки из формы Пути к объектам в Excel-таблицу (со слоями)
0.2. отделяем пути от названия объектов
0.3. в Excel копируем названия объектов во вторую колонку
0.4. [опционально] оставляем только строчки с названиями объектов, которые могут быть переименованы (изо всех слоев, все названия). Например, оставляем (названия форм, датасорсов, методов), названия (таблиц, полей, групп, индексов), названия menuItem и т.п. Убираем label, documentation, контролы внутри форм, элементы внутри enum и т.п.
1. план переименования
1.1. во второй колонке Excel проводим черновое переименование объектов
1.2. во второй колонке Excel формулой находим возможные (с учетом путей) конфликты, дубликаты
1.3. разрешаем конфликты, вводя суфиксы или сохраняя префиксы
1.4. повторяем 1.1-1.4 пока не будут разрешены все конфликты переименования
1.5. в результате получили план переименования: в большинстве объектов префиксы будут удалены, но в некоторых объектах названия изменятся более сложным образом
2. Исполнительная фаза (воможен алгоритм от lev)
2.1. выгружаем слой в XPO
2.2. переименовываем согласно плана переименования (переименовываются как свойства, так и строки кода). Можно выполнять как вручную, так и с помощью каких-нибудь интеллектуальных макросов (типа Emacs). Можно и программку написать
2.3. загружаем измененный XPO
2.4. если во время загрузки получаем конфликты, возвращаемся на шаг 1.1.
3. Проверка
3.1. проводим глобальную компиляцию с уровнем детализации = 4 и со включением заранее выбранного набора рекомендаций.
3.2. если компиляция выдала ошибки и/или рекомендации - разбираемся с ними (возможно возвращаясь на шаг 1.1)

примерно так.
т.е. все-таки работаем с текстовым XPO.
но не механически, а на основании заранее подготовленного плана.

инструменты:
= excel
= xpo
= какой-нибудь продвинутый текстовый редактор, который умеет делать массовую замену по плану (текстовый файл)

Цитата:

Сообщение от mazzy

Спасали рекомендации Best Practice при компиляции. Но и они не выявили всех случаев.

Можно идентифицировать все возможные ошибки и включить проверку на их наличие в классы бест практисес - SysBPCheck*

[Андре]

Цитата:

Кончай меня агитировать за советскую власть.

Процесс агитации всегда подразумевает какую-то цель. У меня этой цели нет. Ты спросил кто как делает - я описал схему по которой я работаю. Не нравится - придумай свою.

Цитата:

Этот? http://ru.wikipedia.org/wiki/Emacs
А как?

Да, этот. Его фишка в том, что он очень расширяем за счет метапрограммирования на диалекте Lisp, благодаря чему его можно заточить под решение своих задач, взяв за основу решения для имеющихся языков программирования (я шел от java, хотя теперь мне кажется это не оптимальным решением).

[lev]

посетила идея, но перед тем как её озвучить хочется задать уточняющий вопрос:
Вам известно на каком(каких) слое(ях) созданы объекты с префиксом, который надо удалить?

[mazzy]

Цитата:

Сообщение от lev

посетила идея, но перед тем как её озвучить хочется задать уточняющий вопрос:
Вам известно на каком(каких) слое(ях) созданы объекты с префиксом, который надо удалить?

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

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

[lev]

если это не системные слои, тогда предлагаю попытаться сделать по следующему алгоритму:

1. Делаем backUp приложения.
2. Заходим в аху формируем проекты для каждого слоя, где есть объекты для переименования (создаем проект, в нем нажимаем на "воронку". в выборе указываем для поля utilLevel критерий нашего слоя).
3. Экспортируем проекты нужных слоев с сохранением Id.
4. В полученных файлах выполняем переименование.
5. В приложении удаляем (переносим в другое место) слои, которые экспортировали.
6. Заходим в аху по очереди в каждый слой, начиная с более глубокого (например если экспортировали usr и cus, тогда в начале зайдем под cus) и заливаем наш проект.

В итоге должны получить то же приложение, но с нормальными названиями.

P.S. конечно же это теоретическая идея, не исключаю что на практике такое невозмжно

[mazzy]

Цитата:

Сообщение от lev

если это не системные слои, тогда предлагаю попытаться сделать по следующему алгоритму:

3. Экспортируем проекты нужных слоев с сохранением Id.
4. В полученных файлах выполняем переименование.
5. В приложении удаляем (переносим в другое место) слои, которые экспортировали.
6. Заходим в аху по очереди в каждый слой, начиная с более глубокого (например если экспортировали usr и cus, тогда в начале зайдем под cus) и заливаем наш проект.

В итоге должны получить то же приложение, но с нормальными названиями.

Я так пробовал.
При УБИРАНИИ префиксов возникают дубли. Которые фиг отловишь в текстовом файле. Может быть какой нибудь EMacs поможет...

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

Цитата:

Сообщение от mazzy

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

Во-первых, были глюки с сохранением идентификаторов. Не везде она их сохранила.
Во-вторых (и это главное) в результате переименования появились объекты с дублирующимися названиями (одинаковые таблицы, одинаковые поля, одинаковые формы).

Дублирующиеся поля категорически отказывались импортироваться в разные объекты. В результате, импорт проекта также превратился в достаточно муторную головоломку.

В общем, что делать с дублями при таком подходе?