Результаты ревью кода 1500+ решений каталога Инфостарт: наиболее частые ошибки разработчиков в коде

10.04.24

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

Поделюсь своим опытом аудита кода авторских продуктов с Infostart.ru как одним из элементов применения DevOps-практик внутри Инфостарт. Будет настоящий код, боевые скриншоты, внутренние мемы от команды ИТ-лаборатории Инфостарт и прочее мясо – все, что любят разработчики.

Статья будет длинная, располагайтесь поудобнее. Статья написана на основании доклада с конференции Infostart Event.

 

 

Введение

 

Меня зовут Артур Аюханов, я технический директор Инфостарта.

Я давно занимаюсь программированием – у меня 23 года опыта разработки на разных языках.

Примерно столько же лет я занимаюсь 1С и ревностно отношусь к соблюдению стандартов по написанию кода – часто их пересматриваю и стараюсь применять.

Написал много правил статического анализа кода – все, кто пользуются статическим анализом, скорее всего, знают об том, что много моих правил в проекте BSL LS – Реализация Language Server Protocol для языка 1C (BSL). И так же немало моих правил в известном платном плагине статического анализа кода 1С для SonarQube.

Читаю много кода. Люблю его читать, люблю находить неожиданные вещи. Учусь на этом коде.

Часто провожу ревью кода соискателей, которых мы принимаем на работу к себе или в соседние отделы. Мы даем код соискателю: «Посмотри и исправь – сделай выданный код максимально похожим на тот код, который ты обычно пишешь». Человек меняет, мы обсуждаем, находим какие-то проблемы или, наоборот, замечательные вещи.

Наверняка слышали шутку для разработчиков: «Пишите код так, чтобы его не стыдно было показать маньяку, который знает ваш адрес». На одном из собеседований я задал соискателю вопрос: «А вы готовы этот код маньяку отдать?.. Мне )» Получилось смешно.

Со мной на собеседовании был мой товарищ Александр Кунташов, он это запомнил и в какой-то момент оформил стикеры в Телеграме. На слайде – один из таких стикеров. Другие стикеры из этого стикер-пака я буду приводить по ходу моей статьи.

 

Пример пользы код-ревью для передачи знаний.

 

 

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

Не так давно, просматривая код, который был в одном из решений в Инфостарте по интеграции с Avito, я увидел нестандартное использование метода ЧтениеXML.ОткрытьФайл().

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

Я заинтересовался – как так? Не может быть! Автор ошибся!

Просмотрел синтакс-помощник, поискал информацию в книге «Технологии интеграции 1С:Предприятия 8.3», на интернет-ресурсах, изучил описания обновлений платформы 1С – не обнаружил никакой информации. Всюду написано, что метод читает только локальные файлы.

Потом я подумал, что у 1С еще много мест, где используется метод ОткрытьФайл(). Но это уже недоиследовал, к сожалению. Если кто-то проверит и остальные объекты, у которых возможен вызов метода ОткрытьФайл, я буду очень рад.

Как видите, читая код, мы можем узнавать что-то новое.

Для меня эта история с ОткрытьФайл() стала открытием. Я много лет с 1С – писал и на 7.7, и на 8.х, начиная с 8.0, но не знал о такой возможности. Когда она появилась, мне также неизвестно.

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

Я примерно представляю, каким образом обсуждаемая функциональность пролезла – наверняка разработчик 1С использовал какую-то библиотеку С++, в которой и реализована подобная возможность единым образом для файлов и интернет-ссылок. Аналогичные реализации есть и для других языков.

Мое предложение к фирме «1С» – не убирайте обсуждаемую функциональность, а просто добавьте описание в руководство разработчика и синтакс-помощник.

 

Про Инфостарт и новый сервис 1С-Store

 

 

Немного напомню, что такое Инфостарт.

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


 

Сейчас у Инфостарта появился в пилотном варианте новый сервис 1С-Store, который развивается совместно с фирмой «1С» и работает на мощностях площадки Инфостарт.

Сервис 1С-Store работает в базах у конечных пользователей, но низом там идет демо-площадка, с которой, возможно, многие из вас на Инфостарте знакомы. По специальной кнопке «Демо» можно зайти и вживую посмотреть продукт на типовой конфигурации 1С в режиме веб-клиента.

Преимущество сервиса 1C-Store в том, что весь ваш код, который попадает в базы к конечным пользователям, предварительно проверяется на соответствие функциональным и нефункциональным требованиям. Когда я говорю «ваш код», я подразумеваю, что кто-то из вас, читателей, является автором решений на Инфостарт. У нас есть:

  • Набор автоматических тестов, которые проверяют ваши решения – пока проверяются только внешние обработки и отчеты.

  • Статический анализ кода, который проверяет ваш код на соответствие набору стандартов 1С – не всем стандартам, естественно, потому что готовых правил не так много. Плюс есть проверки по безопасности – чтобы код, который приходит к пользователю, не нарушал требования по безопасности. Часть используемых правил мы выложили в открытый доступ, сделав очередной вклад в опенсорс-проект BSL LS

  • Ручной аудит кода. Очень много кода сейчас проходит именно через глаза сотрудников Инфостарта. Мы изучаем, смотрим, нам помогают правила статического анализа. И мы видим большую часть кода, хотя раньше мы на него не смотрели. Я по себе сужу – раньше я выборочно проверял какие-то решения. Зато сейчас уже любой файл, который автор обновляет на сайте, приходит к нам, и мы видим код ваших решений.

Расскажу непосредственно о коде и о результатах его проверки.

 

Требования к решениям

 

 

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

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

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

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

 

Типовые замечания к коду решений

 

Есть набор типовых проблем, которые встречаются практически у всех авторов.

  • Любимый всеми нами копипаст – мы все его используем.

  • Закомментированный код – действительно тонны кода. Иногда у нас есть какой-то блок кода, который нас не устраивает, но мы его не удаляем. Думаем, что он нам еще пригодится, чтобы потом оттуда что-то скопировать. Или оставляем т.н. «авторские комментарии».

    • Все эти подходы уже устаревшие – используйте Git, и вам не понадобятся авторские комментарии.

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

    • А чтобы посмотреть историю изменений, лучше использовать Git.

  • Опечатки – как обычно, всякие «внтрений», «мссив», «тблица». «Граммар-наци» (с) в моем лице часто грустит и возмущается.

  • Отступы в коде – частенько не соблюдаются, или есть путаница с пробелами и табуляциями при их одновременном использовании.

    • или разработчики не любят ставить пробелы перед операторами вида «+», «=» и т.п.

  • Неиспользуемые функции. Часто пишутся функции, которые никогда никем не используются. Написали и забыли про них. В коде решения и так много строк, и это пропускается.

  • Ну и аналогично пишутся функции, которые являются процедурами – зачем-то их делают функциями. Зачем – непонятно.

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

 

Простой способ создания внешних файлов для типовых конфигураций

 

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

Нужно просто создать в модуле объекта экспортную функцию СведенияОВнешнейОбработке по формату, описанному на слайде.

Есть шаблон для создания внешних отчетов и обработок, которые подключаются в базу данных по стандартам БСП. Шаблон очень простой – всего 13 строк.

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

Если вы хотите прочитать об этом шаблоне подробнее, есть статья в документации к БСП.

Сначала я думал привести здесь ссылку на какую-нибудь статью на Инфостарте, но затем, вчитавшись в текст статьи 1С:ИТС о программном интерфейсе БСП, увидел, что там отлично разобраны все виды внешних отчетов и обработок. Можно оттуда черпать знания и писать правильно.

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

И добавлю пояснение небольшого нюанса, о котором авторы часто забывают – в структуре, возвращаемой в СведенияОВнешнейОбработке, есть два поля:

  • Наименование

  • Комментарий

Оба этих поля являются служебными, их можно увидеть только в справочнике «ДополнительныеОтчетыИОбработки». Оба поля можно не заполнять – они автоматически будут заполнены из «представления объекта метаданных» и «комментария объекта метаданных» внешней обработки\отчета.

 

О безопасности

 

 

Напомню, что по умолчанию внешние отчеты и обработки подключаются в безопасном режиме. В этом режиме 1С не дает возможности выполнить часть операций – сохранить файл, обратиться к интернету, FTP и т.п. Режим полезен для простого исключения опасных действий.

