Как писать запросы в 1С без ошибок: Практика использования чек-листа для код-ревью

Введение: Простой секрет качества кода

«А вы делаете очевидные вещи?» — этот вопрос психолога, прозвучавший на одном из корпоративных вебинаров, стал отправной точкой для выработки подхода к качеству кода в компании SmartMaster Lab. Как часто разработчики, зная теорию, на практике пропускают элементарные ошибки? Ответом на этот вызов стал чек-лист — тот самый инструмент, который помогает системно делать «очевидные вещи» и не забывать о них под давлением сроков.

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

Зачем нужен чек-лист для запросов?

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

Чек-лист решает несколько ключевых проблем:

• Унификация: 4 разработчика в одной команде — это 4 разных подхода. Чек-лист приучает к единому стилю.

• Обучение: Новый разработчик, сталкиваясь с незнакомым термином в чек-листе (например, «декартово произведение»), вынужден его изучить, тем самым прокачивая свои навыки.

• Сознательное нарушение: Иногда правила приходится нарушать из-за срочности. Но с чек-листом разработчик делает это осознанно, фиксируя «технический долг», который нужно будет вернуть и исправить.

Категории ошибок в запросах: ТОП проблем из реальной практики

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

1. Оформление и чистота кода

• Неиспользуемые поля: Частая ошибка, особенно после правок в устоявшемся запросе. «Засоряет» код, усложняет чтение и может негативно сказаться на производительности при работе с большими таблицами.

• Игнорирование функции ПРЕДСТАВЛЕНИЕ: Не нужно тащить «ссылку», если в конечном счете требуется только ее текстовое или числовое представление. Это лишняя нагрузка на систему.

• Таблицы без выборки полей в ЛЕВОМ СОЕДИНЕНИИ: Такое соединение интерпретатор игнорирует, что делает код неочевидным. Хуже того, если в условиях используется поле из такой таблицы, это может привести к логическим ошибкам.

2. Ошибки в логике

• Сложные условия в ЕСЛИ: Когда в одно условие «впихивается» составное выражение, части которого сами по себе могут быть NULL, результат становится непредсказуемым. Правильное решение — вынести каждую часть в отдельное поле или подзапрос, а затем собрать итоговое условие.

• Декартово произведение: Сознательное или случайное перемножение таблиц без условия соединения — грубая ошибка, ведущая к резкому падению производительности.

3. Элементы оптимизации

• Протягивание поля через половину запроса: Классический пример — когда условие отбора, которое можно было бы применить в параметрах виртуальной таблицы в начале, «тащится» через все уровни запроса и применяется только в самом конце.

• Лишние временные таблицы: Автор метко называет это «размазыванием логики тонким слоем по тарелочке». Вместо того чтобы сделать два ЛЕВЫХ СОЕДИНЕНИЯ, разработчик создает две временные таблицы, усложняя и без того сложный запрос.

• Дублирование кода: В запросах это так же актуально, как и в конфигурации. Повторяющиеся блоки условий или соединений — повод остановиться и подумать над рефакторингом. В команде автора за дублирование кода грозит «прилюдный выговор».

4. Неоднозначность интерпретации

• Поля из других таблиц в условиях соединения: Самый «холиварный» пункт. Речь идет о ситуации, когда третья таблица соединяется не с первой, а через поле второй. Хотя SQL-сервер часто справляется с этим, такая конструкция может быть неоднозначно интерпретирована платформой 1С. Внутри компании договорились делать соединения явно, чтобы избежать потенциальных рисков и повысить читаемость.

Культура качества: Как внедрить и использовать чек-лист?

Опыт SmartMaster Lab показывает, что успех зависит не только от самого списка правил, но и от процесса его интеграции в работу команды.

1. Живой документ: Чек-лист — не догма. Он должен храниться в общем доступе (например, в Confluence) и пополняться новыми пунктами по мере обнаружения ошибок.

2. Визуализация: К правилам стоит добавлять примеры «как не надо» и «как надо». Это снимает 90% вопросов от коллег.

3. Автоматизация + ручная проверка: Такие инструменты, как SonarQube, отлавливают множество ошибок (соединение с виртуальными таблицами без параметров, разыменование). Но многие логические и стилистические ошибки может найти только человек во время код-ревью.

4. Работа с «зубодробительными» запросами: Если запрос занимает 5000 строк и содержит 50 временных таблиц, ревьюить его целиком — миссия невыполнима. Здесь помогает подход из больших ERP-систем: выносить части запроса в отдельные представления (views), которые ревьюятся независимо друг от друга.

Заключение

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

Как сказал докладчик, цель — не идеал, а прогресс: «Надо хотя бы вот это вот сделать, выучиться, постоянно вот это в голове держать, и уже ситуация нормализуется».

Полезные материалы, упомянутые в докладе:

• Стандарты написания кода от фирмы «1С» (на infostart.ru).

• Доклад Дмитрия Дудина «Infostart 2019 – Пишем правильно, красиво, сложно».

• Доклады и курсы Артема Кузнецова (Syntech) по оптимизации запросов.

• Книга «Экспертные оценки в технике 1С».