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

[Vadik]

Цитата:

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

Чтобы подлить керосина в огонь: только что создал таблицу MMEOfficialsActingTable_RU.
Расшифровываем: некто, работающий для клиента "MME", дорабатывает таблицу исполняющих обязанности должностных лиц.
..
Чем плохо?

До тех пор, пока мы не решим включить эту функциональность в наше вертикально-горизонтальное решение (может же у нас теоретически быть более одного клиента, использующего должностных лиц) - ничем
Когда решим - будет винегрет из префиксов в AOT, и при объявлении переменных поди вспомни, под какого клиента объект изначально создавался. И главное, непонятно, кому эта информация в будущем может быть полезна и зачем ее держать в голове ("кэшировать AOT" (с))

P.S. Да чего там - я раньше в названия объектов и методов свои инициалы добавлял префиксом - сейчас, если где-то сохранилось (надеюсь, нет), наверное смотрится как "Киса и Ося были здесь"

[fed]

А вообще - есть такое пародоксальное суждение: Если вы не можете разобраться в коде программы без документации, то вам и документация не поможет
Суждение конечно слишком сильное и провокационное, но я слишком часто при внедрениях Аксапты видел последствия подходов к документированию, позаимствованных на проектах по разработке тиражного софта. То есть - в начале проекта все документируем, префиксы, лейблы,бест-практис и тп. Потом манагер проекта вдруг видит что через 2 месяца запуск а сделано процентов 30 доработок, и начинает стимулировать разработчиков ипатьевским методом. В результате - процентов 30 проекта написано и задокументировано как по книжкам, а оставшиеся 70 процентов - написано как пьяная мартышка левой нижней рукой. Хотя с самого начала можно было не тратить столько времени на все эти методологии разработки "как в книжке", а просто попытаться написать не очень криво, зато почти весь код на одинаковом уровне.

Так что - конечно все рассуждения из серии "Может быть полезным при апгрейде/поддержке и тп" - они в принципе правильные. Действительно может быть полезным. Но гораздо интереснее будет сравнить денежную полезность с денежными затратами на ведение префиксов/суффиксов/лейблов и тп...

[mifi]

Цитата:

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

А вообще - есть такое пародоксальное суждение: Если вы не можете разобраться в коде программы без документации, то вам и документация не поможет
Суждение конечно слишком сильное и провокационное, но я слишком часто при внедрениях Аксапты видел последствия подходов к документированию, позаимствованных на проектах по разработке тиражного софта. То есть - в начале проекта все документируем, префиксы, лейблы,бест-практис и тп. Потом манагер проекта вдруг видит что через 2 месяца запуск а сделано процентов 30 доработок, и начинает стимулировать разработчиков ипатьевским методом. В результате - процентов 30 проекта написано и задокументировано как по книжкам, а оставшиеся 70 процентов - написано как пьяная мартышка левой нижней рукой. Хотя с самого начала можно было не тратить столько времени на все эти методологии разработки "как в книжке", а просто попытаться написать не очень криво, зато почти весь код на одинаковом уровне.

Так что - конечно все рассуждения из серии "Может быть полезным при апгрейде/поддержке и тп" - они в принципе правильные. Действительно может быть полезным. Но гораздо интереснее будет сравнить денежную полезность с денежными затратами на ведение префиксов/суффиксов/лейблов и тп...

Не надо мешать все в одну кучу - "все документируем" - это одно, а следование стандартам разработки - совсем другое. Никогда не сталкивался с тем, что следование стандартам разработки замедляло проект. Разработчик\ПМ, который этим пытается оправдывать задержки сроков- не профессионал. Либо еще, либо вообще.

[fed]

Цитата:

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

Не надо мешать все в одну кучу - "все документируем" - это одно, а следование стандартам разработки - совсем другое. Никогда не сталкивался с тем, что следование стандартам разработки замедляло проект. Разработчик\ПМ, который этим пытается оправдывать задержки сроков- не профессионал. Либо еще, либо вообще.

Вообще-то я как раз высказался за то, чтобы соблюдать стандарты. Просто хорошо бы чтобы стоимость соблюдения стандартов не превышала эффект от их использования. А разработчики, особенно если проектом рулит манагер без серьезного опыта как разработки, склонны завышать стандарты документирования и оформления кода.

[mifi]

Цитата:

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

Вообще-то я как раз высказался за то, чтобы соблюдать стандарты. Просто хорошо бы чтобы стоимость соблюдения стандартов не превышала эффект от их использования. А разработчики, особенно если проектом рулит манагер без серьезного опыта как разработки, склонны завышать стандарты документирования и оформления кода.

