Правила жёлтого напильника

11.08.20

Архитектура

Как вносить изменения в типовые конфигурации при решении задач

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

Разумеется, не утверждаю, что я во всём прав. Наверное, нет правильных правил внесения изменений – у каждого свои приёмы, проверенные временем. Поэтому конструктивная критика и предложения приветствуются.

Для кого делаются доработки

Примите за правило: с вашими доработками будет возиться полный идиот. Он не будет знать вас, вашу компанию, решаемую задачу, заказчика и т.д.

Я не к тому, что надо всё разжевывать, комментировать и использовать человекочитаемые имена переменных. Вам решать, какое сообщение вы хотите до идиота донести. Просто помните, что он будет, идиот-то.

Можете вволю над ним поиздеваться. Можете ему помочь. Можете позаботиться об организации. Можете очистить карму, сделав всё правильно.

Всё равно идиот скажет, что вы написали говнокод.

Типы конфигураций

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

Первый – современные, бешено развивающиеся конфигурации. Сюда относятся ERP, УТ 11, КА 2. При их доработке надо быть чертовски аккуратным, потому что в следующем релизе может измениться всё, что угодно. Вплоть до того, что объект, который вы доработали, исчезнет под какой-нибудь функциональной опцией типа «Для староверов». В такие конфигурации изменения вносить опасно, и делать это надо с оглядкой на планы разработчиков. Вполне вероятно, что функциональность, которую просит клиент, появится через пару месяцев в типовой.

Второй – современные, но консервативные конфигурации. Сюда относятся БП, ЗУП. Консервативные они потому, что пользователи у них не большие выдумщики – бухгалтеры, расчетчики, кадровики, и бОльшая часть функциональности конфигураций регламентирована законодательством – сильно не разбежишься при разработке. К тому же, действуют законы продуктового маркетинга – «маленькие» конфигурации не могут и не будут повторять функциональность «больших», иначе никто не будет покупать ERP. В такие конфигурации вносить изменения можно и нужно. Но и сюрпризы бывают – например, в БП3 появился путевой лист, которые многие разрабатывали сами.

Третий тип – полумёртвые конфигурации, вроде УПП, УТ 10.3, БП 2. Вообще, они почти не развиваются, в части основной функциональности. Но, особенно в последнее время, в них вносят кучу изменений по части вспомогательной функциональности, вроде маркировки, которую неожиданно запихали во всякое старьё (хотя полгода назад говорили, что не будут). В полумёртвых конфигурациях опасными для изменений являются модули всяких маркировок, ЭДО, регл.отчетности – в них регулярно что-то прилетает. Основные же модули и объекты почти не трогают, и можно смело вносить изменения.

Четвертый тип – мёртвые конфигурации, вроде КА1. Среди конфигураций от 1С таких немного, а среди отраслевых – полно. Вплоть до того, что не существует уже компании-разработчика и конфигурацию тупо не купить. Вот тут полный простор для творчества – испортить уже невозможно.

Префиксы добавляемых объектов

У всех добавляемых объектов – неважно, справочник это, или реквизит документа – должен быть префикс. Отсутствие префикса обычно говорит либо о беспросветной тупости, либо о перетаскивании объекта из другой типовой конфигурации, либо о том, что программисту стыдно за этот объект.

Для франча префикс должен коррелировать с названием компании или бренда (типа «бит», «сс» и т.д.).

Для завода вынужден рекомендовать какой-нибудь префикс, коррелирующий с названием организации. Например, если завод называется «Уренгойские штаны», то префиксом может быть «уш». Однако, чисто из жизненного опыта – лучше префикс «ит», который означает «ИТ-отдел», и когда на новой работе будете таскать доработки со старой, не придется переделывать префиксы и код.

Для фрилансеров рекомендую «гв», «гн», «др», «ср» и т.д. – сразу понятно, что вы заходили ненадолго, сделали своё дело и ушли.

Префикс лучше делать с подчеркиванием («бит_», «сс_», «ит_»). Вообще, выглядит лучше без подчеркивания, но визуально проще заметить подчеркнутый префикс.

Подсистемы для объектов

Если задача напрямую не содержит прямого указания о включении доработок в определенную типовую подсистему, то создавайте свою.

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

В платформе есть прекрасные возможности сравнения/объединения и фильтрации по подсистемам, даже если это толстый клиент и какая-нибудь УПП. Подсистема выступит просто как носитель группировки объектов.

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

Да, разумеется, не надо в свою подсистему добавлять типовые объекты.

Маркировка изменений

Маркер изменений должен содержать тот же префикс, что и добавленные объекты. Не надо издеваться над идиотами, используя разные буквы в префиксах и маркерах – они этого не переживут.

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

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

Маркер обязательно должен содержать дату внесения изменений. Время не нужно.

Маркер должен содержать комментарий, поясняющий изменения. Если вы вносите несколько изменений в одну процедуру/функцию, то развернутый комментарий достаточно дать в одном из маркеров, а в остальных написать пару слов, обозначающих принадлежность изменений к одной задаче.

Номер задачи вносить в маркер есть смысл только в том случае, если ведется какой-то бесконечный реестр этих задач, и у идиота будет к нему доступ через несколько лет. Иначе смысла нет.

Изменение типовых запросов

Вообще, лучше так не делать.

В большинстве случаев, если вам понадобилось изменить типовой запрос – вы что-то делаете не так. Исключения бывают, но редко.

Например, если вам надо поменять запрос, заполняющий таб.часть – пишите обработку заполнения табличной части.

Если вам надо поменять запрос в типовой печатной форме – пишите внешнюю.

Если вам надо поменять запрос в отчете, делайте свой отчет.

Если вам надо поменять запрос в общих модулях зарплаты или страховых взносов, то мне вас искренне жаль. Всеми силами постарайтесь этого избежать.

Принципиально есть три варианта внесения изменений: закомментировать типовой запрос и написать свой, внести точечные маркированные изменения в типовой, подменить типовой своим на выходе.

