![]() |
#11 |
Участник
|
Цитата:
Но главное - если приняты префиксы\суффиксы, то искать по одному алгоритму - по функциям коду и принимать решение о слиянии (удалении своих). Здесь еще плюс есть - приложение уже работоспособно сразу после перехода (ну почти сразу). А без преффиксов\суффиксов - в двух местах - есть два варианта развития событий. И приложение с ошибками! еще момент - а если код партнера\клиента лучше MS DAX ? пройтись по своим классам и переименовать + код по ссылкам - то есть обратные действия? А вот другой пример. Добавили новые таблицу или поле. Наименования совпали при переходе, но не типы для полей и обязательно! - разные ID. Что делаем, чтобы обновление базы заработало? Вот именно - нужны дополнительные действия. В целом - если объекты "развязаны" по наименованию, то после перехода меньше ошибок, меньше дополнительных действий, но больше мусора. Процент мусора низкий, потому что "пророков" мало! Важно - малый процент совпадающих полей\таблиц могут принести большую головную боль при обновлении. "Мусору" в таких случаях только радоваться. еще довод созрел для суффиксов, как раз для конкретного случая. Если у Заказчика несколько Исполнителей, то как различить, что делали они, если нет суффикса? А если разовая работа и не активирована журнализация изменений в АОТ, или этот журнал чист? Возникает проблема ответа на извечный вопрос "как же до вас то работало?" - а не работало вовсе! И создателем объекта числится администратор - ведь так чаще переносят код. Код на слое VAR у всех. Надо поднимать бэкапы приложения до.., а последний полгода назад был...и там нет этого объекта! Здесь же вариант одновременной работы двух исполнителей-ай-ти компаний. и еще - практикуется продажа решений айти компаниями - суффиксы объектов в таких проектах хро очень даже кстати. И не всегда сразу ясно, что будет решение при начальном создании объектов. |
|