Чек-листы для проведения Code Review

17.05.21

Разработка - Рефакторинг и качество кода

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

Введение

При внедрении Code Review, о котором я рассказывал ранее ( //infostart.ru/1c/articles/1364611/ ) мы за основу брали стандарт программирования, разработанного фирмой 1С. Для того чтобы с ним ознакомиться, необходимо прочитать соответствующий раздел на ИТС «Система стандартов и методик разработки конфигурация для платформы 1С:Предприятие 8» (https://its.1c.ru/db/v8std ). Обязательными к использованию являются все пункты. Это стандарт фирмы 1С. Все пункты важны, но мы выделили основные пункты и добавили свои пункты, все это переложили в чек-листы  для проведения Code Review (проверка кода), и это стал наш инструмент контроля соответствиям стандарта.

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

По каждому пункту чек-листов дается краткое пояснение. В своей деятельности Вы можете использовать предложенные чек-листы полностью или выделить из них нужную информацию даже без внедренной полноценной системы Code Review.

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

 

Чек-лист для проведения Code Review

 
 Стандарт комментариев.
 
 Форматирование (Заглавные буквы, пробелы и т.д.).
 
 Название объектов (переменные, модули, функции и т.д.). Грамматические ошибки.
 
 Архитектура решения доработки.
 
 Избыточность доработок.
 
 Дублирование кода (ООП).
 
 Проверять деление на «0», проверка на Неопределено.
 
 Проверка на тип (где это необходимо).
 
 Обращение через точку.
 
 Использовать Isnull в запросе.
 
 Не использовать запрос в цикле (кроме исключений).
 
 Использовать «Выразить» для реквизитов составного типа в запросе.
 
 Не использовать соединения с вложенными запросами.
 
 Использование условий в запросе в секции ГДЕ, вместо параметров виртуальной таблицы.
 
 Получение излишних данных в запросе.
 
 Выгрузка результата запроса, где нет необходимости.
 
 Разделить выполнение и выборку/выгрузку  результата запроса.
 
Избегать Полное (Внешнее) соединение в запросе.
 
Не использование БСП (пишем то, что уже есть)
 
Не использовать метод «Сообщить».
 
Использовать ТекущаяДатаСеанса() на &Сервере.
 
Не верные директивы компиляции
 
Использовать инструкции препроцессору в модулях (Объекта, Менеджера, Сеанса).
 
Присутствует «мертвый» код, пустой обработчик.
 
 Использовать стандартные области в модулях формы, объекта, менеджера, а также в общих модулях.
 
 Новые объекты должны быть включены в специальную подсистему «ДобавленныеОбъекты» и на них должны быть даны права.
 
Программное создание всех реквизитов формы, если дорабатываем типовую форму.
 
Не использовать проверку на тип «булево», через ИСТИНА или ЛОЖЬ.
 
Использовать дату «регистра накопления – остатки», как «МоментВремени» (или «Граница»), а не «Дата».
 
Правильное использование: «транзакций» и «попыток».
 
Учитывать RLS при написании запросов.
 
Новые объекты с использованием расширений, нужно создавать в основной конфигурации.

 

      Формат комментариев и префиксация новых объектов

 

Формат комментария должен иметь формат, представленный на рисунке 1:

 

Рисунок 1 Формат комментариев.

 

Ниже приведено описание каждого элемента комментария (номер элемента на картинке соответствует номеру, выделенному жирным, в описании ниже). «Пример 1» для проектных работ, «Пример 2» для работ на сопровождении.

// <Тип комментария> <Наименование организации> <ФИО разработчика> (<Дата внесения изменения в формате "dd.MM.yyyy">) <П|С>.<Номер> <Краткое пояснение изменения>

1 <Тип комментария> - указывается символ «+» для комментариев перед изменением, «-» для комментариев после изменения.

2 <Наименование организации> - наименование организации разработчика для его идентификации. Не более десяти символов.

3 <ФИО разработчика> - фамилия и инициалы разработчика, который вносит изменения в код. Формат: «Фамилия И.О.».

4 <Дата внесения изменения в формате "dd.MM.yyyy"> - следует обязательно придерживаться заданного формата даты. Дата изменения указывается в скобках.

5 <П|С> - если изменение вносится в рамках проекта, то следует указывать «П»; если в рамках сопровождения, то следует указывать «С». <Номер доработки в рамках проекта или сопровождения> - порядковый номер доработки, по которому можно однозначно найти постановку задачи по изменению. Для проектных работ .<Префикс проекта>.<Номер раздела | Номер технического задания>.<Номер доработки>. Для задач на сопровождение .<Номер доработки>.

6 <Краткое описание изменения> - необязательное поле. Указывается, если разработчик считает необходимым описать изменение кода. Не более 50 символов.

 

Создание новых объектов и префиксация

Первое правило – это добавление в конфигурацию объектов верхнего уровня (справочников, документов, регистров и т.д.). В начало наименования объекта нужно добавлять префикс (рисунок 2).

 

Рисунок 2 Создание нового объекта верхнего уровня.

 

Это правило заключается в том, что имена объектов обязательно должны начинаться с префикса. Для чего?

  • Во-первых, это визуально выделяет добавленный элемент в конфигурации и в коде сразу видно, что это – наш добавленный объект.
  • Во-вторых, достигается уникальность имени, потому что поставщик может добавить свой объект с тем же именем. И если мы будем использовать свой префикс, то это гарантирует, что наше имя будет уникально. Синоним указываем без префикса. Синоним не должен значительно отличаться от имени объекта. К примеру, если имя объекта «Префикс_КадроваяИсторияСотрудников», то неверно указывать в качестве синонима «Работники организации».

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

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

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

К примеру: Типовой справочник «Пользователи». В нем необходимо добавить реквизит, который бы содержал, действителен или нет пользователь (рисунок 3). Формат комментария описан выше.  При добавлении реквизитов формы так же необходимо указывать префикс.

 

Рисунок 3 Добавление реквизита в типовой объект.

 

Чек-листы для проверки архитектурных решений кода

 
 Использовать только в крайних случаях объект метаданных - “Константы”. 
 
 Поле на форме, которое подсвечено красной пунктирной линией, должно быть обязательно к заполнению.
 
 При добавлении нового объекта метаданных - “Команда”, “Отчет”, “Документ” и т.д.  не забывать про роли. 
 
 При создании отдельного внешнего отчета, обработки необходимо проверять роли/доступ для всех потенциальных групп пользователей.
 
При использовании общих модулей с повторным использованием возвращаемых значений на время сеанса нужно учитывать, чтобы полученное значение не было изменено во время сеанса.
 
 Не используйте в названиях переменных имена реквизитов формы.
 
 При добавлении новых реквизитов в типовые объекты метаданных необходимо использовать префикс, кроме случаев, когда необходимо  использовать типовой код (например: ввод на основании, реквизит - организация).
 
 Проверка на тип переменной.
 
При добавлении кода в типовые модули, желательно его отделять уникальными проверками для своей логики (проверка на тип, уникальное значение реквизита и т.д.). 
 
Получение данных из периодического регистра сведений срезом последних не по всем измерениям регистра. 
 
Фиксировать по возможности все важные события в журнал регистрации (например: отправка почты (кому и во сколько ушло письмо); обмены с другими системами (во сколько и какие объекты отравлены/загружены)  и т.д.).
 
Отказ от использования функций: НайтиПоКоду, НайтиПоНаименованию.
 
 Необходимые проверки в объектах метаданных нужно выносить в модуль объекта, по возможности исключить их из модуля формы.
 
Осуществлять проверку объектов метаданных на реквизиты “ЭтоГруппа” и “ОбменДанными” (наиболее актуально для новых объектов).
 
Проверка на наличие на форме реквизитов при программном добавлении.
 
Формировать отчеты в фоновом режиме.
 
При использовании в запросах левого соединения контролировать, чтобы не было дублирования строк. 
 
В типовом решении при синхронизации данных между базами нет возможности  отследить какие объекты были выгружены/ загружены. 
 
По возможности не создавать реквизиты с типом “ХранилищеЗначений” для объектов метаданных (справочников, документов) активно использующихся при реализации основной бизнес-логики.
 
При написании запросов желательно:

 

Заключение

Использование приведенных чек-листов (полностью или частично) повысит качество кода программистов, даже без внедренной системы Code Review. Основное правило, чтобы вся команда придерживалась одних стандартов.

См. также

Когда понадобился новый оператор

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда понадобился новый оператор, но его нет в синтакс-помощнике, что делать?

18.03.2024    1138    ZhokhovM    2    

4

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

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда разработчик платформы решил пойти на кухню за кофе, а проверку препроцессоров не добавил, и вот тут-то и началось: "Что, опять все сломалось? Ну и кофе же я забыл сделать!".😅

18.03.2024    2669    ZhokhovM    4    

8

Реструктуризация - бесконечная история

Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

При разработке программ требуемый функционал ставят на первое место, но есть еще и архитектура программы. На горизонте 5-10 лет она становится важнее функционала, который должен работать при масштабировании и росте данных. Реструктуризация 5 терабайтной базы 1С 8.2 в формат 1С 8.3, складывает весь пазл архитектурных просчетов, которые сделали ради функционала. Как это исправить? - для разработки правильной архитектуры, нужно всего лишь сместить фокус с функционала и подумать о «вечном».

29.09.2023    1907    1CUnlimited    15    

22

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 2

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

27.09.2023    6965    Lemmonbri    136    

36

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 1

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

19.09.2023    4344    Lemmonbri    16    

31

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

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

10.08.2023    9581    0    1c-izhtc    37    

21

Задача на ошибки и неоптимальности при проведении приходной накладной

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Задачу эту дают на собеседованиях, видимо, те франчи, которые не в состоянии оценить человека по резюме и в ходе беседы. По идее задачи, подобные этой, должны давать начинающим студентам. Но дают всем подряд. Итак: мои 5 копеек. Критика приветствуется.

11.07.2023    2214    magic1s    32    

11
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Shmell 533 17.05.21 10:15 Сейчас в теме
Отличный чек лист. Саша, хорошо постарался )
S.Mihajlov; AntonKulmetev; starik-2005; +3 Ответить
2. ig-efrem 17 17.05.21 15:37 Сейчас в теме
Спасибо за статью, очень все лаконично и по делу. Буду использовать как инструкцию для подрядчиков и спрашивать по этой статье за их косяки.
3. ekon1982 17.05.21 15:47 Сейчас в теме
Правильное использование: "транзакций" и "попыток". Первый пример "Правильно" и последующий пример "Не правильно" - один и тот же код (за исключением создания нового документа).
buganov; mikukrnet; +2 Ответить
22. Shining_ninja 2155 18.05.21 06:08 Сейчас в теме
(3)
ющий пример "Не правильно" - один и тот же код (за исключением создания нового документа).


