Чек-листы для проведения Code Review

Публикация № 1442065 17.05.21

Методология - Рефакторинг и качество кода

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

Введение

При внедрении Code Review, о котором я рассказывал ранее ( //infostart.ru/1c/articles/1364611/ ) мы за основу брали стандарт программирования, разработанного фирмой 1С. Для того чтобы с ним ознакомиться, необходимо прочитать соответствующий раздел на ИТС «Система стандартов и методик разработки конфигурация для платформы 1С:Предприятие 8» (https://its.1c.ru/db/v8std ). Обязательными к использованию являются все пункты. Это стандарт фирмы 1С. Все пункты важны, но мы выделили основные пункты и добавили свои пункты, все это переложили в чек-листы  для проведения Code Review (проверка кода), и это стал наш инструмент контроля соответствиям стандарта.

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

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

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

 

Чек-лист для проведения Code Review

 
 Стандарт комментариев.
 
 Форматирование (Заглавные буквы, пробелы и т.д.).
 
 Название объектов (переменные, модули, функции и т.д.). Грамматические ошибки.
 
 Архитектура решения доработки.
 
 Избыточность доработок.
 
 Дублирование кода (ООП).
 
 Проверять деление на «0», проверка на Неопределено.
 
 Проверка на тип (где это необходимо).
 
 Обращение через точку.
 
 Использовать Isnull в запросе.
 
 Не использовать запрос в цикле (кроме исключений).
 
 Использовать «Выразить» для реквизитов составного типа в запросе.
 
 Не использовать соединения с вложенными запросами.
 
 Использование условий в запросе в секции ГДЕ, вместо параметров виртуальной таблицы.
 
 Получение излишних данных в запросе.
 
 Выгрузка результата запроса, где нет необходимости.
 
 Разделить выполнение и выборку/выгрузку  результата запроса.
 
Избегать Полное (Внешнее) соединение в запросе.
 
Не использование БСП (пишем то, что уже есть)
 
Не использовать метод «Сообщить».
 
Использовать ТекущаяДатаСеанса() на &Сервере.
 
Не верные директивы компиляции
 
Использовать инструкции препроцессору в модулях (Объекта, Менеджера, Сеанса).
 
Присутствует «мертвый» код, пустой обработчик.
 
 Использовать стандартные области в модулях формы, объекта, менеджера, а также в общих модулях.
 
 Новые объекты должны быть включены в специальную подсистему «ДобавленныеОбъекты» и на них должны быть даны права.
 
Программное создание всех реквизитов формы, если дорабатываем типовую форму.
 
Не использовать проверку на тип «булево», через ИСТИНА или ЛОЖЬ.
 
Использовать дату «регистра накопления – остатки», как «МоментВремени» (или «Граница»), а не «Дата».
 
Правильное использование: «транзакций» и «попыток».
 
Учитывать RLS при написании запросов.
 
Новые объекты с использованием расширений, нужно создавать в основной конфигурации.

 

      Формат комментариев и префиксация новых объектов

 

Формат комментария должен иметь формат, представленный на рисунке 1:

 

Рисунок 1 Формат комментариев.

 

Ниже приведено описание каждого элемента комментария (номер элемента на картинке соответствует номеру, выделенному жирным, в описании ниже). «Пример 1» для проектных работ, «Пример 2» для работ на сопровождении.

// <Тип комментария> <Наименование организации> <ФИО разработчика> (<Дата внесения изменения в формате "dd.MM.yyyy">) <П|С>.<Номер> <Краткое пояснение изменения>

1 <Тип комментария> - указывается символ «+» для комментариев перед изменением, «-» для комментариев после изменения.

2 <Наименование организации> - наименование организации разработчика для его идентификации. Не более десяти символов.

3 <ФИО разработчика> - фамилия и инициалы разработчика, который вносит изменения в код. Формат: «Фамилия И.О.».

4 <Дата внесения изменения в формате "dd.MM.yyyy"> - следует обязательно придерживаться заданного формата даты. Дата изменения указывается в скобках.

5 <П|С> - если изменение вносится в рамках проекта, то следует указывать «П»; если в рамках сопровождения, то следует указывать «С». <Номер доработки в рамках проекта или сопровождения> - порядковый номер доработки, по которому можно однозначно найти постановку задачи по изменению. Для проектных работ .<Префикс проекта>.<Номер раздела | Номер технического задания>.<Номер доработки>. Для задач на сопровождение .<Номер доработки>.

6 <Краткое описание изменения> - необязательное поле. Указывается, если разработчик считает необходимым описать изменение кода. Не более 50 символов.

 

Создание новых объектов и префиксация

Первое правило – это добавление в конфигурацию объектов верхнего уровня (справочников, документов, регистров и т.д.). В начало наименования объекта нужно добавлять префикс (рисунок 2).

 

Рисунок 2 Создание нового объекта верхнего уровня.

 

Это правило заключается в том, что имена объектов обязательно должны начинаться с префикса. Для чего?

  • Во-первых, это визуально выделяет добавленный элемент в конфигурации и в коде сразу видно, что это – наш добавленный объект.
  • Во-вторых, достигается уникальность имени, потому что поставщик может добавить свой объект с тем же именем. И если мы будем использовать свой префикс, то это гарантирует, что наше имя будет уникально. Синоним указываем без префикса. Синоним не должен значительно отличаться от имени объекта. К примеру, если имя объекта «Префикс_КадроваяИсторияСотрудников», то неверно указывать в качестве синонима «Работники организации».

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

Третье правило: новые объекты должны быть обязательно включены в специальную подсистему «Префикс_ДобавленныеОбъекты». Если такая подсистема отсутствует на момент начала добавления новых объектов конфигурации – ее необходимо создать. Включать в командный интерфейс не обязательно. Данная подсистема нужна для определения объектов конфигурации, разработанных нами, а также для возможного переноса объектов по подсистеме в иные конфигурации.

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

К примеру: Типовой справочник «Пользователи». В нем необходимо добавить реквизит, который бы содержал, действителен или нет пользователь (рисунок 3). Формат комментария описан выше.  При добавлении реквизитов формы так же необходимо указывать префикс.

 

Рисунок 3 Добавление реквизита в типовой объект.

 

Чек-листы для проверки архитектурных решений кода

 
 Использовать только в крайних случаях объект метаданных - “Константы”. 
 
 Поле на форме, которое подсвечено красной пунктирной линией, должно быть обязательно к заполнению.
 
 При добавлении нового объекта метаданных - “Команда”, “Отчет”, “Документ” и т.д.  не забывать про роли. 
 
 При создании отдельного внешнего отчета, обработки необходимо проверять роли/доступ для всех потенциальных групп пользователей.
 
При использовании общих модулей с повторным использованием возвращаемых значений на время сеанса нужно учитывать, чтобы полученное значение не было изменено во время сеанса.
 
 Не используйте в названиях переменных имена реквизитов формы.
 
 При добавлении новых реквизитов в типовые объекты метаданных необходимо использовать префикс, кроме случаев, когда необходимо  использовать типовой код (например: ввод на основании, реквизит - организация).
 
 Проверка на тип переменной.
 
При добавлении кода в типовые модули, желательно его отделять уникальными проверками для своей логики (проверка на тип, уникальное значение реквизита и т.д.). 
 
Получение данных из периодического регистра сведений срезом последних не по всем измерениям регистра. 
 
Фиксировать по возможности все важные события в журнал регистрации (например: отправка почты (кому и во сколько ушло письмо); обмены с другими системами (во сколько и какие объекты отравлены/загружены)  и т.д.).
 
Отказ от использования функций: НайтиПоКоду, НайтиПоНаименованию.
 
 Необходимые проверки в объектах метаданных нужно выносить в модуль объекта, по возможности исключить их из модуля формы.
 
Осуществлять проверку объектов метаданных на реквизиты “ЭтоГруппа” и “ОбменДанными” (наиболее актуально для новых объектов).
 
Проверка на наличие на форме реквизитов при программном добавлении.
 
Формировать отчеты в фоновом режиме.
 
При использовании в запросах левого соединения контролировать, чтобы не было дублирования строк. 
 
В типовом решении при синхронизации данных между базами нет возможности  отследить какие объекты были выгружены/ загружены. 
 
По возможности не создавать реквизиты с типом “ХранилищеЗначений” для объектов метаданных (справочников, документов) активно использующихся при реализации основной бизнес-логики.
 
При написании запросов желательно:

 

Заключение

Использование приведенных чек-листов (полностью или частично) повысит качество кода программистов, даже без внедренной системы Code Review. Основное правило, чтобы вся команда придерживалась одних стандартов.

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Shmell 356 17.05.21 10:15 Сейчас в теме
Отличный чек лист. Саша, хорошо постарался )
S.Mihajlov; AntonKulmetev; starik-2005; +3 Ответить
2. ig-efrem 8 17.05.21 15:37 Сейчас в теме
Спасибо за статью, очень все лаконично и по делу. Буду использовать как инструкцию для подрядчиков и спрашивать по этой статье за их косяки.
3. ekon1982 17.05.21 15:47 Сейчас в теме
Правильное использование: "транзакций" и "попыток". Первый пример "Правильно" и последующий пример "Не правильно" - один и тот же код (за исключением создания нового документа).
buganov; mikukrnet; +2 Ответить
22. Alexsandr_Retunskiy 397 18.05.21 06:08 Сейчас в теме
(3)
ющий пример "Не правильно" - один и тот же код (за исключением создания нового документа).


Побольше добавил примеров для понимания.
4. kuntashov 418 17.05.21 16:04 Сейчас в теме
Не нужно делать вручную то, что можно сделать полностью автоматически, бесплатно и без СМС: https://github.com/1c-syntax/bsl-language-server

Можно платно: https://checkbsl.org/ (больше диагностик).

Можно чисто на 1С, АПК: https://releases.1c.ru/project/ACC
nekit_rdx; memb3r; Olenevod; JohnyDeath; brr; Sla; Hoper1981; pavlov_dv; Артано; amoarok; user811769; Evg-Lylyk; olegtymko; Akcium; CyberCerber; +15 Ответить
5. starik-2005 2346 17.05.21 17:09 Сейчас в теме
(4) чтобы что-то автоматизировать, нужно сначала вручную это пару раз сделать и понять, что и где не так или не то, и как надо. А то автомат выплюнет лог, и что с этим логом делать?
6. kuntashov 418 17.05.21 17:18 Сейчас в теме
(5)
и что с этим логом делать?


