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

[mazzy]

Цитата:

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

Я считаю, что для почти всех кастомных объектов (кроме проектов) нужен единый для компании префикс. Т.е. новаю таблицу надо называть не блаблаTable, а Х_блаблаTable.

компании клиента или компании разработчика?
а почему не суффикс?

[titov]

Цитата:

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

Если логика программиста вдруг совпала с логикой от МС - то это повод задуматься об удалении /изменении собственного кода.
Вывод - свой код и код от МС тут хорошо "скрестить" и этто повод делать делать не потом "генеральную уборку", а сразу не мусорить за собой.

По классам спорный вопрос, что лучше - мусор в виде объектов+суффикс или объекты в проекте расхождений с ошибками? оба варианта имеют и плюсы и минусы...
Но главное - если приняты префиксы\суффиксы, то искать по одному алгоритму - по функциям коду и принимать решение о слиянии (удалении своих). Здесь еще плюс есть - приложение уже работоспособно сразу после перехода (ну почти сразу). А без преффиксов\суффиксов - в двух местах - есть два варианта развития событий. И приложение с ошибками!

еще момент - а если код партнера\клиента лучше MS DAX ? пройтись по своим классам и переименовать + код по ссылкам - то есть обратные действия?

А вот другой пример. Добавили новые таблицу или поле. Наименования совпали при переходе, но не типы для полей и обязательно! - разные ID. Что делаем, чтобы обновление базы заработало?
Вот именно - нужны дополнительные действия.

В целом - если объекты "развязаны" по наименованию, то после перехода меньше ошибок, меньше дополнительных действий, но больше мусора. Процент мусора низкий, потому что "пророков" мало!

Важно - малый процент совпадающих полей\таблиц могут принести большую головную боль при обновлении. "Мусору" в таких случаях только радоваться.

еще довод созрел для суффиксов, как раз для конкретного случая. Если у Заказчика несколько Исполнителей, то как различить, что делали они, если нет суффикса? А если разовая работа и не активирована журнализация изменений в АОТ, или этот журнал чист? Возникает проблема ответа на извечный вопрос "как же до вас то работало?" - а не работало вовсе! И создателем объекта числится администратор - ведь так чаще переносят код. Код на слое VAR у всех. Надо поднимать бэкапы приложения до.., а последний полгода назад был...и там нет этого объекта! Здесь же вариант одновременной работы двух исполнителей-ай-ти компаний.

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

[sukhanchik]

Цитата:

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

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

Полезны для кого? Для внедренца? Дык не им же потом (возможно) придется разгребать чужой код. Польза д.б. в первую очередь для конечного клиента. Как следствие - если конечный клиент обратится к внедренцам - им проще будет.

Цитата:

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

Почему-то сразу вспомнился Коламбус 1999-2001 годов

Потому что о нем в первую очередь и речь. Очень сильно вспоминается приложение в котором половина объектов с PRK_, из оставшегося - половина - штатный функционал, а половина - XXX_ и YYY_. Понятно - что внедренец "слепил" код с разных проектов. Если не брать во внимание этические/правовые моменты - то просто мне как разработчику, которому нужно чего-то усовершенствовать в этом коде - просто замучаться разбираться как можно поаккуратнее "вклиниться".

Цитата:

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

Я не о том писал. Я имел в виду, что если нужно добавить новую таблицу, то лучше называть её не SourceTable, а X_SourceTable. При этом никаких Y_SourceTable быть не должно - название после суффикса уникально. Ну и, разумеется, штатной таблицы SourceTable в системе тоже нет.

клиента, конечно. Т.е., если развивается приложение ООО "Рога и Копыта", то объекты надо называть РиК_Объект.
почему не суффикс? не знаю, суффиксы обычно как раз занимают локализаторы (_RU). Это ж моё ИМХО всё-таки

. Вот поэтому и нужно делать суффикс (если делать) - чтобы все было в одном месте и было наглядно видно и сразу пропадало желание делать Y_SourceTable