Побольше добавил примеров для понимания.
4. kuntashov 449 17.05.21 16:04 Сейчас в теме
Не нужно делать вручную то, что можно сделать полностью автоматически, бесплатно и без СМС: https://github.com/1c-syntax/bsl-language-server

Можно платно: https://checkbsl.org/ (больше диагностик).

Можно чисто на 1С, АПК: https://releases.1c.ru/project/ACC
nekit_rdx; memb3r; Olenevod; JohnyDeath; brr; Sla; Hoper1981; pavlov_dv; Артано; amoarok; user811769; Evg-Lylyk; olegtymko; Akcium; CyberCerber; +15 Ответить
5. starik-2005 3033 17.05.21 17:09 Сейчас в теме
(4) чтобы что-то автоматизировать, нужно сначала вручную это пару раз сделать и понять, что и где не так или не то, и как надо. А то автомат выплюнет лог, и что с этим логом делать?
6. kuntashov 449 17.05.21 17:18 Сейчас в теме
(5)
и что с этим логом делать?


Следовать указанным в логе рекомендациям по исправлению:
Прикрепленные файлы:
7. starik-2005 3033 17.05.21 17:23 Сейчас в теме
(6) ну если ссылка в данном случае - это реквизит табличной части, то сообщение неуместно. Кто-то должен быть достаточно грамотным, чтобы это понять.
19. Артано 760 18.05.21 03:22 Сейчас в теме
(7) В любом случае, на такие моменты обращать внимание нужно. Если всё нормально, то "ошибка" помечается как "не ошибка" или "архитектурное решение" =)
44. user1140274 18.05.21 10:28 Сейчас в теме
(7)
А можно конкретный пример. ДокументРасхода.Ссылка.Дата - недопустмо, ДокументРасходаТовары.Ссылка.Дата - допустимо, я правильно понял?
47. Артано 760 18.05.21 10:57 Сейчас в теме
(44) Я думаю, Старик имел ввиду, что в случае ТЧ так и так будет левое соединение с одной единственной таблицей, так что зачем мелочиться и описывать в коде запроса то, что произойдёт.
55. starik-2005 3033 18.05.21 11:52 Сейчас в теме
(44) в документе расхода дата и так есть - зачем тут ссылка? А вот в табличной части даты нет, но ее можно взять из ссылки. В любом случае это левое соединение, но в первом случае ненужное.
56. user1140274 18.05.21 11:58 Сейчас в теме
(55) спасибо, теперь понял
24. Shining_ninja 2155 18.05.21 06:11 Сейчас в теме
(5)
ы что-то автоматизировать, нужно сначала вручную это пару раз сделать и понять, что и где не так или не то, и как надо. А то автомат выплюнет лог, и что с этим логом делать?


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

Автоматическая проверка - у нас есть, ей также пользуемся.
23. Shining_ninja 2155 18.05.21 06:10 Сейчас в теме
(4) Мы уже начали использовать автоматизированные проверки, но сами написали инструмент.
Артано; kuntashov; +2 Ответить
36. kuntashov 449 18.05.21 08:15 Сейчас в теме
(23) Круто, а почему все-таки свой/сами, а не используете готовое?
Планируете ли его открыть или выпустить как продукт?
42. Shining_ninja 2155 18.05.21 09:09 Сейчас в теме
(36)

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

Как продукт не будет, но в будущем возможно выложим на обозрение.
8. DarkAn 1079 17.05.21 18:01 Сейчас в теме
(0) не плохо. Но просьба переработать сообщения спойлеров в одном "направлении". Часть спойлеров понимается, что внутри "как надо", а часть, что внутри "как НЕ надо".
25. Shining_ninja 2155 18.05.21 06:16 Сейчас в теме
(8) напишите пункты, которые нужно изменить - я поправлю. Старался все писать - "как надо".
9. biimmap 1827 17.05.21 19:22 Сейчас в теме
Половина написана правильно, а половина ерунда полная.

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

Половина Ваших "предложений" пустая по содержанию. Написано что делать, но совсем не написано как! Пример: ЛЕВОЕ СОЕДИНЕНИЕ. Есть способы конкретные как избежать дублей и как понять возникнут они или нет при соединении таблиц. Аналогично про RLS. Как добиваться то, чтоб работали запросы все? Опять же есть четкая методика. и т.д.

Ставить минус не стану, т.к. сам являюсь автором статей и получаю и минусы и критику. Но явно Вам стоит подробнее расписать.
Что касается фразы, что любой программист сможет сам это сделать... вот это максимально неверная фраза.
26. Shining_ninja 2155 18.05.21 06:26 Сейчас в теме
(9)
то Вас научил использовать вложенные запросы? Вы не в курсе временных таблиц? Но нет, в курсе, сами пишите об этом в последнем пункте. Как-то странно получается.


Как раз в чек-листе и описывается, что нужно по минимуму использовать вложенные запросы, а лучше использовать временные таблицы.

Этот пункт подтверждает ИТС: https://its.1c.ru/db/v8std#content:655:hdoc

НО! Временные таблицы не всегда оптимальны по производительности, наш коллега снизу об этом пишет.

Не однократно встречал, что программисты простые запросы пишут через вложенные запросы, когда удобнее через временные запросы.

Этот чек-лист и нужен чтобы проверить, что вложенные запросы бывают излишне.
---------------

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


Как раз в чек-листе и описывается, что это нельзя делать и если составной тип, то нужно применять функцию - Выразить.

Этот пункт подтверждает ИТС: https://its.1c.ru/db/v8std#content:654:hdoc

Также на ИТС подобный пример (я сделал подобный пример с ИТС).
10. partizand 129 17.05.21 20:34 Сейчас в теме
Подскажите, что не так со значениями с модулей "на время сеанса"?
Не совсем понятно.
И да видимо вы не запускали АПК и не смотрели результат. В идеале это нужно делать перед код ревью. Особенно меня удивляют форматы комментариев, часто встречающиеся в компаниях, которые нарушают требования Совместимо.
И все же код ревью по чеклисту кто угодно не проведёт. Нужно понимать.
Мне встречались несколько ЗначениеРеквизита подряд одного объекта, да еще внутри цикла. Ваш чеклист это бы одобрил.
27. Shining_ninja 2155 18.05.21 06:31 Сейчас в теме
(10) Мне встречались несколько ЗначениеРеквизита подряд одного объекта, да еще внутри цикла. Ваш[/IS-QUOTE]

Это уже проверка архитектурных решений, это уже должен проверяющий найти при проверке.
Все зависит от бизнес-задачи.

Подскажите, что не так со значениями с модулей "на время сеанса"?


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

И все же код ревью по чеклисту кто угодно не проведёт. Нужно понимать.


Команда пишет и проверяет по одним стандартам.
11. partizand 129 17.05.21 20:43 Сейчас в теме
Еще вопросы, хочется закрыть пробелы в своих знаниях:
1. Почему нельзя использовать полное соединение? Ведь оно доступно в запросах...
2. Почему нельзя сразу выгружать результаты запроса?
13. biimmap 1827 17.05.21 23:08 Сейчас в теме
(11)
1. Неправильно говорить что нельзя... Нужно описать в каких ситуациях можно. Просто задач, которые решаются через ПОЛНОЕ СОЕДИНЕНИЕ очень мало. Надо стараться использовать ЛЕВОЕ. Если надо наложить неявный фильтр, то ВНУТРЕННЕЕ СОЕДИНЕНИЕ. Если надо несколько таблиц слить воедино пользуются ОБЪЕДИНИТЬ ВСЕ, если надо без дублей пишут просто ОБЪЕДИНИТЬ. Полное соединение генерирует лишние записи. Так ещё в них половина полей имеют значение NULL. Это надо учитывать и дополнительно описать в запросе.

2. Выгружать можно, но только в случае, когда таблицу в цикле не обрабатывают!
Т.е. пишут НаборДвижений.Загрузить(Запрос.Выполнить().Выгрузить()). Вот так норм.

Обработка таблицы в цикле идёт медленнее, чем обработка через выборку запроса.
Hoper1981; Артано; +2 Ответить
28. Shining_ninja 2155 18.05.21 06:34 Сейчас в теме
(11)
2. Почему нельзя сразу выгружать результаты запроса?


1. Использовать конечно можно, но не желательно, что подтверждает ИТС: https://its.1c.ru/db/v8std#content:435:hdoc