Но очень часто авторы зачем-то отключают безопасный режим во внешних печатных формах или обработках, даже если их решения работают только с базой – не обращаются к внешним сервисам, не читают и не записывают никакие, даже временные, файлы. Все равно отключают в сведениях о внешней обработке безопасный режим. Зачем? Непонятно. Возможно, по привычке.

По таким решениям у администраторов систем и аудиторов кода возникают вопросы и увеличивается недоверие к решению.

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

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

Для помощи командам разработки и аудиторам решений на языке 1С я сделал специальное правило «Отключение безопасного режима», которое находит несколько вариантов отключения безопасного режима для внешних файлов. Пока это правило не в релизе BSL LS – до сих пор, с июля 2023 года оно находится на стадии код-ревью. У нас в Инфостарте это правило работает примерно с мая-июня 2023 и мы активно его используем для аудита решений Инфостарт для сервиса 1C-Store, ссылка на мой пул-реквест с правилом.

 

 

Самое правильное – это вообще не включать безопасный режим. Или включать точечно, если вы работаете с файлами или с интернетом. Для этого нужно использовать «РаботаВБезопасномРежиме.РазрешениеНаХХХ».

Например:

Разрешение = РаботаВБезопасномРежиме.РазрешениеНаИспользованиеВнешнейКомпоненты(

"ОбщийМакет.КомпонентаПечатиШтрихкодов",

"Печатная форма со штрихкодом");

ПараметрыРегистрации.Разрешения.Добавить(Разрешение);

Самое важное – нужно всего лишь задокументировать это поведение в публикации.

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

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

 

Привилегированный режим

 

 

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

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

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

Когда авторы устанавливают привилегированный режим при формировании печатной формы, наверное, они не хотят задумываться о том, как будет вести себя их печатная форма или обработка, если ее запустят под разными правами. Просто пишут: «УстановитьПривилегированныйРежим(Истина)». Но забывают, что пользователь может увидеть то, что ему не положено – то, что ему явно запретили администраторы системы.

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

Проверять ваше решение перед установкой на боевую систему будут те же самые люди – администраторы систем 1С и аудиторы кода решений. И если вы используете привилегированный режим, шансы вашего решения пройти аудит уменьшаются. Оно будет выглядеть вдвойне подозрительно – зачем в нем выводятся лишние данные?

Для помощи командам разработки и аудиторам решений на языке 1С я сделал специальное правило «Использование привилегированного режима», которое проверяет на установку привилегированного режима. Пока это правило не в релизе BSL LS, хотя пул-реквест я отправил еще в марте 2023 года. У нас в Инфостарте это правило работает примерно с марта 2023 и мы активно его используем для аудита решений Инфостарт для сервиса 1C-Store, ссылка на мой пул-реквест c правилом.

 

 

Рекомендации с моей стороны:

  • Включаем привилегированный режим точечно и только на небольшие блоки кода – ни в коем случае не на все методы и не на весь текст метода

    • т.е. в начале метода формирования печатной формы не стоит включать привилегированный режим

  • И для 1С-Store в тексте публикации нужно обязательно документировать: почему привилегированный режим включается, для каких целей и на какие данные включается – важно понимать, какие именно данные будут получаться без учета прав.

Напомню, что в стандартах 1С есть стандарт по использованию привилегированного режима.

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

По стандарту мы сначала должны выполнить проверку прав доступа, а только потом установить привилегированный режим.

Указанный способ позволяет правильно выполнить проверку прав – если права позволяют выполнить операцию, только тогда устанавливается привилегированный режим. При этом и код стал более производительным, и ограничения соблюдаются!

 

 

Обработка ошибок и исключений

 

 

Поделюсь своими мыслями по моей самой любимой и наболевшей проблеме в разработке 1С – обработке ошибок и исключений. Дело в том, что с исключениями вообще мало кто из разработчиков работает правильно, наблюдаю подобное уже много лет, на ревью кода глаза автоматически выцепляют проблемный код обработки ошибок )

Исключения – это любые ошибки, которые возникают в ходе работы. Обычно мы либо их пропускаем, либо каким-то образом перехватываем в блоке «Попытка… Исключение».

Но если мы их неправильно обрабатываем, то:

  • мы теряем информацию об ошибке;

  • мы вводим в заблуждение администраторов системы, потому что администраторы системы – те, кто поддерживает систему – не знают о проблеме, которая возникает;

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

Рассмотрим конкретные примеры.

Самая частая ошибка – это пустой блок исключения.

 

 

На слайде выше приведены два реальных примера кода.

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

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

Мой коллега Василий назвал этот пример «стилем глухой попытки». Причем Василий просил упомянуть, что «мопед не мой» (с), т.е. он – не автор этого кода, он только дал подобному стилю название.

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

 

 

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

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

Или второй вариант – разработчики решений 1С очень любят сообщать об ошибках только тому пользователю, который сейчас работает с системой. И что? Пользователь прочитал, ужаснулся, не понял ошибку, закрыл и всё. И точно так же никакой администратор не узнает о том, что возникли проблемы.

 

 

Приведу еще один пример боевого кода – я в нем ничего не удалял, ничего не убирал.

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

  • Здесь нечестный комментарий, который говорит, что дальше там будет исключение. Но реально-то никаких исключений нет – автор по какой-то причине написал комментарий, а потом внизу проброс исключения закомментировал.

  • Опять используется «Сообщить()», но никаких данных для администратора никуда не пишется.

  • Закомментированный код – как обычно.

  • И проблема с «корявой» \ сложной сборкой строки сообщения – в случае, когда можно прекрасно использовать СтрШаблон().

 

 

Еще один, уже более продвинутый вариант.

Здесь разработчик уже знает, что использовать ОписаниеОшибки() не нужно, а нужно использовать ИнформацияОбОшибке(), и применяет КраткоеПредставлениеОшибки(ИнформацияОбОшибке()).

Но использует-то все равно неправильно – просто сообщает пользователю. Администраторы системы всё так же не узнают о проблеме.

 

 

Следующая ошибка практически такая же.

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

Если мы покажем ошибку в поле формы, пользователь легко закроет эту форму, и информация об ошибке опять потеряется.

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

На втором скриншоте всё то же самое. Казалось бы, вот оно – внутри блока обработки исключения вызывается исключение с описанием ошибки. Автор подобного кода может считать, что код без изъянов, т.к. выполняется передача исключения из исключения, т.н. «проброс исключения» – это хороший шаблон.

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

 

 

У фирмы «1С» есть отличный и полезнейший стандарт «Перехват исключений в коде»,

Есть правило BSL Language Server, которое реагирует на пустой блок Исключение – выдает ошибку, если в Исключении пустой блок кода или комментарий. Правда, если там будет хоть что-то написано в виде Сообщить() или будет любой блок кода – правило не сработает.

Я придумал, как улучшить подобное поведение – я сделал специальное правило, которое выдает замечание, если внутри кода-обработчика исключения и в вызываемых методах нет записи в системный ЖР, у нас в Инфостарт это правило прошло обкатку и работает уже несколько месяцев. В ближайшее время я выложу пул-реквест с этим правилом в репозиторий BSL LS.

Что я советую для правильной обработки исключений:

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

  • Как я уже говорил, не нужно перехватывать ошибку только для того, чтобы показать сообщение пользователю  – кстати, об этом явно написано в стандарте. Не нужно выдавать ошибку через Сообщить(), платформа и так покажет необработанную ошибку.

  • Самое важное – всегда нужно фиксировать ошибки в ЖР. Практически любые ошибки, кроме незначащих ошибок конвертации, когда мы приводим значение к какому-то типу, крайне желательно писать в ЖР и фиксировать ошибки через метод ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()).

  • Для выявления ошибок использования записи в ЖР я написал ещё одно правило «Неверное использование метода ЗаписьЖурналаРегистрации» в BSL LS, которое контролирует правильность создания ЗаписьЖурналаРегистрации() для работы в исключениях.

  • Если вы обработали исключение, и нужно передать его данные дальше, тогда выполняем какие-то действия и в конце просто вызываем метод без параметров:
    ВызватьИсключение;
    Я специально здесь выделил точку с запятой – никаких параметров метода, ничего дополнительного, передавать не нужно. В этом случае абсолютно все данные, которые нужны системе, включая стек ошибок, будут переданы наверх. Если ошибку дальше перехватят, весь контекст ошибки будет получен в том месте, где будет перехвачена ошибка. Вы не потеряете данные ошибки, а значит, вы правильно обработали ошибку.

  • В стандарте есть два шаблона обработки ошибок – пункты 3.1 и 3.3.

 

 

