Вообще-то я больше склоняюсь к мысли Владимира Максимова:
Цитата:
Сообщение от
Владимир Максимов
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