2. Без необходимости лучше это не делать, т.к. лишняя нагрузка на систему.
35. starik-2005 3033 18.05.21 08:07 Сейчас в теме
(28) кстати, как-то здесь была статья про то, что не стоит использовать Выгрузить() для результата запроса в источнике итераторов для цикла. Так вот люди умные не поленились и сравниди скорость работы с выгрузить и выборка.следующий. Так вот до 100к строк запроса выборка работала медленнее при сопоставимом расходе памяти. А выше 100к строк просто не проверяли, ибо 100к - это в принципе программное ограничение 1С для табличных частей, да и вообще обработка свыше 100к элементов должна параллелиться и отрабатывать многопоточно порциями.

Вообще, стоит иметь ввиду, что в интерпретаторах делают встроенные оптимизации, и может так оказаться, что Для Каждого Х из Запрос.Выполнить().Выгрузить() будет работать без дополнительного выделения памяти, получая данные из непосредственно объекта с результатом запроса, который в любом случае едет из sql в 1С. Но это уровень мышления над платформой (или под ней). На С кода пишешь программу, то понимаешь, что буфер прочитанного фрагмента файла или тот же запрос - это уже выделенная память, которую можно использовать, при том она уже в кеш попала процессорный. В итоге на С скорость обработки тех же 120кк недействительных паспортов у меня в районе 4 секунд, а на том же железе в СУБД это положить - от 25 минут прямым запросом и до 4х часов если писать в регистр сведений средствами 1С))))

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

В общем или программист 1С ограничен платформой и тогда ему лучше тупо соблюдать то, что пишет 1С, ну или он платформой неограничен, и механика работы запроса и оптимизатора лежит в поле дискретной математики, которую не ограниченный программист тоже немножко (в части деревьев и хеш-таблиц, как о них Макконнелл писал) знает и про нормальные формы читал и понял.
user1285052; skillman; +2 Ответить
43. Артано 760 18.05.21 10:01 Сейчас в теме
(35) Я помнится писал подобное, но речь шла о безусловной выгрузке результата независимо от сценария последующего использования. Дело не в скорости, а в дополнительном выделении памяти. Ведь результат запроса уже является таблицей - зачем создавать новую, если уже есть одна? Оптимизации не исключены, 1с любит оптимизировать платформу, чтобы неоптимальный код работал быстрее.
100. skillman 5 12.08.21 17:40 Сейчас в теме
(35)Тебя никто не понял и не плюсанул :)
12. buganov 200 17.05.21 21:24 Сейчас в теме
Фиксировать по возможности все важные события в журнал регистрации (например: отправка почты (кому и во сколько ушло письмо); обмены с другими системами (во сколько и какие объекты отравлены/загружены) и т.д.).

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

Проверка на наличие на форме реквизитов при программном добавлении

Разве реквизиты не создаются в обработчике ПриСозданииНаСервере?

При написании запросов желательно
- Использовать пакетные запросы и временные таблицы вместо вложенных запросов.

- Для объединения нескольких таблиц используйте объединить, а не левое соединение.

- Для отладки сложных запросов используйте дамп запроса.

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


1. Не согласен. Генерить нагрузку на tempdb без имеющихся на то причин, зачем? MSSQL отлично раскрывает скобки.
2. Опять же с потолка. Почему не левое соединение? Чтобы подзапутать оптимизатор?
3. Что такое дам запроса? Что то новенькое и модненькое? Я бы посоветовал для отладки сложных запросов использовать план запроса
4. Вы делали замеры индексирования? Очень редко создание индекса помогает для больших таблиц. Бывает, но редко.

В целом, резюмируя статью, очень много "советов" и причем очень спорных и никак не обоснованных. Не скажу, что статья больше вредная, нежели полезная, хотя, нет, скажу. Автор постарался, но, как говорится в джентельменских кругах: "Тема сисек не раскрыта", а уж советов и подавно, особенно безапелляционные утверждения.
14. biimmap 1827 17.05.21 23:14 Сейчас в теме
(12) с пунктами 1 и 4 не соглашусь.
1. вложенные запросы зло особенно на больших таблицах. + есть стандарты разработки 1С.
4. что касается индексирования... автор неверно написал что делать надо. Надо не создавать индексы в объектах метаданных, а следить, чтоб связи и условия накладывались по индексированным полям. Если таблица огромная (какой-нить регистр накопления) и нет возможности наложить условия последовательно по измерения, нужно согласно стандартов разработки разбить запрос на 2.

в моей практике масса примеров, где индексирование ускоряло процесс существенно. + автор не описал потребность в создании индексов для временных таблиц. Это в определенных ситуациях также в разы ускоряет.
Артано; +1 1 Ответить
32. buganov 200 18.05.21 07:39 Сейчас в теме
(14)
Вот Вы утверждаете, что зло, при этом, видимо, не совсем понимаете, как работает подзапрос и как временная таблица, в чем между ними разница. Запомните, что стандарты разработки часто перестают работать на больших данных.
4. Можно пруфы, сэр? Ну вот элементарно хотя бы планы запросов до и после индексирования.
37. biimmap 1827 18.05.21 08:55 Сейчас в теме
(32) Давай приведу примеры сер.
1. Работал в 1С в отделе разработки ЕРП. Выполнял задачу связанную частично с зарплатой, частично с казначейством. Точнее учет НДФЛ удержанного при выплате зарплаты. Не вспомню конкретный документ, где поставлен был индекс у реквизита ТЧ. Но по этому документу в 4-х местах были написаны запросы с отбором по реквизиту ТЧ. Этот документ был из подсистемы БЗКР (надеюсь знаешь что это). Так вот когда нагенерил млн документов у меня все эти запросы падать начали. Документы по 5-7 секунд проводились при нормативе 2 секунды. После индексации реквизита все показатели уложились в норматив, даже запас остался! Т.е. производительность запросов при больших объёмах данных возросла многократно.
2. Теперь про индексы во временных таблицах. Для крупного агрохолдинга писал конструктор выгрузки данных из ЗУП в Excel. Получается очень много данных и они потом перекрестно ещё используются в запросах. Т.е. кадровые данные и ШР используется дальше во всех запросах. Сначала я забил на индексы, делал функциональность, работал на результат. Когда его получил, то обратил внимание что всё получение данных занимает 5 минут (+ ещё вывод в Excel). Так вот грамотно расставив индексы во временных таблицах, сократил время получения данных до 2-х минут!

ляпунть то конечно можно что кто-то непонимает... сложнее признать собственные пробелы в знаниях. Успехов
45. buganov 200 18.05.21 10:43 Сейчас в теме
(37)
После индексации реквизита все показатели уложились в норматив, даже запас остался! Т.е. производительность запросов при больших объёмах данных возросла многократно.

Индексации реквизита, как объекта метаданных? Так я про это и не спорил даже. Индексы часто приводят к улучшению плана запроса.
По поводу п.2. Я писал, что в очень небольшом проценте индексы сыграют роль. Но Вы просто натыкали индексов не разбираясь, что там внутри. По крайней мере так написано. Ни тебе планов запроса, ни их анализ, ни анализ структуры данных. То есть очевидно, что банально сработал метод тыка. И я не сказал, что индексы ВТ всегда не работают. Работают, но очень редко. Если удалось, что ж, не стоит под одну гребенку крыть одной крышкой.


(37)
сложнее признать собственные пробелы в знаниях

Пробелы я регулярно восполняю, а Вам советую отличные видеокурсы Виктора Богачева. Там восполните уже свои.

П.С. Очень странно читать такое от человека, который работал в 1С над флагманской конфой. Я думал туда только экспертов и берут.

КонецСрача

Успехов
49. Артано 760 18.05.21 11:01 Сейчас в теме
(45)
КонецСрача

Успехов


Неправильно!!!

Вот так должно быть
Dentaky; buganov; biimmap; +3 Ответить
54. buganov 200 18.05.21 11:20 Сейчас в теме
(49)Неправильно)
Вот так должно быть.

КонецСрача;
ПожелатьУспехов(Артано);
52. biimmap 1827 18.05.21 11:11 Сейчас в теме
(45) мне тема с планами запросов не совсем интересна. эта компетенция называется Эксперт по тех. вопросам. я ей владею частично, но той части которой нет, она мне собственно и не требуется в работе.

ведь изучение информации новой должно находить применение и приносить пользу. существенной пользы от этого не будет. стараюсь писать код вдумчиво и соблюдать стандарты (собственно в 1с то научили)

собственно с моей стороны срача и не было))) просто ответил в твоём стиле)))

В 1С берут людей с опытом проектирования интересных решений. Качество кода подымают на месте уже) У них код ревью очень жесткий. А остаются там те, кто готов делать то что ему скажут. у меня такая компетенция отсутствует))) Поэтому ушел довольно быстро.

Тебе тож успехов)
53. buganov 200 18.05.21 11:18 Сейчас в теме
(52)
мне тема с планами запросов не совсем интересна. эта компетенция называется Эксперт по тех. вопросам. я ей владею частично