Вот так выглядит шаблон обработки ошибок по п.3.1 стандарта – если имеется некоторая серверная бизнес-логика, которая вызывается с клиента при интерактивной работе пользователя.

На сервере в блоке Исключение записываем в журнал регистрации ошибку и ее контекст:

  • Событие «Выполнение операции».

  • Уровень – Ошибка или Предупреждение, но скорее всего Ошибка.

  • Передаем подробную информацию об ошибке через ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()).

  • И пробрасываем исключение на клиент через ВызватьИсключение;

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

 

 

А вот так выглядит шаблон обработки ошибок по п.3.3 стандарта – если исключение возникает при обработке какой-то клиентской бизнес-логики.

Обратите внимание, если есть клиентская логика, даже без вызова серверной функции, рекомендуется сделать специальный серверный метод с директивой &НаСервереБезКонтекста, в котором вызвать метод ЗаписьЖурналаРегистрации(). Этот приём и важен, и полезен.

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

Вообще для меня загорается красный сигнал, если я вижу ОписаниеОшибки() – явно что-то не так.

 

Принципы – решения с изменением данных

 

 

Теперь немного остановлюсь на принципах, которые я рекомендую использовать в решениях, где изменяются данные.

  • Самое главное – используйте логирование. Я специально выделил на слайде три раза это слово!

    • Пишите события в журнал регистрации: начало изменения данных, всю детальную информацию о том, какие данные конкретно меняете. Если меняете 10 документов, напишите по каждому документу, что его поменяли. Обязательно!

    • Сообщайте пользователю о действиях, которые выполняете – не обо всех действиях, естественно. Пишите о каких-то сводных данных: время начала, обработали 10 документов, время окончания. А уже в ЖР распишите детально все, что нужно.
      Как я уже говорил, не нужно хранить ошибки на форме. Это можно делать, но только как дополнение. Основная информация об ошибках должна отражаться в ЖР или в каких-то сервисах – благо сейчас есть возможность передавать информацию об ошибках во внешние сервисы.

  • Правильно используйте обработку ошибок в конструкции Попытка…Исключение.

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

  • Используйте таймауты для внешних сервисов. Про таймауты часто забывают, когда создают HTTP или FTP-соединения – не указывают таймаут, а это важно. У фирмы «1С» и для такого есть замечательный стандарт. В нём даже есть рекомендации, для каких операций какое время таймаута выбирать. Обязательно изучите.

  • И еще один важный момент. Если мы делаем обработки для изменения данных, имеет смысл использовать мой любимый принцип TDD – сначала тесты, потом интерфейс или код. Сначала нужно написать некий серверный код. Идеально, конечно, тесты, но если тестов вдруг по каким-то причинам нет, нужно сначала написать серверный код и потом только под него нарисовать форму. Или наоборот – можно нарисовать форму, но с минимальным кодом. Форма должна вызывать только серверные методы – никакой бизнес-логики на клиенте быть не должно. Делаем серверный API и через него работаем. Я так уже много лет работаю – очень удобно.

Именно эти принципы я рекомендую использовать для разработки решений по изменению данных – кратко: логирование, транзакции, Попытка-Исключение и серверный API.

 

Любимое – работа с файлами

 

 

Перехожу к следующим интересным и любимым ошибкам.

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

Это неправильно, потому что сервер и клиент – это разные машины. О подобной разнице нужно всегда помнить. Конечно, для файловой базы это не так, но нужно затвердить у себя в голове, что сервер и клиент – это всегда разные машины. Тогда не будет вопросов и проблем!

Конечно, на файловой базе легко разрабатывать, но при использовании файловой базы вы постепенно начинаете забывать, что у вас клиент и сервер – разные машины.

Если ваше решение рассчитано на работу многих пользователей, оно должно работать в клиент-серверной машине – иначе у пользователя возникнет ошибка, потому что на сервере по этому пути, скорее всего, файла не окажется.

 

 

У упоминаемой ошибки есть различные варианты.

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

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

Но хуже всего – вариант с абсолютными путями. Такие тоже неожиданно встречаются в решениях Инфостарта.

На слайде пример – зачем-то в универсальной обработке так сделано. Причем автор выложил это не как полуфабрикат, а как готовое решение.

При просмотре подобного кода у меня в голове всегда возникает стикер: «Результаты отличные – все красное».

 

 

Резюмирую главное по работе с файлами на клиенте-сервере:

  • Никогда не забывайте, что клиент и сервер – это разные машины. Даже когда работаете с файловой базой – все равно считайте их разными машинами.

  • Никогда не передавайте клиентские пути файлов на сервер или обратно с сервера на клиент.

    • Я хочу сделать правило BSL LS, чтобы контролировать эту ошибку. Но для BSL LS его реализовать тяжело – мы ничего не знаем о том, какого типа у нас переменная. В EDT все-таки проще, там у нас есть контекст, возможно, когда-нибудь я или кто-то другой добавит правило для EDT.

Ну и напомню, как можно обойти проблему, если нам нужно каким-то образом передать данные с клиента на сервер. Есть несколько простых, известных вариантов:

  • Через двоичные данные. Загружаем файл в двоичные данные, потом передаем во временное хранилище и читаем на сервере из временного хранилища.

  • Или можно непосредственно передавать файлы на сервер – есть специальные методы НачатьПомещениеФайлаНаСервер, НачатьПомещениеФайловНаСервер, НачатьПолучениеФайловССервера и их асинхронные варианты. Очень много методов, причем часть из них в 8.3.15 уже перестали поддерживаться – нужно использовать именно асинхронные варианты. В фирме «1С» добавили функциональность и зарезали ее через несколько релизов, но приходится ее поддерживать и указывать в синтакс-помощнике, а мы потом мучаемся, путаемся.

 

Любимое – производительность на клиенте\сервере

 

 

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

Очень часто в методе ПриОткрытии вызываются серверные методы, хотя фирма «1С» специально для этого сделала замечательный метод ПриСозданииНаСервере.

Конечно, иногда есть причины что-то вызывать с клиента, но лучше сразу разделить контекст, чтобы форма открывалась быстрее – формы-то бывают разные.

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

 

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

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

А еще лучше делать внеконтекстный серверный вызов и передавать на сервер только нужные параметры. Так будет еще быстрее.

 

 

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

Кстати, раньше, когда мы создавали команду еще в 1С:8.2, можно было выбирать между вариантами «Создать на клиенте» и «Создать на клиенте и процедуру на сервере». А потом, в какой-то версии 8.3, фирма «1С» добавила возможность выбора варианта «Создать на клиенте и процедуру на сервере без контекста».

Так вот, часто забывают – делают простые серверные методы, в которых данные формы не используются. Это лишняя нагрузка на сервер 1С, но авторы довольно редко задумываются о производительности своего кода.

 

 

Главный принцип написания клиент-серверного взаимодействия – любой серверный вызов нужно валидировать.

Об этом есть стандарт 1С и несколько правил – в BSL LS и в АПК, по-моему, тоже.

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

Проверяем серверный метод:

  • нужно ли его вызывать;

  • можно ли его сделать внеконтекстным;

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

И еще есть важный момент, о котором, возможно, мало кто знает. В серверном методе параметры, которые не изменяются, желательно передавать через Знач. Т.е. добавляем Знач для всех параметров, которые не должны меняться в серверном методе.

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

В стандарте немного об этом есть, правда, совсем чуть-чуть. Я написал правило «Передача параметров между клиентом и сервером» для BSL LS, которое это проверяет – подробнее об этом правиле можно прочитать в тикете с описанием правила. Рекомендую использовать это правило, оно уже входит в набор диагностик BSL LS, если я не ошибаюсь. У нас в Инфостарт используется с марта 2023 г.

 

Сладкое – хардкод

 

 

И почти финальное – на сладкое.

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

Я уже показывал пример с указанием сетевого пути для имени сервера, но оказывается, есть еще код «еще лучше» – когда в решении ищутся конкретные номера документов с конкретными датами. На слайде код из настоящих решений на сайте.

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