Следовать указанным в логе рекомендациям по исправлению:
Прикрепленные файлы:
7. starik-2005 2346 17.05.21 17:23 Сейчас в теме
(6) ну если ссылка в данном случае - это реквизит табличной части, то сообщение неуместно. Кто-то должен быть достаточно грамотным, чтобы это понять.
19. Артано 712 18.05.21 03:22 Сейчас в теме
(7) В любом случае, на такие моменты обращать внимание нужно. Если всё нормально, то "ошибка" помечается как "не ошибка" или "архитектурное решение" =)
44. user1140274 18.05.21 10:28 Сейчас в теме
(7)
А можно конкретный пример. ДокументРасхода.Ссылка.Дата - недопустмо, ДокументРасходаТовары.Ссылка.Дата - допустимо, я правильно понял?
47. Артано 712 18.05.21 10:57 Сейчас в теме
(44) Я думаю, Старик имел ввиду, что в случае ТЧ так и так будет левое соединение с одной единственной таблицей, так что зачем мелочиться и описывать в коде запроса то, что произойдёт.
55. starik-2005 2346 18.05.21 11:52 Сейчас в теме
(44) в документе расхода дата и так есть - зачем тут ссылка? А вот в табличной части даты нет, но ее можно взять из ссылки. В любом случае это левое соединение, но в первом случае ненужное.
56. user1140274 18.05.21 11:58 Сейчас в теме
24. Alexsandr_Retunskiy 397 18.05.21 06:11 Сейчас в теме
(5)
ы что-то автоматизировать, нужно сначала вручную это пару раз сделать и понять, что и где не так или не то, и как надо. А то автомат выплюнет лог, и что с этим логом делать?


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

Автоматическая проверка - у нас есть, ей также пользуемся.
23. Alexsandr_Retunskiy 397 18.05.21 06:10 Сейчас в теме
(4) Мы уже начали использовать автоматизированные проверки, но сами написали инструмент.
Артано; kuntashov; +2 Ответить
36. kuntashov 418 18.05.21 08:15 Сейчас в теме
(23) Круто, а почему все-таки свой/сами, а не используете готовое?
Планируете ли его открыть или выпустить как продукт?
42. Alexsandr_Retunskiy 397 18.05.21 09:09 Сейчас в теме
(36)

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

Как продукт не будет, но в будущем возможно выложим на обозрение.
8. DarkAn 989 17.05.21 18:01 Сейчас в теме
(0) не плохо. Но просьба переработать сообщения спойлеров в одном "направлении". Часть спойлеров понимается, что внутри "как надо", а часть, что внутри "как НЕ надо".
25. Alexsandr_Retunskiy 397 18.05.21 06:16 Сейчас в теме
(8) напишите пункты, которые нужно изменить - я поправлю. Старался все писать - "как надо".
9. biimmap 118 17.05.21 19:22 Сейчас в теме
Половина написана правильно, а половина ерунда полная.

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

Половина Ваших "предложений" пустая по содержанию. Написано что делать, но совсем не написано как! Пример: ЛЕВОЕ СОЕДИНЕНИЕ. Есть способы конкретные как избежать дублей и как понять возникнут они или нет при соединении таблиц. Аналогично про RLS. Как добиваться то, чтоб работали запросы все? Опять же есть четкая методика. и т.д.

Ставить минус не стану, т.к. сам являюсь автором статей и получаю и минусы и критику. Но явно Вам стоит подробнее расписать.
Что касается фразы, что любой программист сможет сам это сделать... вот это максимально неверная фраза.
26. Alexsandr_Retunskiy 397 18.05.21 06:26 Сейчас в теме
(9)
то Вас научил использовать вложенные запросы? Вы не в курсе временных таблиц? Но нет, в курсе, сами пишите об этом в последнем пункте. Как-то странно получается.


Как раз в чек-листе и описывается, что нужно по минимуму использовать вложенные запросы, а лучше использовать временные таблицы.

Этот пункт подтверждает ИТС: https://its.1c.ru/db/v8std#content:655:hdoc

НО! Временные таблицы не всегда оптимальны по производительности, наш коллега снизу об этом пишет.

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

Этот чек-лист и нужен чтобы проверить, что вложенные запросы бывают излишне.
---------------

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


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

Этот пункт подтверждает ИТС: https://its.1c.ru/db/v8std#content:654:hdoc

Также на ИТС подобный пример (я сделал подобный пример с ИТС).
10. partizand 81 17.05.21 20:34 Сейчас в теме
Подскажите, что не так со значениями с модулей "на время сеанса"?
Не совсем понятно.
И да видимо вы не запускали АПК и не смотрели результат. В идеале это нужно делать перед код ревью. Особенно меня удивляют форматы комментариев, часто встречающиеся в компаниях, которые нарушают требования Совместимо.
И все же код ревью по чеклисту кто угодно не проведёт. Нужно понимать.
Мне встречались несколько ЗначениеРеквизита подряд одного объекта, да еще внутри цикла. Ваш чеклист это бы одобрил.
27. Alexsandr_Retunskiy 397 18.05.21 06:31 Сейчас в теме
(10) Мне встречались несколько ЗначениеРеквизита подряд одного объекта, да еще внутри цикла. Ваш[/IS-QUOTE]

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

Подскажите, что не так со значениями с модулей "на время сеанса"?


Встречал код - когда получали значение из модуля "на время сеанса", потом по логике меняли это значение и снова получали из этого модуля (то есть уже старое значение).

И все же код ревью по чеклисту кто угодно не проведёт. Нужно понимать.


Команда пишет и проверяет по одним стандартам.
11. partizand 81 17.05.21 20:43 Сейчас в теме
Еще вопросы, хочется закрыть пробелы в своих знаниях:
1. Почему нельзя использовать полное соединение? Ведь оно доступно в запросах...
2. Почему нельзя сразу выгружать результаты запроса?
13. biimmap 118 17.05.21 23:08 Сейчас в теме
(11)
1. Неправильно говорить что нельзя... Нужно описать в каких ситуациях можно. Просто задач, которые решаются через ПОЛНОЕ СОЕДИНЕНИЕ очень мало. Надо стараться использовать ЛЕВОЕ. Если надо наложить неявный фильтр, то ВНУТРЕННЕЕ СОЕДИНЕНИЕ. Если надо несколько таблиц слить воедино пользуются ОБЪЕДИНИТЬ ВСЕ, если надо без дублей пишут просто ОБЪЕДИНИТЬ. Полное соединение генерирует лишние записи. Так ещё в них половина полей имеют значение NULL. Это надо учитывать и дополнительно описать в запросе.

2. Выгружать можно, но только в случае, когда таблицу в цикле не обрабатывают!
Т.е. пишут НаборДвижений.Загрузить(Запрос.Выполнить().Выгрузить()). Вот так норм.

Обработка таблицы в цикле идёт медленнее, чем обработка через выборку запроса.
Hoper1981; Артано; +2 Ответить
28. Alexsandr_Retunskiy 397 18.05.21 06:34 Сейчас в теме
(11)
2. Почему нельзя сразу выгружать результаты запроса?


1. Использовать конечно можно, но не желательно, что подтверждает ИТС: https://its.1c.ru/db/v8std#content:435:hdoc

2. Без необходимости лучше это не делать, т.к. лишняя нагрузка на систему.
35. starik-2005 2346 18.05.21 08:07 Сейчас в теме
(28) кстати, как-то здесь была статья про то, что не стоит использовать Выгрузить() для результата запроса в источнике итераторов для цикла. Так вот люди умные не поленились и сравниди скорость работы с выгрузить и выборка.следующий. Так вот до 100к строк запроса выборка работала медленнее при сопоставимом расходе памяти. А выше 100к строк просто не проверяли, ибо 100к - это в принципе программное ограничение 1С для табличных частей, да и вообще обработка свыше 100к элементов должна параллелиться и отрабатывать многопоточно порциями.

Вообще, стоит иметь ввиду, что в интерпретаторах делают встроенные оптимизации, и может так оказаться, что Для Каждого Х из Запрос.Выполнить().Выгрузить() будет работать без дополнительного выделения памяти, получая данные из непосредственно объекта с результатом запроса, который в любом случае едет из sql в 1С. Но это уровень мышления над платформой (или под ней). На С кода пишешь программу, то понимаешь, что буфер прочитанного фрагмента файла или тот же запрос - это уже выделенная память, которую можно использовать, при том она уже в кеш попала процессорный. В итоге на С скорость обработки тех же 120кк недействительных паспортов у меня в районе 4 секунд, а на том же железе в СУБД это положить - от 25 минут прямым запросом и до 4х часов если писать в регистр сведений средствами 1С))))

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

В общем или программист 1С ограничен платформой и тогда ему лучше тупо соблюдать то, что пишет 1С, ну или он платформой неограничен, и механика работы запроса и оптимизатора лежит в поле дискретной математики, которую не ограниченный программист тоже немножко (в части деревьев и хеш-таблиц, как о них Макконнелл писал) знает и про нормальные формы читал и понял.
43. Артано 712 18.05.21 10:01 Сейчас в теме
(35) Я помнится писал подобное, но речь шла о безусловной выгрузке результата независимо от сценария последующего использования. Дело не в скорости, а в дополнительном выделении памяти. Ведь результат запроса уже является таблицей - зачем создавать новую, если уже есть одна? Оптимизации не исключены, 1с любит оптимизировать платформу, чтобы неоптимальный код работал быстрее.
12. buganov 175 17.05.21 21:24 Сейчас в теме
Фиксировать по возможности все важные события в журнал регистрации (например: отправка почты (кому и во сколько ушло письмо); обмены с другими системами (во сколько и какие объекты отравлены/загружены) и т.д.).

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

Проверка на наличие на форме реквизитов при программном добавлении

Разве реквизиты не создаются в обработчике ПриСозданииНаСервере?

При написании запросов желательно
- Использовать пакетные запросы и временные таблицы вместо вложенных запросов.

- Для объединения нескольких таблиц используйте объединить, а не левое соединение.

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

- Индексировать реквизиты/ устанавливать индекс для реквизитов, по которым используется отбор, поиск, соединение.