Очень зря. Помогает понять, а самое главное, с опытом предугадать, как поведет себя запрос с теми или иными данными. Согласен, что каждая база индивидуальна и на небольших, до 500Гб, может и не требовать такого погружения.
Кстати, что интересно, на курсах по оптимизации и от 1С и от курсов-1с-рф, где рассматриваются именно большие таблицы, прямо говорят, что стандарты могут перестать работать, они рассчитаны на массового пользователя, и поэтому пока процент баз больше террабайта условного мизерный, стандарты будут действительны)
17. Артано 760 18.05.21 03:00 Сейчас в теме
(12) Поддержу коллегу в (14). "Отлично раскрывает скобки" когда там записей горстка и/или статистики максимально актуальны. Стоит статистикам чуть-чуть протухнунуть и привет, падение производительности в десятки раз.
33. buganov 200 18.05.21 07:41 Сейчас в теме
(17) По такой логике нужно ориентироваться на беспризорные базы? Не видел ни одну большую(>500Гб) базе и без элементарного админа, который настраивает СУБД, статистики и т.п. Да это же элементарно регламентами делается
38. Артано 760 18.05.21 09:03 Сейчас в теме
(33)
По такой логике нужно ориентироваться на беспризорные базы? Не видел ни одну большую(>500Гб) базе и без элементарного админа, который настраивает СУБД, статистики и т.п. Да это же элементарно регламентами делается


Чуткое слежние за статистиками и их тонкое обслуживание посреди рабочего дня требует достаточно квалифицированных админов. Таких людей гораздо меньше, чем одинесников, которым можно дать простую инструкцию. К тому же сам факт апдейта статистик через, само по себе даёт неплохую нагрузку на базу.
29. Shining_ninja 2155 18.05.21 06:41 Сейчас в теме
(12)
Разве реквизиты не создаются в обработчике ПриСозданииНаСервере?


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

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


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


При написании запросов желательно
- Использовать пакетные запросы и временные таблицы вместо вложенных запросов.

- Для объединения нескольких таблиц используйте объединить, а не левое соединение.

- Для отладки сложных запросов используйте дамп запроса.

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


Сверху писал, за основу взят стандарт 1С и соответственно данные пункты взяты с ИТС:
15. rabid_otter 134 18.05.21 00:05 Сейчас в теме
Разделить выполнение и выборку/выгрузку результата запроса.


Зачем сохранять Результат запроса, если он не будет использован? Разве что удобнее его в отладчике дергать вместо Запрос.Выполнить()

Новые объекты должны быть включены в специальную подсистему «ДобавленныеОбъекты» и на них должны быть даны права.

Если подсистем несколько?

Не использовать проверку на тип «булево», через ИСТИНА или ЛОЖЬ.


Если придет не Булево, или Null или неопределено или битая ссылка? Динамическая типизация и все такое.

Префикс_ДобавленныеОбъекты


Выглядит не очень, потом вся конфигурация в Вася_подсистема1, Петя_подсистема2. Видели, знаем.
Что за непонятная тяга к префиксам? Зачем вам подсистемы - разве что реквизиты туда не запихать.

Фиксировать по возможности все важные события в журнал регистрации (например: отправка почты (кому и во сколько ушло письмо); обмены с другими системами (во сколько и какие объекты отравлены/загружены) и т.д.).


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

Использовать пакетные запросы и временные таблицы вместо вложенных запросов.

Это на маленьких таблицах, а если в таблице 60 млн записей, сколько потратится времени на помещение этих записей во временную таблицу? На моей практике как раз использование вложенных таблиц дало 5кратный прирост скорости на большой таблице.

Для объединения нескольких таблиц используйте объединить, а не левое соединение.


Это еще почему?

Пункты, которые следовало бы добавить:
Количество параметров в функциях - не передавать миллионы параметров?
Размеры функций - чтобы функция влезала на экран.
Близость переменных от места использования к месту объявления - чем дальше, тем больше вероятность ошибки.
Связность функций в общих модулях - чтобы один модуль (вы же тут про ООП заговорили) знал поменьше о других модулях?
Использование общего кода форм в клиентских модулях, чтобы текст модуля не перетаскивался постоянно с сервера на клиент и обратно при передаче контекста.
Кэширование постоянно используемых значений в реквизитах на форме, и т. д.
rusmil; zqzq; +2 Ответить
18. Артано 760 18.05.21 03:17 Сейчас в теме
(15)
Зачем сохранять Результат запроса, если он не будет использован? Разве что удобнее его в отладчике дергать вместо Запрос.Выполнить()


Разработка через отладчик vs разработка через тестирование/чтение логов хороший триггер для отличения кодеров с туннельным синдромом от программистов.

Если придет не Булево, или Null или неопределено или битая ссылка? Динамическая типизация и все такое.

Проблемы того, кто передал это значение. Есть же спецификация, что должно приходить булево. А не зная контекста невозможно понять, понять лень разработчика или исключительная ситуация передала Null вместо Ложь.

Выглядит не очень, потом вся конфигурация в Вася_подсистема1, Петя_подсистема2. Видели, знаем.
Что за непонятная тяга к префиксам? Зачем вам подсистемы - разве что реквизиты туда не запихать.


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


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

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

Это на маленьких таблицах, а если в таблице 60 млн записей, сколько потратится времени на помещение этих записей во временную таблицу? На моей практике как раз использование вложенных таблиц дало 5кратный прирост скорости на большой таблице.

Если в таблице 60 миллионов записей, то только неопытный разработчик будет её без предварительной фильтрации куда-то помещать. Скорость работы вложенных запросов зависит здесь от актуальности статистик. Которые, что характерно, могут протухнуть по мнению оптимизатора SQL и просто по таймауту. Так что ваш "5кратный прирост скорости" может легко обратиться в 20кратное падение в пределах одного дня. Надо же оценивать объём работ, а не полагаться только на тестирование "здесь и сейчас", без понимания почему тест пройден/не пройден.

Это еще почему?

Наверное потому, что левое соединение позволяет "склеить" записи разных таблиц по некоторым условиям. А объединение это именно объединение таблиц путём добавления записей в новую общую таблицу. В некоторых частных случаях или путем извращений можно, конечно и левым соединением воспользоваться, но читается такой запрос труднее.


По остальным замечаниям согласен.
16. Артано 760 18.05.21 02:53 Сейчас в теме
Фундаментально, но мне кажется, вы не знаете, что такое Ревью кода. Вы совершенно игнорируете средства статического анализа кода и возлагаете на плечи ревьювера огромный труд. Я обычно критикую автоматизиторов за то, что они излишне полагаются на средства автоматической проверки кода и сичтают, что они не создадут в результате монстра. Но Вы бросились в противопожную крайность.

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

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

P.S. Посмотрел примеры после прочтения комментариев. По части замечаний согласен, есть спорные рекомендации. За префиксы предусмотрен отдельный котёл в аду. Но это вопрос спорный по факту. Многие из рекомендуют, но моё ИМХО таково.
rabid_otter; a_a_burlakov; +2 Ответить
30. Shining_ninja 2155 18.05.21 06:44 Сейчас в теме
(16)
аний согласен, есть спорные рекомендации. За префиксы предусмотрен отдельный котёл в аду. Но это вопрос спорный по факту. Многие из рекомендуют, но моё ИМХО таково.


Спасибо за комментарий, префиксы нам помогают отделить свои доработки от типовых и помогают при обновлении.

Опять же данный чек-лист еще нужно рассматривать, как прокачка программистов, что не дает автоматическая проверка.
39. Артано 760 18.05.21 09:05 Сейчас в теме
(30) посмотрите в сторону суффиксов. Суть не меняется, простота использования повышается.
FatPanzer; zqzq; +2 Ответить
73. Baronello 1 20.05.21 16:49 Сейчас в теме
(30)
префиксы нам помогают отделить свои доработки от типовых

Не надо в типовую пихать свои доработки, юзайте расширения. Все остальное должно быть по алфавиту.
75. Артано 760 21.05.21 04:44 Сейчас в теме
(73) Расширения поддерживать сложнее на данном этапе их развития. Даже с &ИзменениеИКонтроль
Если объём доработок большой, да еще и новые таблицы добавляются, то расширения становятся и вовсе неудобными.
76. Baronello 1 21.05.21 11:05 Сейчас в теме
(75)
Расширения поддерживать сложнее на данном этапе их развития.


А кто говорил что будет легко? Зато коллеги которые после вас придут, не будут думать что вы осел.
И я не понимаю в чем сложность, формы надо программно обновлять типовые, тогда не будут слетать при обновах. А код в любом случае при обновлениях проверять и при объединении это делать как раз таки сложнее.


(75)
да еще и новые таблицы добавляются


???


В расширениях не хватает только констант (но вместо них в любом случае лучше юзать ПВХ или регистр с настройками) и общих типов. Всё остальное уже замечательно работает, плюс расширения позволяют модульно использовать разный функционал в разных точках.
20. Артано 760 18.05.21 03:32 Сейчас в теме
P.P.S. Прочитал предыдущую статью "Кейс по внедрению Ревью кода". Статья отличная. По тексту статьи Вы описываете внедрение системы обеспечения качества, причем "под ключ" без дураков. Но называете это всё ревью кода. Будьте точнее в терминологии, пожалуйста. Иначе вводите в заблуждение и себя и коллег.
31. Shining_ninja 2155 18.05.21 06:45 Сейчас в теме
(20)
Кейс по внедрению Ревью кода". Статья отличная. По тексту статьи Вы описываете внедрение системы обеспечения качества, причем "под ключ" без дураков. Но называете это всё ревью кода. Будьте точнее в терминологии, пожалуйста. Иначе вводите в заблуждение и себя и коллег.


Спасибо учту.
21. Shining_ninja 2155 18.05.21 06:07 Сейчас в теме
(15)

Зачем сохранять Результат запроса, если он не будет использован? Разве что удобнее его в отладчике дергать вместо Запрос.Выполнить()


Спорный момент конечно, но я лично смотрел типовые конфигурации и там в основном разделяют эти процедуры.