А про опасность хардкода логинов, паролей и IP-адресов, я надеюсь, и так все понимают – в BSL LS для этого тоже правило давно есть, ошибочный код давно ловится.

 

Сладкое – как быстро добавить свои правила анализа кода

 

 

Не раз уже упомянутый BSL LS – это замечательный проект и инструмент, я сам очень его люблю, но у этого проекта есть одна проблема – его мейнтейнеры считают, что BSL LS – это не диагностики. Коллеги сами редко делают новые правила, и очень медленно принимают предложенные сообществом диагностики в проект. А нам, разработчикам, командам, нужны новые правила. Я сам стараюсь добавлять новые правила, но это не так легко, как хотелось бы.

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

Еще в 2021 году в BSL LS появилось правило BadWords – «запрещенные» слова. Для этого правила можно указать параметр – регулярное выражение, а в регулярном выражении вы можете указать любой текст, который хотите проверить. Например, вы можете искать вызовы каких-то методов платформы, которые вам или вашей команде кажутся подозрительными.

Если вы этот параметр указали, у вас SonarQube начнет выдавать замечания на код, в котором есть эти методы или эти слова.

Кстати, это правило работает и в комментариях, и в коде, и в этом небольшая проблема у правила, т.к. искомое ищется практически везде, а не только в коде. Я сделал доработку правила, добавив параметр для поиска только внутри кода, мой пул-реквест уже принят, но пока еще не в релизе BSL LS.

Я использую правило как дополнительный показатель, метрику аудита – то, что должно сработать, чтобы на это обратили внимание, чтобы техлид или разработчик посмотрел, что это за код, отмеченный замечанием правила. Может быть, это внешний код, в котором используются какие-то запрещенные методы – например, УдалитьДанныеИнформационнойБазы. Любому разработчику сразу понятно, если такой метод вызывается – это решение подозрительное. Если это внешняя печатная форма, которую принес подрядчик – это подозрительно.

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

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

 

Итоги

 

 

Самое главное:

  • Любите свой код;

  • Ухаживайте за ним;

  • Соблюдайте нефункциональные требования – помните, что код должен выполняться не только правильно, но и быстро, качественно, быть безопасным;

  • Читайте стандарты 1С и статьи на Инфостарте;

  • Пишите статьи на Инфостарте, пожалуйста;

  • Пользуйтесь теми инструментами, которые люди придумали для вас: SonarQube, BSL LS и другие средства статического анализа и DevOps-практик.

И моя любимая фраза: «Лучше день потерять, а потом за пять минут долететь!»

Дай Бог, чтобы ваш код был замечательным, и не вызывал проблем при аудите у нас в Инфостарте.

To be continued …


P.S. Используйте стикеры Телеграм, используемые в статье, и повышайте качество своего кода!

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Ниндзя-код

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

Предлагаю вашему вниманию советы мастеров древности. Программисты прошлого использовали их, чтобы заострить разум тех, кто после них будет поддерживать код. Гуру разработки при найме старательно ищут их применение в тестовых заданиях. Новички иногда используют их ещё лучше, чем матёрые ниндзя. Прочитайте их и решите, кто вы: ниндзя, новичок или, может быть, гуру? (Адаптация статьи "Ниндзя-код" из учебника JavaScript)

01.04.2024    2673    DrAku1a    15    

35

Практическое программирование: когда скорость важнее совершенства

Рефакторинг и качество кода Бесплатно (free)

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

01.04.2024    718    Prepod2003    6    

2

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

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

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

18.03.2024    1455    ZhokhovM    4    

4

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

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

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

18.03.2024    3149    ZhokhovM    4    

9

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

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

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

29.09.2023    2227    1CUnlimited    15    

23

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

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

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

27.09.2023    7419    Lemmonbri    136    

37
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. dsdred 3345 10.04.24 12:01 Сейчас в теме
Спасибо за статью. Доклад был замечательный!
kuntashov; artbear; +2 Ответить
2. biimmap 1917 10.04.24 12:08 Сейчас в теме
Разработка всегда начинается с требований


Позволь не согласиться с данным термином! Проектирование начинается с требований. А разработка с продуманных сценариев.
Nelli_A86; Baszilio; +2 Ответить
3. biimmap 1917 10.04.24 12:38 Сейчас в теме
Хочу предложить ещё одну тему в список ошибок, это блокировки. У 1С где-то (честно не помню где) написано, что при обращении к данным регистра накопления нужно блокировать регистр...

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

Статья огонь! Вроде по чек-листу у меня только с исключениями неверная работа. Правильный путь посмотрел) Но это осознанный путь, я чётко знаю в какой момент происходит ошибка и для его я написал это исключение.
20. artbear 1547 10.04.24 15:50 Сейчас в теме
(3)
Статья огонь! Вроде по чек-листу у меня только с исключениями неверная работа. Правильный путь посмотрел) Но это осознанный путь, я чётко знаю в какой момент происходит ошибка и для его я написал это исключение.


Спасибо за лестную оценку

Хотелось бы понять подробности про осознанный путь и чёткое знание
на примере с расшифровкой

исключений в правильной обработке исключений крайне мало стоит допускать )
22. biimmap 1917 10.04.24 15:54 Сейчас в теме
(20)
Хотелось бы понять подробности про осознанный путь и чёткое знание
на примере с расшифровкой


Думаю тебя будет сложно убедить))) Воздержусь. Но идея с логированием и записью в тех журнал да интересная. Но я с ним пока не работаю)
4. user1876070 19 10.04.24 12:58 Сейчас в теме
А если ЖР не ведётся, то зачем в него писать?)
androidT1C; +1 Ответить
21. artbear 1547 10.04.24 15:51 Сейчас в теме
(4) расшифруйте про "не ведётся ЖР"

а как вы об ошибках узнаете?
только от пользователей?
82. Serg O. 269 25.04.24 10:08 Сейчас в теме
(21) Журнал регистрации это хорошо, но надо его контролировать ЕЖЕДНЕВНО
и желательно на автоматической основе - скидывая отчеты в файл или на почту всем кому надо.

так как Некоторые "очень умные" админы периодически берут ... и просто удаляют файлы ЖР !?
причём иногда не со зла, а типа "я только кэш почистил"... создав новую папку для базы с новым ЖР.
видел такое много раз в своей жизни. ЖР сис.админы не любят - им он не нужен в принципе.
да и никому не нужен если туда никто не смотрит никогда.

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

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

так что с логами и Журналами Регистрации и Тех.Журналом в особенности - нужно очень аккуратно работать и ежедневно его (автоматически) контролировать - иначе никакого прока от них нет.
и все эти журналы слишком много места жрут ...
40. Vovan1975 13 11.04.24 11:34 Сейчас в теме
(4)тут даже более интересный вопрос - если ЖР настроен не отображать то событие с которым вы программно пытаетесь записать сообщение в ЖР - оно запишется или нет?
64. artbear 1547 15.04.24 14:31 Сейчас в теме
(40)
тут даже более интересный вопрос - если ЖР настроен не отображать то событие с которым вы программно пытаетесь записать сообщение в ЖР - оно запишется или нет?

я уверен, что запишется. когда-то очень давно проверял, но результаты не помню )
5. gybson 10.04.24 13:25 Сейчас в теме
Не везде так файлы открываются
Адрес = "https://infostart.ru/1c/articles/2085824/";
ТД = Новый ТекстовыйДокумент();
ТД.Прочитать(Адрес);

Файл не обнаружен 'file://https://infostart.ru/1c/articles/2085824/'


P.S. В приведенном коде есть замечание автору. Кто заметил - молодец.
8. artbear 1547 10.04.24 13:49 Сейчас в теме
(5)
P.S. В приведенном коде есть замечание автору. Кто заметил - молодец.