Про документацию - разговор отдельный и здесь стандарты не всегда разработчиками устанавливаются. Если есть требование писать ТДД - то эта работа должна быть сделана и оплачена, как и любая иная.
А вот насчет "стандартов оформления", т.е. соблюдение бест практис, правил именования, здравого смысла и т.д. - тут ничего завышать не надо, их просто надо соблюдать. И, если человек профессионал, то он понимает, что следование этим стандартам не увеличивает, а сокращает сроки проекта. Если он говорит иначе, то либо у него недостаточно знаний и опыта, либо его цель - написать глючный код, получить деньги и свалить.

[kornix]

Цитата:

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

Вообще-то я как раз высказался за то, чтобы соблюдать стандарты. Просто хорошо бы чтобы стоимость соблюдения стандартов не превышала эффект от их использования. А разработчики, особенно если проектом рулит манагер без серьезного опыта как разработки, склонны завышать стандарты документирования и оформления кода.

Вот тут полностью соглашусь. Причем как правило приходиться учитывать мнение таких PM И начинается поиск баланса и споры В принципе если осознанно писать код, соблюдая основные правила BP, и строить свои доработки так чтобы самому все было четко и прозрачно (именования и т.п.) - следующие поколения должны тоже разобраться, и без документации к коду

[EVGL]

Цитата:

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

Причем как правило приходиться учитывать мнение таких PM

PM не всегда виноват: иногда сам клиент предьявляет абсурдные требования к документации да еще и готов платить за это.

[Ivanhoe]

Самое абсурдное требование клиента, с которым я встречался - предоставить листинги (слово то какое замечательное =) ) Аксапты по всем внедренным модулям (полный БУ учет компании).

А приведенный пример документирования - вполне нормальный подход Сейчас (AX 2009), я так понимаю, MS сама это делает и используется для автоматического создания документации на код.

> По-моему - префиксы/суффиксы совершенно бесполезная штука. Где я ошибаюсь?

Ошибка в слове "совершенно".
Если их не использовать, можно столкнуться с проблемой апгрейда или миграции (в случае если названия ВНЕЗАПНО совпадут)

[oip]

Цитата:

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

Если их не использовать, можно столкнуться с проблемой апгрейда или миграции (в случае если названия ВНЕЗАПНО совпадут)

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

Для этого еще нужно, чтобы логика совпадала )))
Что, конечно, в некоторых случаях довольно вероятно, например добавление display- метода CustName на какую-нибудь таблицу с полем CustAccount.
Но не забывайте про остальные случаи, и в особенности связанные с данными, что будет, если совпадет например поле таблицы? что будет с данными после такого апгрейда? )

[kornix]

Цитата:

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

> По-моему - префиксы/суффиксы совершенно бесполезная штука. Где я ошибаюсь?

Ошибка в слове "совершенно".
Если их не использовать, можно столкнуться с проблемой апгрейда или миграции (в случае если названия ВНЕЗАПНО совпадут)

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

[oip]

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

Не вижу в такой ситуации никаких проблем.

> особенно по сравнению с другими задачами, которые возникают в процессе перевода на новую версию

А сравнивать нужно с вариантом с префиксами (что уж точно не сложнее - дописать 3 символа). При чем тут другие проблемы?

[oip]

Цитата:

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

А сравнивать нужно с вариантом с префиксами (что уж точно не сложнее - дописать 3 символа). При чем тут другие проблемы?

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

А дописать три символа не сложно, кто бы спорил.

> реальных недостатков у префиксов полно и они в этой теме уже подробно описаны и неоднократно

а можно ссылку? а то я не вижу "реальных" недостатков

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

Цитата:

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

> реальных недостатков у префиксов полно и они в этой теме уже подробно описаны и неоднократно

а можно ссылку? а то я не вижу "реальных" недостатков

Я понимаю, что "чукча не читатель, чукча писатель" Поэтому попробую свести вместе результат данного обсуждения

Использование префиксов было рекомендовано первыми выпусками Best Practis в ранних версиях Axapta. В последующих выпусках Best Practis (новых версиях Axapta) этой рекомендации больше нет. "Но осадок остался" (с)


Цель: Исключение пересечения имен с именами стандартных объектов с целью облегчения выделения кастомизированных объектов при переходе на новые версии/фиксы

Возражение:

1) Заявленная цель носит скорее теоретический характер. Никто и никогда еще не говорил на форуме о подобной проблеме.

2) При переходе на новую версию, "простой" upgrade в российских условиях - редкость. Обычно это выливается в написание нового приложения. Как следствие, переносится не код, а логика. Т.е. исходные имена объектов в "старой" версии не так уж и важны

3) Если имя кастомизированного объекта совпало с именем стандартного объекта в новом фиксе, то это повод пересмотреть логику использования данного объекта.