Закомментировать запрос целиком – самая простая в реализации, но самая дурацкая идея, потому что никакой идиот не справится потом с обновлением, которое будет содержать изменения того же запроса – сравнивалка/объединялка просто не сможет понять, что новый типовой и старый, но закомментированный – одно и то же.

Второй по простоте вариант – подменить текст запроса перед его выполнением. Например, в коде написано Запрос.Текст = тырыпыры, а вы после этой строки добавляете свою – вызываете функцию своего общего модуля, которая переопределяет текст запроса (лучше вынести свой текст в отдельную функцию, чтобы не оставлять длинную портянку, увеличивая трудность обновления).

В этом варианте будет меньше проблем при сравнении/объединении – по сути, он покажет изменения в трех строках, где вы вызываете функцию с переопределением текста + две строки маркера. Но если разработчики типовой внесли в запрос существенные изменения, меняющие состав полей или вообще источники данных, и последующий код поменялся, то несчастного идиота ждет треш – по сути, надо будет решить задачу заново.

Самый сложный вариант – внесение точечных изменений. Например, есть запрос, а вам надо в него условие добавить – достаточно в тексте внести 1-2 маркированных строки с изменениями. Тогда весь текст запроса будет сравниваться с типовым, как обычный текст, и нормально найдет ваши пару строк.

Главная проблема этого варианта – невозможность внесения изменений конструктором запросов. Открыться-то он откроется, но нажмете ОК – и все маркеры исчезнут. Поэтому доработка таких, уже доработанных, запросов – не самое приятное дело. Надо открыть запрос конструктором, внести изменения, а потом скопировать текст, не нажимая ОК. Отладить запрос нужно будет где-то в другом месте, типа консоли.

Если изменений в запросе много, и вы не знаете, что и как лучше промаркировать, то просто сохраните исходный и измененный текст в виде текстовых файлов и сравните их (да, 1С прекрасно умеет сравнивать текстовые файлы). Дальше дело техники.

Ну и напоследок – если вы знаете, что запрос не бешеный, выполняется быстро, и вам надо всего лишь добавить сортировку, фильтр, или простой пересчет значения какого-то поля, то сделайте лучше постобработку – например, отсортировав или отфильтровав таблицу значений, в которую результат запроса выгрузился (если там таблица значений, конечно).

Еще раз повторю: если вы хотите внести изменения в типовой запрос, то вы что-то делаете не так.

Добавление новых ссылочных объектов

Сначала стандартная рекомендация: убедитесь, что объекта, который вы хотите добавить, в типовой нет. Не по названию, а по назначению. Если конфигурация незнакомая, спросите у того, кто в ней шарит.

А то знаете ведь как бывает: говорит клиент программисту «сделай мне, чтобы были разные прейскуранты, оптовый и розничный». Программист ищет по слову «прейскурант», не находит, и добавляет. И ладно если справочник – перечисление ведь, морда, добавит, со значениями «Оптовый» и «Розничный». А совсем недалеко лежит справочник «Типы цен».

Вторая рекомендация нестандартная: еще раз подумайте, нужен ли вам этот объект. Особенно, если у клиента – тяжелая база. Потому что вы задолбаетесь его потом удалять.

Проблема в чем: в некоторых конфигурациях, вроде УПП, есть объекты с реквизитами типа ЛюбаяСсылка, или СправочникСсылка, и добавленный вами справочник влезет в состав типов. Но на этом этапе вы никаких трудностей не испытаете.

А вот когда поймете, что объект не нужен, удалите его из конфигурации и нажмете F7, то испытаете удовольствие – зависнет на несколько часов, а то и суток, на реструктуризации какого-нибудь регистра сведений ВерсииОбъектов. Тут как дерево – влезть легко, слезть трудно.

Но спешу обрадовать: если брать основную массу клиентов франча, то там такой проблемы не бывает.

Если всё же столкнулись с проблемой, то можно методом Простоквашино воспользоваться: поменять имя объекта на Заготовка1, удалить все его реквизиты, элементы этого справочника (или кто у вас там), и написать в комментарии к объекту «Справочник ничей, берите кто хотите, только не удаляйте – не дождётесь реструктуризации».

А так – добавляйте свои объекты, это совершенно нормально и к проблемам не приведёт. С учетом рекомендаций, данных выше.

Добавление реквизитов в ссылочные объекты

Добавляйте, сколько хотите. Это один из самых безобидных видов доработки.

Тут, конечно, тоже есть вероятность наткнуться на долгую реструктуризацию, но она очень низка. Просто интересуйтесь до начала работы размером базы или количеством объектов нужного вам типа, и, если цифры вас напугают – будьте внимательны и проверяйте скорость реструктуризации на тестовой базе. Просто добавьте реквизит и нажмите F7.

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

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

В старых конфигурациях, вроде УПП или УТ 10.3, доп. реквизиты лежат в регистре сведений – одном на всех. Обращаться к нему уже сложнее, хотя бы из соображений производительности. Но в некоторых случаях он удобнее – например, если надо получить значение одного и того же свойства у объектов разных типов. В современных конфигурациях пришлось писать бы сложный запрос и не забывать его обновлять при изменении состава назначений доп.свойства.

Добавление реквизита в конфигурацию, если это допустимо условиями клиента – лучше. Этот реквизит сразу появится во всех отчетах, настройках дин.списков, его можно будет использовать в коде без обвеса.

Добавление чего-нибудь в регистры накопления

Как правило, добавлять измерения/ресурсы/реквизиты в регистры накопления – не стоит. Делая это, надо быть уверенным в себе.

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

Дальше вилка. Если это оборотный регистр, то пофиг – проблем не будет, даже если один документ будет заполнять ваше измерение, а второй не будет.

Если же регистр остаточный, и в приходе у вас будет заполняться новое измерение, а в расходе – не будет, то регистр тупо перестанет закрываться. А это жуткий косяк разработчика. И методически, и технически (если не заметят, через пару лет реальная и виртуальные таблицы регистра будут весить жуткие гигабайты).