видимо, я, автор, не молодец, не вижу замечание )
14. gybson 10.04.24 15:08 Сейчас в теме
(8) "магическая строка" в параметрах вызова бьет по глазам
даже если уж совсем никак, то все-равно вынести в переменную надо
83. Serg O. 269 25.04.24 10:15 Сейчас в теме
(8) видимо имеется ввиду, что текстовый документ ... не умеет читать с http: ...
это может делать например HTTPЗапрос(),
а ТекстовыйДокумент() читает только в локальной сети (ну и с FTP максимум)
33. ixijixi 1810 11.04.24 10:11 Сейчас в теме
(5) ЧтениеТекста работает
0x00; artbear; +2 Ответить
6. nemec 18 10.04.24 13:38 Сейчас в теме
Я конечно дико извиняюсь, не то что не гуру кода, а так слесарь по вызову на полставки, и тем не менее - безопасный режим во внешних обработках отключают обычно по одной простой причине - чтобы работала инструкция УстановитьПривелигированныйРежим()
7. artbear 1547 10.04.24 13:46 Сейчас в теме
(6) нет, это предположение неверно )

чаще всего обычно отключают просто по привычке!
просто помнят, что в безопасном режиме работать неудобно )
сам так делал Н-лет назад!

а следующие причины уже использование прив.режима, работа с внешними сервисами и т.п.
Дмитрий74Чел; +1 Ответить
9. nemec 18 10.04.24 13:54 Сейчас в теме
(7) Сужу по себе, потому что обработки пишу под много разных конфигураций и зачастую точно знать какой пользователь с какими правами будет пользоваться в дальнейшем - в принципе невозможно, клиенты все равно сделают всё неправильно. Поэтому перед запросом ставится УстановитьПривелигированныйРежим() как метод решения головной боли
11. starik-2005 3046 10.04.24 14:50 Сейчас в теме
(9)
Поэтому перед запросом ставится
А почему бы в запросе не ставить "РАЗРЕШЕННЫЕ"?
Oxygraphis; kpotoyalo; +2 Ответить
15. nemec 18 10.04.24 15:12 Сейчас в теме
(11) запросы ко всяким служебным данным, которые доступны только под полными правами, тоже через разрешенные делать? Пользователь их не увидит, но допустим они нужны для работы логики. Клиенты у меня в основном простые как кирпич, смысла в RLS их загонять почти никогда нет и если вернуться к изначальному тейку - УстановитьПривилегированныйРежим обычно главная причина снятия с безопасного режима
17. artbear 1547 10.04.24 15:40 Сейчас в теме
(15)
УстановитьПривилегированныйРежим обычно главная причина снятия с безопасного режима


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

"умные==хитрые" менеджеры или бухгалтеры многое могут узнать (
34. Vovan1975 13 11.04.24 11:18 Сейчас в теме
например потому что запрос в привилегированном режиме выполняется без "перчинки" рлс что делает его быстрее
10. user1950534 10.04.24 14:39 Сейчас в теме
Еще бесит, когда вместо функции делают процедуру и передают/получают в параметрах по ссылке, причем параметров штук 10 и половина из них структуры)))

Бесят матрешечные вызовы из 2-3 промежуточных экспортных процедур, каждая по 1 строке кода.

А чем СтрШаблон лучше классической конкатенации строк через + - я так и не понял? На 7.7 еще отцы и деды наши соединяли строки через СокрЛП(Строка1) + СокрЛП(Строка2). Никто не умер, чем этот ваш СтрШаблон лучше?))

Ну и хотелось бы открыться и поговорить начистоту. Я до сих пор пишу синхронные методы вроде "Вопрос", А потом через меню Рефакторинг преобразую в асинхронные вызовы. Это сильно плохо?
androidT1C; SirStefan; mrsmrv; muskul; artbear; +5 Ответить
12. starik-2005 3046 10.04.24 14:51 Сейчас в теме
(10)
соединяли строки через СокрЛП(Строка1) + СокрЛП(Строка2). Никто не умер, чем этот ваш СтрШаблон лучш
Как минимум тем, что СтрШаблон в разы быстрее. А если просто соединить, то лучше массив в СтрСоединить.
синхронные методы вроде "Вопрос"
А почему бы сразу не писать ВопросАсинх?
user975273; Поручик; artbear; +3 1 Ответить
13. user1950534 10.04.24 15:00 Сейчас в теме
(12) А, ну если быстрее то да, другой разговор. Буду переучиваться.

Можно сразу писать Асинх конечно. Но дольше. И нейминг выдерживать стандартный придется. А тут раз - и через менюшку оно само летает))
23. ubnkfl 10.04.24 15:59 Сейчас в теме
(13) Я буквально на прошлой неделе разобрался с этим Асинх / Ждать и понял, что это практически то же самое, что было раньше в синхронном режиме. Потратьте на ролики пол-часа буквально, этого хватит, чтобы начать писать по новому )
Serg O.; artbear; +2 Ответить
29. starik-2005 3046 10.04.24 18:11 Сейчас в теме
(13)
Асинх конечно. Но дольше.
Ctrl+Пробел спасает.
По поводу Асинх, то вообще статейку как-то писал: https://infostart.ru/1c/articles/1746248/
46. DmitryKSL 155 11.04.24 15:17 Сейчас в теме
(13)
А, ну если быстрее то да, другой разговор. Буду переучиваться.

Не торопитесь...
Прикрепленные файлы:
shu_vol; zqzq; Andreeei; +3 Ответить
52. Redokov 81 12.04.24 10:44 Сейчас в теме
(46) На одном вызове делать выводы нельзя. Нужна статистика, чтобы можно было делать выводы. Хотя бы тысячу раз метод вызвать и посмотреть разницу
71. Vovan1975 13 16.04.24 18:57 Сейчас в теме
(46)хочешь медленно писать неэффективный код - пиши по стандартам от один цэ!

угар конечно
18. artbear 1547 10.04.24 15:44 Сейчас в теме
(10)
Ну и хотелось бы открыться и поговорить начистоту. Я до сих пор пишу синхронные методы вроде "Вопрос", А потом через меню Рефакторинг преобразую в асинхронные вызовы. Это сильно плохо?


Спасибо за честность )
хороший трюк!

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

лучше, конечно, на Асинх переходить, но в них есть свои крайне неожиданные заморочки )
27. kuntashov 449 10.04.24 17:27 Сейчас в теме
(10)
Я до сих пор пишу синхронные методы вроде "Вопрос", А потом через меню Рефакторинг преобразую в асинхронные вызовы.


Это классный лафхак! :D
39. mrsmrv 127 11.04.24 11:33 Сейчас в теме

Еще бесит, когда вместо функции делают процедуру и передают/получают в параметрах по ссылке, причем параметров штук 10 и половина из них структуры)))

Бесят матрешечные вызовы из 2-3 промежуточных экспортных процедур, каждая по 1 строке кода.

(10) Это же... Все типовые. Это как при расследовании выйти на самих себя!
Спасибо за коммент. Это именно что Зло!!!!!!
shu_vol; androidT1C; +2 Ответить
16. Поручик 4677 10.04.24 15:24 Сейчас в теме
Кто бы ещё платил за вылизывание кода.
shu_vol; so-quest; корум; mshi; Fox-trot; +5 Ответить
19. artbear 1547 10.04.24 15:48 Сейчас в теме
(16)
Кто бы ещё платил за вылизывание кода.

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

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

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

у каждого свои причины
kuntashov; +1 Ответить
28. RocKeR_13 1329 10.04.24 17:56 Сейчас в теме
(19)
или можно перейти на другую работу

Напомнили мне комментарий по поводу нынешней ситуации со ставками на ипотеку (для тех, кому льготная не положена):

Ну да, из-за ставки ЦБ сейчас ипотека дорогая. Но у нас же есть различные программы типа дальневосточной, арктической или в новых регионах - можно же переехать!


Не все способны работать продуктивно на удаленке, а что-то альтернативное найти в своем регионе - это достаточно сложно, если речь не идет о Москве (хотя и там не знаю, как обстоят дела).
Что касается качественного кода: за других сказать не могу, но писать качественный код - это удовольствие, особенно когда к нему возвращаешься спустя N месяцев) К этому нужно стремиться, но и с другой точкой зрения согласен: порой просто не успеваешь банально комментарии к экспортным процедурам/функциям написать по стандартам
61. artbear 1547 15.04.24 14:24 Сейчас в теме
(28)
но и с другой точкой зрения согласен: порой просто не успеваешь банально комментарии к экспортным процедурам/функциям написать по стандартам

нужно привыкнуть к тому, что любой экспортные метод - это ваше публичное АПИ
и стоит заранее продумывать, что же должен сделать метод

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

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

Исключение одно - методы-оповещения, которые гарантированно не предназначены для внешнего вызова.

