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

[mazzy]

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

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

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

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

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

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

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


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

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

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

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

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

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

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

[Poleax]

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

[mazzy]

Цитата:

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

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

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

[Андре]

Цитата:

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

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

[mazzy]

Цитата:

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

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

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

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

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

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

[Андре]

Цитата:

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

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

Цитата:

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

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

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

[Андре]

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

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

Более простого способа я не вижу.

[mazzy]

Цитата:

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

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

Повторяю: Я ищу оптимальный способ. Я понимаю, что:

Оптимальный способ != Простой путь
Оптимальный способ != Легкий путь
Оптимальный способ != Малозатратный путь

Может хватит дисклаймеров и попыток агитации за советскую власть?

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

=============
Про постоянный и постепенный рефакторинг - понял.
Но вся беда в том, что с Аксаптой связана куча других базулек и сервисов.
Изменение структуры = изменение интерфейса. Что чревато.

[mazzy]

Цитата:

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

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

Пусть так.
А каковы должны быть входные параметры и проверочные результаты для задачи "корерктно изменить названия объектов"?

У меня честно - никаких идей.

[Андре]

Цитата:

Может хватит дисклаймеров и попыток агитации за советскую власть?

Прости, а за что я агитирую? Насчет методики, я подробно написал в предыдущем своем сообщении.

Цитата:

Пусть так.
А каковы должны быть входные параметры и проверочные результаты для задачи "корерктно изменить названия объектов"?

Опять же, это только мое мнение, но входные параметры и результаты зависят от функционала, в котором вы меняете префиксы. Изменение префиксов объектов ничем не отличается от прочего изменения кода.

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

Цитата:

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

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

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

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

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

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

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

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

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

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

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

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

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

[mazzy]

Цитата:

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

Опять же, это только мое мнение, но входные параметры и результаты зависят от функционала, в котором вы меняете префиксы. Изменение префиксов объектов ничем не отличается от прочего изменения кода.

Отличается.
Некоторые вещи влияют только на интерфейс.
Как проверить что не отвалилась функция перехода к основной таблице?
(я же писал, что свойство FormRef не изменяется при изменении menuITem)

Я понимаю, что критерии должны быть такими же как и для обычного кода:
1. компиляция должна проходить без ошибок
2. на 4ом уровне предупреждений не должно быть рекомендаций компилятора (по заранее выбранному набору рекомендаций)

но эти критерии не отлавливают всех возможных ошибок, связанных с переименованием объектов.

в связи с этим:
= (повторюсь) какую методику вы бы выбрали для решения данной задачи?
= как проверить, что работа выполнена корректно и полностью? каковы критерии?

[Андре]

mazzy, по-моему ты меня просто не слышишь. Нет технических возможностей отловить все эти ошибки и поэтому в твоем сценарии должно быть явно указан перечень полей, по которым должен работать переход к основной таблице и должен быть человек, который все это проверит.

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

Если интересует именно техническое решение, то я в подобных случаях просто выгружаю весь AOT в xpo и поиском по нему анализирую все места, где используется изменяемый элемент. Мне этот способ кажется надежнее перекрестных ссылок.

[mazzy]

Цитата:

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

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

можно и так

Цитата:

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

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

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

ага.

Цитата:

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

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

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

Цитата:

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

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

Ага.

Цитата:

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

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

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

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

Цитата:

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

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

Вручную?!

Цитата:

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

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

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

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

Цитата:

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

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

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

[mazzy]

Цитата:

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

mazzy, по-моему ты меня просто не слышишь.

Мне ж тоже нужно время, чтобы написать сообщение.
Некоторые сообщения я не вижу, когда начинаю отвечать.

Цитата:

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

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

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

э-э-э...
Я б повесился, если бы был программистом и мой начальник дал бы мне такое задание.
Я б кричал и топал ногами, если бы я был пользователем и мне бы такое всучили.
Другого способа точно нет?

Цитата:

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

Если интересует именно техническое решение, то я в подобных случаях просто выгружаю весь AOT в xpo и поиском по нему анализирую все места, где используется изменяемый элемент. Мне этот способ кажется надежнее перекрестных ссылок.

интересная мысль. А почему так надежнее?
Можно просто мысли, чтобы хоть понять куда рыть.

[Андре]

Цитата:

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

Ну, это может быть консультант стажер. Это может быть вообще человек нанятый со стороны, не знающий Аксапты, ни имеющий элементарные навыки работы с компьютером и достаточно внимательный и ответственный. При этом я подразумеваю, что план тестирования составляешь ему ты сам.

Цитата:

интересная мысль. А почему так надежнее?

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

Ну и просто вопрос привычки - я привык работать в emacs, а там анализ кода делать очень удобно.

[mazzy]

Цитата:

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

Ну, это может быть консультант стажер.

Можно я повторю? "Я б повесился, если бы..."
Кончай меня агитировать за советскую власть.

Цитата:

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

При этом я подразумеваю, что план тестирования составляешь ему ты сам.

Как должен выглядеть этот план?
Можно я повторю? "У меня честно - никаких идей."

Цитата:

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

Ну и просто вопрос привычки - я привык работать в emacs, а там анализ кода делать очень удобно.

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

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

Цитата:

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[Андре]

Цитата:

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

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

Цитата:

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

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