1. Не согласен. Генерить нагрузку на tempdb без имеющихся на то причин, зачем? MSSQL отлично раскрывает скобки.
2. Опять же с потолка. Почему не левое соединение? Чтобы подзапутать оптимизатор?
3. Что такое дам запроса? Что то новенькое и модненькое? Я бы посоветовал для отладки сложных запросов использовать план запроса
4. Вы делали замеры индексирования? Очень редко создание индекса помогает для больших таблиц. Бывает, но редко.

В целом, резюмируя статью, очень много "советов" и причем очень спорных и никак не обоснованных. Не скажу, что статья больше вредная, нежели полезная, хотя, нет, скажу. Автор постарался, но, как говорится в джентельменских кругах: "Тема сисек не раскрыта", а уж советов и подавно, особенно безапелляционные утверждения.
14. biimmap 118 17.05.21 23:14 Сейчас в теме
(12) с пунктами 1 и 4 не соглашусь.
1. вложенные запросы зло особенно на больших таблицах. + есть стандарты разработки 1С.
4. что касается индексирования... автор неверно написал что делать надо. Надо не создавать индексы в объектах метаданных, а следить, чтоб связи и условия накладывались по индексированным полям. Если таблица огромная (какой-нить регистр накопления) и нет возможности наложить условия последовательно по измерения, нужно согласно стандартов разработки разбить запрос на 2.

в моей практике масса примеров, где индексирование ускоряло процесс существенно. + автор не описал потребность в создании индексов для временных таблиц. Это в определенных ситуациях также в разы ускоряет.
Артано; +1 1 Ответить
32. buganov 175 18.05.21 07:39 Сейчас в теме
(14)
Вот Вы утверждаете, что зло, при этом, видимо, не совсем понимаете, как работает подзапрос и как временная таблица, в чем между ними разница. Запомните, что стандарты разработки часто перестают работать на больших данных.
4. Можно пруфы, сэр? Ну вот элементарно хотя бы планы запросов до и после индексирования.
37. biimmap 118 18.05.21 08:55 Сейчас в теме
(32) Давай приведу примеры сер.
1. Работал в 1С в отделе разработки ЕРП. Выполнял задачу связанную частично с зарплатой, частично с казначейством. Точнее учет НДФЛ удержанного при выплате зарплаты. Не вспомню конкретный документ, где поставлен был индекс у реквизита ТЧ. Но по этому документу в 4-х местах были написаны запросы с отбором по реквизиту ТЧ. Этот документ был из подсистемы БЗКР (надеюсь знаешь что это). Так вот когда нагенерил млн документов у меня все эти запросы падать начали. Документы по 5-7 секунд проводились при нормативе 2 секунды. После индексации реквизита все показатели уложились в норматив, даже запас остался! Т.е. производительность запросов при больших объёмах данных возросла многократно.
2. Теперь про индексы во временных таблицах. Для крупного агрохолдинга писал конструктор выгрузки данных из ЗУП в Excel. Получается очень много данных и они потом перекрестно ещё используются в запросах. Т.е. кадровые данные и ШР используется дальше во всех запросах. Сначала я забил на индексы, делал функциональность, работал на результат. Когда его получил, то обратил внимание что всё получение данных занимает 5 минут (+ ещё вывод в Excel). Так вот грамотно расставив индексы во временных таблицах, сократил время получения данных до 2-х минут!

ляпунть то конечно можно что кто-то непонимает... сложнее признать собственные пробелы в знаниях. Успехов
45. buganov 175 18.05.21 10:43 Сейчас в теме
(37)
После индексации реквизита все показатели уложились в норматив, даже запас остался! Т.е. производительность запросов при больших объёмах данных возросла многократно.

Индексации реквизита, как объекта метаданных? Так я про это и не спорил даже. Индексы часто приводят к улучшению плана запроса.
По поводу п.2. Я писал, что в очень небольшом проценте индексы сыграют роль. Но Вы просто натыкали индексов не разбираясь, что там внутри. По крайней мере так написано. Ни тебе планов запроса, ни их анализ, ни анализ структуры данных. То есть очевидно, что банально сработал метод тыка. И я не сказал, что индексы ВТ всегда не работают. Работают, но очень редко. Если удалось, что ж, не стоит под одну гребенку крыть одной крышкой.


(37)
сложнее признать собственные пробелы в знаниях

Пробелы я регулярно восполняю, а Вам советую отличные видеокурсы Виктора Богачева. Там восполните уже свои.

П.С. Очень странно читать такое от человека, который работал в 1С над флагманской конфой. Я думал туда только экспертов и берут.

КонецСрача

Успехов
49. Артано 712 18.05.21 11:01 Сейчас в теме
(45)
КонецСрача

Успехов


Неправильно!!!

Вот так должно быть
buganov; biimmap; +2 Ответить
54. buganov 175 18.05.21 11:20 Сейчас в теме
(49)Неправильно)
Вот так должно быть.

КонецСрача;
ПожелатьУспехов(Артано);
52. biimmap 118 18.05.21 11:11 Сейчас в теме
(45) мне тема с планами запросов не совсем интересна. эта компетенция называется Эксперт по тех. вопросам. я ей владею частично, но той части которой нет, она мне собственно и не требуется в работе.

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

собственно с моей стороны срача и не было))) просто ответил в твоём стиле)))

В 1С берут людей с опытом проектирования интересных решений. Качество кода подымают на месте уже) У них код ревью очень жесткий. А остаются там те, кто готов делать то что ему скажут. у меня такая компетенция отсутствует))) Поэтому ушел довольно быстро.

Тебе тож успехов)
53. buganov 175 18.05.21 11:18 Сейчас в теме
(52)
мне тема с планами запросов не совсем интересна. эта компетенция называется Эксперт по тех. вопросам. я ей владею частично

Очень зря. Помогает понять, а самое главное, с опытом предугадать, как поведет себя запрос с теми или иными данными. Согласен, что каждая база индивидуальна и на небольших, до 500Гб, может и не требовать такого погружения.
Кстати, что интересно, на курсах по оптимизации и от 1С и от курсов-1с-рф, где рассматриваются именно большие таблицы, прямо говорят, что стандарты могут перестать работать, они рассчитаны на массового пользователя, и поэтому пока процент баз больше террабайта условного мизерный, стандарты будут действительны)
17. Артано 712 18.05.21 03:00 Сейчас в теме
(12) Поддержу коллегу в (14). "Отлично раскрывает скобки" когда там записей горстка и/или статистики максимально актуальны. Стоит статистикам чуть-чуть протухнунуть и привет, падение производительности в десятки раз.
33. buganov 175 18.05.21 07:41 Сейчас в теме
(17) По такой логике нужно ориентироваться на беспризорные базы? Не видел ни одну большую(>500Гб) базе и без элементарного админа, который настраивает СУБД, статистики и т.п. Да это же элементарно регламентами делается
38. Артано 712 18.05.21 09:03 Сейчас в теме
(33)
По такой логике нужно ориентироваться на беспризорные базы? Не видел ни одну большую(>500Гб) базе и без элементарного админа, который настраивает СУБД, статистики и т.п. Да это же элементарно регламентами делается


Чуткое слежние за статистиками и их тонкое обслуживание посреди рабочего дня требует достаточно квалифицированных админов. Таких людей гораздо меньше, чем одинесников, которым можно дать простую инструкцию. К тому же сам факт апдейта статистик через, само по себе даёт неплохую нагрузку на базу.
29. Alexsandr_Retunskiy 397 18.05.21 06:41 Сейчас в теме
(12)
Разве реквизиты не создаются в обработчике ПриСозданииНаСервере?


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

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


Согласен, но других решений в типовых конфигурациях не знаю. Напишите, если знаете.


При написании запросов желательно
- Использовать пакетные запросы и временные таблицы вместо вложенных запросов.

- Для объединения нескольких таблиц используйте объединить, а не левое соединение.

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

- Индексировать реквизиты/ устанавливать индекс для реквизитов, по которым используется отбор, поиск, соединение.


Сверху писал, за основу взят стандарт 1С и соответственно данные пункты взяты с ИТС:
15. oleganatolievich 148 18.05.21 00:05 Сейчас в теме
Разделить выполнение и выборку/выгрузку результата запроса.


Зачем сохранять Результат запроса, если он не будет использован? Разве что удобнее его в отладчике дергать вместо Запрос.Выполнить()

Новые объекты должны быть включены в специальную подсистему «ДобавленныеОбъекты» и на них должны быть даны права.

Если подсистем несколько?

Не использовать проверку на тип «булево», через ИСТИНА или ЛОЖЬ.


Если придет не Булево, или Null или неопределено или битая ссылка? Динамическая типизация и все такое.

Префикс_ДобавленныеОбъекты


Выглядит не очень, потом вся конфигурация в Вася_подсистема1, Петя_подсистема2. Видели, знаем.
Что за непонятная тяга к префиксам? Зачем вам подсистемы - разве что реквизиты туда не запихать.

Фиксировать по возможности все важные события в журнал регистрации (например: отправка почты (кому и во сколько ушло письмо); обмены с другими системами (во сколько и какие объекты отравлены/загружены) и т.д.).


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

Использовать пакетные запросы и временные таблицы вместо вложенных запросов.

Это на маленьких таблицах, а если в таблице 60 млн записей, сколько потратится времени на помещение этих записей во временную таблицу? На моей практике как раз использование вложенных таблиц дало 5кратный прирост скорости на большой таблице.

Для объединения нескольких таблиц используйте объединить, а не левое соединение.


Это еще почему?

Пункты, которые следовало бы добавить:
Количество параметров в функциях - не передавать миллионы параметров?
Размеры функций - чтобы функция влезала на экран.
Близость переменных от места использования к месту объявления - чем дальше, тем больше вероятность ошибки.
Связность функций в общих модулях - чтобы один модуль (вы же тут про ООП заговорили) знал поменьше о других модулях?
Использование общего кода форм в клиентских модулях, чтобы текст модуля не перетаскивался постоянно с сервера на клиент и обратно при передаче контекста.
Кэширование постоянно используемых значений в реквизитах на форме, и т. д.
rusmil; zqzq; +2 Ответить
18. Артано 712 18.05.21 03:17 Сейчас в теме
(15)
Зачем сохранять Результат запроса, если он не будет использован? Разве что удобнее его в отладчике дергать вместо Запрос.Выполнить()


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

Если придет не Булево, или Null или неопределено или битая ссылка? Динамическая типизация и все такое.

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