Это удобно - для отладки (немного) и в основном выполнение и выборка/выгрузка находятся в разных процедурах (используется менеджервременныхтаблиц).

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

Если подсистем несколько?


Системы может быть несколько и если в Ваших системах, только добавленные элементы, то все норм.

Если в Ваших системах есть и типовые объекты, то это уже не подходит.

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

Если придет не Булево, или Null или неопределено или битая ссылка? Динамическая типизация и все такое.


Здесь конечно нужно смотреть конкретно по задачи.

Если Реквизит, типа - Булево, то другие значения мало вероятно могут прийти.

А так можно использовать - ЗначениеЗаполнено.

Выглядит не очень, потом вся конфигурация в Вася_подсистема1, Петя_подсистема2. Видели, знаем.
Что за непонятная тяга к префиксам? Зачем вам подсистемы - разве что реквизиты туда не запихать.


У нас все лаконично, максимум 2-3 подсистемы, одна на добавленные объекты, остальные на бизнес-задачи.

Тэги и префиксы очень помогают найти в конфигурации добавленные объекты и код.

В комментарии описываем все доработки, согласно стандарту.

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


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

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


Это на маленьких таблицах, а если в таблице 60 млн записей, сколько потратится времени на помещение этих записей во временную таблицу? На моей практике как раз использование вложенных таблиц дало 5кратный прирост скорости на большой таблице.


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

ИТС подтверждает ваши слова: https://its.1c.ru/db/v8std#content:777:hdoc


Это еще почему?


Это согласно инструкции ИТС: https://its.1c.ru/db/v8std#content:434:hdoc (при объединении таблиц нужно использовать ОБЪЕДИНИТЬ).

За основу мы брали стандарт 1С.

Пункты, которые следовало бы добавить:
Количество параметров в функциях - не передавать миллионы параметров?
Размеры функций - чтобы функция влезала на экран.
Близость переменных от места использования к месту объявления - чем дальше, тем больше вероятность ошибки.
Связность функций в общих модулях - чтобы один модуль (вы же тут про ООП заговорили) знал поменьше о других модулях?
Использование общего кода форм в клиентских модулях, чтобы текст модуля не перетаскивался постоянно с сервера на клиент и обратно при передаче контекста.
Кэширование постоянно используемых значений в реквизитах на форме, и т. д.


Спасибо за информацию, у нас также постепенно совершенствуется чек-листы и мы уже задействовали автоматические проверки, так что развитие идет.
34. buganov 200 18.05.21 07:48 Сейчас в теме
(21) С того же ИТС
Использование временных таблиц
#std777
Область применения: управляемое приложение, мобильное приложение, обычное приложение.

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

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

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

2.3. Не следует помещать во временную таблицу поля, которые не используются в последующих запросах, т.к. время и место для их размещения тратится впустую.

2.4. Не следует создавать и удалять временные таблицы в цикле, если можно создать одну временную таблицу до выполнения цикла.

2.5. Не следует копировать одну временную таблицу в другую только ради того, чтобы переименовать первую таблицу во вторую. Вместо этого, следует передавать имя таблицы.

А вот теперь представьте анализ продаж за период. Или анализ остатков крупной сети. Или много еще каких примеров в организациях с высокой интенсивностью введения данных и гигантскими, в десятки и сотни гигабайт, таблицами. И Вы вместе с Артано предлагаете всю эту простыню положить во временное хранилище, а еще потом создать индекс, а уже потом соединять. Как это называть?
40. Shining_ninja 2155 18.05.21 09:07 Сейчас в теме
(34)
Все индивидуально, если стандарт по нему пишут и всегда есть исключения, которые нужно обосновать.
41. Артано 760 18.05.21 09:08 Сейчас в теме
(34)
А вот теперь представьте анализ продаж за период. Или анализ остатков крупной сети. Или много еще каких примеров в организациях с высокой интенсивностью введения данных и гигантскими, в десятки и сотни гигабайт, таблицами. И Вы вместе с Артано предлагаете всю эту простыню положить во временное хранилище, а еще потом создать индекс, а уже потом соединять. Как это называть?


А зачем анализ продаж складывать во временную таблицу? Я такое даже в своём замечании не предлагал, напротив, указывал на недопустимость помещения нефильтрованных данных в ВТ.
Скажите задачу и обсудим на конкретном примере
48. buganov 200 18.05.21 10:58 Сейчас в теме
(41) Проблема в том, что данные фильтруются, но их все-равно огромное количество. 600 магазинов, 10К позиций, что даже по одной записи даст 6 миллионов. А записей, ясно, гораздо больше. Бывают случаи, когда использование ВТ приведет к деградации производительности всей системы в целом. tempdb хоть и резиновая, но ограничена сверху, как и ее журнал транзакций, переполнение которого приведет к остановке системы, что недопустимо.
Отмечу, что ВТ не зло, точнее это инструмент, который в правильных руках повышает скорость выборки, но в плохих может и систему положить. Про подзапрос то же самое. И любой более-менее сложный и объемный запрос я лично стараюсь проверить не только на малой выборке, но и взять реальную, если подразумевается работа с большими таблицами. И, анализируя план запроса, уже прихожу к решению, что мне использовать.
51. Артано 760 18.05.21 11:02 Сейчас в теме
(48) Наверное я не знаю кейс, где может потребоваться засунуть 6 лямов записей в одну ВТ. Если расскажете пример, можем поговорить предметно
46. SkrAn 1 18.05.21 10:48 Сейчас в теме
>>разделять выполнение и выборку/выгрузку результата запроса
А в чем разница то?
Чем не устраивает Выполнить().Выбрать() ? если мне нужна выборка 1 раз и больше результат не нужен?
57. Артано 760 18.05.21 14:06 Сейчас в теме
(46) Если не ошибаюсь, то писали и в статье и в комментах уже - пункт взят из стандартов 1с.

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

Подобные и некоторые другие вопросы я рассматривал в своих статьях как раз со стороны "почему это правильно, а это неправильно". Возможно, станет понятнее и позиция автора и позиция фирмы 1с
50. пользователь 18.05.21 11:02
Сообщение было скрыто модератором.
...
58. Darklight 32 18.05.21 16:12 Сейчас в теме
Почему все рекомендуют добавлять префиксы слева от идентификатора. Вот в первых типовых решениях на 1С Предприятие 8, и их расширениях (тогда это ещё не было видом конфигурации ибо платформа была 8.0) были префиксы перед идентификаторами – было ужасно неудобно (особенно при поиске по первым буквам – строки фильтра в дереве метаданных ещё не было, и в быстрой подсказке); и от этого отказались. Теперь опять советуют префиксы слева от идентификатора. Жесть. Не…. ну я понимаю, что платформа тут очень ущербна и что-бы не нарваться на дубли имён при очередном апдейте (в т.ч. с расширениями) и для повышения понимания того «кем добавлен» и к чему относится тот или иной идентификатор нужно как-то разграничивать пространства имён идентификаторов (за неимением в платформе более продвинутых механизмов) – но почему тогда не ставить эти присловутые префиксы как суффиксы (окончания) СПРАВА от идентификатора «МойРеквизит_МойПрефикс» - так они не будут никому мешать, названия реквизитов будут лаконичны, легко набираемы, легко читаемы (особенно когда идентификатор длинный, а префикс «ещё длиннее»).
Я, вот, ставлю, префиксы справа – и очень доволен (насколько можно быть тут довольным в ущербной платформе 1С Предприятие 8)! Но да - «1С Совместимо» такая конфигурация вряд ли пройдёт (хот я считаю «1С Совместимо» весьма корявым стандартом, но он хоть какой-то стандарт, в 1С среде стандартов мало…. Хе… кто бы жаловался на то что стандартов мало, а не наоборот – слишком много).
Кстати, говоря, если присмотреться, то типовые конфигурации от 1С используют префиксы-суфиксы и именно СПРАВА:

Примеры префиксов:



«Дублирование кода (ООП): Общие процедуры и функции нужно выносить в общие модули» - рекомендация отчасти противоречит заголовку. Ущербная платформа 1С Предприятие 8 – не совсем ООП – вернее почти совсем не ООП для тех, кто в ней парограммирует. Но – этот ООП отчасти можно эмулировать – как раз используя обработки – как псевдо-объекты. Тогда – как раз можно было собирать общие алгоритмы в таких обхектах-обработках создавать их, передавать их и вызхывать их методы – простите – функции и процедуры. Но… модуль объектов как и модуль менеджера не доступен на клиенте (ущербная платформа), хотя для клиента можно использовать форм(у)ы обработки. И это, относительно удобно – хотя мало разработок этим пользуется (хотя, вот, есть Инструменты разработчика от Tormozit). Место ООП такие объекты можно воспринимать как библиотеки. Хотя, т.к. нельзя эффективно управлять директивами препроцессора – то это решение имеет много минусов, по сравнению с общими модулями, хотя у кого их больше – это ещё вопрос – в неуправляемом приложении уж точно.
А размещение алгоритмах в обработках позволяет легко создавать локальный контекст «библиотеку» - называем обработки длинными уникальными именами (чтобы во всех конфигурациях и расширениях они не пересекались) и пишем специальную функцию – которая по имени контекста будет создавать и наполнять структуру объектами таких обработок с унифицированными именами (если в составе общей конфигурации есть повторяющиеся унифицированные имена обработок – то просто выбираем одну из них (по старшинству версии; стратегия MIXIN тут не получится – хотя при должной сноровки и её можно было бы эмулировать) – далее либо используем экземпляр такой структуры локально – либо присваиваем глобальной переменной (увы – только в клиентском контексте (для упр. приложения нужно создавть экземпляры форм); на сервере можно было бы запихнуть в параметры сеанса – если было бы можно – хотя можно во временное хранилище – но лучше просто обойтись функцией в модуле повторного использования – а там уже задейстовать и параметры сеанса и временное хранилище). Таким макаром можно и более-менее полноценную иерархию пространств имён получить (с вложенными модулями). Справедливости ради, замечу, что эта стратегия работает и с общими модулями – но ими управлять куда менее удобно и менее универсально! А орбработки бывают ещё и внешними – что открывает коллосальные возможности к динамическому программированию.
Не «1С Совместимо»!


Говоря о функции «ЗначенияРеквизитаОбъекта» стоило бы упомянуть и функцию «ЗначенияРеквизитовОбъекта» - потому что редко, когда нужно взять только один реквизит. А заодно и другие функции получения значений реквизитов объектов.


Использовать «Выразить» для реквизитов составного типа в запросах – это палка о двух концах. С одной стороны – да нужно стараться использоваться (особенно при работе с субконто и характеристиками). А, вот, приведённый пример «ВЫРАЗИТЬ(УчетНоменклатуры.Регистратор КАК Документ.РасходнаяНакладна).Номер» очень спорный – т.к. в данном случае как раз обычно нужны номера любых документов, зарегистрировавших запись. И что делать – если (а так обычно и бывает) нужно более 1-го вида регистратора регистратор? Но бывают, конечно исключения – и вот... программисту лень городить сложные конструкции с оператором «ВЫБРАТЬ КОГДА ТОГДА» и «ВЫРАЗИТЬ», тяня туда десятки видов документов. А если нагородит – то потом появляется новый вид документа (например, подключится расширение) и…. БАА!.. запрос уже не работает корректно (работает без ошибок, но некорректные результаты выдаёт)! Пойди найди все такие запросы, чтобы внести в них правки! Налицо очередная ущербность платформы и неудачная рекомендация!
Не говоря уже о том, что одно лишь «ВЫРАЗИТЬ» без фильтра «ГДЕ ВЫРАЗИТЬ(ТоварыНаСкладах.Регистратор Ссылка Документ.ПоступлениеТоваровУслуг)» никакого особого выигрыша в производительности (и уж тем более в корректности результата) не даёт (но защищает от переполнения числа таблиц в итоговом запросе – что может быть чревато для некоторых старых СУБД). А если написать указанный фильтр – то «ВЫРАЗИТЬ» уже можно не писать (если этого не требует логика) – выигрыша в производительности почти не будет (хотя это может только MS SQL умеет так условия проталкивать) – почти все соединения будут пустыми.
Хотя это очередной раз говорит об ущербности платформы – ведь можно было бы не делать соединения с таблицами, если их нет в условии с оператором «Ссылка» (когда его можно однозначно определить). Не говоря уже о том, что все эти фильтры и выражения типа нужно декларировать вне запроса (в дереве метаданных) и лишь применять в запросах – чтобы не выискивать их потом. Сделать это можно было бы вообще круто – введя интерфейсы – и используя их как как типы, да хоть в том же операторе «ВЫРАЗИТЬ» но уже одном – а на выходе будет NULL если интерфейс не поддерживается; или все доступные поля интерфейса (да ещё и, возможно, по-разному реализованные (да хоть имеющие разные имена идентификаторов) в разных источниках, но сведённые к единой мнемонике использования в запросе; а настраивалось бы всё декларативно в конфигурации).


«Использование условий в секции ГДЕ вместо параметров виртуальных таблиц» – это справедливо только для регистров накопления и иже с ними. Применение в регистрах сведений должно быть с осторожностью – т.к. это может повлиять на логику выборки среза.


А чем не угодил метод «Сообщить»? Он вроде бы внутри реализует логику объекта «СообщениеПользователю» (пусть и в урезанном виде).


«Не использовать проверку на тип «булево», через ИСТИНА или ЛОЖЬ» - вот это рекомендация просто убила! Что – и тут 1С Предприятие 8 имеет проблемы? А в друг в переменной будет значение «неопределено» или «null» (это могут быть как легитимные значения, так и не очень – ведь 1С Предприятие 8 – это система с полностью динамической типизацией). Скажите – уж лучше в этом случае ошибку получить? Когда-то да – лучше – но чаще – просто можно считать условие не выполнившимся! Хотя, вот числовые значения 1С приводит неявно к булевым – и ничего – никто не умер (я надеюсь)!


Примера с транзакциями очень неудачные – скорее всего научат как раз плохому коду!


« Правильное решение - это использовать регистр сведений в котором будет четыре измерения: “Аналитика” (составной тип)» - Вот это можно пояснить. Зачем тут 4 измерения аналитики, да ещё и составного типа?

Я использую регистр сведений:



Вот про контроль изменения значений в модулях повторного использования можно подробнее. Ранее уже пробовал городить огород на эту тему – но пока плюнул на это дело – не сталкивался на пактике с большими проблемами с отсудившем такого контроля. Хотя можно завести отдельну константу – дата сброса кеша (и параметре сеанса – с текущей датой сброса кеша) – периодически проверять в каждом сеансе, и если дата в константе станет моложе даты в параметре сеанса – то вызвать функцию «ОбновитьПовторноИспользуемыеЗначения()» (очень неудачное имя идентификатора) – сбросив вообще весь кеш (и обновит параметр сеанса) – соответственно пользоваться этим только при очень большой необходимости.


«Для отладки сложных запросов используйте дамп запроса.» Что это такое?


Странно, что нет ни слова про применение окончаний а-ля "Клиент" "КлиентСервер", "ПовтИсп", "ПолныеПрава", "ВызовСервера".., и суффиксов а-ля "Переопределяемый", "Служебный", "События"...

Хотя, лично я, против такой практики - из-за неё в ERP2 больше сотни общих модулей, и очень сложно разобраться к какому же модулю нужно обращаться. Я перешёл к практике 2-3 префиксов на модуль:
В первом располагается вся логика
Во-втором осуществляется переход на сервер из функции первого модуля (если того требует контекст) и обратный возврат вызова в первый модуль (здесь нет никакой логики - только смена контекста)
В-третьем - кеширование - когда нужно - и вызов опять первого модуля

Всё разделение на контексты доступности реализую директивами препроцессора уже внутри первого общего модуля.
Это очень удобно.
Вообще можно было бы обойтись одним первым общим модулем (особенно если бы платофрма 1С Предприятие не была такой ущербной и позволила бы применять аннотации контекста (как в управляемых формах) внутри общих модулей (в т.ч. для смены контекста вызова). Или можно просто сделать два ЕДИНЫХ общих модуля для смены контекста и производить его смену через функцию "вычислить" (все вызываемые методы должны быть функциями - впрочем я всегда так стараюсь делать) - увы - не будет работать на iOS - а ссылок на функции в 1С Предприятие 8 не завезли (и это в процедурном то языке программирования). Хотя можно частично выкрутиться через "ОписаниеОповещения" (увы - только на клиенте - хотя нужно это только для iOS).
Тогда смену контекста можно производить через общие прокси функции, вызывающие нужные функции по строковому пути - на производительности это не сильно сказывается
mikukrnet; Артано; +2 Ответить
60. Артано 760 19.05.21 06:47 Сейчас в теме
(58) Подписываюсь почти под всем.
Из "громких" есть замечание по поводу "как сделать ООП в 1с". Здесь главное без фанатизма и не городить костыли, просто так чтобы было ООП. Вполне достаточно ориентироваться на общую ООП-парадигму используя те её методы, которые можно без существенных костылей внедрить в процесс разработки, особенно коллективной.
65. Darklight 32 19.05.21 09:56 Сейчас в теме
(60)Я не предлагал делать ООП в 1С. Я просто описал некий паттерн (не мной придуманный, хотя, возможно я внёс в его формирование некие новые идеи) иной компоновки API общих (и частных) алгоритмов, где во главу угла ставятся обработки, а не общие модули (можно и общие модули, можно и комбинировать). И всё. Никакого полиморфизма и наследования; ограниченная инкапсуляция. Это скорее развитие идеи процедурного программирования (нужны только делегаты-ссылки на функции - но, как показал в комментарии, это тоже отчасти реализуемо) - то есть это больше динамический или статический библиотечный подход, чем ООП. Вероятно зря вообще упомянул ООП, не в нём суть.

Говоря же об интерфейсах (которые обычно относят к ООП) я не касался ООП - и предлагал их гипотетическое использование в контексте запросов (либо платформа должна развиться для их поддержки, либо, в контексте их представления в моём комментарии, можно внедрить свой прокси-движок для выполнения запросов с их препроцессорном перед выполнением - чтобы обработать эти интерфейсы, немного кустарно хранящиеся в метаданных или даже в данных ИБ). То есть, в этом смысле - Интерфейс - это просто описание контракта - на основании которого при его применении происходит автогенерация дополнительного кода (в данном случае конструкций "ВЫБОР... ВЫРАЗИТЬ"), и программисту, применившему приведение типа к интерфейсу, не нужно думать о том, что там за код генерируется и на основании каких данных-настроек этого интерфейса. Вернее думать надо , но только о том, что если применяешь интерфейс, то нужно следить за его актуальностью - но это уже, скорее вопрос к процессу доработки конфигурации , её расширению и обновлению - вот в этих процессах нужно следить за актуальностью имеющихся интерфейсов. Особенно, когда в платформе нет встроенной продвинутой поддержки этих процессов для интерфейсов (а ведь не сложно было бы сделать).

P.S.
Относительный нормальный ООП в 1С кустарно построить можно - но только если сделать свой расширенный компилятор в байт-код платформы. Это вполне возможно.... но вряд ли кто-то будет делать (хотя бы по той причине, что в 1С Предприятие 8 очень ограничены возможности по внедрению в конфигурацию скомпилированного байт-кода, а жаль).
69. Darklight 32 19.05.21 19:32 Сейчас в теме
(58)Сейчас проводил тесты разных запросов к регистру сведений. Был удивлён На выборке среза последних величиной в ~100M строк (без фильтров) запрос (с несколькими обращениями к одному и тому же срезу) с вложенными друг в друга внутренними соединениями (без временных таблиц; с итоговой выборкой около 100K строк) отработал всего за 70-80 сек (разброс от нескольких запусков). Вто время ка все варианты с временной таблице (куда помещался исходный срез) отрабатывал за 300-400 сек, примерно столько же заняли и разные варианты с вложениями через оператор "В()". А вот несколько последовательных-одноуровневых (не вложенных друг друга) внутренних соединений выполнялись 2000-2500 сек!
С включёнными итогами на срез последних выполнение почти всех вариантов сводилось к нескольким десяткам секунд (но было исключение с одним из запросов с оператором "В()" - который выполнялся около 100 сек).
Наличие/отсутcnвие индексов на временной таблице на результат почти не влияло (индекс был у другой таблице, к которой присоединялась обработанная выборка и регистра).
Та что, использование временных таблиц для регистра сведений перед его обработкой - не всегда однозначно прирост производительности, относительно прямого обращения к срезу (даже несколько раз во вложенных запросах) - а запросы с большим числом вложений были производительнее более "плоских".
СУБД MS SQL Server 13.0
70. Артано 760 20.05.21 06:29 Сейчас в теме
(69) А чему тут удивляться, вы программно создали огромную таблицу и ждете, что эти накладные расходы на быстродействии не скажутся =)
72. Darklight 32 20.05.21 10:24 Сейчас в теме
(70)Я просто говорю, что для разных задач эффективными могут совершенно разные подходы. И применение временных таблиц тут не является однозначно лучшим решением
86. triviumfan 92 24.05.21 19:03 Сейчас в теме
(58)
Почему все рекомендуют добавлять префиксы слева от идентификатора.

Потому что это удобно, плюс где-то было в стандартах, лень искать.
Мало того, что префикс должен быть в начале, так ещё и в синониме он тоже должен фигурировать, чтобы в интерфейсе было понятно, где типовой реквизит, а где твой добавленный.
87. Darklight 32 24.05.21 20:37 Сейчас в теме
(86)Стандарты стандартами. Но я задался вопросом почему именно так? Почему это удобно? Я не возражаю против префикса. Я возражаю, что его ставят слева. Я своё обоснование того, что префикс эффективнее ставить справа, привёл, и подкрепил примерами, где с моей точки зрения, в типовых конфигурациях префикс находится именно справа. Что не так в моих рассуждениях?
Про префикс в синониме не возражал. И да, тоже считаю, что он должен быть - и именно справа я его там ставлю - отдельным словом в скобках - чтобы не мешал восприятию основного наименования сущности (но только не для реквизитов и табличных частей, чтобы не мешал автоотображению заголовка на форме).

А в общем, такая префиксация - от лукавого - т.е. от ущербности платформы. В идеале, задачи дублирования имён и определения принадлежности к проекту должны решаться иначе - но это уже не 1С Предприятие 8 (по крайней мере в типовом исполнении редактора конфигурации)
88. triviumfan 92 25.05.21 00:31 Сейчас в теме
(87)
в типовых конфигурациях префикс находится именно справа

В каких типовых?) Твои примеры это не префикс, а аббревиатура названия модуля, в который вложена смысловая нагрузка.
Открой любую отраслевую конфу на основе типовой или БСП и ты увидишь, где стоят префиксы для новых объектов метаданных :)
89. Darklight 32 25.05.21 10:08 Сейчас в теме
(88)Отраслевые конфигурации следуют стандарту 1С - чтобы получить заветное "1С Совместимо" - это - как: "мы вам дадим пропуск на рынок, но вы должны ходить в колпаке с колокольчиками" (не объясняя зачем) - вот и ходят - пропуск то им важнее.