Правило из бсл лс умеет исключать подобные методы-оповещения
66. RocKeR_13 1329 15.04.24 15:41 Сейчас в теме
(61) В проектах для Инфостарта сейчас всё так и делаю и это прям удовольствие доставляет (видимо, где-то внутри сидит перфекционист)). А вот во франче с этим совсем сложно: это либо сильно за свой счет, либо заказчик недоволен предварительной оценкой сроков выполнения. А если даже и за свой счет брался (с заделом на более простую дальнейшую поддержку), то сильно не укладывался в сроки. На каких-то средних проектах в принципе часто удается найти "золотую середину".
31. gybson 10.04.24 22:29 Сейчас в теме
(16) Не платят и не будут. Это вопрос личной гигиены, каково вам с таким кодом.
artbear; kuntashov; +2 1 Ответить
35. Vovan1975 13 11.04.24 11:24 Сейчас в теме
(16) тут проблема в том что "качество кода" это откровенно неопределенная херня
atseparate; +1 1 Ответить
42. GenAcid 11.04.24 12:32 Сейчас в теме
(16) Ну, за откровенные косяки, вроде "Попытка ... Исключение КонецПопытки;" скорее всего кто-то рано или поздно заплатит. Вопрос в том, будет эта переделка дешевой и запланированной, или внезапной и вероятно уже не такой дешевой.
24. biimmap 1917 10.04.24 16:11 Сейчас в теме
Кстати возник вопрос:

Сейчас я написал обработку для переноса из ЗУП 2.5/УПП в ЗУП 3. С точки зрения загрузки вообще всё равно откуда данные прилетят, т.к. это шаблоны Excel (SAP, Axapta, ERP...).

Так вот вопрос в чём: если добавить в загрузку логирование, на сколько это затормозит работу загрузчика. Данные и так сутками грузятся... Что произойдёт? Есть таблиц где сотни тысяч записей.
59. artbear 1547 15.04.24 14:17 Сейчас в теме
(24)
Так вот вопрос в чём: если добавить в загрузку логирование, на сколько это затормозит работу загрузчика. Данные и так сутками грузятся... Что произойдёт? Есть таблиц где сотни тысяч записей.

Стоит использовать разные виды\уровни логирования.
Не всегда логирование должно дублировать все действия и тем более данные!
часто достаточно фиксировать только промежуточные операции, начало очередного этапа
25. oreshekk 10.04.24 17:04 Сейчас в теме
26. Erne100 286 10.04.24 17:04 Сейчас в теме
"Самое важное – всегда нужно фиксировать ошибки в ЖР. "

Спорным выглядит слово "Всегда"

Если бы это было стандартом от 1С, то наверное не было в типовых
столько серверной логики построено на попытках
(в т.ч и без обработки исключений и/или логирования в ЖР).
Я уже даже остановку по ошибке в отладке боюсь использовать из-за этого.

А иногда при проведении типового документа в попытке, вывод пользователю и запись в ЖР будет сделан в самом документе. Зачем дублировать?

P.S. Статья огонь!
zqzq; ixijixi; +2 Ответить
36. Vovan1975 13 11.04.24 11:25 Сейчас в теме
(26) ЖР тоже имеет определенную пропускную способность увы.
zqzq; androidT1C; Andreeei; +3 Ответить
38. mrsmrv 127 11.04.24 11:31 Сейчас в теме
(36) ООО да. при удалении записей регистров 30% времени отнимает как раз журнал регистрации. Отключение его помогает быстрее почистить базу.
60. artbear 1547 15.04.24 14:20 Сейчас в теме
(26)
А иногда при проведении типового документа в попытке, вывод пользователю и запись в ЖР будет сделан в самом документе. Зачем дублировать?

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

поэтому и стоит писать в ЖР проблему на своем уровне, с собственным комментарием, пояснением ошибки согласно выполняемой операции.

Естественно, на практике стоит выбирать разные подходы, но запись в ЖР ошибок должна быть всегда !
30. RustIG 1631 10.04.24 22:28 Сейчас в теме
Если есть обратная связь от тех, кто скачал-воспользовался-и дал обратную связь, то почему бы не сделать, не добавить, не улучшить код и функционал.
А так статья - непонятно - призыв к чему?
Обратной связи на Инфостарт не хватает. У меня выборка небольшая.... Но те, кто ко мне обращался, я всегда улучшал и подсказывал как лучше сделать им самостоятельно. В большинстве случаев, никто не обращается за доработками - сами дорабатывают.
Я бы обратил внимание Инфостарт на то, что от самих скачавших нет обратной связи: от простого - поставить плюс и написать отзыв, до сложного - подробно расписать ситуацию - версию конфы, версию платформы, сделать скриншот, описать сценарий ....

Есть еще один момент - кто-то пишет о стандартах на ИТС (кто -то же написал их на ИТС), а кто-то встречает в типовых такие непонятные алгоритмы, механизмы и логику, что никакой стандарт не спасет от костылей... То есть кто-то в компании 1С радеет за стандарты, а остальные разработчики делают по своему - не по стандартам... А нам, внедренцам, приходится с этим как-то уживаться: и в грязь не падать - изучать стандарты и писать по ним, и не замечать "нестандартных" решений в типовых решениях....
32. siamagic 11.04.24 00:18 Сейчас в теме
Настоящий программист ленив от природы, версия бсп берется стандартной функцией как и идентификатор и представление команды.
62. artbear 1547 15.04.24 14:28 Сейчас в теме
(32)
версия бсп берется стандартной функцией как и идентификатор и представление команды

версию БСП лучше указывать самому, вручную
Этим автор указывает, какую версию БСП и его подсистемы по доп.отчетам\обработок он будет использовать.

если в будущем БСП будет использовать другой механизм, при помощи подобного указания решение автора точно будет работать, т.к. в БСП сохранят совместимость со старой версией

правда, пока что таких кардинальных не было, кроме одного бага, если указать версию ниже 2.3
- статья на Инфостарте https://infostart.ru/1c/articles/1951623/
37. mrsmrv 127 11.04.24 11:30 Сейчас в теме
Статья полезная.
Но в БПО - обработка исключений, из самых низов сообщается пользователю и всё.

Написано про дублирование кода. Но про вызов одного и того же по нескольку раз не очень описано в статье, а это тоже зло. Например в Типовой УНФ, вызов функции общего модуля налогиУНФ.НалогообложениеНДС при создании нового документа ЗаказПокупателя производится 4 раза.
63. artbear 1547 15.04.24 14:29 Сейчас в теме
(37)
Но в БПО - обработка исключений, из самых низов сообщается пользователю и всё.

разработчики нарушают стандарт 1С, бывает и такое (
41. user1950534 11.04.24 11:36 Сейчас в теме
(29) У меня нет Асинх, я на 15й платформе, бро(

И да, я факаюсь с проблемами вроде того, как направить ПриЗаписи или особенно ПриЗакрытии по другой ветке алгоритма, если юзверь ответил на Вопрос "да нет не знаю"))

И поэтому особенно в последнее время стал злоупотреблять рефакторингом и шаблонами....
44. starik-2005 3046 11.04.24 13:09 Сейчас в теме
(41)
У меня нет Асинх, я на 15й платформе
Так большинство типовых уже требуют 20+, а ты на 15-й. У нас жуткий легаси-проект с 8.1 еще, но и мы уже на 24-ю переезжать планируем на днях с 22-й.
45. user1950534 11.04.24 14:30 Сейчас в теме
(39)
(44) это к начальству вопросы, что касается меня то я хоть бэтту 28ю завтра готов накатить))
43. sergey279 112 11.04.24 12:54 Сейчас в теме
Хорошая статья, молодец!

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

Смотри как просто заговнить чужой труд =)
корум; artbear; +2 Ответить
65. artbear 1547 15.04.24 14:35 Сейчас в теме
(43)
А не кажется ли что использование недокументированных возможностей, как чтение по интернет ссылке ведет к риску ее отключения со стороны вендора при очередном обновлении платформы. Ведь он обязательства через выпуск документации на себя не брал. И судя по мисте у данной фичи есть особенность, если мы начинаем перемалывать данные быстрее чем загрузиться файл то ловим ошибку, т.е. попадаем в зависимость от размера файла и скорости соединения.

конечно, если фича недокументирована, ее могут отключить в любой момент.

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