Выглядит не очень, потом вся конфигурация в Вася_подсистема1, Петя_подсистема2. Видели, знаем.
Что за непонятная тяга к префиксам? Зачем вам подсистемы - разве что реквизиты туда не запихать.


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


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

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

Это на маленьких таблицах, а если в таблице 60 млн записей, сколько потратится времени на помещение этих записей во временную таблицу? На моей практике как раз использование вложенных таблиц дало 5кратный прирост скорости на большой таблице.

Если в таблице 60 миллионов записей, то только неопытный разработчик будет её без предварительной фильтрации куда-то помещать. Скорость работы вложенных запросов зависит здесь от актуальности статистик. Которые, что характерно, могут протухнуть по мнению оптимизатора SQL и просто по таймауту. Так что ваш "5кратный прирост скорости" может легко обратиться в 20кратное падение в пределах одного дня. Надо же оценивать объём работ, а не полагаться только на тестирование "здесь и сейчас", без понимания почему тест пройден/не пройден.

Это еще почему?

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


По остальным замечаниям согласен.
16. Артано 712 18.05.21 02:53 Сейчас в теме
Фундаментально, но мне кажется, вы не знаете, что такое Ревью кода. Вы совершенно игнорируете средства статического анализа кода и возлагаете на плечи ревьювера огромный труд. Я обычно критикую автоматизиторов за то, что они излишне полагаются на средства автоматической проверки кода и сичтают, что они не создадут в результате монстра. Но Вы бросились в противопожную крайность.

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

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

P.S. Посмотрел примеры после прочтения комментариев. По части замечаний согласен, есть спорные рекомендации. За префиксы предусмотрен отдельный котёл в аду. Но это вопрос спорный по факту. Многие из рекомендуют, но моё ИМХО таково.
oleganatolievich; a_a_burlakov; +2 Ответить
30. Alexsandr_Retunskiy 397 18.05.21 06:44 Сейчас в теме
(16)
аний согласен, есть спорные рекомендации. За префиксы предусмотрен отдельный котёл в аду. Но это вопрос спорный по факту. Многие из рекомендуют, но моё ИМХО таково.


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

Опять же данный чек-лист еще нужно рассматривать, как прокачка программистов, что не дает автоматическая проверка.
39. Артано 712 18.05.21 09:05 Сейчас в теме
(30) посмотрите в сторону суффиксов. Суть не меняется, простота использования повышается.
FatPanzer; zqzq; +2 Ответить
73. Baronello 1 20.05.21 16:49 Сейчас в теме
(30)
префиксы нам помогают отделить свои доработки от типовых

Не надо в типовую пихать свои доработки, юзайте расширения. Все остальное должно быть по алфавиту.
75. Артано 712 21.05.21 04:44 Сейчас в теме
(73) Расширения поддерживать сложнее на данном этапе их развития. Даже с &ИзменениеИКонтроль
Если объём доработок большой, да еще и новые таблицы добавляются, то расширения становятся и вовсе неудобными.
76. Baronello 1 21.05.21 11:05 Сейчас в теме
(75)
Расширения поддерживать сложнее на данном этапе их развития.


А кто говорил что будет легко? Зато коллеги которые после вас придут, не будут думать что вы осел.
И я не понимаю в чем сложность, формы надо программно обновлять типовые, тогда не будут слетать при обновах. А код в любом случае при обновлениях проверять и при объединении это делать как раз таки сложнее.


(75)
да еще и новые таблицы добавляются


???


В расширениях не хватает только констант (но вместо них в любом случае лучше юзать ПВХ или регистр с настройками) и общих типов. Всё остальное уже замечательно работает, плюс расширения позволяют модульно использовать разный функционал в разных точках.
20. Артано 712 18.05.21 03:32 Сейчас в теме
P.P.S. Прочитал предыдущую статью "Кейс по внедрению Ревью кода". Статья отличная. По тексту статьи Вы описываете внедрение системы обеспечения качества, причем "под ключ" без дураков. Но называете это всё ревью кода. Будьте точнее в терминологии, пожалуйста. Иначе вводите в заблуждение и себя и коллег.
31. Alexsandr_Retunskiy 397 18.05.21 06:45 Сейчас в теме
(20)
Кейс по внедрению Ревью кода". Статья отличная. По тексту статьи Вы описываете внедрение системы обеспечения качества, причем "под ключ" без дураков. Но называете это всё ревью кода. Будьте точнее в терминологии, пожалуйста. Иначе вводите в заблуждение и себя и коллег.


Спасибо учту.
21. Alexsandr_Retunskiy 397 18.05.21 06:07 Сейчас в теме
(15)

Зачем сохранять Результат запроса, если он не будет использован? Разве что удобнее его в отладчике дергать вместо Запрос.Выполнить()


Спорный момент конечно, но я лично смотрел типовые конфигурации и там в основном разделяют эти процедуры.

Это удобно - для отладки (немного) и в основном выполнение и выборка/выгрузка находятся в разных процедурах (используется менеджервременныхтаблиц).

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

Если подсистем несколько?


Системы может быть несколько и если в Ваших системах, только добавленные элементы, то все норм.

Если в Ваших системах есть и типовые объекты, то это уже не подходит.

Идея данной системы - сразу находить все добавленные объекты в одном месте.

Если придет не Булево, или Null или неопределено или битая ссылка? Динамическая типизация и все такое.


Здесь конечно нужно смотреть конкретно по задачи.

Если Реквизит, типа - Булево, то другие значения мало вероятно могут прийти.

А так можно использовать - ЗначениеЗаполнено.

Выглядит не очень, потом вся конфигурация в Вася_подсистема1, Петя_подсистема2. Видели, знаем.
Что за непонятная тяга к префиксам? Зачем вам подсистемы - разве что реквизиты туда не запихать.


У нас все лаконично, максимум 2-3 подсистемы, одна на добавленные объекты, остальные на бизнес-задачи.

Тэги и префиксы очень помогают найти в конфигурации добавленные объекты и код.

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

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


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

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


Это на маленьких таблицах, а если в таблице 60 млн записей, сколько потратится времени на помещение этих записей во временную таблицу? На моей практике как раз использование вложенных таблиц дало 5кратный прирост скорости на большой таблице.


Я написал "желательно", но не обязательно, нужно конечно смотреть конкретно на каждую задачу.

ИТС подтверждает ваши слова: https://its.1c.ru/db/v8std#content:777:hdoc


Это еще почему?


Это согласно инструкции ИТС: https://its.1c.ru/db/v8std#content:434:hdoc (при объединении таблиц нужно использовать ОБЪЕДИНИТЬ).

За основу мы брали стандарт 1С.

Пункты, которые следовало бы добавить:
Количество параметров в функциях - не передавать миллионы параметров?
Размеры функций - чтобы функция влезала на экран.
Близость переменных от места использования к месту объявления - чем дальше, тем больше вероятность ошибки.
Связность функций в общих модулях - чтобы один модуль (вы же тут про ООП заговорили) знал поменьше о других модулях?
Использование общего кода форм в клиентских модулях, чтобы текст модуля не перетаскивался постоянно с сервера на клиент и обратно при передаче контекста.
Кэширование постоянно используемых значений в реквизитах на форме, и т. д.


Спасибо за информацию, у нас также постепенно совершенствуется чек-листы и мы уже задействовали автоматические проверки, так что развитие идет.
34. buganov 175 18.05.21 07:48 Сейчас в теме
(21) С того же ИТС
Использование временных таблиц
#std777
Область применения: управляемое приложение, мобильное приложение, обычное приложение.

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

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

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

2.3. Не следует помещать во временную таблицу поля, которые не используются в последующих запросах, т.к. время и место для их размещения тратится впустую.

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

2.5. Не следует копировать одну временную таблицу в другую только ради того, чтобы переименовать первую таблицу во вторую. Вместо этого, следует передавать имя таблицы.

А вот теперь представьте анализ продаж за период. Или анализ остатков крупной сети. Или много еще каких примеров в организациях с высокой интенсивностью введения данных и гигантскими, в десятки и сотни гигабайт, таблицами. И Вы вместе с Артано предлагаете всю эту простыню положить во временное хранилище, а еще потом создать индекс, а уже потом соединять. Как это называть?
40. Alexsandr_Retunskiy 397 18.05.21 09:07 Сейчас в теме
(34)
Все индивидуально, если стандарт по нему пишут и всегда есть исключения, которые нужно обосновать.
41. Артано 712 18.05.21 09:08 Сейчас в теме
(34)
А вот теперь представьте анализ продаж за период. Или анализ остатков крупной сети. Или много еще каких примеров в организациях с высокой интенсивностью введения данных и гигантскими, в десятки и сотни гигабайт, таблицами. И Вы вместе с Артано предлагаете всю эту простыню положить во временное хранилище, а еще потом создать индекс, а уже потом соединять. Как это называть?


А зачем анализ продаж складывать во временную таблицу? Я такое даже в своём замечании не предлагал, напротив, указывал на недопустимость помещения нефильтрованных данных в ВТ.
Скажите задачу и обсудим на конкретном примере
48. buganov 175 18.05.21 10:58 Сейчас в теме
(41) Проблема в том, что данные фильтруются, но их все-равно огромное количество. 600 магазинов, 10К позиций, что даже по одной записи даст 6 миллионов. А записей, ясно, гораздо больше. Бывают случаи, когда использование ВТ приведет к деградации производительности всей системы в целом. tempdb хоть и резиновая, но ограничена сверху, как и ее журнал транзакций, переполнение которого приведет к остановке системы, что недопустимо.
Отмечу, что ВТ не зло, точнее это инструмент, который в правильных руках повышает скорость выборки, но в плохих может и систему положить. Про подзапрос то же самое. И любой более-менее сложный и объемный запрос я лично стараюсь проверить не только на малой выборке, но и взять реальную, если подразумевается работа с большими таблицами. И, анализируя план запроса, уже прихожу к решению, что мне использовать.
51. Артано 712 18.05.21 11:02 Сейчас в теме
(48) Наверное я не знаю кейс, где может потребоваться засунуть 6 лямов записей в одну ВТ. Если расскажете пример, можем поговорить предметно
46. SkrAn 1 18.05.21 10:48 Сейчас в теме
>>разделять выполнение и выборку/выгрузку результата запроса
А в чем разница то?
Чем не устраивает Выполнить().Выбрать() ? если мне нужна выборка 1 раз и больше результат не нужен?
57. Артано 712 18.05.21 14:06 Сейчас в теме
(46) Если не ошибаюсь, то писали и в статье и в комментах уже - пункт взят из стандартов 1с.

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