Примерно то же самое с ресурсами. Если вы добавите в регистр товаров «Количество2», но забудете его минусовать, то таблица остатков будет пухнуть – ей же придётся помнить все остатки за всю историю в разрезе всех измерений.

Реквизиты добавляйте, если надо. Другое дело, что в регистрах накопления ими редко пользуются, только от безысходности – например, в регистрах УчетЗатрат, чтобы хранить кор.аналитику. Не забывайте, что значения реквизитов доступны только в реальной таблице регистра, а в остатках/оборотах их не будет.

Самые безопасные, повторю – оборотные регистры, особенно узкого назначения (а они почти все такие), типа ВыпускПродукции, Продажи – в них пишет не много документов, и найти все точки записи легко.

Зачастую, если вам надо сделать расширение аналитики остаточного регистра, проще поставить рядом такой же и добавить, чего вам там надо. В таком случае источником для записи в ваш регистр может служить «родительский» - можно тупо подписаться на событие его записи (если объем данных небольшой). Если же задача про большие объемы данных, то лучше сделать обработку/регламентный документ, который будет заполнять ваш регистр на основе родительского.

Добавление нового регистра накопления или регистра сведений, подчиненного регистратору

Добавляйте, сколько хотите. Главное – не поганьте типовые модули при формировании движений. Сделайте подписку на проведение документа, и там формируйте свои движения.

Если при этом надо получить что-то из типовой обработки проведения, то для этого есть ДополнительныеСвойства – предопределенное свойство любого объекта, в которое можно засунуть практически всё, что угодно. При этом посмотрите сначала на типовой код – вполне возможно, там уже весь контекст в объект засунут. Если же нет, добавьте одну строчку, которая поместит нужные вам данные в ДополнительныеСвойства – например, обработанную таблицу товаров или текущие остатки для контроля.

Не забудьте про очистку движений. Обычно, в типовых документах, используется универсальная процедура общего модуля для удаления движений. Ей пофиг, типовой регистр или ваш – она спросит у метаданных, и почистит всё, что найдет. В этом случае париться не надо.

Можно в свойствах регистра оставить автоматическое удаление движений при отмене проведения.

См. также

Архитектура решений Программист Платформа 1С v8.3 Бесплатно (free)

В статье расскажу про относительно уникальное явление на рынке. EmplDos - полноценный сервис, который в качестве Backend использует платформу 1С. Речь пойдёт не только о технической и архитектурной стороне вопроса, а ещё и о всех трудностях и граблях, которые пришлось и до сих пор приходится преодолевать на пути к успеху.

14.10.2024    4170    0    comol    28    

28

Кейсы автоматизации Платформа 1С v8.3 1С:Документооборот Бесплатно (free)

Компания «Уралхим» использует 1С:Документооборот не только для хранения и согласования документов, но и для централизованного управления НСИ между 47 системами (не только на 1С); для бэкенда к мобильным приложениям охранников; и в качестве сервиса заказа справок для сотрудников. О деталях реализации нестандартных решений, разработанных в компании «Уралхим» на базе 1С:Документооборот, пойдет речь в статье.

02.08.2024    3572    0    Novattor    1    

16

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    2234    0    slavik27    7    

15

Отчеты и дашборды Бизнес-аналитик Бухгалтер Пользователь Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Если вы привыкли выгружать бухгалтерские операции в Excel и дополнять их там управленческой информацией, вы сможете значительно сэкономить время, получая нужные управленческие отчеты в бухгалтерской программе сразу, без лишних движений. Представляем решение для самостоятельного внедрения управленческого учета в 1С:Бухгалтерии.

11.12.2023    2971    0    Serg_Tangatarov    2    

16

Архитектура решений Программист Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    5719    0    ivanov660    10    

35

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    3020    0    user1754524    15    

17

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Когда проект внедрения ERP в крупном холдинге захлебывается в проблемах производительности и в отчаянии пользователей, нужен комплексный подход. Расскажем о битве за производительность и об организационных мероприятиях по наведению порядка в системе и коллективе.

29.08.2023    3562    0    ke_almaty    0    

15
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. RustIG 1750 19.06.20 10:16 Сейчас в теме
Не забудьте в процедуре обработки проведения, которую пишете, проверить в начале на Источник.ОбменДанными.Загрузка, чтобы не формировать движения для объекта, прилетевшего с обменом.


Конструкция кода вида:

Документ.ОбменДанными.Загрузка = Истина;
Документ.Записать(РежимЗаписиДокумента.Проведение);

вызывает исключение! поскольку проводить в режиме обмена нельзя

Поэтому вопрос: как понять вашу рекомендацию?

В типовых ни разу не видел, чтобы в процедуре проведения стояла такая проверка.
Артано; echo77; improg; awk; +4 Ответить
2. Drivingblind 233 19.06.20 10:21 Сейчас в теме
(1) много где так.
Вот пример из модуля документа ПриобретениеТоваровУслуг в ERP:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
	
	Если ОбменДанными.Загрузка Тогда
		Возврат;
	КонецЕсли;
<.....>
КонецПроцедуры

вот статья по этому вопросу на ИТС: https://its.1c.ru/db/v8std#content:773:hdoc
3. RustIG 1750 19.06.20 10:37 Сейчас в теме
(2) Дривинблинд, читайте внимательно публикацию и комменты
pavlov_dv; Andreeei; Fox-trot; +3 Ответить
7. Drivingblind 233 19.06.20 10:52 Сейчас в теме
(3) извиняюсь. Поторопился
9. RustIG 1750 19.06.20 10:57 Сейчас в теме
4. 1c-intelligence 12852 19.06.20 10:41 Сейчас в теме
(1) да, вы правы, не обратил на это внимание, что такая проверка перед/при записи делаться должна. Исправлю.
5. RustIG 1750 19.06.20 10:43 Сейчас в теме
(4) у вас тут новосибирская поддержка? не глядя, заступаются :)
6. 1c-intelligence 12852 19.06.20 10:47 Сейчас в теме
(5) а я не знаю, что такое новосибирская поддержка.
8. RustIG 1750 19.06.20 10:57 Сейчас в теме
(6) :) ладно, проехали)))
(7) все нормуль :)
37. &rew 52 22.06.20 07:11 Сейчас в теме
(6)"Я свидетель! Что случилось?"
40. ILM 241 22.06.20 09:41 Сейчас в теме
(6) Нас надо знать в лицо. Приедете в Новосибирск, Вас поддержат!
17. json 3351 19.06.20 13:47 Сейчас в теме
(1) вот так надо делать при обмене, чтобы не было ошибки:

Документ.ОбменДанными.Загрузка = Истина;
Документ.Проведен = Источник.Проведен;
Документ.Записать(РежимЗаписиДокумента.Запись);


А движения приходят отдельным потоком
Altez; i.s.o; vdscom; +3 Ответить
19. RustIG 1750 19.06.20 14:01 Сейчас в теме
(17) 1) во второй строке лишнее слово ОбменДанными, а то получается что у свойства ОбменДанными есть свойство Проведен....
2) при обмене поле Документ.Проведен чаще всего равен автоматом полю Источник.Проведен. Это зависит от правил обмена, и в правилах регулируется. Дополнительно прописывать такую конструкцию мне кажется не надо.
3) в процедуре ПередЗаписью нет переменной Источник. Поэтому будет синтаксическая ошибка.

Для разных конфигураций движения отличаются, например для обмена УТ-БП....
Отдельным потоком не представляю по каким правилам они приходят.
Мне кажется проще провести документ отдельной командой, если он проведенный, тогда он сам сделает все нужные движения.
20. json 3351 19.06.20 14:16 Сейчас в теме
(19)
1. Исправил
3. Это прописывается в правилах обмена, а не в процедуре ПередЗаписью(). В типовых правилах есть переменная Источник, из которой заполняется объект

Если конфигурация идентичная и это просто узлы одной системы, то движения могут ходить.
Если конфигурации разные, то тогда обычно проведение выполняется отдельным регл. заданием. А документы для проведения помещаются в регистр, по которому работает это регл. задание
10. Synoecium 786 19.06.20 11:24 Сейчас в теме
неплохо, но тема слабо раскрыта.
1) Изменение ролей - если вам приходится менять типовые роли, вы свернули не туда. Сделайте лучше дополнительную роль с доступом к новым объектам (можно даже к типовым объектам, но лучше не надо). Копировать типовую роль и добавлять туда новые объекты тоже плохой тон
2) Добавление предопределенных значений - лучше в типовые объекты их не добавлять, велик риск потерять при обновлении. Сделайте лучше отдельный справочник предопределенных значений с значением любого типа и допиливайте его себе на здоровье. Идиот будет счастлив
3) Изменение элементов/реквизитов форм. Вообще, на сегодняшний день, я считаю что все изменения форм в типовых конфигурациях на УФ должны выполняться программно. Для этого есть переопределямые модули в современных конфигурациях, а в тех, что попроще, такие модули можно добавить 1 раз и пользоваться всю жизнь. Идиот конечно будет сильно озадачен как оно так все происходит, но после первого обновления скажет вам спасибо
4) Насчет изменения запросов, рекомендую попробовать новый объект СхемаЗапроса. С его помощью можно гораздо меньше зависеть от структуры и типовых изменений исходного запроса. Добавление полей, например, делается парой строчек. Еще парой строчек кода можно присобачить левым соединением какой-нибудь регистр сведений с нужными данными. На поля и таблицы из схемы можно опираться в своем алгоритме и прописать разные ветки условий и т.д. Для идиота это будет выглядеть сложно, но ему в любом случае будет сложно, зато мы получим некоторую устойчивость доработки к изменениям. Кстати, через схему запроса можно также дорабатывать запрос из динамического списка, что немаловажно, так как доступа к тексту запроса в модулях нет.
5) Изменение определяемых типов - лучше их не изменять. Опять же высок риск потерять изменения при обновлении, к тому же можно неявно расширить тип какого-нибудь регистратора или измерения в регистре, что может вылиться в проблемы схожие с "Добавление чего-нибудь в регистры накопления"
Rafaraf; igee12; trest30; improg; Darklight; mip128; RustIG; +7 Ответить
11. 1c-intelligence 12852 19.06.20 11:27 Сейчас в теме
(10) до этого еще руки не дошли просто.
15. ipoloskov 164 19.06.20 12:34 Сейчас в теме
(10)
Изменение определяемых типов - лучше их не изменять. Опять же высок риск потерять изменения при обновлении

Я разработал методику, как обезопасить себя от потери данных: https://infostart.ru/public/1227685/
Изменять приходится, например, чтобы добавить присоединенные файлы к своим объектам.
21. Darklight 33 19.06.20 17:07 Сейчас в теме
(10)Плюсую, но:
4) Насколько я знаю "СхемаЗапроса" - та ещё дрянь (пробовал пользоваться пару лет назад - больше не хочу, может что-то, конечно, сейчас изменилось - не знаю - скажите коли стало лучше) - у данного инструмента три фундаментальные проблемы:
1. Очень ограниченный API на изменения - банально даже поиска нормального даже в линейном списке нет, не говоря уже о поиске нужной точки изменения во всём запрос - от того конструкции работы с этим объектом просто монструозны - с кучей вложенных циклов; и даже если создавать свой хелперский API - всё равно всё - банальные операции выливаются в десятки строк кода (и сотни-тысячи строк в хелперском кустарном API). В 98% гораздо проще просто обработать текст банальными текстовым функциями. А надёжность - да почти не пострадает (будет на уровне 50% в обоих случаях) - тут просто проблемы уже глубже лежат - внутри самого синтаксиса запросов.

