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

[kornix]

Цитата:

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

Есть клиент.
Теперь с ним работаем мы. Но раньше с ним кто только не работал.

Поколения разработчиков использовали префиксы (как это рекомендовалось в ранних бест-практисах)
в результате сейчас нередки подобные названия DDD_Codes.KKK_XXX_LL_OKVED. (где ККК, ХХХ, LL - префиксы)

Поскольку кастомизированных таблиц и полей много, то сложно запомнить какие префиксы и в какой момент нужно использовать. Что выбешивает.

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

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

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

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

В принципе, какая-то идентификация в самом объекте приложения в основном помогает что-то найти тому разработчику, который собственноручно создал какой-то новый объект (или коллегам из этой же компании). Вопрос удобства - относительный
По опыту, сталкивался с такой постановкой задачи: разработать новый модуль, все объекты, принадлежащие этому модулю именовать по правилу: <3 символа модуля>_<Имя объекта>. При разработке, и при переносе, и даже сейчас при поддержке этой функциональности это довольно удобно, психологически выделяется группа классов, EDT, таблиц и т.д. в АОТ, глядя на которые понимаешь - "Это этот модуль". Но тут, получается смысл префикса объекта приложения - идентификация его принадлежности к модулю (и удобная сортировка в AOT). На мой взгляд, префикс имеет смысл только в похожем случае (суффикс наверно был бы не настолько читабельным, и группа объектов, принадлежащая этому модулю будет разбросана в алфавитном порядке, и не будет представляться "группой" объектов).
С другой стороны, делая доработки для одной компании, в которой кто только не успел "попрограммировать", постоянно встречаю префиксы. Причем префиксы были как названием компании, так и самих разработчиков В итоге открываю форму, начинаю смотреть дизайн, поля называются ~ "<префикс>_amount" (а EDT - AmountMST), перехожу в класс - вижу в нем и префиксы и комментарии. Помогают, пожалуй, только комментарии, а префиксы - оооооочень отвлекают и путают (в силу их неорганизованности в этом случае) .
В результате, мне кажется префиксы имеют смысл при написании какой-то довольно большой новой функциональности (что бывает не очень часто), и они не имеют смысла, если выполняются запросы по поддержке функционала (исправление ошибок и т.п.).

[EVGL]

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

[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 не всегда виноват: иногда сам клиент предьявляет абсурдные требования к документации да еще и готов платить за это.

[AlexSD]

Цитата:

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

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

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

[kornix]

Цитата:

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

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

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

[AxaptaUser]

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

[sukhanchik]

Цитата:

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

хотелось бы увидеть примеры "абсурдных требований"(кроме уже упомянутых суффикосов/префиксов), с которыми приходиться/приходилось сталкиваться программистам.

Сам не сталкивался - но видел код решения Колумбуса для Перекрестка (еще с далекого 2001-го года) и слышал со слов участвовавших в том проекте - что руководство ИТ Перекрестка заставляло в каждом классе в classDeclaration писать комментарии следующего плана:

// Описание:    [Что делает этот класс]
// Вход:       [Какие данные нужно передать классу]
// Выход:     [Что выдает класс в результате своей работы]
// Создан:      [Дата], [Код и название можификации], [Код разработчика]

Я не считаю данное требование абсурдным (хотя может и для всех подряд объектов это и абсурдно) - тем не менее - это требование было именно со стороны Заказчика.

[Ivanhoe]

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

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

[kornix]

Цитата:

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

Сам не сталкивался - но видел код решения Колумбуса для Перекрестка (еще с далекого 2001-го года) и слышал со слов участвовавших в том проекте - что руководство ИТ Перекрестка заставляло в каждом классе в classDeclaration писать комментарии следующего плана:

// Описание:    [Что делает этот класс]
// Вход:       [Какие данные нужно передать классу]
// Выход:     [Что выдает класс в результате своей работы]
// Создан:      [Дата], [Код и название можификации], [Код разработчика]

Я не считаю данное требование абсурдным (хотя может и для всех подряд объектов это и абсурдно) - тем не менее - это требование было именно со стороны Заказчика.

В плане кода, мне кажется Коламбус мега крут Похоже у них к оформлению своего кода какие-то свои, особенные, внутренние правила

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

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

[oip]

Цитата:

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

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

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

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

[oip]

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

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

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

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