Подобные и некоторые другие вопросы я рассматривал в своих статьях как раз со стороны "почему это правильно, а это неправильно". Возможно, станет понятнее и позиция автора и позиция фирмы 1с
58. Darklight 27 18.05.21 16:12 Сейчас в теме
Почему все рекомендуют добавлять префиксы слева от идентификатора. Вот в первых типовых решениях на 1С Предприятие 8, и их расширениях (тогда это ещё не было видом конфигурации ибо платформа была 8.0) были префиксы перед идентификаторами – было ужасно неудобно (особенно при поиске по первым буквам – строки фильтра в дереве метаданных ещё не было, и в быстрой подсказке); и от этого отказались. Теперь опять советуют префиксы слева от идентификатора. Жесть. Не…. ну я понимаю, что платформа тут очень ущербна и что-бы не нарваться на дубли имён при очередном апдейте (в т.ч. с расширениями) и для повышения понимания того «кем добавлен» и к чему относится тот или иной идентификатор нужно как-то разграничивать пространства имён идентификаторов (за неимением в платформе более продвинутых механизмов) – но почему тогда не ставить эти присловутые префиксы как суффиксы (окончания) СПРАВА от идентификатора «МойРеквизит_МойПрефикс» - так они не будут никому мешать, названия реквизитов будут лаконичны, легко набираемы, легко читаемы (особенно когда идентификатор длинный, а префикс «ещё длиннее»).
Я, вот, ставлю, префиксы справа – и очень доволен (насколько можно быть тут довольным в ущербной платформе 1С Предприятие 8)! Но да - «1С Совместимо» такая конфигурация вряд ли пройдёт (хот я считаю «1С Совместимо» весьма корявым стандартом, но он хоть какой-то стандарт, в 1С среде стандартов мало…. Хе… кто бы жаловался на то что стандартов мало, а не наоборот – слишком много).
Кстати, говоря, если присмотреться, то типовые конфигурации от 1С используют префиксы-суфиксы и именно СПРАВА:

Примеры префиксов:



«Дублирование кода (ООП): Общие процедуры и функции нужно выносить в общие модули» - рекомендация отчасти противоречит заголовку. Ущербная платформа 1С Предприятие 8 – не совсем ООП – вернее почти совсем не ООП для тех, кто в ней парограммирует. Но – этот ООП отчасти можно эмулировать – как раз используя обработки – как псевдо-объекты. Тогда – как раз можно было собирать общие алгоритмы в таких обхектах-обработках создавать их, передавать их и вызхывать их методы – простите – функции и процедуры. Но… модуль объектов как и модуль менеджера не доступен на клиенте (ущербная платформа), хотя для клиента можно использовать форм(у)ы обработки. И это, относительно удобно – хотя мало разработок этим пользуется (хотя, вот, есть Инструменты разработчика от Tormozit). Место ООП такие объекты можно воспринимать как библиотеки. Хотя, т.к. нельзя эффективно управлять директивами препроцессора – то это решение имеет много минусов, по сравнению с общими модулями, хотя у кого их больше – это ещё вопрос – в неуправляемом приложении уж точно.
А размещение алгоритмах в обработках позволяет легко создавать локальный контекст «библиотеку» - называем обработки длинными уникальными именами (чтобы во всех конфигурациях и расширениях они не пересекались) и пишем специальную функцию – которая по имени контекста будет создавать и наполнять структуру объектами таких обработок с унифицированными именами (если в составе общей конфигурации есть повторяющиеся унифицированные имена обработок – то просто выбираем одну из них (по старшинству версии; стратегия MIXIN тут не получится – хотя при должной сноровки и её можно было бы эмулировать) – далее либо используем экземпляр такой структуры локально – либо присваиваем глобальной переменной (увы – только в клиентском контексте (для упр. приложения нужно создавть экземпляры форм); на сервере можно было бы запихнуть в параметры сеанса – если было бы можно – хотя можно во временное хранилище – но лучше просто обойтись функцией в модуле повторного использования – а там уже задейстовать и параметры сеанса и временное хранилище). Таким макаром можно и более-менее полноценную иерархию пространств имён получить (с вложенными модулями). Справедливости ради, замечу, что эта стратегия работает и с общими модулями – но ими управлять куда менее удобно и менее универсально! А орбработки бывают ещё и внешними – что открывает коллосальные возможности к динамическому программированию.
Не «1С Совместимо»!


Говоря о функции «ЗначенияРеквизитаОбъекта» стоило бы упомянуть и функцию «ЗначенияРеквизитовОбъекта» - потому что редко, когда нужно взять только один реквизит. А заодно и другие функции получения значений реквизитов объектов.


Использовать «Выразить» для реквизитов составного типа в запросах – это палка о двух концах. С одной стороны – да нужно стараться использоваться (особенно при работе с субконто и характеристиками). А, вот, приведённый пример «ВЫРАЗИТЬ(УчетНоменклатуры.Регистратор КАК Документ.РасходнаяНакладна).Номер» очень спорный – т.к. в данном случае как раз обычно нужны номера любых документов, зарегистрировавших запись. И что делать – если (а так обычно и бывает) нужно более 1-го вида регистратора регистратор? Но бывают, конечно исключения – и вот... программисту лень городить сложные конструкции с оператором «ВЫБРАТЬ КОГДА ТОГДА» и «ВЫРАЗИТЬ», тяня туда десятки видов документов. А если нагородит – то потом появляется новый вид документа (например, подключится расширение) и…. БАА!.. запрос уже не работает корректно (работает без ошибок, но некорректные результаты выдаёт)! Пойди найди все такие запросы, чтобы внести в них правки! Налицо очередная ущербность платформы и неудачная рекомендация!
Не говоря уже о том, что одно лишь «ВЫРАЗИТЬ» без фильтра «ГДЕ ВЫРАЗИТЬ(ТоварыНаСкладах.Регистратор Ссылка Документ.ПоступлениеТоваровУслуг)» никакого особого выигрыша в производительности (и уж тем более в корректности результата) не даёт (но защищает от переполнения числа таблиц в итоговом запросе – что может быть чревато для некоторых старых СУБД). А если написать указанный фильтр – то «ВЫРАЗИТЬ» уже можно не писать (если этого не требует логика) – выигрыша в производительности почти не будет (хотя это может только MS SQL умеет так условия проталкивать) – почти все соединения будут пустыми.
Хотя это очередной раз говорит об ущербности платформы – ведь можно было бы не делать соединения с таблицами, если их нет в условии с оператором «Ссылка» (когда его можно однозначно определить). Не говоря уже о том, что все эти фильтры и выражения типа нужно декларировать вне запроса (в дереве метаданных) и лишь применять в запросах – чтобы не выискивать их потом. Сделать это можно было бы вообще круто – введя интерфейсы – и используя их как как типы, да хоть в том же операторе «ВЫРАЗИТЬ» но уже одном – а на выходе будет NULL если интерфейс не поддерживается; или все доступные поля интерфейса (да ещё и, возможно, по-разному реализованные (да хоть имеющие разные имена идентификаторов) в разных источниках, но сведённые к единой мнемонике использования в запросе; а настраивалось бы всё декларативно в конфигурации).


«Использование условий в секции ГДЕ вместо параметров виртуальных таблиц» – это справедливо только для регистров накопления и иже с ними. Применение в регистрах сведений должно быть с осторожностью – т.к. это может повлиять на логику выборки среза.


А чем не угодил метод «Сообщить»? Он вроде бы внутри реализует логику объекта «СообщениеПользователю» (пусть и в урезанном виде).


«Не использовать проверку на тип «булево», через ИСТИНА или ЛОЖЬ» - вот это рекомендация просто убила! Что – и тут 1С Предприятие 8 имеет проблемы? А в друг в переменной будет значение «неопределено» или «null» (это могут быть как легитимные значения, так и не очень – ведь 1С Предприятие 8 – это система с полностью динамической типизацией). Скажите – уж лучше в этом случае ошибку получить? Когда-то да – лучше – но чаще – просто можно считать условие не выполнившимся! Хотя, вот числовые значения 1С приводит неявно к булевым – и ничего – никто не умер (я надеюсь)!


Примера с транзакциями очень неудачные – скорее всего научат как раз плохому коду!


« Правильное решение - это использовать регистр сведений в котором будет четыре измерения: “Аналитика” (составной тип)» - Вот это можно пояснить. Зачем тут 4 измерения аналитики, да ещё и составного типа?

Я использую регистр сведений:



Вот про контроль изменения значений в модулях повторного использования можно подробнее. Ранее уже пробовал городить огород на эту тему – но пока плюнул на это дело – не сталкивался на пактике с большими проблемами с отсудившем такого контроля. Хотя можно завести отдельну константу – дата сброса кеша (и параметре сеанса – с текущей датой сброса кеша) – периодически проверять в каждом сеансе, и если дата в константе станет моложе даты в параметре сеанса – то вызвать функцию «ОбновитьПовторноИспользуемыеЗначения()» (очень неудачное имя идентификатора) – сбросив вообще весь кеш (и обновит параметр сеанса) – соответственно пользоваться этим только при очень большой необходимости.


«Для отладки сложных запросов используйте дамп запроса.» Что это такое?


Странно, что нет ни слова про применение окончаний а-ля "Клиент" "КлиентСервер", "ПовтИсп", "ПолныеПрава", "ВызовСервера".., и суффиксов а-ля "Переопределяемый", "Служебный", "События"...

Хотя, лично я, против такой практики - из-за неё в ERP2 больше сотни общих модулей, и очень сложно разобраться к какому же модулю нужно обращаться. Я перешёл к практике 2-3 префиксов на модуль:
В первом располагается вся логика
Во-втором осуществляется переход на сервер из функции первого модуля (если того требует контекст) и обратный возврат вызова в первый модуль (здесь нет никакой логики - только смена контекста)
В-третьем - кеширование - когда нужно - и вызов опять первого модуля

Всё разделение на контексты доступности реализую директивами препроцессора уже внутри первого общего модуля.
Это очень удобно.
Вообще можно было бы обойтись одним первым общим модулем (особенно если бы платофрма 1С Предприятие не была такой ущербной и позволила бы применять аннотации контекста (как в управляемых формах) внутри общих модулей (в т.ч. для смены контекста вызова). Или можно просто сделать два ЕДИНЫХ общих модуля для смены контекста и производить его смену через функцию "вычислить" (все вызываемые методы должны быть функциями - впрочем я всегда так стараюсь делать) - увы - не будет работать на iOS - а ссылок на функции в 1С Предприятие 8 не завезли (и это в процедурном то языке программирования). Хотя можно частично выкрутиться через "ОписаниеОповещения" (увы - только на клиенте - хотя нужно это только для iOS).
Тогда смену контекста можно производить через общие прокси функции, вызывающие нужные функции по строковому пути - на производительности это не сильно сказывается
mikukrnet; Артано; +2 Ответить
60. Артано 712 19.05.21 06:47 Сейчас в теме
(58) Подписываюсь почти под всем.
Из "громких" есть замечание по поводу "как сделать ООП в 1с". Здесь главное без фанатизма и не городить костыли, просто так чтобы было ООП. Вполне достаточно ориентироваться на общую ООП-парадигму используя те её методы, которые можно без существенных костылей внедрить в процесс разработки, особенно коллективной.
65. Darklight 27 19.05.21 09:56 Сейчас в теме
(60)Я не предлагал делать ООП в 1С. Я просто описал некий паттерн (не мной придуманный, хотя, возможно я внёс в его формирование некие новые идеи) иной компоновки API общих (и частных) алгоритмов, где во главу угла ставятся обработки, а не общие модули (можно и общие модули, можно и комбинировать). И всё. Никакого полиморфизма и наследования; ограниченная инкапсуляция. Это скорее развитие идеи процедурного программирования (нужны только делегаты-ссылки на функции - но, как показал в комментарии, это тоже отчасти реализуемо) - то есть это больше динамический или статический библиотечный подход, чем ООП. Вероятно зря вообще упомянул ООП, не в нём суть.

Говоря же об интерфейсах (которые обычно относят к ООП) я не касался ООП - и предлагал их гипотетическое использование в контексте запросов (либо платформа должна развиться для их поддержки, либо, в контексте их представления в моём комментарии, можно внедрить свой прокси-движок для выполнения запросов с их препроцессорном перед выполнением - чтобы обработать эти интерфейсы, немного кустарно хранящиеся в метаданных или даже в данных ИБ). То есть, в этом смысле - Интерфейс - это просто описание контракта - на основании которого при его применении происходит автогенерация дополнительного кода (в данном случае конструкций "ВЫБОР... ВЫРАЗИТЬ"), и программисту, применившему приведение типа к интерфейсу, не нужно думать о том, что там за код генерируется и на основании каких данных-настроек этого интерфейса. Вернее думать надо , но только о том, что если применяешь интерфейс, то нужно следить за его актуальностью - но это уже, скорее вопрос к процессу доработки конфигурации , её расширению и обновлению - вот в этих процессах нужно следить за актуальностью имеющихся интерфейсов. Особенно, когда в платформе нет встроенной продвинутой поддержки этих процессов для интерфейсов (а ведь не сложно было бы сделать).

P.S.
Относительный нормальный ООП в 1С кустарно построить можно - но только если сделать свой расширенный компилятор в байт-код платформы. Это вполне возможно.... но вряд ли кто-то будет делать (хотя бы по той причине, что в 1С Предприятие 8 очень ограничены возможности по внедрению в конфигурацию скомпилированного байт-кода, а жаль).
69. Darklight 27 19.05.21 19:32 Сейчас в теме
(58)Сейчас проводил тесты разных запросов к регистру сведений. Был удивлён На выборке среза последних величиной в ~100M строк (без фильтров) запрос (с несколькими обращениями к одному и тому же срезу) с вложенными друг в друга внутренними соединениями (без временных таблиц; с итоговой выборкой около 100K строк) отработал всего за 70-80 сек (разброс от нескольких запусков). Вто время ка все варианты с временной таблице (куда помещался исходный срез) отрабатывал за 300-400 сек, примерно столько же заняли и разные варианты с вложениями через оператор "В()". А вот несколько последовательных-одноуровневых (не вложенных друг друга) внутренних соединений выполнялись 2000-2500 сек!
С включёнными итогами на срез последних выполнение почти всех вариантов сводилось к нескольким десяткам секунд (но было исключение с одним из запросов с оператором "В()" - который выполнялся около 100 сек).
Наличие/отсутcnвие индексов на временной таблице на результат почти не влияло (индекс был у другой таблице, к которой присоединялась обработанная выборка и регистра).
Та что, использование временных таблиц для регистра сведений перед его обработкой - не всегда однозначно прирост производительности, относительно прямого обращения к срезу (даже несколько раз во вложенных запросах) - а запросы с большим числом вложений были производительнее более "плоских".
СУБД MS SQL Server 13.0
70. Артано 712 20.05.21 06:29 Сейчас в теме
(69) А чему тут удивляться, вы программно создали огромную таблицу и ждете, что эти накладные расходы на быстродействии не скажутся =)
72. Darklight 27 20.05.21 10:24 Сейчас в теме
(70)Я просто говорю, что для разных задач эффективными могут совершенно разные подходы. И применение временных таблиц тут не является однозначно лучшим решением
86. triviumfan 26 24.05.21 19:03 Сейчас в теме
(58)
Почему все рекомендуют добавлять префиксы слева от идентификатора.

Потому что это удобно, плюс где-то было в стандартах, лень искать.
Мало того, что префикс должен быть в начале, так ещё и в синониме он тоже должен фигурировать, чтобы в интерфейсе было понятно, где типовой реквизит, а где твой добавленный.
87. Darklight 27 24.05.21 20:37 Сейчас в теме
(86)Стандарты стандартами. Но я задался вопросом почему именно так? Почему это удобно? Я не возражаю против префикса. Я возражаю, что его ставят слева. Я своё обоснование того, что префикс эффективнее ставить справа, привёл, и подкрепил примерами, где с моей точки зрения, в типовых конфигурациях префикс находится именно справа. Что не так в моих рассуждениях?
Про префикс в синониме не возражал. И да, тоже считаю, что он должен быть - и именно справа я его там ставлю - отдельным словом в скобках - чтобы не мешал восприятию основного наименования сущности (но только не для реквизитов и табличных частей, чтобы не мешал автоотображению заголовка на форме).

А в общем, такая префиксация - от лукавого - т.е. от ущербности платформы. В идеале, задачи дублирования имён и определения принадлежности к проекту должны решаться иначе - но это уже не 1С Предприятие 8 (по крайней мере в типовом исполнении редактора конфигурации)
88. triviumfan 26 25.05.21 00:31 Сейчас в теме
(87)
в типовых конфигурациях префикс находится именно справа

В каких типовых?) Твои примеры это не префикс, а аббревиатура названия модуля, в который вложена смысловая нагрузка.
Открой любую отраслевую конфу на основе типовой или БСП и ты увидишь, где стоят префиксы для новых объектов метаданных :)
89. Darklight 27 25.05.21 10:08 Сейчас в теме
(88)Отраслевые конфигурации следуют стандарту 1С - чтобы получить заветное "1С Совместимо" - это - как: "мы вам дадим пропуск на рынок, но вы должны ходить в колпаке с колокольчиками" (не объясняя зачем) - вот и ходят - пропуск то им важнее.