2. Работать можно только очень строго последовательно - т.е. если надо добавить поле - то нужно сначала добавить источник этого поля (если его нет), а чтобы его добавить - нужно добавить все прочие источники, от которых он зависит, и настроить соединения. А когда доходит до временных таблиц - так вообще просто жесть какая-то при работе выходит. Шаг влево - шаг в право - и всё - сразу ошибка при вызове метода. От того вносить правки в запросы - ОЧЕНЬ сложно и громоздко - приходится думать минимум на три шага вперёд и "бегать" по всему API данного объекта и его производных. От того код модификации получается крайне запутанным и трудно воспринимаемым. Ну, а если исходный запрос вообще ещё требует постобработки (да хотя бы банальной сборки из нескольких частей-подзапросов и временных таблиц, а в конфигурациях такое бывает частенько) - то в схему его либо вообще не загрузить, либо если и загрузить - то по выходу потеряются все "управляющие комментарии" (или "фигурные" расширения языка запросов - да хоть для СКД).

3. Доступность: "Сервер, толстый клиент, внешнее соединение". Может не так уж принципиально, но порой тексты запросов формируются на клиенте, а потом только передаются на сервер для выполнения (или устанавливаются в интерактивные объекты)

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

5) ОпределяемыеТипы штука очень мощная, но криво сделанная (особенно в расширениях). Их применение в конфигурации - большое благо (могло бы быть) - как раз из-за возможности в едином месте настраивать тип общего назначения, и потом везде его применять. И 1С идёт таким путём. И чтобы расширить это назначение своими типами - гораздо надёжнее внести их именно в определяемый тип, чем лезть в реквизиты, где он используется, проконтролировать (и объединить) опредлеляемый тип при обновлении куда менее рисковано, чем контролировать все места его применения (которые могут прибавляться/убавляться)
12. pm74 203 19.06.20 11:27 Сейчас в теме
боянчик конечно , но с юмором и читается легко поэтому +
Принципиально есть три варианта внесения изменений: закомментировать типовой запрос и написать свой, внести точечные маркированные изменения в типовой, подменить типовой своим
четвертый - через схему запроса
13. ipoloskov 164 19.06.20 12:21 Сейчас в теме
Чтобы у идиота был доступ к реестру задач, нужно вести этот реестр в самой конфигурации (в расширении). Например, в общем модуле __ОписаниеИзмененийКонфигурации
Rafaraf; Дмитрий74Чел; davdykin; mvxyz; RustIG; +5 Ответить
14. awk 744 19.06.20 12:21 Сейчас в теме
Отсутствие префикса обычно говорит либо о беспросветной тупости, либо о перетаскивании объекта из другой типовой конфигурации, либо о том, что программисту стыдно за этот объект.


Есть еще вариант. Мы работаем забегая вперед и знаем, что 1С создаст такой же объект (рано или поздно). Что бы это вовремя засечь и не плодить сущности, процитирую вас:

Сначала стандартная рекомендация: убедитесь, что объекта, который вы хотите добавить, в типовой нет. Не по названию, а по назначению. Если конфигурация незнакомая, спросите у того, кто в ней шарит.


Правда - это крайне редкий случай. 99,99% случаев проще (да и нужно) ставить префикс.
16. pm74 203 19.06.20 13:31 Сейчас в теме
есть еще один класс задач по доработке (про который ничего не сказано)
требующий отдельной главы в методичке . Когда нужно добавить функциональности отдельному сегменту чего либо.
пример на скрине
Прикрепленные файлы:
Albert_2008; RustIG; +2 Ответить
25. muskul 20.06.20 04:37 Сейчас в теме
(16)разные виды номенклатуры со своим учетом по характеристикам? не?
29. pm74 203 20.06.20 10:11 Сейчас в теме
(25) уже настроены , в данном случае требуется сделать выбор вида характеристики обязательным в частном случае
32. AntonSm 30 20.06.20 16:10 Сейчас в теме
33. pm74 203 20.06.20 18:54 Сейчас в теме
(32) спасибо , мне помощь не требуется
Я говорю про общий класс задач (очень частых кстати), для решения которых применяется несколько общераспространенных методов, начиная от "НайтиПоКоду" , заканчивая приведенным вами способом. И раз уж речь идет о методичке для " стажеров и программистов" , то недурно бы дополнить для обсуждения.
18. dandykry 11 19.06.20 14:01 Сейчас в теме
Еще раз повторю: если вы хотите внести изменения в типовой запрос, то вы что-то делаете не так.


Либо разработчики КА/УТ/ЕРП что-то делают не так уже несколько лет.
К примеру в предпоследнем релизе ЕРП при печати нескольких Коммерческих предложений, все печаталось как 1 большой документ.

Тема хорошая. К примеру, у нас есть отдельные правила по маркировке исправлений косяков от 1с )
22. rabid_otter 134 19.06.20 20:47 Сейчас в теме
1. Для кого делаются доработки
Про идиота - зачем эти эмоции лишние? Это уже давно сказано
«Пишите код так, как будто поддерживать его будет склонный к насилию психопат, который знает, где вы живёте» (с) Джон Ф. Вудс.

2. Типы конфигураций.
Это разумеется само собой. Достаточно график обновлений посмотреть.

3. Префиксы добавляемых объектов
Раздражает, когда в коде читаешь кашу из ИТ, ИИ, ББ, и т. д.
Почему это этот префикс обязателен? Это в конвенции по оформлению кода от 1С прописано? А подсистемы для кого придуманы?

4. Маркировка изменений
Разумеется само собой. Зачем делать заметку об измененном коде без первоначального?

5. Изменение типовых запросов
Если правка ошибки в типовом запросе? Лучше обрабатывать текст запроса после его объявления, а не править это объявление.

6. Добавление новых ссылочных объектов
Обычно новая подсистема, и конечно нужно делать какое-то исследование конфигурации, чтобы не плодить сущности. Это очевидно.