а что за обсуждение на мисте?
скиньте ссылку в личку
47. karpik666 3784 11.04.24 16:38 Сейчас в теме
Привет, Артур, спасибо за статью и выступление, очень интересно.
BSL LS отличная штука, сам периодически пользуюсь ( (раньше часто использовал phoenix bsl, где нужно просто проанализировать текущий код)), и тем самым повышая свой уровень кода, всего не упомнишь, и без проверки можно многое упустить при разработке. Главное такие знания вспоминать и применять на практике, а то все со временем забывается. Но некоторые проверки отключаю, например, проверка на устаревшие функции, или проверка
чтобы строковые литералы обязательно были помещены в конструкцию НСТр.

Не хочу быть "адвокатом дьявола", но не все так категорично:

По поводу "глухой попытки" - когда-то ранее в типовых наличие свойства у объекта проверяли через попытку: обратились к свойству, если исключение, то значит свойства нет, чуть позже пришли к созданию структуры со свойством, и через ЗаполнитьЗначениеСвойство() проверяют если свойство заполнено, то значит оно есть у объекта, довольно оригинально. Да и в принципе помню есть ряд моментов, что исключение это лишь повод
использовать другой способ обработки данных, и его необязательно куда-то записывать и вызывать, либо исключение оказывается гораздо быстрее, что проверка на валидацию данных.

Про открытие XML по интернету: Использование недокументированных возможностей - это зло. Хотя помню как передавали таблицу значений с сервера на клиент через метод сообщить, и потом преобразовывали ее из ЗначениеИзСтрокиВнутр():)

Отмечу также, что ряд проверок не учитывают ни версию БСП, ни версию платформы, ни конфигурацию, для которой разрабатывается решение. То есть у нас всегда должна быть актуальная платформа, и желательно ERP, но не все так радужно для разработчика какого-нибудь собственного решения.
Если у тебя не жесткая зависимость одна конфигурация определенной версии - одно решение, то тебе уже приходится как-то извращаться, чтобы твое решение работало и на Бухгалтерии актуального релиза, и на какой-нибудь допотопной УНФ, или вообще на обычных формах. В такие моменты начинаешь ценить, что в синтакс-помощнике есть информация, с какой именно версии платформы появилась функциональность, те же самые таймауты на http соединение тоже появились не сразу, плюс некоторые функциональности работают по-разному в разных режимах совместимости платформы.
Или вот рекомендация по поводу использования ДополнительныеОтчетыИОбработки.СведенияОВнешнейОбработке(). Разработчики не от хорошей жизни использовали по началу такую конструкцию, ведь в БСП по факту не было подобного варианта реализации, не было готовой структуры, которую можно вызывать, так и приучились. А кто хочет переучиваться, если итак все работает? Отсюда выходит, что проблема не от того, что не хочешь писать красивый код, а слишком много знаешь, и повидал такого в типовых, что волосы дыбом.

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

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

Кстати, "функции, которые являются процедурами – зачем-то их делают функциями" - это делается для того, чтобы можно было вызывать их при отладке через "ВычислитьВыражение" :)
Torin; artbear; +2 Ответить
48. Fox-trot 158 11.04.24 22:20 Сейчас в теме
повеселил автор, конечно, зачет
требовать за работу стоимостью три копейки логирования и прочих плюшек - это прям врожденный пмщик должен быть, не меньше
а тем более требовать какую-то там совместимость со своими продуктами и при этом упоминать универсальность решений. ни это ли противоречие? у мну куча конфигураций без каких-либо бсп. для чего прикажете вписывать ваш шаблон подключения?
статья огонь, но по мне огонь какой-то нарисованный как у известного папы
Vovan1975; Andreeei; mixsture; atseparate; Gaffer; +5 1 Ответить
49. Gaffer 85 11.04.24 22:26 Сейчас в теме
Я может сейчас крамольную вещь скажу, но для 90% разработчиков 1С верную.

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

Ну камон, ребята, если вы не разрабатываете тиражное решение или потенциально хитовую разработку для выкладки на Инфостарт, то какой смысл городить все эти асинхронные вопросы и многопоточные исполнения, если вы автоматизируете конторку на 200-500 человек и 5-7 пользователей?

Очень редкий заказчик поймет и оценит, если ты ему выставишь 30 часов за то, что можно сделать за 3-4 с минимальной оптимизацией. Он этот отчет раз в квартал запускает. И ты потратишь 25 часов high-paid разработчика, чтобы сэкономить 7 минут в год бухгалтерше по материалам. Класс.

Понятно, что совсем уж дичь писать нельзя, типа хардкода или запросов в цикле, но упарываться по соблюдению стандартов там, где это не нужно, не ценится и не оплачивается - совершенно точно перебор.
sys1c; Andreeei; mixsture; Fox-trot; +4 Ответить
50. kuntashov 449 11.04.24 23:33 Сейчас в теме
(49) Так в статье речь не об упарывании при соблюдении буквы стандартов, а об элементарной гигиене, как правильно выше написали.
51. Gaffer 85 12.04.24 02:05 Сейчас в теме
(50) не знаю, где как, но в наших провинциальных палестинах использование GIT и подключение внешних обработок в безопасном режиме не то что к гигиене не относится, это вообще никто, нигде и никогда не применяет.

Повидал многие-многие десятки проектов от детских садов до контор, где был договор с контрагентом на 1.1 трлн.руб - все работают по-старинке в Конфигураторе, никто в глаза не видывал эти ваши столичные EDT, СонарКубы, Ванессы, ГИТы, анализаторы кода и прочие приколдесины.

Люди просто делают дела, быстро, эффективно и без заморочек. Появляются проблемы - решают по месту. Непрофессиональную ерунду стараются не писать, уровень абстракции поддерживают на достаточном уровне, пишут самодокументируемый код с комментариями там, где они оправданы. Вот и все.
user715892; HectorPrima; atseparate; +3 1 Ответить
53. Redokov 81 12.04.24 10:54 Сейчас в теме
(51) Распространенное заблуждение. Особенно в части

Люди просто делают дела, быстро, эффективно и без заморочек.


Возможно быстро и без заморочек, но откуда понятие эффективно, если нет никаких метрик?

Непрофессиональную ерунду стараются не писать


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

А когда ревью станет обычным делом, то легко сможете подключить сонар или АПК и удивитесь сколько замечаний прилетит.
artbear; kuntashov; +2 Ответить
55. gybson 12.04.24 11:32 Сейчас в теме
(51) Это к коду вообще отношения не имеет. Это инструменты производства любого кода, хоть чистого, хоть грязного.
В чудеса "быстро, эффективно, дешево" не знаю кто еще верит. Наверное те, кто газету "Водолей" читают и в гороскопы верят.
kuntashov; +1 Ответить
54. gybson 12.04.24 11:14 Сейчас в теме
(49) 90% и не должны много зарабатывать.
56. twiny 15 13.04.24 15:37 Сейчас в теме
Коллеги, поясните, все-таки
По тексту у вас есть рассказ про новый параметр BadWords в БСЛ ЛС и тут же начинаете ссылаться на Сонар.
Насколько я понимаю, это 2 разных продукта и правила Сонара и БСЛ ЛС - это 2 разных правила по форме.
57. kuntashov 449 13.04.24 18:41 Сейчас в теме
(56)
Насколько я понимаю, это 2 разных продукта и правила Сонара и БСЛ ЛС - это 2 разных правила по форме.


Сонар (SonarQube) - это инструмент проверки кода. Ядро Сонара реализует общие универсальные механизмы + GUI, а сами проверки кода реализуются плагинами - для каждого языка программирования свой плагин.

Под BSL LS в беседах 1Сников чаще всего понимается группа продуктов с открытым исходным кодом, ядром которых является давший им имя BSL Language Server - реализация универсального Language Server Protocol для языка 1С (и OneScript).

Одним из продуктов группы BSL LS как раз и является плагин SonarQube 1C (BSL) Community Plugin, который реализует поддержку языка 1С в Сонаре.