А в приведённых мной примерах данные аббревиатуры являются не чем иным как префиксами (или по-русски - окончаниями, или как ещё называют - суффиксами, что в данном случае морфологии русского языка будет вернее, как вот тут "ИнтеграцияИСМПВызовСервера" суффиксом будет "ИСМП", а окончанием "ВызовСервера", хотя как выше приводил в типовых бывает и такое "ОбщегоНазначенияMicrosoftExcelКлиентСерверУХ" - тут "УХ" окончание, а "КлиентСервер" - суффикс, а ещё есть "MicrosoftExcel" - тоже суффикс; но уже как-то привычно сложилось, чтобы не разбираться в тонкостях морфологии русского языка, все это называют префиксом). Так вот, в этих примерах префиксы расположены справа - и не важно, как они образованы - автором (владельцем) данных объектов метаданных, или названием модулей. Стилистически - эти префиксы расположены справа. А как будет выглядеть - будь они слева - я уже показал - на мой взгляд выглядит ужасно (а в использовании ещё ужаснее чем выглядит).

Можно конечно, привести убийственный контр пример - что когда делаешь расширение конфигурации - то платформа ЯВНО ставит префикс ВСЕГДА СЛЕВА - т.е. соблюдает стандарт 1С - и это ужасно - сердце кровью обливается кода я вижу понатыканные префиксы слева. Вот хочешь обратиться к объекту метаданных - знаешь его бизнес- имя - ан-нет - сначала набери префикс - а потом уже вводи имя - быстрые подсказки или поиск превращаются в муку! Как и в муку превращает их просмотр в списке - когда четверть отображаемого имени - это префикс - а затем ещё четверть реального имени умещается в списке - а остальная часть просто не влезает в ширину списка.

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

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

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

Например, для решения проблемы принадлежности - можно было бы просто ввести в конфигурацию доп вид метаданных - "Разработчик" (а заодно и "Вендор"("Издатель") и "Автор" - соответственно выше и ниже по иерархии относительно Разработчика) - и присваивать их всем объектам метаданных любого уровня вложенности (по умолчанию наследуются из свойств корня текущего модуля-метаданных, или из свойств пользователя, или просто выбираются вручную в настройках на время сессии или сохраняются в локальном профиле на компьютере для конфигурации или иным путём). А далее - можно было бы по ним фильтровать, группировать метаданные или просто выводить сбоку (на выбор слева или справа) в представлениях метаданных или в отдельной колонке.

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

Ну а флаги разграничения видимости/доступа ещё больше снижают вероятности таких конфликтов.

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

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

Этим я хотел сказать - что префиксы (особенно слева) - это очень не красиво и очень ущербно - есть куда более красивые и надёжные решения (не претендуя на то, что всё что мной сказано - это лучшее из всех возможных решений - просто привёл своё мнение). И задал вопрос - почему префиксы именно слева. Но пока неявно получаю ответ - потому что так "истерически у кого-то зачесалась пятая нога"! Ведь началось всё ещё в 1С Предприятие 8.0 (да и даже в 1С Предприятие 7.7 наверное - просто уже плохо помню те времена, а сами префиксы метаданных тогда были куда менее распространены).
И в чём удобство префиксов именно слева - так никто и не объяснил (кроме - ну так же у всех - хотя и не всех так же). А я объяснил - почему считаю, что префиксы справа - это куда удобнее, чем префиксы слева!

Но если стандарты говорят - что всем нужно ходить строем, а "шаг влево шаг вправо - расстрел", и не объясняют почему строем ходить правильно, чем тоже друг за другом но в вразвалочку - да ну нафиг такие стандарты, даже если за их не соблюдение не дадут баланду - найдём сами что похавать (пока есть такая возможность и всех "строем насильно не выстроили пулемётными очередями")!
90. triviumfan 92 25.05.21 17:40 Сейчас в теме
(89) Много букв, нет времени читать.
Но вот прямо сейчас я снова обновляю сильно доработанную конфу. И если бы вместо префиксов были бы суффиксы - я бы буквально глаза сломал.
Есть функция ИТМ_ЗаполнитьРезервамиПоЗаказуНаСервере. Но если бы она называлась ЗаполнитьРезервамиПоЗаказуНаСервере_ИТМ, то мне пришлось бы тратить время, чтобы прочитать все название процедуры, искать суффикс, а не доработанная ли это функция и нужно ли её оставлять или все же удалять.
Почему тебе так удобнее мне никогда не понять (наверное, ты просто не занимаешься обновлением). А переубеждать бессмысленно - у тебя своя правда.
91. Darklight 32 25.05.21 18:07 Сейчас в теме
(90)Ну вот, хоть какой-то аргумент за левые префиксы. Хотя и слабый аргумент - к счастью, человеческий взгляд так устроен, что может легко читать части текста как слева так и справа - не нужно читать всё название целиком слева на право - если префиксы находятся справа - так и искать глазами (когда это требуется) их нужно справа, а не читать весь идентификатор целиком в поисках префикса. Тут всё удобство/неудобство - дело привычки. В отличие от приведённых мной аргументов.

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

В идеале таких вопросов вообще быть не должно - такие функции не должны явно попадать в общий список сравнения содержимого модулей. А если попадают - то сразу должны быть особым образом выделены (да хоть цветом).

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

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