7. Добавление чего-нибудь в регистры накопления
Уж тем более надо провести исследование, поиск ссылок на объект, прежде чем что-то трогать в таблице, которая может оказаться огромной. За названия ресурсов ИмяРесурсаX надо лишать премии.

8. Добавление нового регистра накопления или регистра сведений, подчиненного регистратору

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

Много букв. Основная мысль, которая заграфоманена в статье - "не лезь в типовую. а если лезешь, то сделай анализ изменений, и добавляй чаще, чем изменяй".
xantif_2000; aegoncharov; +2 Ответить
27. aegoncharov 20.06.20 09:46 Сейчас в теме
(22) Поддержу по п.3 про префиксы. Вопрос неоднозначный.
Особенно что касается безапелляционной рекомендации:

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


Если каждый программист начнет делать свои префиксы в зависимости от места своего трудоустройства, то без слез на конфигурацию сложно будет смотреть. То же касается и "местячковых" префиксов предприятий.
Во-первых, у владельца конфигурации, по хорошему, должна быть некоторая концепция префиксации при доработках, которой следует придерживаться всем приходящим разработчикам. Если ее нету - то внешний разработчик может предложить ее.
Во-вторых, я считаю, что префиксация в большинстве случаев должна коррелировать с самим прикладным смыслом доработки.
Если вносится какая-то универсальная подсистема, например, какой-нибудь "Контроль доступа к данным", состоящая их нескольких модулей, регистров, справочников, то этим объектам вполне удобно будет дать префикс, какой-нибудь "КДД_".
Если вносится какая-то отраслевая доработка/подсистема, то можно дать "отраслевой" префикс, например, ХБКП (хлебобулочно-кондитерское производство).
Очевидный плюс в таком подходе - эти доработки проще переносить на другие предприятия (если сравнивать с префиксацией по наименованию предприятия, которое вообще может поменяться).
Если вносятся изменения непосредственно в типовую функциональность, то тут, вероятно, вообще лучше придерживаться стандартов наименований объектов и реквизитов самой типовой конфигурации. Многие алгоритмы по обработке данных используют совпадение наименований реквизитов в зависимости от их содержания. Если есть реквизит "Контрагент", хоть типовой, хоть добавленный, уже из наименования ясно что в нем.

Да, есть проблема, когда в конфигурацию добавляют свой документ/реквизит, а потом 1С делает свой с таким же наименованием, ее надо иметь ввиду.
JohnyDeath; Infector; +2 Ответить
28. rabid_otter 134 20.06.20 09:50 Сейчас в теме
(27)
Если каждый программист начнет делать свои префиксы в зависимости от места своего трудоустройства, то без слез на конфигурацию сложно будет смотреть.

да, согласен. видел много таких поделок.
жаль, в 1С нету аналога пакетов из Java, которые ограничивают пространство имен.
23. Labotamy 19.06.20 21:28 Сейчас в теме
Объясните плз беспросветному тупому трусу нафига префикс?
sashocq; rabid_otter; +2 Ответить
30. davdykin 25 20.06.20 13:58 Сейчас в теме
(23) Префиксы на самом деле очень удобны:
1. Можно найти все функции в модуле, какие ты добавлял, редактировал и т.д.
2. Вы видите реквизит в конфе, которого нет в поставке, что это, артефакт от прошлого кривого обновления, дописанный реквизит? По префиксу сразу видно. Да и искать такие реквизиты среди 20-30 стандартных - значительно проще.
3. Ну.. автодополниение тоже удобно, доработки в основном все скидываю в один модуль, т.к. не удобно под 2-3 процедуры делать отдельный модуль, выделяешь префиксом ДоработкаПравил_, ДоработкаОбмена и т.д., очень удобно
Дмитрий74Чел; +1 Ответить
24. genayo 19.06.20 22:48 Сейчас в теме
А так-то, лучше во франче не работать :))
31. davdykin 25 20.06.20 13:59 Сейчас в теме
(24)По-моему для "начала" работы самое то:
1. Поработаете с разными задачами
2. Если франч путевый - посмотрите стандарты работы, это сильно помогает в дальнейшем
3. Очень большой плюс - обмен опытом.
34. genayo 20.06.20 20:38 Сейчас в теме
(31) Вот именно, если франч путёвый. А их, путёвых, не так уж и много.
35. davdykin 25 21.06.20 05:09 Сейчас в теме
(34)Даже не путевый франч, опыта вам даст больше )). Хотя сейчас франчи мне кажется кроме как "проехать по ушам какая крутая штука ИТС", на большее не способны
52. genayo 24.06.20 08:26 Сейчас в теме
(35) Я тут дорабатывал одну подсистему "от франча" - проклял всё, проще было самому с нуля написать. Нахрен такой опыт по велосипедостроению с квадратными колёсами.
56. davdykin 25 28.06.20 10:46 Сейчас в теме
(52) Ну вообще очень странно, вы по одному случаю делаете обобщающие выводы.. вы думаете те кто не во франче - сразу пилять чистый, красивый код?
59. genayo 29.06.20 13:54 Сейчас в теме
(56) Это не один случай, это просто свежий пример. Конечно, не все сразу пишут качественный код, но во многих мелких (и не очень :( ) франчах, чтобы заработать, надо быстро писать код, который хоть как-то работает, чтобы быть принятым заказчиком. А про дальнейшую доработку и поддержку думать как-то не принято...
60. davdykin 25 29.06.20 18:12 Сейчас в теме
(59)Не знаю, я всю жизнь во франче работал и работаю, и как-то стараюсь не писать работающий говнокод, потому что клиенты потом в основном обращаются к нам же за поддержкой, зачем мне создавать себе лишнюю работу... да и как-то стыдно будет, если "следующие" ребята обслуживающие увидят твои грабли
26. z86 56 20.06.20 08:23 Сейчас в теме
А мне больше нравится суфиксы в новых объектах: когда что-то пишешь то по логике можно написать Номенклатура_сд чем чих_номенклатура. Также в комментариях пишем префикс но : "//с.д. рижий 2020-06-19" потому что подобрать префикс из 2-3 бук который не повторяется в тексте очень сложно. Ище есть небольшая рекомендация - когда пишем свои функции и переменные в тексте то начинаем с префикса "сд_" или просто "_", и обязательно коменты
36. JohnyDeath 302 21.06.20 10:38 Сейчас в теме
Префиксы - зло!
Даешь постфиксы!
48. 1c-intelligence 12852 23.06.20 22:35 Сейчас в теме
(36) я вот честно не понимаю, чем постфиксы лучше.
Мыслю в стандартном контексте: вносим не очень много изменений в типовую, т.е. наиболее распространённая ситуация для франча. Допустим, 3 справочника, 1 документ, 5 регистров сведений, ну и по мелочи - роли там, подписки.

Преимущества префикса:
1. Визуально в списке объектов МД их лучше видно, т.к. по левому краю они одинаковы (а список объектов прижат влево);
2. Если кто-то решит отсортировать список МД, то все добавленные объекты останутся рядом друг с другом, не разбегутся по списку (как объекты с постфиксами);
3. В контекстной подсказке достаточно набрать префикс, и тут же под курсором окажется весь наш небольшой набор. С постфиксами так не получится - контекстная подсказка по подстроке не ищет.

В остальном всё одинаково. Поиск в дереве метаданных одинаков для префиксов и постфиксов.

Объясните?
53. JohnyDeath 302 24.06.20 09:12 Сейчас в теме
(48) Те самый плюсы, которые ты описываешь для префиксов, являются для меня минусами )
Если кто-то добавил справочник "ПунктыПогрузкиВыгрузки" или общий модуль "КоннекторХТТП", то я хочу в подсказке видеть их именно по "пункты..." или "кон.." и не вспоминать о том, какой- же у них был префикс. Я работал в конфигурации, над которой трудилось куча франчей. И вот такое правило с префиксами у заказчика было обязательным требованием при приемке работ. Так вот там найти что-то внятное было очень сложно, отсюда росли еще одни грабли, о которых ты здесь также писал: некоторые модули ил даже справочники просто-напросто дублировали друг друга только потому, что разработчик одного франча не нашел похожего объекта/модуля другого франча.