А в приведённых мной примерах данные аббревиатуры являются не чем иным как префиксами (или по-русски - окончаниями, или как ещё называют - суффиксами, что в данном случае морфологии русского языка будет вернее, как вот тут "ИнтеграцияИСМПВызовСервера" суффиксом будет "ИСМП", а окончанием "ВызовСервера", хотя как выше приводил в типовых бывает и такое "ОбщегоНазначенияMicrosoftExcelКлиентСерверУХ" - тут "УХ" окончание, а "КлиентСервер" - суффикс, а ещё есть "MicrosoftExcel" - тоже суффикс; но уже как-то привычно сложилось, чтобы не разбираться в тонкостях морфологии русского языка, все это называют префиксом). Так вот, в этих примерах префиксы расположены справа - и не важно, как они образованы - автором (владельцем) данных объектов метаданных, или названием модулей. Стилистически - эти префиксы расположены справа. А как будет выглядеть - будь они слева - я уже показал - на мой взгляд выглядит ужасно (а в использовании ещё ужаснее чем выглядит).

Можно конечно, привести убийственный контр пример - что когда делаешь расширение конфигурации - то платформа ЯВНО ставит префикс ВСЕГДА СЛЕВА - т.е. соблюдает стандарт 1С - и это ужасно - сердце кровью обливается кода я вижу понатыканные префиксы слева. Вот хочешь обратиться к объекту метаданных - знаешь его бизнес- имя - ан-нет - сначала набери префикс - а потом уже вводи имя - быстрые подсказки или поиск превращаются в муку! Как и в муку превращает их просмотр в списке - когда четверть отображаемого имени - это префикс - а затем ещё четверть реального имени умещается в списке - а остальная часть просто не влезает в ширину списка.

И особенно ужасно то, что по сути эти префиксы в расширениях ни черта не решают проблему дублирования имён - потому, что легко может быть несколько расширений с одними и теми же идентификаторами-метаданными и одними и теми же префиксами (как от одного вендора, так и от разных). При этом сами метаданные могут как быть реально одинаковыми (просто общими), или тоже одинаковыми - но реализующими разные части общего расширения - т.е. должны быть объединены в единое целое. Но это уже ущербность системы расширений конфигураций платформы 1С Предприятие 8. Хотя при установке "расширений" через сравнение-объединение конфигураций - проблема тоже остаётся - хотя тут больше способов её решению - но всё это костыли! И префиксы тут совсем не панацея - а лишь иллюзия, что проблем не будет!

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

И мне бы хотелось, чтобы в будущем появился иной стандарт - хотя бы для гипотетической "1С Предприятие 9". Где такие нюансы как проблема идентификаторов будет решена более изящно, чем через префиксы (где бы они ни были).

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

