|
06.10.2010, 20:03 | #1 |
Участник
|
Цитата:
Цитата:
ВР раньше рекомендовал префикс\суффикс. Родились разные стили и привычка к ним - без, один из вариантов, вариации в виде сочетаний. Теперь мнения разделились по поводу - а как правильно? Сколько стилей столько и мнений. И доводы разные, но сводятся всего к трем - уникальность, авторство и просто удобство - так привыкли, или так. Думаю, что правильно для нас всех - одинаково по единому регламенту, желательно полученному от поставщика продукта! Тогда код будет понятен всем, и из других компаний, а не только группе разработки со своим стилем. Цитата:
Если пойти до конца, то отказ от дополнительных символов - это и есть самый "чистый стандарт-регламент", понятный всем. Он отсекает попытки создать свой стиль и вводить в заблуждение других. Получается так. ps новый ВР получается говорит именно об этом - нет побочным стилям! ps авторство под вопросом. убрать префикс - изменить исходный код. с другой стороны формат наименования новый, но не жестко обязательный. интересный момент новой версии - вот и причина почему новый ВР не акцентирует требование по наименованию обязательно без префикса\суффикса. Последний раз редактировалось titov; 06.10.2010 в 20:49. |
|
06.10.2010, 19:29 | #2 |
Member
|
На мой взгляд как консультанта с навыками разработки дублирование в системе одних и тех же сущностей противоречит концепциям ООП и противоестественно для самой Аксапты.
Сам стараюсь использовать стандартные типы. А если создавать, по такому же принципу как стандартные. С Еременко, который рекомендовал при создании своего решения генерировать свои типы даже если такие же в системе уже есть (в книжке по 3.0 еще), мотивируя это тем, что в стандартном типе может поменяться метка, — принципиально не согласен. Приложение после нескольких внедренцев видел. Для меня это дико. Попытка найти нужный тип раздражает. Против префиксов я категорически. Имя таблицы, класса должно начинаться с модуля. Типа — как правило с сути, и если тип действительно специализированный для модуля, то может начинаться с модуля. В моем понимании так. Я не против суффиксов. С поиском они не мешают. Сам обычно не использую. Насчет апгрейда кода. Мне кажется, что в процессе апгрейда вопрос стоит не в том, кто именно создал объект, если разработчик объекта не анархист в отношении ВР. Слоев и комментариев обычно достаточно.
__________________
С уважением, glibs® |
|
|
За это сообщение автора поблагодарили: mazzy (2), Ivanhoe (2). |
06.10.2010, 20:24 | #3 |
Member
|
Кстати, локализацию, как известно, изначально писал Колумбус. И судя по тому что тут пишут, возможно "_RU" нужно было для того, чтобы отличать локализаторские доработки от проектных.
Насколько я могу себе представить процесс разработки в такой большой компании, это вполне возможно и могло быть полезно. Навижн получил "_RU" по наследству в 2001-м, насколько я представляю. С тех пор так и осталось. И было применено на всю Восточную Европу впоследствии. Да, временами взгляда на объект достаточно чтобы понять чей он. С этой точки зрения удобно, не спорю. Но это не панацея. Есть и альтернативы (и в рамках ВР). По поводу авторства таблицы, типа данных, пунктов меню и схожих типов объектов мне кажется лучшим вариантом указывать в них конфигурационный ключ. Это не коверкает названия, но позволяет получить ответ на вопрос о принадлежности. Я видел команды разработчиков, которые так делают. С разными вариациями. В классе, форме, отчете можно написать комментарий было всегда в декларации класса.
__________________
С уважением, glibs® |
|
06.10.2010, 22:03 | #4 |
Banned
|
Когда появились первые "_RU", еще долго не было никаких проектов. Просто как-то повелось...
|
|
07.10.2010, 10:11 | #5 |
Участник
|
Цитата:
Но тут ситуация сильно отличается от того, что обсуждается в данной теме: стандартное приложение поставляется "как есть" - без всяких там историй в системе контроля версий и документации по запросам, на основании которых появились те или иные поля/таблицы/классы, в то время как для доработок такая дополнительная информация как минимум может (если не должна) быть обеспечена разработчиками. Цитата:
Цитата:
Сообщение от sukhanchik
В качестве убийственного аргумента, с которым я не смог не согласиться был довод - что любая документация нуждается в обновлении при изменении кода. Т.е. если я пишу в качестве комментария - описание того, что делает тот или иной класс/метод, то при изменении кода - я обязан изменить комментарий (а это лишнее время).
Цитата:
Сообщение от sukhanchik
наличие корректных комментариев (=корректная ссылка на документацию) помогает разобраться в коде, а наличие некорректных комментариев (=некорректная ссылка на документацию) - только мешает. Отсутствие комментариев - действует нейтрально. Теперь - зададимся все вопросом - мы всегда обновляем свои и чужие комментарии в коде при его изменении? А если эта ссылка "зашита" в название поля/метода/объекта?
|
|
06.10.2010, 22:37 | #6 |
Гость
|
Смысл использования префиксов/суффиксов сильно увязан с наличием и качеством документации по проекту.
Если есть вменяемые детальные описания автоматизируемых процессов, которые порождают пронумерованные задания на разработку, то смысл в префиксах/суффиксах есть. Пример: Название SomeTable_R012 говорит нам о том, что таблица была добавлена в рамках задания 12 проекта внедрения с кодом R (возможно это первая буква в названии консалтера). Ищем проектную документацию этого консалтера, находим задание 12 и описание процесса, автоматизации которого способствовало выполнение данного задания. После прочтения становится ясно с какой целью это появилось и как это использовать. Поля в новой таблице называем без префиксов. Затем в новом задании 128 нам вдруг понадобилось добавить поле в SomeTable_R012. Называем его SomeField_R128. Это говорит нам о том, что описание полей без суффикса искать в задании 12, а описание этого поля в задании 128. Тоже самое проделываем, если добавляем поле в стандартную таблицу. Если документации нет, то называйте объекты как хотите, а последователи будут разбираться потом по сравнению слоев, перекрестным ссылкам, комментариям и коду, зачем все это нужно и как люди могут это применять в повседневной жизни. |
|
06.10.2010, 22:58 | #7 |
Axapta
|
Цитата:
Сообщение от Кирилл
Название SomeTable_R012 говорит нам о том, что таблица была добавлена в рамках задания 12 проекта внедрения с кодом R (возможно это первая буква в названии консалтера)
.... Затем в новом задании 128 нам вдруг понадобилось добавить поле в SomeTable_R012. Называем его SomeField_R128. Это говорит нам о том, что описание полей без суффикса искать в задании 12, а описание этого поля в задании 128. Тоже самое проделываем, если добавляем поле в стандартную таблицу.
__________________
С уважением, Олег. |
|
06.10.2010, 23:09 | #8 |
Гость
|
Цитата:
Мифический кто-то ведет целый реестр созданных и модифицированных объектов и регулярно его обновляет. Кто-то оставляет комментарии. Кто-то использует суффиксы/префиксы. Кто-то просто называет как придется и ничего не комментирует. Кстати, все ли защитники SomeField где-нибудь в методе find удосуживаются написать комментарий, в рамках какого задания это поле было добавлено, если оно было добавлено не в том же задании, что и сама таблица? |
|
06.10.2010, 23:38 | #9 |
Axapta
|
Цитата:
Тех, в которых я принимал участие и о которых могу судить. Зашивать в название полей код модификации - по моему, это уже совсем за гранью. Это же совсем разного уровня абстракции - структура базы данных и внутренние номера проектных модификаций. Вас не раздражают сплошные почти никогда ненужные цифры в коде и в АОТе? В глазах не рябит? А что вы будете делать при возможном переходе на новую версию? Это будет перевнедрение и номера модификаций изменятся. А в случае с консалтинговой компанией, когда один и тот же код ставится разным заказчикам? Вот как раз хорошо документированное приложение и не требует никаких префиксов-суффиксов. P.S. Наболело просто. Сейчас как раз частично работаю в приложении, где приняты префиксы. Ужас.
__________________
С уважением, Олег. |
|
07.10.2010, 09:28 | #10 |
Участник
|
Угу. А вы его устанавливаете всем клиентам?
А если программисты клиента тоже работают в этом приложении и категорически отказываются? (типа, сложно...) (впрочем, это оффтопик) |
|
06.10.2010, 23:22 | #11 |
Гость
|
На чьих проектах?
Все хорошо, все так. Каждый выбирает удобный ему способ. Можно почесать макушку рукой, можно специальным скребком, можно нанять команду чесателей. Это не означает, что какой-то из этих способов неверен. |
|
07.10.2010, 09:24 | #12 |
Участник
|
Цитата:
с суффиксом получится SomeTable_R012_D0045_C05 с префиксом получится C05_D0045_R012_SomeTable |
|
07.10.2010, 11:33 | #13 |
Гость
|
Цитата:
Вообще, меня никакие именования не расстраивают. Суффиксы, префиксы, их отсутствие. Это как расстраиваться от того, что елки с иголками, а березки не с иголками. Расстраивает когда нет информации. Анализ кода может ответить на вопрос "как", но не может ответить на вопрос "зачем". |
|
07.10.2010, 11:40 | #14 |
Участник
|
Цитата:
предположим, даже был первоаначальный проект. предположим, он даже доступен текущему поколению разработчиков. Если не записывать проекты, то объект может быть изменен в другом проекте. Но разработчик в этом не уверен. В результате разработчик все так же должен сканировать код каждый раз. Независимо от наличия или отсутствия суффикса. Если же все последующие проекты записывать каким-то образом в первоначальный проект. Но снова возникает вопрос неактуальности. Расхождений кода и документации и т.п. И снова разработчик должен сканировать код. |
|
07.10.2010, 12:03 | #15 |
Гость
|
Да
Цитата:
На примере таблицы добавленной в рамках одного задания и поля, добавленного в нее в рамках другого задания все прозрачно. Поля SomeTable_R12, которые не имеют суффиксов описаны в R12, поле SomeField_R128 из таблицы SomeTable_R12 описано в R128. Для примеров где нет смысла в суффиксах, так там и не будем их использовать. |
|
07.10.2010, 00:21 | #16 |
Administrator
|
2Кирилл: Подход интересный - но не могу не согласиться с мыслью от oip - что от цифр в коде рябить будет.
Во-первых - есть неудобство по отношению к консалтинговой компании. Если хочется "разлить" на несколько приложений (разным заказчикам) одну и ту же модификацию - то придется перенумеровывать поля, т.е. править код. Во-вторых - есть неудобство по отношению к запоминанию полей. Думаю, что многие специалисты уже привыкли к штатным названиям полей - типа CostAmountPosted, AmountCurDebit и т.д. Без технологии IntelliSense (а она далеко не везде применима) - вспомнить название поля может быть нетривиальной задачей. Конечно по сравнению с префиксами - может так и лучше - но ... наверное действительно вопрос привычки. Кстати - по ходу писания возник вопрос. А как дела обстоят с перекрытыми методами? Их же нельзя переименовывать? Добавили мы метод myMethod_R0123(). Спустя полгода - решили сделать наследника класса и перекрыть этот же метод. Он будет сделан уже в рамках другой модификации. А нумерация останется той же? Аналогичный вопрос по отношению к Map-ам и нумерации полей в нем. Особенно интересно - когда 2 поля в разные таблицы были добавлены в рамках двух разных модификаций, а соединить в Map все это было решено в рамках 3-й модификации. Лирическое отступление. В свое время довелось мне спорить с Валерием Ушаковым (VALU - для тех кто знает - отвечал некоторое время за разработку АХ в МС) по поводу оформления смысловых комментариев в коде. Он был противником любых комментариев в коде. В качестве убийственного аргумента, с которым я не смог не согласиться был довод - что любая документация нуждается в обновлении при изменении кода. Т.е. если я пишу в качестве комментария - описание того, что делает тот или иной класс/метод, то при изменении кода - я обязан изменить комментарий (а это лишнее время). При этом для человека, который будет разбираться в моем коде - наличие неверных комментариев гораздо больше будет мешать вниканию в код, нежели их отсутствие. Т.о. получается следующая ситуация - что наличие корректных комментариев (=корректная ссылка на документацию) помогает разобраться в коде, а наличие некорректных комментариев (=некорректная ссылка на документацию) - только мешает. Отсутствие комментариев - действует нейтрально. Теперь - зададимся все вопросом - мы всегда обновляем свои и чужие комментарии в коде при его изменении? А если эта ссылка "зашита" в название поля/метода/объекта?
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 07.10.2010 в 00:23. |
|
07.10.2010, 11:49 | #17 |
Гость
|
Цитата:
Сообщение от sukhanchik
Кстати - по ходу писания возник вопрос. А как дела обстоят с перекрытыми методами? Их же нельзя переименовывать? Добавили мы метод myMethod_R0123(). Спустя полгода - решили сделать наследника класса и перекрыть этот же метод. Он будет сделан уже в рамках другой модификации. А нумерация останется той же?
Аналогичный вопрос по отношению к Map-ам и нумерации полей в нем. Особенно интересно - когда 2 поля в разные таблицы были добавлены в рамках двух разных модификаций, а соединить в Map все это было решено в рамках 3-й модификации. Для методов можно вообще не использовать суффиксы, все равно внутрь метода будут заглядывать и увидят комментарий. А внутрь поля не заглянешь. В примере каждое поле в таблицах имеет свой суффикс 1 и 2, у нового мапа суффикс 3, а у его полей вообще нет суффиксов. Кстати, у таблиц и мапов есть свойство DeveloperDocumentation, так что и для них можно сейчас без суффикса обойтись. Раньше такого свойства не было и кто-то привык добавлять прямо в название ссылочку. |
|
07.10.2010, 01:43 | #18 |
Member
|
Кирилл, а в чем практическая ценность понимания на основании какого задания что-то добавлено?
Предположим, что мы добавляем на основании задания 25 в некой таблице поле Currency_25. В задании 60 нам нужно использовать поле с валютой в этой же таблице. Я предполагаю, что еще одно поле Currency_60 вы не создаете, а используете существующее. И вряд ли его переименовываете в Currency_25-60 с перелопачиванием всего кода. Разработчик все равно будет пользоваться перекрестными ссылками и прочими стандартными инструментами. Консультант... да, часто бывает консультанту сложно понять что за параметр был добавлен, кем добавлен и главное, как этот параметр работает (сужу не по себе, т.к. код читать умею, а на основании наблюдения за коллегами, не владеющим средствами разработки). Но актуализация его использования в последующих задачах не происходит. И надежнее получается попросить разработчика посмотреть по коду все равно. Прошу не воспринимать мой пост как агрессию или попытку подвергнуть сомнению разумность вашего подхода. За ним желание докопаться до истины, и ничего более.
__________________
С уважением, glibs® |
|
07.10.2010, 09:36 | #19 |
Участник
|
Префиксы-суффиксы. Как лучше? Стоит ли избавляться от них?
Лучше для кого? - одного разработчика, группы, партнера, клиента, майкрософт или всех вместе взятых? - В новом ВР и отражена "новая" точка зрения поставщика продукта на подход к вопросу наименования - без преффиксов\суффиксов - именно так лучше для ВСЕХ!. Все-таки приоритет теперь только за бизнес-логикой. Стоит ли от них избавлятся? По старым версиям, думаю, нет. Скажем так - там мы живет по тем "старым законам - ВР с преффиксами\суффиксами". А на при переносе на новую версию с "новыми законами" - ВР - Да!, по возможности избавляться. По возможности - если это не противоречит уже юридическим законам. Как правильнее? - По актуальному правилу (ВР) на текущую версию. PS Надо признать, что старый ВР привил нам очень сильную "привычку" и создал целую "культуру" мысли в разных направлених. Майкрософт это признал. Осталось дело за нами. Последний раз редактировалось titov; 07.10.2010 в 10:00. |
|
07.10.2010, 11:21 | #20 |
Гость
|
Цитата:
Ключевые пользователи заняты, им некогда консультировать консультантов. Новые бойцы читать документацию ради ее чтения вряд ли будут. Полистают максимум. И вот поменялся процесс или возникли какие-либо проблемы. Пользователи могут на пальцах объяснить что их волнует и даже указать на нужные места в системе. Если в этих местах будут какие-либо ссылки на проектную документацию (не обязательно префиксы/суффиксы), то можно уже более пристально изучать данный процесс, разбираться почему именно так, восстановить последовательность событий, которые происходили с этим местом системы. Иными словами, можно быстро овладеть контекстом ситуации. |
|