Всё это только подчёркивает ущербность платформы 1С Предприятие 8 - то что, её архитектура почти не развивается - и действительно полезных фишек в ней почти не появляется
Артано; +1 1 Ответить
93. Артано 760 27.05.21 05:32 Сейчас в теме
(90) Если функции нужен префикс/суффикс, то она должна располагаться в отдельном модуле. В коде вообще этому не место. Тут скорее лень/кривые руки авторов доработки ИТМ.
94. triviumfan 92 27.05.21 18:03 Сейчас в теме
(93)
Если функции нужен префикс/суффикс, то она должна располагаться в отдельном модуле. В коде вообще этому не место.

Может тебе здесь не место?! :) В каком коде?! Каком модуле?!
Делаю обновление -> сравнение/объединение, поставщик конфигурации сильно поменял форму объекта.
Смотрю различия с учетом структуры - там сотня функций. Половина подсвечена красным. Как я должен понять, моя эта функция или поставщика? Удалять её или нет? Для таких глупых/криворуких и имеются стандарты - был бы там префикс, то я бы сразу пропустил её.
Прикрепленные файлы:
95. Артано 760 27.05.21 18:55 Сейчас в теме
(94)
Может тебе здесь не место?! :) В каком коде?! Каком модуле?!
Делаю обновление -> сравнение/объединение, поставщик конфигурации сильно поменял форму объекта.
Смотрю различия с учетом структуры - там сотня функций. Половина подсвечена красным. Как я должен понять, моя эта функция или поставщика? Удалять её или нет? Для таких глупых/криворуких и имеются стандарты - был бы там префикс, то я бы сразу пропустил её.


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

Итак. Если дорабатывается объект поставщика, то делается это через подписки и/или точки входа с вызовом функций из собственных (не поставщика) модулей. Таким образом, означенная в цитате проблема, есть проблема созданная "такими глупыми/криворукими" и героически ими же решаемая. Можете не благодарить.
96. triviumfan 92 27.05.21 19:23 Сейчас в теме
(95) Ты во всех типовых конфигурациях видел точки входа для вызова своих функций? Да откуда вы такие берётесь?!
Да даже речь не про это! Даже если ты добавил команду в своём кривом модуле и вызовешь его ПриСозданииНаСервере(), то сам обработчик команды у тебя без префикса будет - сам говоришь, что префиксу тут не место.
Повторюсь: может тебе все-таки тебе тут не место? После таких вот людей, кто освоил методику доработки объектов поставщика, сопровождать конфигурацию противно. Моя б воля - уволил бы сразу.
97. Артано 760 28.05.21 10:03 Сейчас в теме
(96) Я, к счастью, могу принимать сам решения где мне работать, а где нет, и если бы пришлось работать с тобой (вдруг бы случилось такое чудо), то это бы продлилось недолго, здесь согласен =)

По существу. Зачем обработчику команды префикс не возьму в толк? В типовых есть точки входа, в общем то. Как правило обработчики в новых типовых имеют их. В старых - всё в твоих руках (после выпрямления, хе-хе). Ну если ты агрессивно считаешь, что курочить типовые объекты лучше, чем делать подписки, точки входа там где подписки невозможны, то не вижу смысла разговаривать. Невежество в сочетании с агрессией приводит к драке. Попробуй попить таблетки, чтобы хотя бы на людей не бросаться.
Если же у тебя просто не хватает некоторых знаний, то почитай например у Онянова, там вполне хорошие и структурированные требования по доработке. Некоторые моменты неоднозначные, но в целом всё здраво и обоснованно.
98. triviumfan 92 29.05.21 21:29 Сейчас в теме
(97)
Зачем обработчику команды префикс не возьму в толк?

Тогда снова перечитай (95).
Перечитывай до тех пор, пока не "возьмёшь в толк":)
ЗЫ: И да, если ты не знал (видимо опыта не хватает), то не все формы типовых конфигураций имеют "точки входа".
Артано; +1 Ответить
99. Артано 760 29.05.21 22:24 Сейчас в теме
(98)
Тогда снова перечитай (95).
Перечитывай до тех пор, пока не "возьмёшь в толк":)
ЗЫ: И да, если ты не знал (видимо опыта не хватает), то не все формы типовых конфигураций имеют "точки входа".


Посмеялся. Заскриню, иначе мне никто не поверит.
59. RPGrigorev 692 18.05.21 16:56 Сейчас в теме
Отличная статья, спасибо! Пункт "Использование условий в запросе в секции ГДЕ, вместо параметров виртуальной таблицы." - результат не только отличается скоростью выполнения, более того, он может давать логически разные результаты, при использовании виртуальных таблиц "Срез последних" и т.п.
61. Артано 760 19.05.21 06:48 Сейчас в теме
(59) Разные в случае если отбор в виртуальной таблице не только по измерениям? Ну тогда человек сам себе враг, раз такое пишет. Регистр в виртуальной таблице группируется именно по измерениям.
62. RPGrigorev 692 19.05.21 07:19 Сейчас в теме
63. Артано 760 19.05.21 07:55 Сейчас в теме
(62)
Хотя данные запросы различаются только способом указания отбора, их результаты, в отличие от случая с запросами по регистру накопления, будут различны


Статья из разряда эксперимента "безногий таракан не слышит" =)
Нет бы по-человечески объяснили бы, что группировка идет по измерениям в виртуальной таблице, поэтому только по ним и можно отбирать, если хотите такой же результат как при отборе нефильтрованной таблицы
RPGrigorev; +1 Ответить
64. RPGrigorev 692 19.05.21 08:14 Сейчас в теме
(61) согласен, абсолютно верно подмечено, спасибо
66. ashvik 19.05.21 11:35 Сейчас в теме
67. mikukrnet 181 19.05.21 12:36 Сейчас в теме
"Правильно разделять выполнение и выборку/выгрузку результата запроса"

Объяснитесь, сэр
68. OlegLad67 19.05.21 15:45 Сейчас в теме
Спасибо за статью! Возьму на вооружение.
71. Артано 760 20.05.21 06:35 Сейчас в теме
Начал вдумчиво читать чек-лист, дошел до пункта с рекомендацией про функцию IsNull и вспомнил смешное.

Однажды объяснил парням про составные типы и необходимость использования функции Выразить. В итоге наблюдал такие запросы как во вложении
Прикрепленные файлы:
82. Cyberhawk 135 24.05.21 08:54 Сейчас в теме
(71) А что с этим запросом не так? Как его следовало бы переписать?
83. Артано 760 24.05.21 09:10 Сейчас в теме
(82) В том, что прежде чем проверить условие отбора или соединения необходимо будет вычислить некую функцию. Как следствие нет никакого шанса использовать индексы или иные средства оптимизации запроса. Все записи будут обработаны функцией.

Функции Isnull, Выразить, ТипЗначения заменяются соответствующими операторами Is Null и Ссылка. Приводил в списке типичных ошибок прилагаемых к статье об ошибках. Параграф 2.4
84. Cyberhawk 135 24.05.21 09:16 Сейчас в теме
(83)
В том, что прежде чем проверить условие отбора или соединения необходимо будет вычислить некую функцию ... Все записи будут обработаны функцией
А, ну т.е. идея в том, что ВЫРАЗИТЬ само по себе не делает фильтрацию (по указанному там типу документа), и поэтому нужно было еще и отбор на тип регистратора (в параметры виртуальной таблицы или в ГДЕ добавить), так?
85. Артано 760 24.05.21 19:02 Сейчас в теме
(84) Да. Вообще плохая практика копаться в регистраторах. Но раз уж так спроектирована БД, то хотя бы с наименьшими потерями
Cyberhawk; +1 Ответить
74. van_za 243 20.05.21 17:16 Сейчас в теме
77. Артано 760 21.05.21 17:44 Сейчас в теме
(76)
А кто говорил что будет легко? Зато коллеги которые после вас придут, не будут думать что вы осел.

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

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

Как только такая возможность появится я буду первым, кто поддержит повсеместное использование расширений.
Сейчас же их обоснованная ниша это временные заплатки, до полноценного обновления конфы.
78. Baronello 1 22.05.21 11:29 Сейчас в теме
(77)
Вы можете в любой момент времени дать оценку адекватности и вообще объёму изменений в коде по сравнению с конфигурацией поставщика, в случае если все доработки помещены в расширения?

Эм, сравнить и объединить?
81. Артано 760 24.05.21 02:46 Сейчас в теме
(78)
Эм, сравнить и объединить?


А уже добавили сравнение расширения и конфигураций?
79. alex_sayan 22.05.21 15:36 Сейчас в теме
По-моему за префиксы в именах объектов нужно бить по рукам. В 99% случаев префикс - сорная информация, которая всюду лезет на передний план. Ухудшается работа контекстной подсказки, ухудшается восприятие информации, убивается нормальная сортировка имен. Если очень уж хочется изуродовать имя своего объекта/свойства лишней информацией, то можно использовать постфикс в имени. Это будет хотя бы не так уродливо. Вместо:
ххх_Товар
ххх_Контрагент
ххх_Склад

Писать:
Товар_ххх
Контрагент_ххх
Склад_ххх


а вообще, у всех объектов метаданных и их свойств есть комментарий. Можно в нём увековечить имя автора. Как жаль, что за столько лет существования платформы, прикладные разработчики так и не научились использовать комментарии к метаданным
rabid_otter; Артано; +2 1 Ответить
92. Артано 760 27.05.21 05:29 Сейчас в теме
(79) Интересно, кто влепил минус и не отметился почему. Я с автором комментария согласен, готов выслушать мнение несогласных.
Оставьте свое сообщение