А для решения проблемы дублирования имён нужно вводить пространства имён, области видимости и интерфейсы. Все объекты метаданных могут входить в те или иные пространства имён. Тогда, скажем, у модуля-метаданных могут быть пространства имён, подключаемые по умолчанию (в них идентификаторы (условно) не должны пересекаться, но только в рамках контекста модуля-метаданных), отдельные метаданные модуля-метаданных (и отдельно их модули-алгоритмов) могут переназначать пространства имён по умолчанию, а так же добавлять для своего контекста новые или просто обращаться по полному пути).
В случае конфликта идентификаторов в контексте действия нескольких пространств можно просто задать локальные псевдонимы для проблемных идентификаторов внутри контекста, где возник конфликт.

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

Интерфейсы - тоже мощная штука - внутри некоего объекта метаданных могут быть свои внутренние (не обязательно публичные идентификаторы). Но для него может быть создан интерфейс (множество интерфейсов, или он может использовать готовый интерфейс) - который будет привязывать эти внутренние идентификаторы к своему API. Интерфейсы не глобальны. Между собой (условно) не пересекаются. Когда нужен доступ к объекту метаданных - можно привести его к Интерфейсу и обращаться через API этого Интерфейса не заморачиваясь о том какие там идентификаторы и как их имена могут пересекаться с другими расширениями этого объекта (ведь там Интерфейс будет уже другой). Тут, конечно, очень много своих тонкостей - но их можно решать на уровне правильного декларирования и обновления, а не вводя кривых имён и префиксов.

Мощным принципом мог бы и быть принцип общих идентификаторов - определяющих заданную бизнес-сущность. Можно было бы вести общий список таких идентификаторов в рамках какого-то регистратора (их может быть много). Тогда, при необходимости использования такой бизнес-сущности в метаданных - её можно без опаски ввести под заданным именем - связав её с уникальным идентификатором общего идентификатора. Тогда - если произойдёт конфликт имён (скажем при установке нового модуля-метаданных или обновления существующего) и оба идентификатора будут связаны с одним и тем же уникальным идентификатором общей бизнес-сущности, то проверяется соответствие внутреннего API этих идентификаторов - если оно не противоречит зарегистрированному для общей бизнес-сущности (может быть расширенной) - то конфликта имён не будет - идентификатор будет единым для нескольких модулей-метаданных (но его API может быть расширен), и он будет иметь связи с со всеми такими модулями (при удалении всех модулей, с которыми он связан, он будет удалён из конфигурации). В рамках своего модуля-связи он будет ограничен API этого модуля (но может получить обобщённый API по явному запросу).
И это правильно - зачем в систему добавлять две одинаковые бизнес-сущности - чем бы они ни были - одинаковыми справочниками, реквизитами, макетами, модулями-алгоритмов, глобальными переменными/функциями...

Этим я хотел сказать - что префиксы (особенно слева) - это очень не красиво и очень ущербно - есть куда более красивые и надёжные решения (не претендуя на то, что всё что мной сказано - это лучшее из всех возможных решений - просто привёл своё мнение). И задал вопрос - почему префиксы именно слева. Но пока неявно получаю ответ - потому что так "истерически у кого-то зачесалась пятая нога"! Ведь началось всё ещё в 1С Предприятие 8.0 (да и даже в 1С Предприятие 7.7 наверное - просто уже плохо помню те времена, а сами префиксы метаданных тогда были куда менее распространены).
И в чём удобство префиксов именно слева - так никто и не объяснил (кроме - ну так же у всех - хотя и не всех так же). А я объяснил - почему считаю, что префиксы справа - это куда удобнее, чем префиксы слева!

Но если стандарты говорят - что всем нужно ходить строем, а "шаг влево шаг вправо - расстрел", и не объясняют почему строем ходить правильно, чем тоже друг за другом но в вразвалочку - да ну нафиг такие стандарты, даже если за их не соблюдение не дадут баланду - найдём сами что похавать (пока есть такая возможность и всех "строем насильно не выстроили пулемётными очередями")!
90. triviumfan 26 25.05.21 17:40 Сейчас в теме
(89) Много букв, нет времени читать.
Но вот прямо сейчас я снова обновляю сильно доработанную конфу. И если бы вместо префиксов были бы суффиксы - я бы буквально глаза сломал.
Есть функция ИТМ_ЗаполнитьРезервамиПоЗаказуНаСервере. Но если бы она называлась ЗаполнитьРезервамиПоЗаказуНаСервере_ИТМ, то мне пришлось бы тратить время, чтобы прочитать все название процедуры, искать суффикс, а не доработанная ли это функция и нужно ли её оставлять или все же удалять.
Почему тебе так удобнее мне никогда не понять (наверное, ты просто не занимаешься обновлением). А переубеждать бессмысленно - у тебя своя правда.
91. Darklight 27 25.05.21 18:07 Сейчас в теме
(90)Ну вот, хоть какой-то аргумент за левые префиксы. Хотя и слабый аргумент - к счастью, человеческий взгляд так устроен, что может легко читать части текста как слева так и справа - не нужно читать всё название целиком слева на право - если префиксы находятся справа - так и искать глазами (когда это требуется) их нужно справа, а не читать весь идентификатор целиком в поисках префикса. Тут всё удобство/неудобство - дело привычки. В отличие от приведённых мной аргументов.

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

В идеале таких вопросов вообще быть не должно - такие функции не должны явно попадать в общий список сравнения содержимого модулей. А если попадают - то сразу должны быть особым образом выделены (да хоть цветом).

Но лучше - чтобы не пересекались - были расположены в отдельном модуле - но, увы, с иерархией (да даже с линейным списком, кроме общих) модулей - в 1С Предприятие 8 всё туго! А давно уже надо было ввести такую возможность, уже в 1С Предприятие 8.х добавить как любое число модулей объекта, менеджера, формы, команды, сеанса, приложения; так и иерархию этих модулей (вложенные друг в друга модули, с настраиваемой видимостью содержимого относительна владельца и подчинённых модулей) - это не ломало бы общую архитектуру 8-ки, а только подчёркивало то, что в ней можно создавать произвольное число подчинённых объектов метаданных, на ряду с табличными частями, макетами и формами (чего не было в 1С 7.7).

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

Всё это только подчёркивает ущербность платформы 1С Предприятие 8 - то что, её архитектура почти не развивается - и действительно полезных фишек в ней почти не появляется
Артано; +1 1 Ответить
93. Артано 712 27.05.21 05:32 Сейчас в теме
(90) Если функции нужен префикс/суффикс, то она должна располагаться в отдельном модуле. В коде вообще этому не место. Тут скорее лень/кривые руки авторов доработки ИТМ.
94. triviumfan 26 27.05.21 18:03 Сейчас в теме
(93)
Если функции нужен префикс/суффикс, то она должна располагаться в отдельном модуле. В коде вообще этому не место.

Может тебе здесь не место?! :) В каком коде?! Каком модуле?!
Делаю обновление -> сравнение/объединение, поставщик конфигурации сильно поменял форму объекта.
Смотрю различия с учетом структуры - там сотня функций. Половина подсвечена красным. Как я должен понять, моя эта функция или поставщика? Удалять её или нет? Для таких глупых/криворуких и имеются стандарты - был бы там префикс, то я бы сразу пропустил её.
Прикрепленные файлы:
95. Артано 712 27.05.21 18:55 Сейчас в теме
(94)
Может тебе здесь не место?! :) В каком коде?! Каком модуле?!
Делаю обновление -> сравнение/объединение, поставщик конфигурации сильно поменял форму объекта.
Смотрю различия с учетом структуры - там сотня функций. Половина подсвечена красным. Как я должен понять, моя эта функция или поставщика? Удалять её или нет? Для таких глупых/криворуких и имеются стандарты - был бы там префикс, то я бы сразу пропустил её.


Постараюсь быть ласковым и терпеливым к тем, кто освоил унылые мемы, но не освоил методику доработки объектов поставщика.

Итак. Если дорабатывается объект поставщика, то делается это через подписки и/или точки входа с вызовом функций из собственных (не поставщика) модулей. Таким образом, означенная в цитате проблема, есть проблема созданная "такими глупыми/криворукими" и героически ими же решаемая. Можете не благодарить.
96. triviumfan 26 27.05.21 19:23 Сейчас в теме
(95) Ты во всех типовых конфигурациях видел точки входа для вызова своих функций? Да откуда вы такие берётесь?!
Да даже речь не про это! Даже если ты добавил команду в своём кривом модуле и вызовешь его ПриСозданииНаСервере(), то сам обработчик команды у тебя без префикса будет - сам говоришь, что префиксу тут не место.
Повторюсь: может тебе все-таки тебе тут не место? После таких вот людей, кто освоил методику доработки объектов поставщика, сопровождать конфигурацию противно. Моя б воля - уволил бы сразу.
97. Артано 712 28.05.21 10:03 Сейчас в теме
(96) Я, к счастью, могу принимать сам решения где мне работать, а где нет, и если бы пришлось работать с тобой (вдруг бы случилось такое чудо), то это бы продлилось недолго, здесь согласен =)

По существу. Зачем обработчику команды префикс не возьму в толк? В типовых есть точки входа, в общем то. Как правило обработчики в новых типовых имеют их. В старых - всё в твоих руках (после выпрямления, хе-хе). Ну если ты агрессивно считаешь, что курочить типовые объекты лучше, чем делать подписки, точки входа там где подписки невозможны, то не вижу смысла разговаривать. Невежество в сочетании с агрессией приводит к драке. Попробуй попить таблетки, чтобы хотя бы на людей не бросаться.
Если же у тебя просто не хватает некоторых знаний, то почитай например у Онянова, там вполне хорошие и структурированные требования по доработке. Некоторые моменты неоднозначные, но в целом всё здраво и обоснованно.
98. triviumfan 26 29.05.21 21:29 Сейчас в теме
(97)
Зачем обработчику команды префикс не возьму в толк?

Тогда снова перечитай (95).
Перечитывай до тех пор, пока не "возьмёшь в толк":)
ЗЫ: И да, если ты не знал (видимо опыта не хватает), то не все формы типовых конфигураций имеют "точки входа".
Артано; +1 Ответить
99. Артано 712 29.05.21 22:24 Сейчас в теме
(98)
Тогда снова перечитай (95).
Перечитывай до тех пор, пока не "возьмёшь в толк":)
ЗЫ: И да, если ты не знал (видимо опыта не хватает), то не все формы типовых конфигураций имеют "точки входа".