Цель: Идентификация компании/модуля/разработчика/фикса (в зависимости от того, что "шифруют" в префиксе) с целью последующего "разбора полетов"

Возражение:

1) Для идентификации автора объекта существует ряд других способов, не связанных с именованием объектов

2) Если проблема, связанная с объектом выявляется достаточно быстро, то и так все знают, кто автор. А если проблема выявляется не сразу, то на момент обнаружения проблемы уже не важно, кто автор. Надо проблему решать, а не искать крайнего

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

4) Если в префиксе "шифруется" разработчик или код фикса, то возникают проблемы при модификации подобного объекта. Ведь его префикс перестает соответствовать содержанию.

5) Если в префиксе "шифруется" компания, для которой сделана кастомизация, то возникает проблема при портировании решения для других компаний. Безотносительно к правовой стороне данного вопроса. Префикс перестает соответствовать содержанию.

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

6) "Шифрование" в префиксе модуля оправдано только в случае, если это действительно отдельный независимый модуль. Но, в этом случае использование префикса фактически совпадает со "стандартной" идеологией именования объектов в системе Axapta. "А если нет разницы, то зачем...?" (с)


Цель: Идентификация кода модификаций в именах проектов

Возражение: Это единственный случай, который не вызывает существенных возражений Есть "придирка", а не возражение.

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

Впрочем, это все-равно удобно. В случе поддержания правил вставки комментариев в код X++ можно определить имя проекта и посмотреть все объекты, включенные в данный проект. Сразу видно, что еще было изменено в данном проекте.

Хотя, данный способ использования можно считать "вне темы", поскольку к именованию объектов АОТ он не относится.


Цель: Модификации с одинаковым префиксом располагаются в АОТ рядом. Удобнее искать

Возражение:

1) Удобно, пока общее количество объектов относительно небольшое. При большом количестве объектов это уже существенного влияния не оказывает

2) Если объекты относятся к разным модулям, то поиск усложняется, поскольку объект оказывается далеко от стандартных объектов данного модуля. Необходим "двойной" поиск. Сначала по именам без префиксов, потом по именам с префиксами. Вне зависимости от того, нашли или нет что-то по поиску без префиксов. Если есть несколько префиксов, то надо будет выполнять поиск по каждому префиксу в отдельности.


Цель: "Расширение" одноименных объектов (дополнительные поля таблиц) или их локализация

Возражение: Для этой цели удобнее использовать суффиксы. Не нарушается стандартная идеология именования объектов и объекты оказываются рядом в АОТ


Дополнительные проблемы

1) В случае многочисленных кастомизаций будет много разных префиксов. Как следствие, возникают сложности в поиске и идентификации нужных объектов

2) Наличие префиксов - это паралельный стандарт именования объектов. Паралельный тому, который не явно предлагают разработчики Axapta. Как следствие, возникает необходимость поддержания нескольких стандартов именования. Чем их больше, тем сложнее.

3) Усложняется процесс вхождения в курс дела нового сотрудника. Ему нужно изучить "двойные стандарты" именования

4) Потенциально способствует дублированию функционала. Ну, не нашел нужного объекта (забыл про префикс) и создал свой собственный

[Pustik]

Цитата:

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

Цель: Идентификация компании/модуля/разработчика/фикса (в зависимости от того, что "шифруют" в префиксе) с целью последующего "разбора полетов"

Возражение:

1) Для идентификации автора объекта существует ряд других способов, не связанных с именованием объектов

Что это? Слои? Комментарии в коде? Createdby в свойствах объекта? Придуманный программистом лог изменения объектов?
Наверное, все-таки, в бытовых случаях пользоваться стандартным поиском по АОТ удобно, где префиксы доминируют.

[dech]

Роберт Мартин - Чистый код. Создание, анализ и рефакторинг

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

Цитата:

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

Что это? Слои? Комментарии в коде? Createdby в свойствах объекта? Придуманный программистом лог изменения объектов?

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

Цитата:

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

Наверное, все-таки, в бытовых случаях пользоваться стандартным поиском по АОТ удобно, где префиксы доминируют.

Предположим, у Вас есть такие объекты

InventTable
XXX_InventTable
YYY_InventTable
ZZZ_InventTable

Как Вы думаете, будет ли Вам удобно искать по AOT, если Вы точно не знаете где именно находится то, что Вам нужно? А если Вы точно не знаете сколько всего префиксов может быть?

На всякий случай уточню. Сама идея префиксов предполагает поиск только и исключительно в алфавитном порядке и никак иначе! Поскольку для всех других способов поиска в AOT факт наличия или отсутствия префикса никакого значения не имеет.