Чек-листы для проведения Code Review
Разработка - Рефакторинг и качество кода
Введение
При внедрении 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
Более подробно описано в отдельном разделе.
Код должен легко читаться, и написан в одном стиле.
Код должен читаться без пояснений и не должен содержать грамматические ошибки.
Доработка не должна противоречить общей архитектуре системы.
Можно решить более простым методом; избыточные соединения в запросе и т.д..
Общие процедуры и функции нужно выносить в общие модули.
Добавлять проверки на данные значения, чтобы избежать красных ошибок.
Например:
Если одна переменная может быть, как объектом, там и структурой.
Избегать обращение через точку. Для объектов использовать стандартные функции БСП: (ОбщегоНазначения.ЗначениеРеквизитаОбъекта и т.д.).
Например:
Не правильно
Правильно:
При левом соединение в запросе, обязательно использовать Isnull.
Например:
Не правильно:
Правильно:
По возможности выносить запросы из цикла.
Например:
Не правильно:
Правильно:
Разыменование ссылочных полей в запросе. Если реквизит в запросе имеет составной тип, то необходимо использовать функцию «Выразить», иначе будет неявные соединения со всеми типами реквизита.
Например:
Не правильно:
Правильно:
Избегать соединения с вложенными запросами. Соединения с виртуальными таблицами «СрезПервых», «СрезПоследних» - по факту являются соединениями с вложенными запросами, кроме случая, когда в свойствах регистра сведения стоит признак «Разрешить итоги СрезПервых», «Разрешить итоги СрезПоследних». Вместо соединения с вложенными запросами, нужно использовать соединения с виртуальными таблицами.
Например:
Не правильно:
Правильно:
Данные пункт значительно влияет на производительность. Необходимо отборы накладывать на параметры виртуальной таблицы, а не в секции ГДЕ запроса.
Например:
Не правильно:
Правильно:
Не выбирать данные в запросе, которые в дальнейшем не будут использоваться.
Например:
Не правильно:
Правильно:
Задействуется больше ресурсов сервера.
Правильно разделять выполнение и выборку/выгрузку результата запроса
Например:
Не правильно:
Правильно:
Данное ограничение накладывается СУБД PostgreSQL. Вместо Полного(Внешнего) соединения, нужно использовать секцию: Объединить.
Например:
Не правильно:
Правильно:
Изучаем БСП, используем уже готовые функции/процедуры БСП.
(например: ОбщегоНазначения.ЗначениеРеквизитаОбъекта; ОбщегоНазначения. ОписаниеТипаЧисло();ОбщегоНазначения.СообщитьПользователю()).
Вместо метода «Сообщить» нужно использовать «СообщитьПользователю».
Нельзя использовать ТекущаяДата() на &Сервере, т.к. она может отличаться от текущий даты сеанса.
Например: обращаемся к серверной процедуре, но не используем «Объект» (использование на &НаСервере вместо &НаСервереБезКонтекста).
Например:
Не правильно:
Правильно:
Инструкции препроцессору: Сервер, ТолстыйКлиентОбычноеПриложение, ВнешнееСоединение и т.д.
Если их не использовать, то можно получить красные ошибки при запуске приложения, например в веб-клиенте.
Например:
Не должно быть закомментированного кода и пустых обработчиков.
Легче читать и группировать код, например область: #Доработки.
Например:
Новые объекты должны быть включены в отдельную новую подсистему и на них должны быть даны права. Это позволяет легче ориентироваться в добавленных объектах.
В таком случае легче проводить обновление. В новых конфигурациях все доработки форм можно выносить в один модуль: СобытияФормИС. ПриСозданииНаСервере, СобытияФормИС. ПриЧтенииНаСервере, СобытияФормИС. ПослеЗаписиНаСервере.
Например:
Не правильно:
Правильно:
Иначе может быть получены неверные данные.
Например:
Не правильно:
Правильно:
Избегать вложенных попыток и транзакций.
Не должна возникать ошибка: В данной транзакции уже происходили ошибки.
Например:
Не правильно:
Правильно:
Например:
Не правильно:
Правильно:
При включении RLS должны работать все запросы.
Для предотвращения потери данных все новые объекты конфигурации, а также добавляемые реквизиты для существующих объектов, создаются в основной конфигурации, это необходимо для того, чтобы при любой нештатной ситуации с расширением данные остались в целости.
Все остальные манипуляции, как редактирование форм, модулей и т.д. выполняются через расширения. Как работать с расширениями можно узнать на сайте ИТС.
Формат комментариев и префиксация новых объектов
Формат комментария должен иметь формат, представленный на рисунке 1:
Рисунок 1 Формат комментариев.
Ниже приведено описание каждого элемента комментария (номер элемента на картинке соответствует номеру, выделенному жирным, в описании ниже). «Пример 1» для проектных работ, «Пример 2» для работ на сопровождении.
// <Тип комментария> <Наименование организации> <ФИО разработчика> (<Дата внесения изменения в формате "dd.MM.yyyy">) <П|С>.<Номер> <Краткое пояснение изменения>
1 <Тип комментария> - указывается символ «+» для комментариев перед изменением, «-» для комментариев после изменения.
2 <Наименование организации> - наименование организации разработчика для его идентификации. Не более десяти символов.
3 <ФИО разработчика> - фамилия и инициалы разработчика, который вносит изменения в код. Формат: «Фамилия И.О.».
4 <Дата внесения изменения в формате "dd.MM.yyyy"> - следует обязательно придерживаться заданного формата даты. Дата изменения указывается в скобках.
5 <П|С> - если изменение вносится в рамках проекта, то следует указывать «П»; если в рамках сопровождения, то следует указывать «С». <Номер доработки в рамках проекта или сопровождения> - порядковый номер доработки, по которому можно однозначно найти постановку задачи по изменению. Для проектных работ .<Префикс проекта>.<Номер раздела | Номер технического задания>.<Номер доработки>. Для задач на сопровождение .<Номер доработки>.
6 <Краткое описание изменения> - необязательное поле. Указывается, если разработчик считает необходимым описать изменение кода. Не более 50 символов.
Создание новых объектов и префиксация
Первое правило – это добавление в конфигурацию объектов верхнего уровня (справочников, документов, регистров и т.д.). В начало наименования объекта нужно добавлять префикс (рисунок 2).
Рисунок 2 Создание нового объекта верхнего уровня.
Это правило заключается в том, что имена объектов обязательно должны начинаться с префикса. Для чего?
- Во-первых, это визуально выделяет добавленный элемент в конфигурации и в коде сразу видно, что это – наш добавленный объект.
- Во-вторых, достигается уникальность имени, потому что поставщик может добавить свой объект с тем же именем. И если мы будем использовать свой префикс, то это гарантирует, что наше имя будет уникально. Синоним указываем без префикса. Синоним не должен значительно отличаться от имени объекта. К примеру, если имя объекта «Префикс_КадроваяИсторияСотрудников», то неверно указывать в качестве синонима «Работники организации».
Второе правило: комментарии ко всем добавленным объектам должны содержать специальную метку с именем разработчика и номером задачи. Эта метка аналогична открывающему комментарию из модуля, только без специальных символов – с ее помощью всегда можно понять, кто, когда и по какой задаче добавил этот объект.
Третье правило: новые объекты должны быть обязательно включены в специальную подсистему «Префикс_ДобавленныеОбъекты». Если такая подсистема отсутствует на момент начала добавления новых объектов конфигурации – ее необходимо создать. Включать в командный интерфейс не обязательно. Данная подсистема нужна для определения объектов конфигурации, разработанных нами, а также для возможного переноса объектов по подсистеме в иные конфигурации.
Первое правило распространяется и на реквизиты объектов, регистров, форм и названия элементов форм, если такие реквизиты добавляются в типовые объекты. За тем исключением, что в реквизитах форм можно указать только префикс в имени.
К примеру: Типовой справочник «Пользователи». В нем необходимо добавить реквизит, который бы содержал, действителен или нет пользователь (рисунок 3). Формат комментария описан выше. При добавлении реквизитов формы так же необходимо указывать префикс.
Рисунок 3 Добавление реквизита в типовой объект.
Чек-листы для проверки архитектурных решений кода
Одна константа со временем может принимать несколько значений, в зависимости от разных сущностей.
Правильное решение - это использовать регистр сведений в котором будет четыре измерения: “Аналитика” (составной тип) и одни ресурс: Значение (составной тип).
Иначе у пользователей возникает непонимание по данному полю.
Например:
Необходимо добавить новую роль или включить доступ объекта в одну или несколько существующих ролей
Т.к. в результате можем получить не работающий у всех функционал (ошибка доступа в некоторых случаях) или различные результаты в данных.
Иначе можем получить не верную работу функционала системы.
Синтаксический анализатор не укажет на наличие ошибки, но в процессе работы можно столкнуться с непонятным на первый взгляд исключением.
В данном случае нужно отказаться от использования префикса, чтобы типовой функционал отрабатывал и для новых реквизитов.
Если переменная может принимать различные типы (например: структура или объект метаданных: “документ”), то перед обращением к реквизитам переменной нужно проверить тип.
Например:
Не правильно:
Правильно:
Это связано с тем, что в современных конфигурациях модули могут вызываться из множества других модулей и добавленная логика может нарушить работу другого модуля.
В таком случае возможно получение дублированных записей (отличаются значениями неучтенных измерений).
Это поможет при анализе спорных ситуаций с пользователями.
Например:
Т.к. со временем код и наименование объекта может быть изменено.
Т.к. возможно программная запись (проведение) объекта.
Т.к. для этих реквизитов возможно по-другому должен выполняться основной функционал (логика) объектов.
Данная проверка избавит от критической ошибки при повторном добавлении реквизита на форму.
Например:
Чтобы пользователи могли работать при построении отчета.
Например:
Соединения между таблицами должны быть достаточными, но не избыточными.
Данная информация будет необходима при анализе интеграционных процессов. Необходимо разработать регистр сведений для хранения информации по отправке/ получению данных или фиксировать данную информацию в журнал регистрации.
Т.к. это может значительно может повлиять на производительность. Поэтому, например, вопрос хранения тех же фотографий лучше решать не в основном справочнике, а в отдельном подчиненном справочнике или регистре сведений.
- Использовать пакетные запросы и временные таблицы вместо вложенных запросов.
- Для объединения нескольких таблиц используйте объединить, а не левое соединение.
- Для отладки сложных запросов используйте дамп запроса.
- Индексировать реквизиты/ устанавливать индекс для реквизитов, по которым используется отбор, поиск, соединение.
Заключение
Использование приведенных чек-листов (полностью или частично) повысит качество кода программистов, даже без внедренной системы Code Review. Основное правило, чтобы вся команда придерживалась одних стандартов.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Нейросети Рефакторинг и качество кода Запросы Разработчик 1С 8.3 Абонемент ($m)
Нейросеть написала запрос или процедуру для вашей базы 1С, и непонятно, все ли имена в нём настоящие. Обработка компилирует текст без выполнения, сверяет его с метаданными этой базы и к каждой ошибке пишет настоящее имя, например ВНаличииОстаток вместо выдуманного КоличествоОстаток. Список ошибок с подсказками одной кнопкой копируется обратно в чат с моделью.
10 стартмани
02.11.2026 377 2 nedomolkov.ivan 3
Рефакторинг и качество кода Разработчик 1С:Предприятие 8 Россия Бесплатно (free)
Одна проверка в обработчике кнопки может выглядеть достаточной, пока ту же операцию не вызовут из другого места. На примере управляемой формы разберём, почему так происходит, как разместить проверку в общей серверной функции и чем отличается удобная проверка ввода от обязательного условия выполнения операции.
29.10.2026 386 YA_777378709 0
Рефакторинг и качество кода Разработчик Бесплатно (free)
Рассказываем, почему качественный код – это не техническая прихоть, а актив, который помогает бизнесу быстрее адаптироваться к изменениям и запускать новые фичи без бесконечного преодоления техдолга. Показываем, как объяснить бизнесу ценность рефакторинга через понятные признаки: замедление разработки, неточные оценки, страх перед legacy и хрупкость системы. Разбираем, почему неправильный рефакторинг может быть дороже его отсутствия, какие анти-паттерны ломают процесс и как не превратить улучшения в бесконечную переделку ради переделки. Объясняем, как сделать рефакторинг частью культуры команды: договориться с бизнесом, научить разработчиков видеть проблемные места, закрепить правила и поддерживать улучшения на уровне тимлидов, архитекторов и всей команды.
28.10.2026 501 Pavel791 0
Рефакторинг и качество кода HighLoad оптимизация Системный администратор Разработчик Стажер 1С 8.3 Абонемент ($m)
Если к HTTP-сервису 1С обращаются сразу несколько программ, сколько запросов в секунду он успеет обработать? Я опубликовала простой HTTP-сервис на нашей "подопытной" конфигурации «Нано-УТ» (файловая база, Apache, без прав администратора) и нагрузила его скриптом на Python. Ответ: около 15-16 запросов в секунду, сколько бы клиентов ни обращалось одновременно. Запросы ждут своей очереди, и при 32 клиентах ответ приходит через 2 секунды вместо 64 мс. Заодно разобрала скрипт из первого варианта статьи: он «проверял» сервер, который отвечал по одному, и считал ошибки вместе с успешными ответами. В архиве исправленный скрипт, учебный сервер, HTTP-сервис для 1С и инструкция по запуску.
1 стартмани
23.10.2026 533 Ninel_S 3
Рефакторинг и качество кода Разработчик 1С 8.3 Абонемент ($m)
Запустили Analyzer 1C 2.7.65 на промышленной конфигурации (596 модулей, 13 669 функций) и исследовали перегруженные функции (до 1887 строк), циклические зависимости и экран «Циклы» (кольцо из 64 модулей). Разобрали, почему популярные метрики (McCabe, связность) не представлены в продукте вендора, и составили пошаговый план разделения модуля. Привели проверенный платформой 8.3.27 пример до и после рефакторинга и выявили скрытую ловушку загрузки модулей с точкой в имени.
9 стартмани
19.10.2026 469 Ninel_S 2
Рефакторинг и качество кода EDT СКД Разработчик 1С 8.3 1С 8.5 1С:Бухгалтерия 3.0 Бесплатно (free)
Одиннадцать граблей схем компоновки, которые не видно в конструкторе и не ловит EDT, на реальных отчетах БП КОРП. Формат числа задается в двух местах, и условное оформление варианта перебивает формат поля. Ресурс складывает штуки с часами, и помогает выражение «только когда единица одна». Ресурс пуст в детальных записях, параметр не появляется в шапке без userSettingID, valueListAllowed ломает границы периода, Остатки и СрезПоследних с параметром периода падают с «Несоответствием типов», title без xsi:type дает «Исключение XDTO» при загрузке. В конце код проверки схемы из файла до обновления базы, сводная таблица и чеклист.
16.10.2026 550 Konstmax13 2
Инструментарий разработчика Нейросети Рефакторинг и качество кода EDT Разработчик 1С 8.3 1С 8.5 1С:Бухгалтерия 3.0 Бесплатно (free)
Как ИИ-агент (Claude Code) работает в живом EDT-проекте 1С:Бухгалтерии КОРП 3.0: из чего собрать стенд с MCP-сервером для EDT, как ставить задачи агенту, где он ломает проект и какие проверки это ловят. Реальные случаи: рукописные метаданные, ронявшие конфигуратор; четыре дня зависшего обновления из-за порядка блоков в Rights.rights; ошибки, которые EDT пропускает, а платформа нет; сплошная сверка вместо «вроде работает». В приложении шаблон CLAUDE.md, шаблон правила, чеклист перед обновлением базы и скрипты проверки ролей и схем СКД.
15.10.2026 3518 Konstmax13 11
Рефакторинг и качество кода Тестирование QA Разработчик 1С 8.3 Абонемент ($m)
Инженерный анализ влияния (Impact Analysis) при изменении общего метода в 1С:Предприятии: почему штатный поиск ссылок скрывает 99% зависимостей и как обратный обход графа вызовов выявляет 370 скрытых потребителей на глубине 3 уровней. В статье — верификация сквозной цепочки обмена с маркетплейсом; в архиве-компаньоне — автономный BFS-анализатор на Python, слепки графа и план регрессионного тестирования.
1 стартмани
12.10.2026 335 Ninel_S 0
Побольше добавил примеров для понимания.
Можно платно: (больше диагностик).
Можно чисто на 1С, АПК:
А можно конкретный пример. ДокументРасхода.Ссылка.Дата - недопустмо, ДокументРасходаТовары.Ссылка.Дата - допустимо, я правильно понял?
Все верно, многие не учитывают - что это реально большая прокачка для новеньких и самих программистов.
Я лично не плохо прокачался, когда мы только начинали запускать ревью кода.
Автоматическая проверка - у нас есть, ей также пользуемся.
Свой сервис сделали, для проверки по своему стандарту, часть рутиной работы на себя взял.
Как продукт не будет, но в будущем возможно выложим на обозрение.
Кто Вас научил использовать вложенные запросы? Вы не в курсе временных таблиц? Но нет, в курсе, сами пишите об этом в последнем пункте. Как-то странно получается.
Почему Вы решили, что в принципе допустимо разыменовывание полей в запросах? Точнее в каких случаях это реально можно делать? В описанном Вами случае нельзя совсем, ибо составной тип имеют измерения регистров чаще всего накопления. Их размеры огромны и поэтому табу так делать.
Половина Ваших "предложений" пустая по содержанию. Написано что делать, но совсем не написано как! Пример: ЛЕВОЕ СОЕДИНЕНИЕ. Есть способы конкретные как избежать дублей и как понять возникнут они или нет при соединении таблиц. Аналогично про RLS. Как добиваться то, чтоб работали запросы все? Опять же есть четкая методика. и т.д.
Ставить минус не стану, т.к. сам являюсь автором статей и получаю и минусы и критику. Но явно Вам стоит подробнее расписать.
Что касается фразы, что любой программист сможет сам это сделать... вот это максимально неверная фраза.
Как раз в чек-листе и описывается, что нужно по минимуму использовать вложенные запросы, а лучше использовать временные таблицы.
Этот пункт подтверждает ИТС:
НО! Временные таблицы не всегда оптимальны по производительности, наш коллега снизу об этом пишет.
Не однократно встречал, что программисты простые запросы пишут через вложенные запросы, когда удобнее через временные запросы.
Этот чек-лист и нужен чтобы проверить, что вложенные запросы бывают излишне.
---------------
Как раз в чек-листе и описывается, что это нельзя делать и если составной тип, то нужно применять функцию - Выразить.
Этот пункт подтверждает ИТС:
Также на ИТС подобный пример (я сделал подобный пример с ИТС).
Не совсем понятно.
И да видимо вы не запускали АПК и не смотрели результат. В идеале это нужно делать перед код ревью. Особенно меня удивляют форматы комментариев, часто встречающиеся в компаниях, которые нарушают требования Совместимо.
И все же код ревью по чеклисту кто угодно не проведёт. Нужно понимать.
Мне встречались несколько ЗначениеРеквизита подряд одного объекта, да еще внутри цикла. Ваш чеклист это бы одобрил.
Это уже проверка архитектурных решений, это уже должен проверяющий найти при проверке.
Все зависит от бизнес-задачи.
Встречал код - когда получали значение из модуля "на время сеанса", потом по логике меняли это значение и снова получали из этого модуля (то есть уже старое значение).
Команда пишет и проверяет по одним стандартам.
1. Неправильно говорить что нельзя... Нужно описать в каких ситуациях можно. Просто задач, которые решаются через ПОЛНОЕ СОЕДИНЕНИЕ очень мало. Надо стараться использовать ЛЕВОЕ. Если надо наложить неявный фильтр, то ВНУТРЕННЕЕ СОЕДИНЕНИЕ. Если надо несколько таблиц слить воедино пользуются ОБЪЕДИНИТЬ ВСЕ, если надо без дублей пишут просто ОБЪЕДИНИТЬ. Полное соединение генерирует лишние записи. Так ещё в них половина полей имеют значение NULL. Это надо учитывать и дополнительно описать в запросе.
2. Выгружать можно, но только в случае, когда таблицу в цикле не обрабатывают!
Т.е. пишут НаборДвижений.Загрузить(Запрос.Выполнить().Выгрузить()). Вот так норм.
Обработка таблицы в цикле идёт медленнее, чем обработка через выборку запроса.
1. Использовать конечно можно, но не желательно, что подтверждает ИТС:
2. Без необходимости лучше это не делать, т.к. лишняя нагрузка на систему.
Вообще, стоит иметь ввиду, что в интерпретаторах делают встроенные оптимизации, и может так оказаться, что Для Каждого Х из Запрос.Выполнить().Выгрузить() будет работать без дополнительного выделения памяти, получая данные из непосредственно объекта с результатом запроса, который в любом случае едет из sql в 1С. Но это уровень мышления над платформой (или под ней). На С кода пишешь программу, то понимаешь, что буфер прочитанного фрагмента файла или тот же запрос - это уже выделенная память, которую можно использовать, при том она уже в кеш попала процессорный. В итоге на С скорость обработки тех же 120кк недействительных паспортов у меня в районе 4 секунд, а на том же железе в СУБД это положить - от 25 минут прямым запросом и до 4х часов если писать в регистр сведений средствами 1С))))
Ну и временные таблицы - это только для очень небольших фильтрующих выборок получая в ВТ полбазы, ты можешь просто повесить сеовак любого уровня.
В общем или программист 1С ограничен платформой и тогда ему лучше тупо соблюдать то, что пишет 1С, ну или он платформой неограничен, и механика работы запроса и оптимизатора лежит в поле дискретной математики, которую не ограниченный программист тоже немножко (в части деревьев и хеш-таблиц, как о них Макконнелл писал) знает и про нормальные формы читал и понял.
И при высокой интенсивности работы в базе наткнуться на очереди к диску. Или потом иметь гемор с поиском по дикому ЖР. Или пилить отдельные решения и оборачивать в тот же эластик. Это то, с чем столкнулся лично я.
Разве реквизиты не создаются в обработчике ПриСозданииНаСервере?
- Использовать пакетные запросы и временные таблицы вместо вложенных запросов.
- Для объединения нескольких таблиц используйте объединить, а не левое соединение.
- Для отладки сложных запросов используйте дамп запроса.
- Индексировать реквизиты/ устанавливать индекс для реквизитов, по которым используется отбор, поиск, соединение.
1. Не согласен. Генерить нагрузку на tempdb без имеющихся на то причин, зачем? MSSQL отлично раскрывает скобки.
2. Опять же с потолка. Почему не левое соединение? Чтобы подзапутать оптимизатор?
3. Что такое дам запроса? Что то новенькое и модненькое? Я бы посоветовал для отладки сложных запросов использовать план запроса
4. Вы делали замеры индексирования? Очень редко создание индекса помогает для больших таблиц. Бывает, но редко.
В целом, резюмируя статью, очень много "советов" и причем очень спорных и никак не обоснованных. Не скажу, что статья больше вредная, нежели полезная, хотя, нет, скажу. Автор постарался, но, как говорится в джентельменских кругах: "Тема сисек не раскрыта", а уж советов и подавно, особенно безапелляционные утверждения.
1. вложенные запросы зло особенно на больших таблицах. + есть стандарты разработки 1С.
4. что касается индексирования... автор неверно написал что делать надо. Надо не создавать индексы в объектах метаданных, а следить, чтоб связи и условия накладывались по индексированным полям. Если таблица огромная (какой-нить регистр накопления) и нет возможности наложить условия последовательно по измерения, нужно согласно стандартов разработки разбить запрос на 2.
в моей практике масса примеров, где индексирование ускоряло процесс существенно. + автор не описал потребность в создании индексов для временных таблиц. Это в определенных ситуациях также в разы ускоряет.
Вот Вы утверждаете, что зло, при этом, видимо, не совсем понимаете, как работает подзапрос и как временная таблица, в чем между ними разница. Запомните, что стандарты разработки часто перестают работать на больших данных.
4. Можно пруфы, сэр? Ну вот элементарно хотя бы планы запросов до и после индексирования.
1. Работал в 1С в отделе разработки ЕРП. Выполнял задачу связанную частично с зарплатой, частично с казначейством. Точнее учет НДФЛ удержанного при выплате зарплаты. Не вспомню конкретный документ, где поставлен был индекс у реквизита ТЧ. Но по этому документу в 4-х местах были написаны запросы с отбором по реквизиту ТЧ. Этот документ был из подсистемы БЗКР (надеюсь знаешь что это). Так вот когда нагенерил млн документов у меня все эти запросы падать начали. Документы по 5-7 секунд проводились при нормативе 2 секунды. После индексации реквизита все показатели уложились в норматив, даже запас остался! Т.е. производительность запросов при больших объёмах данных возросла многократно.
2. Теперь про индексы во временных таблицах. Для крупного агрохолдинга писал конструктор выгрузки данных из ЗУП в Excel. Получается очень много данных и они потом перекрестно ещё используются в запросах. Т.е. кадровые данные и ШР используется дальше во всех запросах. Сначала я забил на индексы, делал функциональность, работал на результат. Когда его получил, то обратил внимание что всё получение данных занимает 5 минут (+ ещё вывод в Excel). Так вот грамотно расставив индексы во временных таблицах, сократил время получения данных до 2-х минут!
ляпунть то конечно можно что кто-то непонимает... сложнее признать собственные пробелы в знаниях. Успехов
Индексации реквизита, как объекта метаданных? Так я про это и не спорил даже. Индексы часто приводят к улучшению плана запроса.
По поводу п.2. Я писал, что в очень небольшом проценте индексы сыграют роль. Но Вы просто натыкали индексов не разбираясь, что там внутри. По крайней мере так написано. Ни тебе планов запроса, ни их анализ, ни анализ структуры данных. То есть очевидно, что банально сработал метод тыка. И я не сказал, что индексы ВТ всегда не работают. Работают, но очень редко. Если удалось, что ж, не стоит под одну гребенку крыть одной крышкой.
(37)
Пробелы я регулярно восполняю, а Вам советую отличные видеокурсы Виктора Богачева. Там восполните уже свои.
П.С. Очень странно читать такое от человека, который работал в 1С над флагманской конфой. Я думал туда только экспертов и берут.
КонецСрача
Успехов
ведь изучение информации новой должно находить применение и приносить пользу. существенной пользы от этого не будет. стараюсь писать код вдумчиво и соблюдать стандарты (собственно в 1с то научили)
собственно с моей стороны срача и не было))) просто ответил в твоём стиле)))
В 1С берут людей с опытом проектирования интересных решений. Качество кода подымают на месте уже) У них код ревью очень жесткий. А остаются там те, кто готов делать то что ему скажут. у меня такая компетенция отсутствует))) Поэтому ушел довольно быстро.
Тебе тож успехов)
Очень зря. Помогает понять, а самое главное, с опытом предугадать, как поведет себя запрос с теми или иными данными. Согласен, что каждая база индивидуальна и на небольших, до 500Гб, может и не требовать такого погружения.
Кстати, что интересно, на курсах по оптимизации и от 1С и от курсов-1с-рф, где рассматриваются именно большие таблицы, прямо говорят, что стандарты могут перестать работать, они рассчитаны на массового пользователя, и поэтому пока процент баз больше террабайта условного мизерный, стандарты будут действительны)
Чуткое слежние за статистиками и их тонкое обслуживание посреди рабочего дня требует достаточно квалифицированных админов. Таких людей гораздо меньше, чем одинесников, которым можно дать простую инструкцию. К тому же сам факт апдейта статистик через, само по себе даёт неплохую нагрузку на базу.
В новых конфигурациях стало все очень удобно, все вынесено в отдельные модули и процедуры.
Согласен, но других решений в типовых конфигурациях не знаю. Напишите, если знаете.
При написании запросов желательно
- Использовать пакетные запросы и временные таблицы вместо вложенных запросов.
- Для объединения нескольких таблиц используйте объединить, а не левое соединение.
- Для отладки сложных запросов используйте дамп запроса.
- Индексировать реквизиты/ устанавливать индекс для реквизитов, по которым используется отбор, поиск, соединение.
Сверху писал, за основу взят стандарт 1С и соответственно данные пункты взяты с ИТС:
Зачем сохранять Результат запроса, если он не будет использован? Разве что удобнее его в отладчике дергать вместо Запрос.Выполнить()
Если подсистем несколько?
Если придет не Булево, или Null или неопределено или битая ссылка? Динамическая типизация и все такое.
Выглядит не очень, потом вся конфигурация в Вася_подсистема1, Петя_подсистема2. Видели, знаем.
Что за непонятная тяга к префиксам? Зачем вам подсистемы - разве что реквизиты туда не запихать.
А когда будет запущено несколько десятков фоновых ждать вечность в поиске по этому журналу.
Это на маленьких таблицах, а если в таблице 60 млн записей, сколько потратится времени на помещение этих записей во временную таблицу? На моей практике как раз использование вложенных таблиц дало 5кратный прирост скорости на большой таблице.
Это еще почему?
Пункты, которые следовало бы добавить:
Количество параметров в функциях - не передавать миллионы параметров?
Размеры функций - чтобы функция влезала на экран.
Близость переменных от места использования к месту объявления - чем дальше, тем больше вероятность ошибки.
Связность функций в общих модулях - чтобы один модуль (вы же тут про ООП заговорили) знал поменьше о других модулях?
Использование общего кода форм в клиентских модулях, чтобы текст модуля не перетаскивался постоянно с сервера на клиент и обратно при передаче контекста.
Кэширование постоянно используемых значений в реквизитах на форме, и т. д.
Разработка через отладчик vs разработка через тестирование/чтение логов хороший триггер для отличения кодеров с туннельным синдромом от программистов.
Проблемы того, кто передал это значение. Есть же спецификация, что должно приходить булево. А не зная контекста невозможно понять, понять лень разработчика или исключительная ситуация передала Null вместо Ложь.
Что за непонятная тяга к префиксам? Зачем вам подсистемы - разве что реквизиты туда не запихать.
Согласен, префиксы дурацкая по сути система, ломающая весь интерфейс разработчика.
Текущая оптимизированная версия журнала вполне себе шустро работает. Главное следить, чтобы заголовки событий журнала были средствами группировки событий, а не их уникальными идентификаторами. Тогда будут тормоза при получении списка видов событий.
Если в таблице 60 миллионов записей, то только неопытный разработчик будет её без предварительной фильтрации куда-то помещать. Скорость работы вложенных запросов зависит здесь от актуальности статистик. Которые, что характерно, могут протухнуть по мнению оптимизатора SQL и просто по таймауту. Так что ваш "5кратный прирост скорости" может легко обратиться в 20кратное падение в пределах одного дня. Надо же оценивать объём работ, а не полагаться только на тестирование "здесь и сейчас", без понимания почему тест пройден/не пройден.
Наверное потому, что левое соединение позволяет "склеить" записи разных таблиц по некоторым условиям. А объединение это именно объединение таблиц путём добавления записей в новую общую таблицу. В некоторых частных случаях или путем извращений можно, конечно и левым соединением воспользоваться, но читается такой запрос труднее.
По остальным замечаниям согласен.
Если данный список рассматривать как список для проверки вообще, то согласен. Сама работа, повторюсь, хороша.
В итоге ставлю плюс за труд, но прошу преамбулу переработать.
Неточности и ошибки есть, но здесь нужно внимательнее пройтись по содержимому спойлеров. Вывод пишу на основании чтения заголовков спойлеров.
P.S. Посмотрел примеры после прочтения комментариев. По части замечаний согласен, есть спорные рекомендации. За префиксы предусмотрен отдельный котёл в аду. Но это вопрос спорный по факту. Многие из рекомендуют, но моё ИМХО таково.
Спасибо за комментарий, префиксы нам помогают отделить свои доработки от типовых и помогают при обновлении.
Опять же данный чек-лист еще нужно рассматривать, как прокачка программистов, что не дает автоматическая проверка.
А кто говорил что будет легко? Зато коллеги которые после вас придут, не будут думать что вы осел.
И я не понимаю в чем сложность, формы надо программно обновлять типовые, тогда не будут слетать при обновах. А код в любом случае при обновлениях проверять и при объединении это делать как раз таки сложнее.
(75)
???
В расширениях не хватает только констант (но вместо них в любом случае лучше юзать ПВХ или регистр с настройками) и общих типов. Всё остальное уже замечательно работает, плюс расширения позволяют модульно использовать разный функционал в разных точках.
Спасибо учту.
Спорный момент конечно, но я лично смотрел типовые конфигурации и там в основном разделяют эти процедуры.
Это удобно - для отладки (немного) и в основном выполнение и выборка/выгрузка находятся в разных процедурах (используется менеджервременныхтаблиц).
Мы у себя придерживаемся именно этой конструкции, как я описал в введении - многие пункты могут быть для Вас не обязательные (то есть Вам не подходить).
Системы может быть несколько и если в Ваших системах, только добавленные элементы, то все норм.
Если в Ваших системах есть и типовые объекты, то это уже не подходит.
Идея данной системы - сразу находить все добавленные объекты в одном месте.
Здесь конечно нужно смотреть конкретно по задачи.
Если Реквизит, типа - Булево, то другие значения мало вероятно могут прийти.
А так можно использовать - ЗначениеЗаполнено.
Что за непонятная тяга к префиксам? Зачем вам подсистемы - разве что реквизиты туда не запихать.
У нас все лаконично, максимум 2-3 подсистемы, одна на добавленные объекты, остальные на бизнес-задачи.
Тэги и префиксы очень помогают найти в конфигурации добавленные объекты и код.
В комментарии описываем все доработки, согласно стандарту.
Тоже проблем с этим не было, тут именно нужно выделить запись нужных событий и в нужные моменты.
Также при записи называть свой процесс по особенному, чтобы потом можно было его быстро найти.
Этот пункт относятся к типовому функционалу, если конфигурация снята с поддержки, то можно рассмотреть в сторону регистра сведений, который будет фиксировать лог выполнения определенных задач.
Это на маленьких таблицах, а если в таблице 60 млн записей, сколько потратится времени на помещение этих записей во временную таблицу? На моей практике как раз использование вложенных таблиц дало 5кратный прирост скорости на большой таблице.
Я написал "желательно", но не обязательно, нужно конечно смотреть конкретно на каждую задачу.
ИТС подтверждает ваши слова:
Это еще почему?
Это согласно инструкции ИТС: (при объединении таблиц нужно использовать ОБЪЕДИНИТЬ).
За основу мы брали стандарт 1С.
Количество параметров в функциях - не передавать миллионы параметров?
Размеры функций - чтобы функция влезала на экран.
Близость переменных от места использования к месту объявления - чем дальше, тем больше вероятность ошибки.
Связность функций в общих модулях - чтобы один модуль (вы же тут про ООП заговорили) знал поменьше о других модулях?
Использование общего кода форм в клиентских модулях, чтобы текст модуля не перетаскивался постоянно с сервера на клиент и обратно при передаче контекста.
Кэширование постоянно используемых значений в реквизитах на форме, и т. д.
Спасибо за информацию, у нас также постепенно совершенствуется чек-листы и мы уже задействовали автоматические проверки, так что развитие идет.
Использование временных таблиц
#std777
Область применения: управляемое приложение, мобильное приложение, обычное приложение.
1. В общем случае, временные таблицы рекомендуется использовать для повышения производительности и стабильности выполнения запросов. Их можно использовать для других целей (например, для улучшения архитектуры кода), но при этом, нужно понимать, что это может в некоторых случаях приводить к снижению производительности.
2. Есть ситуации, когда временные таблицы не следует создавать или создание временных таблиц необходимо минимизировать.
2.1. Не следует создавать временные таблицы с очень большим объемом данных (сотни тысяч записей). Иначе это приведет к существенному снижению производительности при записи и исчерпанию свободного места на диске. Если алгоритму требуется работать с большим объемом данных, то он должен выполнять обработку этих данных порциями.
2.2. Следует максимально ограничивать количество данных, выбираемых во временную таблицу. Не следует помещать во временную таблицу больше данных, чем требуется последующим запросам.
2.3. Не следует помещать во временную таблицу поля, которые не используются в последующих запросах, т.к. время и место для их размещения тратится впустую.
2.4. Не следует создавать и удалять временные таблицы в цикле, если можно создать одну временную таблицу до выполнения цикла.
2.5. Не следует копировать одну временную таблицу в другую только ради того, чтобы переименовать первую таблицу во вторую. Вместо этого, следует передавать имя таблицы.
А вот теперь представьте анализ продаж за период. Или анализ остатков крупной сети. Или много еще каких примеров в организациях с высокой интенсивностью введения данных и гигантскими, в десятки и сотни гигабайт, таблицами. И Вы вместе с Артано предлагаете всю эту простыню положить во временное хранилище, а еще потом создать индекс, а уже потом соединять. Как это называть?
Все индивидуально, если стандарт по нему пишут и всегда есть исключения, которые нужно обосновать.
А зачем анализ продаж складывать во временную таблицу? Я такое даже в своём замечании не предлагал, напротив, указывал на недопустимость помещения нефильтрованных данных в ВТ.
Скажите задачу и обсудим на конкретном примере
Отмечу, что ВТ не зло, точнее это инструмент, который в правильных руках повышает скорость выборки, но в плохих может и систему положить. Про подзапрос то же самое. И любой более-менее сложный и объемный запрос я лично стараюсь проверить не только на малой выборке, но и взять реальную, если подразумевается работа с большими таблицами. И, анализируя план запроса, уже прихожу к решению, что мне использовать.
Почему так лучше делать - упрощается реиспользование кода. То есть сама программная архитектура строится под то, что вернется результат запроса. Отсюда меньше переделок потом, когда потребуется, например, повторно использовать функцию возвращающую результат запроса. А если сэкономить одну строчку кода, то переделок потребуется больше.
Можно конечно и скопипастить исходную функцию и поправить в ней строчку с Запрос.Выполнить.Выбрать() на Запрос.Выполнить() и получить на поддержку две функции с изначально идентичным содержимым.
Подобные и некоторые другие вопросы я рассматривал в своих статьях как раз со стороны "почему это правильно, а это неправильно". Возможно, станет понятнее и позиция автора и позиция фирмы 1с
Я, вот, ставлю, префиксы справа – и очень доволен (насколько можно быть тут довольным в ущербной платформе 1С Предприятие 8)! Но да - «1С Совместимо» такая конфигурация вряд ли пройдёт (хот я считаю «1С Совместимо» весьма корявым стандартом, но он хоть какой-то стандарт, в 1С среде стандартов мало…. Хе… кто бы жаловался на то что стандартов мало, а не наоборот – слишком много).
Кстати, говоря, если присмотреться, то типовые конфигурации от 1С используют префиксы-суфиксы и именно СПРАВА:
Примеры префиксов: |
|---|
| ОбщегоНазначенияБП
ОбщегоНазначенияБЗК ОбщегоНазначенияБРО ОбщегоНазначенияБТС ОбщегоНазначенияУТ ОбщегоНазначенияСлужебныйКлиентСервер ОбщегоНазначенияЛокализация ОбщегоНазначенияЗУП ОбщегоНазначенияУХ ОбщегоНазначенияЭДКО ОбщегоНазначенияЭД ОбщегоНазначенияMicrosoftExcelКлиентСерверУХ ОбщегоНазначения_ОДП //Это уже мой модуль ПроверкаИПодборПродукцииЕГАИС ПроверкаИПодборПродукцииЕГАИСУТ ПроверкаИПодборПродукцииИС ПроверкаИПодборПродукцииИСМП ПроверкаИПодборПродукцииИСМПУТ ПроверкаИПодборПродукцииМОТП Неужели так было бы лучше (но именно так, в общем-то, предлагает данная рекомендация): БП_ОбщегоНазначения БЗК_ОбщегоНазначения БРО_ОбщегоНазначения БТС_ОбщегоНазначения УТ_ОбщегоНазначения Служебный_ОбщегоНазначенияКлиентСервер Локализация_ОбщегоНазначения ЗУП_ОбщегоНазначения УХОбщегоНазначения ЭДКООбщегоНазначения ЭДОбщегоНазначения УХ_MicrosoftExcel_ОбщегоНазначенияКлиентСервер ОДП_ОбщегоНазначения ЕГАИС_ПроверкаИПодборПродукции ЕГАИСУТ_ПроверкаИПодборПродукции ИС_ПроверкаИПодборПродукции ИСМП_ПроверкаИПодборПродукции ИСМПУТ_ПроверкаИПодборПродукции МОТП_ПроверкаИПодборПродукции |
«Дублирование кода (ООП): Общие процедуры и функции нужно выносить в общие модули» - рекомендация отчасти противоречит заголовку. Ущербная платформа 1С Предприятие 8 – не совсем ООП – вернее почти совсем не ООП для тех, кто в ней парограммирует. Но – этот ООП отчасти можно эмулировать – как раз используя обработки – как псевдо-объекты. Тогда – как раз можно было собирать общие алгоритмы в таких обхектах-обработках создавать их, передавать их и вызхывать их методы – простите – функции и процедуры. Но… модуль объектов как и модуль менеджера не доступен на клиенте (ущербная платформа), хотя для клиента можно использовать форм(у)ы обработки. И это, относительно удобно – хотя мало разработок этим пользуется (хотя, вот, есть Инструменты разработчика от Tormozit). Место ООП такие объекты можно воспринимать как библиотеки. Хотя, т.к. нельзя эффективно управлять директивами препроцессора – то это решение имеет много минусов, по сравнению с общими модулями, хотя у кого их больше – это ещё вопрос – в неуправляемом приложении уж точно.
А размещение алгоритмах в обработках позволяет легко создавать локальный контекст «библиотеку» - называем обработки длинными уникальными именами (чтобы во всех конфигурациях и расширениях они не пересекались) и пишем специальную функцию – которая по имени контекста будет создавать и наполнять структуру объектами таких обработок с унифицированными именами (если в составе общей конфигурации есть повторяющиеся унифицированные имена обработок – то просто выбираем одну из них (по старшинству версии; стратегия MIXIN тут не получится – хотя при должной сноровки и её можно было бы эмулировать) – далее либо используем экземпляр такой структуры локально – либо присваиваем глобальной переменной (увы – только в клиентском контексте (для упр. приложения нужно создавть экземпляры форм); на сервере можно было бы запихнуть в параметры сеанса – если было бы можно – хотя можно во временное хранилище – но лучше просто обойтись функцией в модуле повторного использования – а там уже задейстовать и параметры сеанса и временное хранилище). Таким макаром можно и более-менее полноценную иерархию пространств имён получить (с вложенными модулями). Справедливости ради, замечу, что эта стратегия работает и с общими модулями – но ими управлять куда менее удобно и менее универсально! А орбработки бывают ещё и внешними – что открывает коллосальные возможности к динамическому программированию.
Не «1С Совместимо»!
Говоря о функции «ЗначенияРеквизитаОбъекта» стоило бы упомянуть и функцию «ЗначенияРеквизитовОбъекта» - потому что редко, когда нужно взять только один реквизит. А заодно и другие функции получения значений реквизитов объектов.
Использовать «Выразить» для реквизитов составного типа в запросах – это палка о двух концах. С одной стороны – да нужно стараться использоваться (особенно при работе с субконто и характеристиками). А, вот, приведённый пример «ВЫРАЗИТЬ(УчетНоменклатуры.Регистратор КАК Документ.РасходнаяНакладна).Номер» очень спорный – т.к. в данном случае как раз обычно нужны номера любых документов, зарегистрировавших запись. И что делать – если (а так обычно и бывает) нужно более 1-го вида регистратора регистратор? Но бывают, конечно исключения – и вот... программисту лень городить сложные конструкции с оператором «ВЫБРАТЬ КОГДА ТОГДА» и «ВЫРАЗИТЬ», тяня туда десятки видов документов. А если нагородит – то потом появляется новый вид документа (например, подключится расширение) и…. БАА!.. запрос уже не работает корректно (работает без ошибок, но некорректные результаты выдаёт)! Пойди найди все такие запросы, чтобы внести в них правки! Налицо очередная ущербность платформы и неудачная рекомендация!
Не говоря уже о том, что одно лишь «ВЫРАЗИТЬ» без фильтра «ГДЕ ВЫРАЗИТЬ(ТоварыНаСкладах.Регистратор Ссылка Документ.ПоступлениеТоваровУслуг)» никакого особого выигрыша в производительности (и уж тем более в корректности результата) не даёт (но защищает от переполнения числа таблиц в итоговом запросе – что может быть чревато для некоторых старых СУБД). А если написать указанный фильтр – то «ВЫРАЗИТЬ» уже можно не писать (если этого не требует логика) – выигрыша в производительности почти не будет (хотя это может только MS SQL умеет так условия проталкивать) – почти все соединения будут пустыми.
Хотя это очередной раз говорит об ущербности платформы – ведь можно было бы не делать соединения с таблицами, если их нет в условии с оператором «Ссылка» (когда его можно однозначно определить). Не говоря уже о том, что все эти фильтры и выражения типа нужно декларировать вне запроса (в дереве метаданных) и лишь применять в запросах – чтобы не выискивать их потом. Сделать это можно было бы вообще круто – введя интерфейсы – и используя их как как типы, да хоть в том же операторе «ВЫРАЗИТЬ» но уже одном – а на выходе будет NULL если интерфейс не поддерживается; или все доступные поля интерфейса (да ещё и, возможно, по-разному реализованные (да хоть имеющие разные имена идентификаторов) в разных источниках, но сведённые к единой мнемонике использования в запросе; а настраивалось бы всё декларативно в конфигурации).
«Использование условий в секции ГДЕ вместо параметров виртуальных таблиц» – это справедливо только для регистров накопления и иже с ними. Применение в регистрах сведений должно быть с осторожностью – т.к. это может повлиять на логику выборки среза.
А чем не угодил метод «Сообщить»? Он вроде бы внутри реализует логику объекта «СообщениеПользователю» (пусть и в урезанном виде).
«Не использовать проверку на тип «булево», через ИСТИНА или ЛОЖЬ» - вот это рекомендация просто убила! Что – и тут 1С Предприятие 8 имеет проблемы? А в друг в переменной будет значение «неопределено» или «null» (это могут быть как легитимные значения, так и не очень – ведь 1С Предприятие 8 – это система с полностью динамической типизацией). Скажите – уж лучше в этом случае ошибку получить? Когда-то да – лучше – но чаще – просто можно считать условие не выполнившимся! Хотя, вот числовые значения 1С приводит неявно к булевым – и ничего – никто не умер (я надеюсь)!
Примера с транзакциями очень неудачные – скорее всего научат как раз плохому коду!
« Правильное решение - это использовать регистр сведений в котором будет четыре измерения: “Аналитика” (составной тип)» - Вот это можно пояснить. Зачем тут 4 измерения аналитики, да ещё и составного типа?
Я использую регистр сведений: |
|---|
| Измерения:
Идентификатор ДатаНачала ДатаОкончания Организация База (для идентификации ИБ, в т.ч. узла при применении распределения настроек из единого центра) Пользователь (для персонализации по пользователю) Метаданные (для привязки к конкретному метаданными – для удобства интерактивной настройки) - все, кроме идентификатора, не обязательны к заполнению Реквизиты: ДатаИзменения АвторИзмиенения Ответственный (Владелец параметра) Описание (параметра) Комментарий (к текущему значению И ресурс «Значение» - строковый неограниченной длинны – хранит серилизованное значение (т.е. так можно хранить куда больше вариантов типов данных, в т.ч. списки и даже деревья значений). И нет проблем с неэффективным хранением значений разных примитивных типов, и можно хранить неограниченные строки. Идентификатор – может быть ссылкой на отдельный справочник/ПВХ с предопределёнными значениями (для удобства), но может быть и просто строкой (ограниченной длинны). Доступ к регистру через функцию модуля повторного использования – так что обращения кэшируются. По-моему, почти идеально! |
Вот про контроль изменения значений в модулях повторного использования можно подробнее. Ранее уже пробовал городить огород на эту тему – но пока плюнул на это дело – не сталкивался на пактике с большими проблемами с отсудившем такого контроля. Хотя можно завести отдельну константу – дата сброса кеша (и параметре сеанса – с текущей датой сброса кеша) – периодически проверять в каждом сеансе, и если дата в константе станет моложе даты в параметре сеанса – то вызвать функцию «ОбновитьПовторноИспользуемыеЗначения()» (очень неудачное имя идентификатора) – сбросив вообще весь кеш (и обновит параметр сеанса) – соответственно пользоваться этим только при очень большой необходимости.
«Для отладки сложных запросов используйте дамп запроса.» Что это такое?
Странно, что нет ни слова про применение окончаний а-ля "Клиент" "КлиентСервер", "ПовтИсп", "ПолныеПрава", "ВызовСервера".., и суффиксов а-ля "Переопределяемый", "Служебный", "События"...
Хотя, лично я, против такой практики - из-за неё в ERP2 больше сотни общих модулей, и очень сложно разобраться к какому же модулю нужно обращаться. Я перешёл к практике 2-3 префиксов на модуль:
В первом располагается вся логика
Во-втором осуществляется переход на сервер из функции первого модуля (если того требует контекст) и обратный возврат вызова в первый модуль (здесь нет никакой логики - только смена контекста)
В-третьем - кеширование - когда нужно - и вызов опять первого модуля
Всё разделение на контексты доступности реализую директивами препроцессора уже внутри первого общего модуля.
Это очень удобно.
Вообще можно было бы обойтись одним первым общим модулем (особенно если бы платофрма 1С Предприятие не была такой ущербной и позволила бы применять аннотации контекста (как в управляемых формах) внутри общих модулей (в т.ч. для смены контекста вызова). Или можно просто сделать два ЕДИНЫХ общих модуля для смены контекста и производить его смену через функцию "вычислить" (все вызываемые методы должны быть функциями - впрочем я всегда так стараюсь делать) - увы - не будет работать на iOS - а ссылок на функции в 1С Предприятие 8 не завезли (и это в процедурном то языке программирования). Хотя можно частично выкрутиться через "ОписаниеОповещения" (увы - только на клиенте - хотя нужно это только для iOS).
Тогда смену контекста можно производить через общие прокси функции, вызывающие нужные функции по строковому пути - на производительности это не сильно сказывается
Из "громких" есть замечание по поводу "как сделать ООП в 1с". Здесь главное без фанатизма и не городить костыли, просто так чтобы было ООП. Вполне достаточно ориентироваться на общую ООП-парадигму используя те её методы, которые можно без существенных костылей внедрить в процесс разработки, особенно коллективной.
Говоря же об интерфейсах (которые обычно относят к ООП) я не касался ООП - и предлагал их гипотетическое использование в контексте запросов (либо платформа должна развиться для их поддержки, либо, в контексте их представления в моём комментарии, можно внедрить свой прокси-движок для выполнения запросов с их препроцессорном перед выполнением - чтобы обработать эти интерфейсы, немного кустарно хранящиеся в метаданных или даже в данных ИБ). То есть, в этом смысле - Интерфейс - это просто описание контракта - на основании которого при его применении происходит автогенерация дополнительного кода (в данном случае конструкций "ВЫБОР... ВЫРАЗИТЬ"), и программисту, применившему приведение типа к интерфейсу, не нужно думать о том, что там за код генерируется и на основании каких данных-настроек этого интерфейса. Вернее думать надо , но только о том, что если применяешь интерфейс, то нужно следить за его актуальностью - но это уже, скорее вопрос к процессу доработки конфигурации , её расширению и обновлению - вот в этих процессах нужно следить за актуальностью имеющихся интерфейсов. Особенно, когда в платформе нет встроенной продвинутой поддержки этих процессов для интерфейсов (а ведь не сложно было бы сделать).
P.S.
Относительный нормальный ООП в 1С кустарно построить можно - но только если сделать свой расширенный компилятор в байт-код платформы. Это вполне возможно.... но вряд ли кто-то будет делать (хотя бы по той причине, что в 1С Предприятие 8 очень ограничены возможности по внедрению в конфигурацию скомпилированного байт-кода, а жаль).
С включёнными итогами на срез последних выполнение почти всех вариантов сводилось к нескольким десяткам секунд (но было исключение с одним из запросов с оператором "В()" - который выполнялся около 100 сек).
Наличие/отсутcnвие индексов на временной таблице на результат почти не влияло (индекс был у другой таблице, к которой присоединялась обработанная выборка и регистра).
Та что, использование временных таблиц для регистра сведений перед его обработкой - не всегда однозначно прирост производительности, относительно прямого обращения к срезу (даже несколько раз во вложенных запросах) - а запросы с большим числом вложений были производительнее более "плоских".
СУБД MS SQL Server 13.0
Потому что это удобно, плюс где-то было в стандартах, лень искать.
Мало того, что префикс должен быть в начале, так ещё и в синониме он тоже должен фигурировать, чтобы в интерфейсе было понятно, где типовой реквизит, а где твой добавленный.
Про префикс в синониме не возражал. И да, тоже считаю, что он должен быть - и именно справа я его там ставлю - отдельным словом в скобках - чтобы не мешал восприятию основного наименования сущности (но только не для реквизитов и табличных частей, чтобы не мешал автоотображению заголовка на форме).
А в общем, такая префиксация - от лукавого - т.е. от ущербности платформы. В идеале, задачи дублирования имён и определения принадлежности к проекту должны решаться иначе - но это уже не 1С Предприятие 8 (по крайней мере в типовом исполнении редактора конфигурации)
В каких типовых?) Твои примеры это не префикс, а аббревиатура названия модуля, в который вложена смысловая нагрузка.
Открой любую отраслевую конфу на основе типовой или БСП и ты увидишь, где стоят префиксы для новых объектов метаданных :)
А в приведённых мной примерах данные аббревиатуры являются не чем иным как префиксами (или по-русски - окончаниями, или как ещё называют - суффиксами, что в данном случае морфологии русского языка будет вернее, как вот тут "ИнтеграцияИСМПВызовСервера" суффиксом будет "ИСМП", а окончанием "ВызовСервера", хотя как выше приводил в типовых бывает и такое "ОбщегоНазначенияMicrosoftExcelКлиентСерверУХ" - тут "УХ" окончание, а "КлиентСервер" - суффикс, а ещё есть "MicrosoftExcel" - тоже суффикс; но уже как-то привычно сложилось, чтобы не разбираться в тонкостях морфологии русского языка, все это называют префиксом). Так вот, в этих примерах префиксы расположены справа - и не важно, как они образованы - автором (владельцем) данных объектов метаданных, или названием модулей. Стилистически - эти префиксы расположены справа. А как будет выглядеть - будь они слева - я уже показал - на мой взгляд выглядит ужасно (а в использовании ещё ужаснее чем выглядит).
Можно конечно, привести убийственный контр пример - что когда делаешь расширение конфигурации - то платформа ЯВНО ставит префикс ВСЕГДА СЛЕВА - т.е. соблюдает стандарт 1С - и это ужасно - сердце кровью обливается кода я вижу понатыканные префиксы слева. Вот хочешь обратиться к объекту метаданных - знаешь его бизнес- имя - ан-нет - сначала набери префикс - а потом уже вводи имя - быстрые подсказки или поиск превращаются в муку! Как и в муку превращает их просмотр в списке - когда четверть отображаемого имени - это префикс - а затем ещё четверть реального имени умещается в списке - а остальная часть просто не влезает в ширину списка.
И особенно ужасно то, что по сути эти префиксы в расширениях ни черта не решают проблему дублирования имён - потому, что легко может быть несколько расширений с одними и теми же идентификаторами-метаданными и одними и теми же префиксами (как от одного вендора, так и от разных). При этом сами метаданные могут как быть реально одинаковыми (просто общими), или тоже одинаковыми - но реализующими разные части общего расширения - т.е. должны быть объединены в единое целое. Но это уже ущербность системы расширений конфигураций платформы 1С Предприятие 8. Хотя при установке "расширений" через сравнение-объединение конфигураций - проблема тоже остаётся - хотя тут больше способов её решению - но всё это костыли! И префиксы тут совсем не панацея - а лишь иллюзия, что проблем не будет!
Стандарт 1С - вещь хорошая - но только потому, что иных то стандартов для разработки в 1С нет , и без следования ему не получить заветные для многих вендоров "1С Совместимо". Но сам по себе стандарт очень специфический - в нём очень много задано очень криво и неудобно (впрочем - это касается любого стандарта - всегда будут придирки) - и зачастую эти недостатки обусловлены ущербностью платформы.
И мне бы хотелось, чтобы в будущем появился иной стандарт - хотя бы для гипотетической "1С Предприятие 9". Где такие нюансы как проблема идентификаторов будет решена более изящно, чем через префиксы (где бы они ни были).
Например, для решения проблемы принадлежности - можно было бы просто ввести в конфигурацию доп вид метаданных - "Разработчик" (а заодно и "Вендор"("Издатель") и "Автор" - соответственно выше и ниже по иерархии относительно Разработчика) - и присваивать их всем объектам метаданных любого уровня вложенности (по умолчанию наследуются из свойств корня текущего модуля-метаданных, или из свойств пользователя, или просто выбираются вручную в настройках на время сессии или сохраняются в локальном профиле на компьютере для конфигурации или иным путём). А далее - можно было бы по ним фильтровать, группировать метаданные или просто выводить сбоку (на выбор слева или справа) в представлениях метаданных или в отдельной колонке.
А для решения проблемы дублирования имён нужно вводить пространства имён, области видимости и интерфейсы. Все объекты метаданных могут входить в те или иные пространства имён. Тогда, скажем, у модуля-метаданных могут быть пространства имён, подключаемые по умолчанию (в них идентификаторы (условно) не должны пересекаться, но только в рамках контекста модуля-метаданных), отдельные метаданные модуля-метаданных (и отдельно их модули-алгоритмов) могут переназначать пространства имён по умолчанию, а так же добавлять для своего контекста новые или просто обращаться по полному пути).
В случае конфликта идентификаторов в контексте действия нескольких пространств можно просто задать локальные псевдонимы для проблемных идентификаторов внутри контекста, где возник конфликт.
Ну а флаги разграничения видимости/доступа ещё больше снижают вероятности таких конфликтов.
Интерфейсы - тоже мощная штука - внутри некоего объекта метаданных могут быть свои внутренние (не обязательно публичные идентификаторы). Но для него может быть создан интерфейс (множество интерфейсов, или он может использовать готовый интерфейс) - который будет привязывать эти внутренние идентификаторы к своему API. Интерфейсы не глобальны. Между собой (условно) не пересекаются. Когда нужен доступ к объекту метаданных - можно привести его к Интерфейсу и обращаться через API этого Интерфейса не заморачиваясь о том какие там идентификаторы и как их имена могут пересекаться с другими расширениями этого объекта (ведь там Интерфейс будет уже другой). Тут, конечно, очень много своих тонкостей - но их можно решать на уровне правильного декларирования и обновления, а не вводя кривых имён и префиксов.
Мощным принципом мог бы и быть принцип общих идентификаторов - определяющих заданную бизнес-сущность. Можно было бы вести общий список таких идентификаторов в рамках какого-то регистратора (их может быть много). Тогда, при необходимости использования такой бизнес-сущности в метаданных - её можно без опаски ввести под заданным именем - связав её с уникальным идентификатором общего идентификатора. Тогда - если произойдёт конфликт имён (скажем при установке нового модуля-метаданных или обновления существующего) и оба идентификатора будут связаны с одним и тем же уникальным идентификатором общей бизнес-сущности, то проверяется соответствие внутреннего API этих идентификаторов - если оно не противоречит зарегистрированному для общей бизнес-сущности (может быть расширенной) - то конфликта имён не будет - идентификатор будет единым для нескольких модулей-метаданных (но его API может быть расширен), и он будет иметь связи с со всеми такими модулями (при удалении всех модулей, с которыми он связан, он будет удалён из конфигурации). В рамках своего модуля-связи он будет ограничен API этого модуля (но может получить обобщённый API по явному запросу).
И это правильно - зачем в систему добавлять две одинаковые бизнес-сущности - чем бы они ни были - одинаковыми справочниками, реквизитами, макетами, модулями-алгоритмов, глобальными переменными/функциями...
Этим я хотел сказать - что префиксы (особенно слева) - это очень не красиво и очень ущербно - есть куда более красивые и надёжные решения (не претендуя на то, что всё что мной сказано - это лучшее из всех возможных решений - просто привёл своё мнение). И задал вопрос - почему префиксы именно слева. Но пока неявно получаю ответ - потому что так "истерически у кого-то зачесалась пятая нога"! Ведь началось всё ещё в 1С Предприятие 8.0 (да и даже в 1С Предприятие 7.7 наверное - просто уже плохо помню те времена, а сами префиксы метаданных тогда были куда менее распространены).
И в чём удобство префиксов именно слева - так никто и не объяснил (кроме - ну так же у всех - хотя и не всех так же). А я объяснил - почему считаю, что префиксы справа - это куда удобнее, чем префиксы слева!
Но если стандарты говорят - что всем нужно ходить строем, а "шаг влево шаг вправо - расстрел", и не объясняют почему строем ходить правильно, чем тоже друг за другом но в вразвалочку - да ну нафиг такие стандарты, даже если за их не соблюдение не дадут баланду - найдём сами что похавать (пока есть такая возможность и всех "строем насильно не выстроили пулемётными очередями")!
Но вот прямо сейчас я снова обновляю сильно доработанную конфу. И если бы вместо префиксов были бы суффиксы - я бы буквально глаза сломал.
Есть функция ИТМ_ЗаполнитьРезервамиПоЗаказуНаСервере. Но если бы она называлась ЗаполнитьРезервамиПоЗаказуНаСервере_ИТМ, то мне пришлось бы тратить время, чтобы прочитать все название процедуры, искать суффикс, а не доработанная ли это функция и нужно ли её оставлять или все же удалять.
Почему тебе так удобнее мне никогда не понять (наверное, ты просто не занимаешься обновлением). А переубеждать бессмысленно - у тебя своя правда.
Другое дело - что названная вами ситуация менее редкая, чем обращение к функции из текстов алгоритмов - значит даже если бы тут были неудобства - то они были бы меньше, чем неудобства при постоянном вводе алгоритмов.
И уже, тем более, плохо то - что такого рода чтения и мыслительная деятельность вообще требуется от программиста (как я понял - при обновлении конфигурации).
В идеале таких вопросов вообще быть не должно - такие функции не должны явно попадать в общий список сравнения содержимого модулей. А если попадают - то сразу должны быть особым образом выделены (да хоть цветом).
Но лучше - чтобы не пересекались - были расположены в отдельном модуле - но, увы, с иерархией (да даже с линейным списком, кроме общих) модулей - в 1С Предприятие 8 всё туго! А давно уже надо было ввести такую возможность, уже в 1С Предприятие 8.х добавить как любое число модулей объекта, менеджера, формы, команды, сеанса, приложения; так и иерархию этих модулей (вложенные друг в друга модули, с настраиваемой видимостью содержимого относительна владельца и подчинённых модулей) - это не ломало бы общую архитектуру 8-ки, а только подчёркивало то, что в ней можно создавать произвольное число подчинённых объектов метаданных, на ряду с табличными частями, макетами и формами (чего не было в 1С 7.7).
Для функций вообще их принадлежность можно было бы писать в комментариях (обычно я так и делаю, а не помечаю префиксом - тут вероятность пересечься по имени минимальная - а если и редко произойдёт - то несложно решается рефакторингом имени при обновлении). Вот комментарий тоже можно было бы выводить в списке функций в отдельной колонке (первую строчку с тегами первой, остальной комментарий доступен во всплывающей подсказке всего текста).
Всё это только подчёркивает ущербность платформы 1С Предприятие 8 - то что, её архитектура почти не развивается - и действительно полезных фишек в ней почти не появляется
Может тебе здесь не место?! :) В каком коде?! Каком модуле?!
Делаю обновление -> сравнение/объединение, поставщик конфигурации сильно поменял форму объекта.
Смотрю различия с учетом структуры - там сотня функций. Половина подсвечена красным. Как я должен понять, моя эта функция или поставщика? Удалять её или нет? Для таких глупых/криворуких и имеются стандарты - был бы там префикс, то я бы сразу пропустил её.
Делаю обновление -> сравнение/объединение, поставщик конфигурации сильно поменял форму объекта.
Смотрю различия с учетом структуры - там сотня функций. Половина подсвечена красным. Как я должен понять, моя эта функция или поставщика? Удалять её или нет? Для таких глупых/криворуких и имеются стандарты - был бы там префикс, то я бы сразу пропустил её.
Постараюсь быть ласковым и терпеливым к тем, кто освоил унылые мемы, но не освоил методику доработки объектов поставщика.
Итак. Если дорабатывается объект поставщика, то делается это через подписки и/или точки входа с вызовом функций из собственных (не поставщика) модулей. Таким образом, означенная в цитате проблема, есть проблема созданная "такими глупыми/криворукими" и героически ими же решаемая. Можете не благодарить.
Да даже речь не про это! Даже если ты добавил команду в своём кривом модуле и вызовешь его ПриСозданииНаСервере(), то сам обработчик команды у тебя без префикса будет - сам говоришь, что префиксу тут не место.
Повторюсь: может тебе все-таки тебе тут не место? После таких вот людей,
По существу. Зачем обработчику команды префикс не возьму в толк? В типовых есть точки входа, в общем то. Как правило обработчики в новых типовых имеют их. В старых - всё в твоих руках (после выпрямления, хе-хе). Ну если ты агрессивно считаешь, что курочить типовые объекты лучше, чем делать подписки, точки входа там где подписки невозможны, то не вижу смысла разговаривать. Невежество в сочетании с агрессией приводит к драке. Попробуй попить таблетки, чтобы хотя бы на людей не бросаться.
Если же у тебя просто не хватает некоторых знаний, то почитай например у Онянова, там вполне хорошие и структурированные требования по доработке. Некоторые моменты неоднозначные, но в целом всё здраво и обоснованно.
Тогда снова перечитай .
Перечитывай до тех пор, пока не "возьмёшь в толк":)
ЗЫ: И да, если ты не знал (видимо опыта не хватает), то не все формы типовых конфигураций имеют "точки входа".
Перечитывай до тех пор, пока не "возьмёшь в толк":)
ЗЫ: И да, если ты не знал (видимо опыта не хватает), то не все формы типовых конфигураций имеют "точки входа".
Посмеялся. Заскриню, иначе мне никто не поверит.
Статья из разряда эксперимента "безногий таракан не слышит" =)
Нет бы по-человечески объяснили бы, что группировка идет по измерениям в виртуальной таблице, поэтому только по ним и можно отбирать, если хотите такой же результат как при отборе нефильтрованной таблицы
Однажды объяснил парням про составные типы и необходимость использования функции Выразить. В итоге наблюдал такие запросы как во вложении
Функции Isnull, Выразить, ТипЗначения заменяются соответствующими операторами Is Null и Ссылка. Приводил в списке типичных ошибок прилагаемых к . Параграф 2.4
Так вам понты или ехать? Мне плевать на мнение тех, кто из-за модной, и оттого применяемой к месту и не к месту фичи, понижает производительность труда.
Почему так? Ответьте на вопрос и всё станет на свои места:
Вы можете в любой момент времени дать оценку адекватности и вообще объёму изменений в коде по сравнению с конфигурацией поставщика, в случае если все доработки помещены в расширения?
Как только такая возможность появится я буду первым, кто поддержит повсеместное использование расширений.
Сейчас же их обоснованная ниша это временные заплатки, до полноценного обновления конфы.
ххх_Товар
ххх_Контрагент
ххх_СкладПисать:
Товар_ххх
Контрагент_ххх
Склад_ххха вообще, у всех объектов метаданных и их свойств есть комментарий. Можно в нём увековечить имя автора. Как жаль, что за столько лет существования платформы, прикладные разработчики так и не научились использовать комментарии к метаданным
Очень скупое правило. Имена переменных и методов - главное оружие программиста. От выразительности имен переменных и методов сильно зависит легкость восприятия кода. На эту тему можно целую книгу написать
Рейтинг: 2222
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1442065
Создание 17.05.21 09:30
Обновление 17.05.21 09:30
Просмотры 23616
Загрузки 0
Рейтинг
143
Комментарии 100
Код открыт Да
Рубрики Рефакторинг и качество кода
Кому Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль 1С:Франчайзи, автоматизация бизнеса
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