По преимуществам префиксов из списка:
1. Визуально в списке объектов МД их лучше видно, т.к. по левому краю они одинаковы (а список объектов прижат влево);

Зачем их видеть визуально в списке МД? В предприятии, надеюсь, они отображаются без префиксов? И ничего, пользователи знают и любят названия без префиксов. А чем мы хуже?
2. Если кто-то решит отсортировать список МД, то все добавленные объекты останутся рядом друг с другом, не разбегутся по списку (как объекты с постфиксами);

Так это же наоборот плюс постфиксам. Справочник "КонтрагентыПрисоединенныеФайлы_бит" я хотел бы видеть рядом со справочником "Контрагенты", и не пытаться искать его по "бит_Контрагент", "кд_Контрагенты", "вз_Контрагенты"...
3. В контекстной подсказке достаточно набрать префикс, и тут же под курсором окажется весь наш небольшой набор. С постфиксами так не получится - контекстная подсказка по подстроке не ищет.

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

Очень много отраслевых решений, построенных на типовых конфигурациях, имеют в своих правилах "префиксы". И когда они доходят до клиентов, то уже на местах начинают добавлять свои префиксы. Т.е. уже на старте имеем 2 префикса.
sashocq; artbear; +2 Ответить
54. 1c-intelligence 12852 24.06.20 11:34 Сейчас в теме
(53) похоже, это все-таки дело вкуса. Как квас и кефир.
55. JohnyDeath 302 24.06.20 12:58 Сейчас в теме
(54) Можно еще посмотреть на типовые конфигурации и их Общие модули. Например "ОбщегоНазначения" и его "дети" в бухгалтерии: ОбщегоНазначенияБП, ОбщегоНазначенияБРО, ОбщегоНазначенияБТС, ОбщегоНазначенияЭДКО
Если бы разработчики каждой из этих подсистем (модулей) следовал правилу префиксов, то мы бы заимели "БП_ОбщегоНазначения" и т.п. Использовать такие ОМ крайне неудобно.
Но это лично мое мнение, никому его не навязываю. Просто с лихвой хлебанул этих префиксов у трех разных клиентов, где трудилась армия разных групп франчей. И их сортировка в дереве метаданных по префиксу, а не по смыслу только напрягает. Про контекстную подсказку можно просто забыть
38. skillman 5 22.06.20 07:33 Сейчас в теме
Как эта тема сейчас стала популярна!
Прям раньше жили без этого теперь опомнились или наелись обновлять типовые релизы ,которые кто-то поменял!?
39. &rew 52 22.06.20 07:47 Сейчас в теме
(38)Да нет. Просто сейчас дорабатывать типовые конфы стало сложнее. Много скрытых зависимостей. Изменились требования к аппаратной части. И если писать "за ПИСОТ рублей", то вместо базы можно в недалеком будущем получить "мертвяка". У меня так товарищ"алкашку" УТ восстанавливал после таких деятелей. Весь учет угробили. Самого бог миловал пока.
41. Mechanik21 24 23.06.20 17:53 Сейчас в теме
Не по теме: подскажите, что за классическое письмо было упомянуто в Корпоративном Ламанчском о верности работников? Я его тогда сразу нашёл и прочитал, а теперь вспомнить не могу, а случай такой, что дословно процитировать хочется)
42. 1c-intelligence 12852 23.06.20 18:10 Сейчас в теме
(41) послание Гарсиа
Mechanik21; +1 Ответить
47. Mechanik21 24 23.06.20 21:33 Сейчас в теме
43. German 413 23.06.20 20:04 Сейчас в теме
Начал за здравие, а закончил...