Посмеялся. Заскриню, иначе мне никто не поверит.
59. RPGrigorev 608 18.05.21 16:56 Сейчас в теме
Отличная статья, спасибо! Пункт "Использование условий в запросе в секции ГДЕ, вместо параметров виртуальной таблицы." - результат не только отличается скоростью выполнения, более того, он может давать логически разные результаты, при использовании виртуальных таблиц "Срез последних" и т.п.
61. Артано 712 19.05.21 06:48 Сейчас в теме
(59) Разные в случае если отбор в виртуальной таблице не только по измерениям? Ну тогда человек сам себе враг, раз такое пишет. Регистр в виртуальной таблице группируется именно по измерениям.
62. RPGrigorev 608 19.05.21 07:19 Сейчас в теме
63. Артано 712 19.05.21 07:55 Сейчас в теме
(62)
Хотя данные запросы различаются только способом указания отбора, их результаты, в отличие от случая с запросами по регистру накопления, будут различны


Статья из разряда эксперимента "безногий таракан не слышит" =)
Нет бы по-человечески объяснили бы, что группировка идет по измерениям в виртуальной таблице, поэтому только по ним и можно отбирать, если хотите такой же результат как при отборе нефильтрованной таблицы
RPGrigorev; +1 Ответить
64. RPGrigorev 608 19.05.21 08:14 Сейчас в теме
(61) согласен, абсолютно верно подмечено, спасибо
66. ashvik 19.05.21 11:35 Сейчас в теме
67. mikukrnet 177 19.05.21 12:36 Сейчас в теме
"Правильно разделять выполнение и выборку/выгрузку результата запроса"

Объяснитесь, сэр
68. OlegLad67 19.05.21 15:45 Сейчас в теме
Спасибо за статью! Возьму на вооружение.
71. Артано 712 20.05.21 06:35 Сейчас в теме
Начал вдумчиво читать чек-лист, дошел до пункта с рекомендацией про функцию IsNull и вспомнил смешное.

Однажды объяснил парням про составные типы и необходимость использования функции Выразить. В итоге наблюдал такие запросы как во вложении
Прикрепленные файлы:
82. Cyberhawk 129 24.05.21 08:54 Сейчас в теме
(71) А что с этим запросом не так? Как его следовало бы переписать?
83. Артано 712 24.05.21 09:10 Сейчас в теме
(82) В том, что прежде чем проверить условие отбора или соединения необходимо будет вычислить некую функцию. Как следствие нет никакого шанса использовать индексы или иные средства оптимизации запроса. Все записи будут обработаны функцией.

Функции Isnull, Выразить, ТипЗначения заменяются соответствующими операторами Is Null и Ссылка. Приводил в списке типичных ошибок прилагаемых к статье об ошибках. Параграф 2.4
84. Cyberhawk 129 24.05.21 09:16 Сейчас в теме
(83)
В том, что прежде чем проверить условие отбора или соединения необходимо будет вычислить некую функцию ... Все записи будут обработаны функцией
А, ну т.е. идея в том, что ВЫРАЗИТЬ само по себе не делает фильтрацию (по указанному там типу документа), и поэтому нужно было еще и отбор на тип регистратора (в параметры виртуальной таблицы или в ГДЕ добавить), так?
85. Артано 712 24.05.21 19:02 Сейчас в теме
(84) Да. Вообще плохая практика копаться в регистраторах. Но раз уж так спроектирована БД, то хотя бы с наименьшими потерями
Cyberhawk; +1 Ответить
74. van_za 144 20.05.21 17:16 Сейчас в теме
77. Артано 712 21.05.21 17:44 Сейчас в теме
(76)
А кто говорил что будет легко? Зато коллеги которые после вас придут, не будут думать что вы осел.

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

Почему так? Ответьте на вопрос и всё станет на свои места:
Вы можете в любой момент времени дать оценку адекватности и вообще объёму изменений в коде по сравнению с конфигурацией поставщика, в случае если все доработки помещены в расширения?

Как только такая возможность появится я буду первым, кто поддержит повсеместное использование расширений.
Сейчас же их обоснованная ниша это временные заплатки, до полноценного обновления конфы.
78. Baronello 1 22.05.21 11:29 Сейчас в теме
(77)
Вы можете в любой момент времени дать оценку адекватности и вообще объёму изменений в коде по сравнению с конфигурацией поставщика, в случае если все доработки помещены в расширения?

Эм, сравнить и объединить?
81. Артано 712 24.05.21 02:46 Сейчас в теме
(78)
Эм, сравнить и объединить?


А уже добавили сравнение расширения и конфигураций?
79. puzakov 22.05.21 15:36 Сейчас в теме
По-моему за префиксы в именах объектов нужно бить по рукам. В 99% случаев префикс - сорная информация, которая всюду лезет на передний план. Ухудшается работа контекстной подсказки, ухудшается восприятие информации, убивается нормальная сортировка имен. Если очень уж хочется изуродовать имя своего объекта/свойства лишней информацией, то можно использовать постфикс в имени. Это будет хотя бы не так уродливо. Вместо:
ххх_Товар
ххх_Контрагент
ххх_Склад

Писать:
Товар_ххх
Контрагент_ххх
Склад_ххх


а вообще, у всех объектов метаданных и их свойств есть комментарий. Можно в нём увековечить имя автора. Как жаль, что за столько лет существования платформы, прикладные разработчики так и не научились использовать комментарии к метаданным
oleganatolievich; Артано; +2 1 Ответить
92. Артано 712 27.05.21 05:29 Сейчас в теме
(79) Интересно, кто влепил минус и не отметился почему. Я с автором комментария согласен, готов выслушать мнение несогласных.
80. puzakov 22.05.21 15:42 Сейчас в теме
Код должен читаться без пояснений и не должен содержать грамматические ошибки.


Очень скупое правило. Имена переменных и методов - главное оружие программиста. От выразительности имен переменных и методов сильно зависит легкость восприятия кода. На эту тему можно целую книгу написать
AKunitsyn; Артано; +2 Ответить
Оставьте свое сообщение

См. также

Антипаттерны программирования в 1С

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

Поговорим про плохой стиль программирования и рассмотрим 17 часто встречающихся антипаттернов.

19.07.2021    7379    ivanov660    119    

Ускорение расчета себестоимости УПП 1.3 в несколько раз

Рефакторинг и качество кода Закрытие периода v8 УПП1 БУ УУ Бесплатно (free)

Как определить причину медленного расчёта себестоимости в УПП 1.3, один из вариантов поиска проблем производительности с помощью инструментов 1С и ускорения расчёта средствами встроенного языка

02.02.2021    3073    RPGrigorev    19    

Реальный кейс по внедрению CodeReview

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

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

20.01.2021    1746    Alexsandr_Retunskiy    3    

Операторы перехода в программном коде: использовать или нет?

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

Рассмотрим ситуации использования операторов перехода Перейти (GoTo), Возврат (Return), Прервать (Break), Продолжить (Continue). Как вы считаете - это дурной тон, нормальная практика или зависит от ситуации?

16.11.2020    2772    ivanov660    22    

Чистый кот (Clean cat)

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

От автора легендарного бестселлера "Совершенный кот".

04.11.2020    1788    vasilev2015    25    

Доработайте это "немедленно", или как уменьшить доработки конфигурации

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

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

25.09.2020    4033    Богатырев Артур    24    

Метод борьбы с большим количеством комментариев в коде

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

Решил поделиться нашим способом борьбы с сильно закомментированным кодом.

08.09.2020    1445    tambu    9    

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

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

Наличие в 1С-решениях некачественного кода мешает их поддержке и эффективному развитию. Как добиться соблюдения стандартов разработки при написании кода и внедрить бюджетный Code Review с помощью инструментария на основе АПК (Автоматизированной проверки конфигураций) на конференции Infostart Event 2019 Inception рассказал технический руководитель компании Бизнес Лоджик Иван Козлов.

22.06.2020    3797    kozlov.alians    1    

Молчание "best practices": тестовые и эталонные данные, структура и связность, падения и новая функциональность, и другие неудобные вопросы к сценарному тестированию

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

Непонимание некоторых базовых вопросов мешает программистам начать применять инструменты тестирования в процессе разработки для 1С. Как разобраться в терминологии и интегрировать процесс тестирования в разработку 1С-решений на конференции Infostart Event 2019 Inception рассказал руководитель отдела разработки компании C.T.Consultants Решитко Дмитрий.

29.05.2020    4942    grumagargler    14    

Рефакторинг в редакторе модулей

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

Для тех, кто не пользуется Ctrl+Alt+R. “Контролируемый процесс улучшения кода без написания новой функциональности”, “Равносильное преобразование алгоритмов” и т.п в данной статье НЕ рассматриваются. Тема статьи: замечательные команды из подменю Рефакторинг контекстного меню редактора модулей в конфигураторе. В статье описано, как команды из подменю Рефакторинг помогают при написании кода

10.03.2020    4506    pparshin    5    

Качество кода: Поведенческие паттерны проектирования

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

Поговорим про применение паттернов проектирования в разработке на 1С.

03.03.2020    8513    ivanov660    0    

Боремся с запросами в циклах. Мой опыт рефакторинга запросов

Рефакторинг и качество кода v8::Запросы 1cv8.cf Бесплатно (free)

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

02.03.2020    8577    aximo    55    

Стабильность превыше всего

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

Странная заметка о поддержании стабильности в условиях интенсивного изменения конфигурации.

07.11.2019    10077    YPermitin    40    

Оценка скорости кода. Сложность алгоритма

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

Эта тема одной из первых всплывает на собеседовании программистов языков вроде Java и C, но она почти неизвестна в "мире 1С". Поговорим о вычислительной сложности алгоритмов.

07.10.2019    6451    m-rv    12    

Управление качеством кода

Математика и алгоритмы Рефакторинг и качество кода SonarQube EDT v8 Бесплатно (free)

О SonarQube, АПК, EDT. Какие преимущества дает их использование. Для каких команд подходит.

22.07.2019    18809    Stepa86    40    

По следам код-ревью

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

Приведу примеры с картинками и небольшим пояснением по вопросам, связанным с код-ревью (обзором кода).

09.07.2019    13933    ivanov660    111    

Что такое рефакторинг и в чем его цели

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

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

30.10.2018    13084    eu_genij    34    

Мастер-класс от Poppy (практикум по рефакторингу)

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

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

04.11.2008    18891    poppy    33