Не смотря на то, что платформа предоставляет богатые возможности для работы пользователей и разработки, некоторые из этих средств стоит использовать с ограничениями или не использовать вовсе
- Конструктор запроса в конфигураторе
Можно лишь предположить, что эта возможность появилась в конфигураторе в наследство от платформы 1С:Предприятие 7.7, запросы которой не имеют никакого отношения к SQL.
Вместо того, чтобы сделать нормальный диалог редактирования запроса с подсветкой синтаксиса и сохранением форматирования (впоследствии это появилось в EDT), было сделано средство для "простого" составления запросов.
Нужно учитывать, что для разработки более/менее сложного запроса конструктор не поможет, результирующий запрос получается со спорным форматированием. Конструктор запроса создает ложное чувство того, что запрос оптимальный, отчего возникают запросы с кучей лишних временных таблиц, передачи десятков тысяч строк на сервер и полного непонимания того, как он будет работать.
Был даже комичный случай на курсах получения сертификата "1С:Эксперт по технологическим вопросам". Экзаменатор в конце курса спросил слушателей о том, встречались ли они в своей практике с медленными запросами, которые не удалось упростить. И один из слушателей стал рисовать на доске окно конструктора запросов!
- Объект СхемаЗапроса
Конструктор запроса в худшем его представлении. Вместо того, чтобы реализовать вложенные функции для выборки данных (типа Справочники.Справочник1.Выбрать().Отобрать().Сгруппировать()) был создан интерфейс для конструктора запроса. Просто забудьте что есть такой функционал и удаляйте его отовсюду где его видите
- Директива #Область внутри функции
Так как платформа позволяет создавать только ограниченное число модулей для каждого объекта или формы, директива #Область больше всего подходит именно для разделения модуля на логические части. Использование директивы #Область внутри функции всегда можно заменить на вызов функции, поэтому ее появление там будет всегда неожиданным
- Использование переводов функции НСтр()
К сожалению платформа не поддерживает хранение многоязычных строк за пределами кода модуля, но хранение переводов внутри модуля еще хуже. Лучшее решение - замена функции НСтр() на вызов любой другой глобальной функции, например ЛСтр(), а внутри ее реализовывать получение представления на других языках по основному языку. Для выявления всех локализованных строк достаточно выгрузить все модули в файлы, заменить ЛСтр(<строка>) на НСтр("ru='<строка>'"), загрузить в другую конфигурацию и воспользоваться функцией конфигуратора "Редактирование текстов интерфейсов". Хранить переводы можно как в регистре сведений, так и в макете
- Флаг "Устанавливать права для новых объектов" у роли
Не смотря на то, что его использование кажется очевидным, он несет кучу проблем при добавлении в информационную базу других конфигураций, каждая из которых может иметь свою систему ограничения прав доступа.
- Редактирование условного оформления в свойствах управляемой формы
Не смотря на то, что условное оформление управляемой формы имеет сходный синтаксис с условным оформлением для отчета имеется принципиальные различия:
- Условные оформления более сложные и часто используются общие процедуры для их установки
- При переименовании реквизитов объекта метаданных или формы требуется быстро найти все места их использования
- Требуется создание динамических условных оформлений, которые добавляются/удаляются в зависимости от значений реквизитов объектов
Из за этих проблем условное оформление для формы стоит определять исключительно в коде
- Запуск фоновых заданий из незавершенной транзакции
По-умолчанию, если запустить фоновое задание из транзакции, она начнет выполняться немедленно. Сложно представить себе задачи, в которых это может потребоваться, поэтому запускать фоновые задачи из транзакции необходимо только через блокируемый регистр сведений
- Сохранение данных строки при интерактивной отмене редактирования
Достаточно нелогично, что отменяя изменения строки на самом деле отменяется только значение в текущей ячейке. Поэтому необходимо всегда при начале редактирования сохранять все поля текущей строки в переменной модуля, а при отмене изменений восстанавливать.
- При удалении значения реквизита формы вызывается событие ПриИзменении вместо события Очистка
Конечно есть ряд случаев, когда очистка значения поля не должна считаться изменением значения реквизита, например когда очистка означает заполнение значением по умолчанию, но чаще всего очистка значения ничем не отличается от функции Очистить, поэтому если при очистке планируется задавать вопросы, то же самое необходимо делать в обработчике ОкончаниеВводаТекста анализировать значение параметра Текст и если он пустой - выполнять те же действия, что и Очистка.
- Системное перечисление КодировкаТекста
При записи некоторых типов объектов (например ТекстовыйДокумент) в качестве кодировки текста можно указать в том числе значения КодировкаТекста.OEM и КодировкаТекста.ANSI. По замыслу разработчиков система должна получать правильные значения кодировки на основании локали пользователя. Вот только если используется англоязычная версия Windows данный подход не работает и вместо русских символов будут выведены символы ?. Если на при вызове на клиенте это можно исправить изменением локали, то на сервере смена локали не помогает. Кто-то делает какие-то настройки в реестре, но самый правильный подход - никогда не использовать значения этого перечисления, проще указать конкретную кодировку в виде строки и быть увереным, что приложение будет правильно работать на любом окружении
- Странная логика при сравнении/объединении конфигурации с файлом
Если при обновлении конфигурации поставщика поиск выполняется по идентификатором объектов метаданных, то при сравнении/объединении сначала выполняется поиск по имени. Из-за этого если существующий объект метаданных или реквизит был переименован и добавлен новый с таким же именем будет выполнено неправильное сопоставление. Приходится запоминать все такие случаи и при сравнении / объединении делать привязки вручную.