1С:Предприятие 8
10.7K subscribers
53 photos
7 files
1.88K links
Канал обо всем, что связано с 1С. Для обратной связи @shalimski
Download Telegram
⚡️ Ozon Tech community 1C meetup

▶️30 марта | 18:00 мск
▶️ онлайн и офлайн в Москве

Обновим вашу базу знаний 1С бесплатно, без смс, но с регистрацией.

🟡Обсудим, как интегрировать 1С со смежными системами.
🟡Погрузимся в детали тестирования и посмотрим на красивые отчёты по тестам в их естественной среде обитания.
🟡Поговорим о разработке мастер-конфигураций.
🟡А ещё будет блок про новинки платформы 1С:Предприятие.

Вечер обещает быть если не томным, то уж точно насыщенным!

Зарегистрируйтесь, чтобы получить офлайн-билет или присоединиться к трансляции.
22 апреля 2023 Омск
V открытая конференция специалистов 1С в Омске. Предусмотрена онлайн трансляция. Регистрируйтесь на сайте конференции https://на1с.рф
КАК ВЫПОЛНИТЬ ПРОЦЕДУРУ В ОТЛАДКЕ?

Не баян, а классика.

Находясь в отладчике, мы можем вызывать функции (в т.ч. при помощи "Вычислить выражение").
Это бывает нужно для тестирования и выявления каких-то проблем. Например, сделать что-то с данными формы в закрытых полях и так далее.

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

Как же можно вызвать процедуру в отладке?
Для этого нам нужна функция. Самый простой пример:
Функция Вып(Код, Параметр = Неопределено) Экспорт
Выполнить Код;
КонецФункции

Функция может быть сложнее и удобнее в использовании. Главное, чтобы она вызывала метод платформы Выполнить(НашКод)

🤔 ГДЕ РАЗМЕСТИТЬ ВСПОМОГАТЕЛЬНУЮ ФУНКЦИЮ?

1️⃣ В своём инструменте
Да, самое очевидное - добавить метод там, где мы его будем использовать. В нашей обработке, например. Но такая функция будет доступна только внутри нашего инструмента. Не очень удобно

2️⃣ Общий модуль
Другой напрашивающийся способ - найти (или добавить) где-то в общем модуле. Это может потребовать доработки конфигурации или же установки расширения.

2️⃣ Внешняя обработка
Если бы всегда нам подходили первые два способа, то было бы не так интересно.
Но если мы по какой-то причине не хотим ставить расширение для таких целей, то можно пойти другим путём. Создать внешнюю обработку с таким же методом. Метод придётся разместить в модуле самой обработки и дополнительно в форме. Тогда он будет доступен и на сервере и на клиенте.

🤔 КАК ИСПОЛЬЗОВАТЬ ТАКУЮ ОБРАБОТКУ
Сначала нужно её открыть в режиме предприятия. Так мы "подключим" её к сеансу. А далее уже в коде можем создавать её объекты. Давайте выведем таким образом сообщение:

Для выполнения НаКлиенте можно делать так:
ПолучитьФорму("ВнешняяОбработка.Вып.Форма").Вып("Сообщить(Параметр)", "Текст");

А НаСервере так:
ВнешниеОбработки.Создать("Вып").Вып("Сообщить(Параметр)", "Текст")

Если же мы ведем отладку в фоновом задании, то открытие обработки в режиме предприятия нам не поможет. Но можно использовать и другой вызов:
ВнешниеОбработки.Создать("МойПутьКФайлу", Ложь).Вып("Сообщить(Параметр)", "Текст")

Главное в таком случае разместить обработку в доступном для сервера каталоге. Правда и тут может произойти проблема, если установлена "Защита от опасных действий". Тогда нужно при создании обработки передать ещё третий параметр - ОписаниеЗащитыОтОпасныхДействий. Для его создания обычно в типовых есть метод ОбщегоНазначения.ОписаниеЗащитыБезПредупреждений()

ВнешниеОбработки.Создать("МойПутьКФайлу", Ложь, ОбщегоНазначения.ОписаниеЗащитыБезПредупреждений()).Вып("Сообщить(
Параметр
)", "Текст")

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

_______________
@JuniorOneS
Please open Telegram to view this post
VIEW IN TELEGRAM
Длинные имена переменных – зло. 

Naming is hard. Это правда, и вот почему. Во-первых, у нас пока нет метрики, которая может сказать, что вот этот нэйминг плохой, а вот это хороший. Думаю через год или два ИИ линтер сможет предлагать варианты наименований. А пока выкручиваемся как можем.

Во-вторых, бытует мнение, якобы длинные и исчерпывающие имена – это хорошо. Чистый код на максималках такой. Например, readFileFromPathAndThrowExceptinIfNoSuchFile(Path absolutePathToFile). Ну круто же! Одна сигнатура уже говорит о том, что делается и тело метода даже читать не надо! Комментарии не нужны! 

В какой-то степени это имеет смысл. За неимением лучшего можно писать так. Но что, если есть более простой и лаконичный способ? Я говорю про правильное разграничение ответственностей. Абстракции короче.

В выдуманном примере смешиваются несколько уровней абстракции: формат ошибки (exception), представление пути в файловой системе (Path), формат пути (absolute). Все это повышает когнитивную нагрузку на читателя. Представьте себе сто строк кода, написанных вот в таком стиле дедушки Боба! Брр...

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

Мысль предельно проста. Давайте разделим код на уровни абстракции и будем использовать имена, которые соответствуют текущему уровню абстракции. Наверху у нас readFile, дальше идут проверки на корректность пути и бросание эксепшенов. Еще ниже сами придумайте. 

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