Итого, когда выше в публикации говорится, что в диагностики BSL LS добавлено новое правило BadWords, то в контексте упоминания Сонара это означает, что эта диагностика также доступна в плагине SonarQube 1C (BSL) Community Plugin. Подключив этот плагин к Сонару вы сможете проверять код на 1С, в том числе при помощи диагностики BadWords.
58. Cyberhawk 135 13.04.24 19:08 Сейчас в теме
автор из клиентского метода ПриОткрытии получает данные по организации, хотя для этого гораздо удобнее использовать обработчик ПриСозданииНаСервере
Это было бы справедливо, если бы между этими двумя событиями в платформе не было никаких других.
А так есть еще пара событий загрузки настроек формы на сервере, которые как раз вклиниваются между созданием на сервере и открытием на клиенте и которые легко могут перекрыть логику, заложенную в "ПриСозданииНаСервере".
Поэтому делать что-то в "ПриОткрытии" - это самый надежный и контролируемый вариант (увы ценою лишнего серверного вызова).
zqzq; Fox-trot; +2 Ответить
68. artbear 1547 16.04.24 11:11 Сейчас в теме
(58)
Это было бы справедливо, если бы между этими двумя событиями в платформе не было никаких других.
А так есть еще пара событий загрузки настроек формы на сервере, которые как раз вклиниваются между созданием на сервере и открытием на клиенте и которые легко могут перекрыть логику, заложенную в "ПриСозданииНаСервере".
Поэтому делать что-то в "ПриОткрытии" - это самый надежный и контролируемый вариант (увы ценою лишнего серверного вызова).

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

чаще всего авторы просто не задумываются о подобных проблемах с производительностью клиент-сервер, к сожалению.
и делают так, как привыкли, о чем я и написал в статье )
69. Cyberhawk 135 16.04.24 11:47 Сейчас в теме
(68)
автор в своем решении полностью контролирует поведение
Сегодня он контролирует, а завтра уже нет: включит он или кто-либо еще сохранение данных в форме, поставит реквизиту флажок "Сохранение" и все - теперь надо вспоминать-анализировать, переопределялось ли в коде что-то в "ПриСозданииНаСервере" или нет, а если переопределялось, то адаптировать это.
В итоге весь этот контроль сводится к памяти или вниманию человека, поэтому в сопровождении дороже.

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

Поэтому исходный тезис про "гораздо удобнее (сделать на сервере)" не всегда справедлив, а стремление перенести логику из "ПриОткрытии" в "ПриСозданииНаСервере" тоже вполне можно окрестить "делают как привыкли"...
zqzq; Gaffer; +2 Ответить
67. mixsture 16.04.24 00:43 Сейчас в теме
Отвечу за претензии к логированию ошибок. Не потому ли эта тема игнорируется, что 1с предоставила в платформе крайне слабый функционал? А делать за нее этот функционал, да еще и в каждом решении - не очень-то хочется.
Давайте смоделируем идеальную поддержку логирования платформой:
1) логи нужны разным потребителям: пользователю, админу, разработчику. Значит одно событие должно иметь возможность быть кратко и целостно описанным для этих 3х потребителей. Не быть размазаным по коду как сейчас: тут для пользователя, в другой процедуре тож самое для админа, в третьей для разработчика.
2) логи замедляют работу программы, а поэтому должны иметь возможность отдельной настройки админом. Т.е. отдельные файлы настройки, не в коде. А еще и разделяться по-модульно - т.е. можно включить вот для этого модуля отладочный режим логов и заглянуть в них.
3) добавление записи в лог должно быть очень кратким, чтобы не мусорило бизнес-логику и не добавляло затрат разработчику. Стоит взглянуть на иерархичность настроек логгеров в других языках, на то, как они умеют собирать контекстные дополнительные переменные (а вовсе не пытаются при каждой записи лога эти переменные собрать в кучу)
4) у логов должны определяться хранилища, причем определяться админом (без мороки разработчика при написании кода). С возможностью детализации до каждого модуля/уровня события. Храним события "Ошибка" 30 дней в файле Х с ротацией каждого дня и запаковкой в zip, а события уровня "Инфо" храним 1 день.

Где все это в платформе 1с? Вот так и получилось, что полновесное логирование очень затратно для разработчика, бизнес в нем ценность видит не особо и все перебрасываются горячей картошкой.
zqzq; mshi; Gaffer; artbear; +4 Ответить
70. androidT1C 76 16.04.24 15:57 Сейчас в теме
Стандартный ЖР давно требует глубокого переосмысления. На больших объемах (гигабайты в сутки) он просто не работает. Даже возможности отключить запись определенных событий (например, выбранных регистров или справочников) 1С так и не сделала.
Приходится делать свой рег.сведений, и в нём фиксировать все ошибки. Большой минус такого подхода - это надо делать вне транзакции, что приводит к лишним вызовам фоновых заданий. Или изобретать велосипед в виде внешнего файла и последующего переноса в рег.сведений.
Ну и в целом, гнаться за нововведениями - такое себе занятие. Забавно читать, что устарели фичи, которые появились всего лишь несколько лет назад.
Бизнесу нужна стабильность, а не постоянное переписывание кода и гонка за стандартами.
kuzyara; Vovan1975; +2 Ответить
81. leemuar 24.04.24 13:33 Сейчас в теме
(70) если у вас гигабайты логов, и вам с ними нужно плотно работать - вам нужен внешний инструмент. Так же как вы переходите от встроенной СУБД к внешней при росте нагрузки.
72. triviumfan 94 16.04.24 20:08 Сейчас в теме
73. vikad 130 16.04.24 20:18 Сейчас в теме
(72) какие именно? В хроме все ссылки проверила, работают. У вас в каком браузере не работают? И как это выражается?
74. triviumfan 94 17.04.24 09:28 Сейчас в теме
(73) А сейчас работают. Тоже хром последней версии. Либо поправили, либо какой-то лаг браузера/сайта.
75. starik-2005 3046 18.04.24 08:14 Сейчас в теме
(46) А ничего, что Стр1 = "123" занимает 90%, хотя вроде бы что там такого, да? )))

Протестил у себя на линухе. Скорость конкатенации на "последней" платформе (8.3.23.1782) действительно выше, чем СтрШаблон. От размера строк зависит теперь мало. Видимо, 1С-неги с этим разобрались. Я - было время - много занимался выгрузкой/загрузкой текстов. Так вот на старых платформах (8.3.12 - точно) конструкция, собирающая в цикле стрку через конкатенацию работала на порядок медленнее, чем СтрШаблон. Не вспомню уже, почему не использовал СтрСоединить, которая доступна с 8.3.6, но какие-то причины были. Также может быть, что скорость зависила и от размера строк.
76. DmitryKSL 155 18.04.24 09:34 Сейчас в теме
(75) А ничего, что Стр1 = "123" занимает 90%, хотя вроде бы что там такого, да? )))
Ну очевидно же, разве нет?
Прикрепленные файлы:
корум; +1 Ответить
77. starik-2005 3046 18.04.24 11:02 Сейчас в теме
(76) А Вы точно до конца дочитали?
78. Slava_prog 19.04.24 08:56 Сейчас в теме
(49) Очередной раз вижу упоминание про то что запрос в цикле это плохо.
Но в типовых конфигурациях запрос в цикле используется.
В СКД при связке нескольких наборов данных под капотом тоже запрос в цикле.
Есть множество сценариев когда это нормально.
Почему Вы считаете что запрос в цикле это плохо ?
79. Slava_prog 19.04.24 09:56 Сейчас в теме
Очень полезно для повышения качества кода разрабатывать расширения для 1С:Фрэш.
Есть требования от 1С

https://1cfresh.com/articles/so_addprocess_req
https://1cfresh.com/articles/so_confext_req

Код проходит аудит, ваши навыки объективно оценят.
80. Gaffer 85 19.04.24 12:22 Сейчас в теме
(78) многократная выборка однотипных данных, подразумевающая чтение из СУБД это потенциально узкое место с точки зрения производительности. А если в цикле выполняется запрос, в котором нет чтения из СУБД (какие-то операции с временными таблицами, например, или арифметические расчеты), то на мой взгляд пофиг - будет это запрос в цикле или обычный программный цикл

В типовых много дичи, встречал даже реквизит объекта с именем "Документ")) на них ориентироваться можно, но с оговорками
84. siamagic 25.04.24 18:48 Сейчас в теме
(62) Хоть один пример укажите, кроме версии бсп ещё имяОбработки и команда - сразу видно автор школьник. К тому же его поделка не заведется на другой версии, вообщем писал человек без опыта.
Оставьте свое сообщение