Цитата:

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

Когда я завожу в системе новую таблицу, я не с потолка беру её название - оно всё-таки как-то должно описывать хранимые в таблице данные. При этом одни и те же данные можно обозвать по-разному, да и одно название на английском может описывать разные сущности (invoice тот же, например). Если мой предшественник в базе клиента создаст таблицу RequestTable (которая будет задействована во МНОГИХ местах), а потом одноимённая таблица появится в Ax6 в сводном - будет совсем не хорошо.

На самом деле не совсем все так. Просто так дубль не появится. Обязательно будет префикс модуля. А вот уж если в МС "забыли" поставить префикс модуля и программист у клиента тоже забыл - то это уже урок этому программисту - что надо думать.
Именно из-за наличия префикса модуля - табличка в сводном никогда не пересечется с табличкой в ГК к примеру. Поэтому - никогда не следует создавать табличку RequestTable. Она должна относиться к чему-то. Либо это LedgerRequestTable (А может быть даже и LedgerRequestJournalTable), либо это InventRequestTable, smmRequestTable, MyModuleRequestTable и т.д.

Цитата:

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

По классам спорный вопрос, что лучше - мусор в виде объектов+суффикс или объекты в проекте расхождений с ошибками? оба варианта имеют и плюсы и минусы... Но главное - если приняты префиксы\суффиксы, то искать по одному алгоритму

"Безобразно но единообразно" - это точно.

Цитата:

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

еще момент - а если код партнера\клиента лучше MS DAX ?

Хотя это и вполне так бывает - но я бы стал отталкиваться от штатного кода как от эталона. По причине его тиражируемости. Таблицу CustTable знают все. А таблицу XXX_MySuperTable - никто.

Цитата:

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

А вот другой пример. Добавили новые таблицу или поле. Наименования совпали при переходе, но не типы для полей и обязательно! - разные ID. Что делаем, чтобы обновление базы заработало??
Вот именно - нужны дополнительные действия.?

Как уже писал fed - случаи апгрейда редки. Значит ими можно пренебречь. Вероятность такого события - очень мала. Да и оно некритично - сборка приложения делается не в авральном режиме за ночь. Т.е. берем перекрестные ссылки и проходимся у себя и выясняем - насколько отличается бизнес-логика, завязанная на это поле. После этого либо поле переименовываем - либо переделываем наши модификации на новые реалии (опять-таки - по проекту из перекрестных ссылок - это не такая проблема)

Цитата:

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

В целом - если объекты "развязаны" по наименованию, то после перехода меньше ошибок, меньше дополнительных действий, но больше мусора. Процент мусора низкий, потому что "пророков" мало!

Важно - малый процент совпадающих полей\таблиц могут принести большую головную боль при обновлении. "Мусору" в таких случаях только радоваться.

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

Цитата:

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

еще довод созрел для суффиксов, как раз для конкретного случая. Если у Заказчика несколько Исполнителей, то как различить, что делали они, если нет суффикса? А если разовая работа и не активирована журнализация изменений в АОТ, или этот журнал чист? Возникает проблема ответа на извечный вопрос "как же до вас то работало?" - а не работало вовсе! И создателем объекта числится администратор - ведь так чаще переносят код. Код на слое VAR у всех. Надо поднимать бэкапы приложения до.., а последний полгода назад был...и там нет этого объекта! Здесь же вариант одновременной работы двух исполнителей-ай-ти компаний.

2 вывода:
1. Если делать префикс/суффикс - то он должен обозначать внедренца, но никак не клиента.
2. Развести исполнителей по модулям и включить систему контроля версий. Не верится - что одновременно 2 исполнителя будут править один и тот же объект.
Если же рассматривать работу исполнителей во времени - то как раз получим ворох разнопомеченных объектов. Не спасет суффикс от неработоспособности функционала. Тут нужно как-то по-другому организовывать работу. Проектами может делить.