Начал читать, понравилось/зацепило деление на типы конфигураций, отложил, потом выкроил свободный вечерок на чтение статьи..
А дальше хоть не читай:
Префиксы - редуцент из тех времен когда в конфигураторе не было поиска по части строки, представьте что у вас будет с конфой когда у вас работает 10 или 20 компаний подрядчиков, не удивительно что они потом у вас "ТипыЦен найти не могут"..
Внешние отчеты/обработки/заполнения в типовых - ахахаха

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

Что бы не быть голословным подготовлю к публикации наш правила/регламент которой ковался кровью в больших коллективах и современных конфигурациях
44. 1c-intelligence 12852 23.06.20 20:13 Сейчас в теме
(43) а расскажете, чем могут 30 человек одновременно заниматься в одном проекте по доработке типовой конфигурации? Правда интересно.
45. German 413 23.06.20 20:32 Сейчас в теме
(44) как вы себе представляете этот рассказ? Если вы ставите под сомнение необходимость такого огромного числа ресурсов, то могу лишь сказать, что их по факту было 2 раза больше, а дальше вопрос объема данных и масштабов компании и стоящих задач.
46. 1c-intelligence 12852 23.06.20 20:47 Сейчас в теме
(45) нет, не ставлю под сомнение, правда интересно.
Если это фуллтайм и франч, то это 10 млн. в месяц.
Если это внутренняя команда, и все разрабы, то они именно типовую дорабатывают? Ну и это всё равно 5 тыс. ч/часов в месяц - столько стоит хороший проект внедрения erp, но там не только разработка.
Если это разработка, а не доработка, то там, вроде, другие правила нужны.
49. BabySG 23.06.20 22:45 Сейчас в теме
(46) пилили овердофига. И не один франч, их было иногда 10+. Ну а детали может Герман рассказать (ему пофиг на NDA, а мне нет :) )
Разработчиков, действительно, было меньше. Но важно понимать, что может быть разработчик, который раз в месяц вносит изменение (например, это эксперт и занимается производительностью) - но от этого требования к соблюдению правил не меняются.
PS. Кстати, изначально Герман не был настроен так против внешних обработок )
50. 1c-intelligence 12852 23.06.20 22:56 Сейчас в теме
(49) ну я подожду, чё.

Я встречал людей, которые все печатные формы всех документов УПП рисовали в модуле объекта. Вроде у них было какое-то объяснение даже, но я уже не помню, какое. Интересно ваше послушать.

Просто может оказаться, что вы (или он) опишете, как обстоят дела в 0.01% ситуаций - меня тоже часто в этом упрекают, говорят, что это синдром выжившего.

А так, мне правда интересно. Например, почему Герман назвал современной конфигурацию, в которую надо вносить бешеное количество доработок. А полумертвой - ту, в которую не надо. Весь мой опыт говорит об обратном.

В общем, жду интересного рассказа.
51. genayo 24.06.20 08:24 Сейчас в теме
(50) "Уж полночь близится, а Германа всё нет" :)
57. Tavalik 3412 29.06.20 05:57 Сейчас в теме
Вы уж, Иван, извините, но вода водянистая. А на методичку для стажеров и подавно не тянет.

Прикреплю наши правила разработки, может вам пригодятся: https://infostart.ru/public/647048/
58. 1c-intelligence 12852 29.06.20 08:43 Сейчас в теме
(57) у вас хорошо написано, но не всё объяснено - стажеры не сдадут мне экзамен, если не смогут объяснить, почему именно так надо вносить изменения.
Ну и не про все виды изменений написано. Например, ничего нет про регистры.
61. Cyberhawk 135 19.07.20 00:50 Сейчас в теме
в свойствах регистра оставить автоматическое удаление движений при отмене проведения
У регистров нет такого свойства
rudnitskij; +1 Ответить
62. 1c-intelligence 12852 11.08.20 11:43 Сейчас в теме
63. rudnitskij 14.08.20 10:40 Сейчас в теме
Не стал бы так слепо верить в непогрешимость авторов запросов в типовых конфигурациях. Их пишут тоже люди, и они тоже пишут написать фигню.
В конфигурации "Бухгалтерия для Украины 1.2" (из неё этот косяк без изменений перешел в версию 2.0) есть запрос, намертво завешивающий базу при попытке даже открыть форму документа, в таб части которого больше полусотни строк. Потому что в запросе наложили одинаковый отбор и в основной таблице, и во вложенном запросе. Стоило убрать дублирующий отбор - всё стало открываться за доли секунды и полминуты на документ с полутора тысячами строк (до оптимизации запроса эта операция завешивала сервер намертво, ждали ради эксперимента до вечера - не дождались)
64. Eeeehhhh 02.09.20 16:57 Сейчас в теме
Наткнулся на первую и после фразы о "тупости" засомневался в интеллектуальном уровне автора. Как раз префиксация новых объектов в дереве это самая большая глупость со стороны нелепых образований под названием фрачайзи 1С и их говнокодеров.
65. 1c-intelligence 12852 02.09.20 18:19 Сейчас в теме
66. myoker 9 12.03.21 07:11 Сейчас в теме
(64) Аргументируйте пожалуйста
67. Eeeehhhh 11.09.21 11:24 Сейчас в теме
(66) лучше поздно, чем никогда - вопрос удобства разработки и снижения избыточности кода. Предположим сильно "умный" создал с сотню объектов начинающихся с (да, да английскими буквами) IT_ОбщийМодульСервер ... Справочник.IT_СписокСамыхУмных - это во первых усложняет, а во вторых замедляет работу программиста. За ним приходит другой "самый умный" из другого франча и у нас возникает новые справочник "RA_СписокСамыхУмных" и новые модули "RA_ОбщийМодульСервер". Если бы юзался постфикс - "ОбщийМодульСервер_IT" и "Справочник.СписокСамыхУмных_IT" - во первых это упрощало бы контекстную подсказку наличия модуля\объекта, а значит бы страховало от избыточности -.потому что легко бы находилось бы в дереве конфигурации.
Оставьте свое сообщение