(75) Люди, у которых "время-деньги", должны понимать других людей, что у них тоже "время-деньги", и не писать заведомо медленный и неправильный код.
Тем более, что в БСП это тоже делается одной строчкой, хоть и более длинной. А если конфа без БСП, стоит подумать хотя бы о переносе модуля ОбщегоНазначения. Там вообще много хороших функций.
(90) Строго говоря это неправда, потому и не "итак понятно". Банальный пример: простой запрос в цикле зачастую оказывается гораздо более ресурсоемкой операцией, нежели выполнение одного сложного запроса. И чем больше активных пользователей, работающих в базе, чем больше таких "мелочей" оказывается разбросанными в модулях конфигурации, тем более вероятно они складываются в одни общие "тормоза".
(101) это как надо приучить себя к говнокодингу чтобы писать запрос в цикле. Вот я хоть и знатный говнокодер, но запрос в цикле для меня это уже перебор...))
(132) Вывод в печ. форму Ссылки вместо наименования - тот же запрос в цикле. Обращение к реквизиту через точку цикле - тот же запрос в цикле. Возможно, вы просто этого не замечаете.
(132) вот здесь почитайте https://infostart.ru/public/1043307/ иногда запрос в цикле - единственный способ решить задачу
не будьте так категоричны в высказываниях!
(84) Простите, но раз вы такое говорите, мне сложно будет вам что-то доказать. Прочитайте ссылки выше, которые давали в обсуждении объектного чтения. Также была недавно исследовательская статья на эту тему здесь на ИС.
ОбщегоНазначения тянет за собой ОбщегоНазначенияПовтИсп, ОбщегоНазначенияКлиентСерверный, а они в свою очередь кучу других. Это ещё полбеды, главное, мало кто изучает эти модули. Проще набыдлокодить.
За исключением некоторых примеров - спорно. Читаемость кода ухудшается, что усложняет поддержку. Скорость разработки также ухудшается. Если смотреть со стороны франчей, то все так и должно быть. Сделать как можно сложнее, чтобы не слезли с крючка, а потом доить..
Как по мне, код нужно писать на идеально, а оптимально. Для разных задач может использоваться разный подход написания.
И да, не нужно слепо следовать стандартам 1С.
Как по мне, код нужно писать на идеально, а оптимально. Для разных задач может использоваться разный подход написания.
И да, не нужно слепо следовать стандартам 1С.
Эти оптимизации помогают на приличных базах сократить сотни секунд серверных вызовов. Вы недооцениваете эти рекомендации.
(137) Я же написал. Для разных задач - разный подход. Сколько процентов от всех баз 1С - приличные базы? Не имеет смысла для малых баз писать идеальный код. Это лишние трудозатраты. Только если для узких мест.
(137) верно !
но команды разработчиков сами договариваются о принципах кодинга!
...бывают проекты, когда по приоритетам внедрить как можно скорее важнее, чем оптимизация кода... разным целям - разные подходы
ются о принципах кодинга!
...бывают проекты, когда по приоритетам внедрить как
Я не очень понимаю, почему вы считаете, что тут дело в стандартах кода. Не использовать запрос в цикле при печати массива документов это не стандарт кода, это элементарно квалификация, во всех типовых так применяется. Да и код не усложняется, по крайней мере, если написал так хотя бы два три раза. Писать ПолучитьЗначениеРеквизита не вопрос стандарта, это вопрос того, как будет ваше приложение медленно работать.
Да, некоторые не знают, что запрос в цикле нужно избегать, но это не вопрос к их стандартам, это вопрос к квалификации. Кто хоть раз делал замеры по производительности, на любой базе, тот всегда будет писать один запрос для всех объектов.
Хочу немного раскритиковать данную статью по некоторым параметрам.
1. Для подобного рода синтаксического контроля есть SonarQube (возможно есть еще что-то...), причем правил по написанию кода не 3 а, 233. Вплоть до отчетов по качеству когда и созданного технологического долга.
Выискивать код который написан "Не стандартно", по всей конфигурации, самостоятельно, сверяясь со всеми "стандартами" о которых было миллион раз написано на инфостарте, методолгами на сайте 1С и т.д не рационально и ОЧЕНЬ спорно и трудозатратно.
2. Дело не в "клиповом" мышлении, а дело в том, что 1 содержательная картинка, лучше чем 100 (или больше) слов. Именно по этому бизнес аналитики пользуются различными нотациями при описании бизнес-процессов, по этому инструкции для пользователей нарезаются из скриншотов, именно по этому вы подключаетесь к клиенту по удаленному доступу и смотрите в его экран, это удобно и информативнее. Именно по этому я дочитал эту статью до конца.
3. Тема с разыменованием полей не до конца раскрыта.
3.1 Когда вы пишете запрос следующего вида:
|ВЫБРАТЬ
|СУММА(Документ.Ссылка.ЕщеЧтоТо.Контрагент.ИНН) КАК Сумма
т.е. где больше одного разыменования поля, следует все таблицы дополнительные присоединять через левое соединение. "ЕщеЧтоТо" должно быть отдельным левым соединением. В противном случае весь смысл использования запроса теряется.
3.2 Например получилась такая ситуация и я вынужден использовать "НайтиПоКоду" имею полное право, есть такая функциональность, почему и нет. То в данном случае место цифр кода, я должен передавать переменную, в которой будет код и выглядеть это должно следующим образом:
При таком написании не важно где вы используете этот стандарт например:
HTTPЗапрос = Новый HTTPЗапрос(СтруктураURI.ПутьНаСервере);
... получаем код возврата
НеверныйЗапрос = 400; //HTTP 400 Bad Request
Если Результат.КодСостояния = НеверныйЗапрос Тогда
//что-то делаем
КонецЕсли;
И вот это правильно.
Подведя черту хочу сказать следующее:
Возможности платформы, которые доступны разработчикам "из коробки", в области автоматизированной проверки качества кода, автоматизированного тестирования, версионирования кода и .т.п убогие и требуют серьезных трудозатрат по автоматизации этого процесса.
Можно написать миллион статей и комментариев про то "как надо" и это не будет выполняться в следствии понятных всем причин. Как минимум можно все эти "надо" оспорить в одностороннем порядке и не делать, просто потому что я считаю что вы не правы, кто-то не прочитает статью, кто-то забудет, не заметит, пропустит, отвлечется в момент того когда надо будет проконтролировать качество написания когда и все, создан технологический долг, который точно не возможно будет исправлен.
p.s. пока пиал комментарий, попытался перейти на ИТС и прочитать Соглашения при написании кода 1С, на что мне вернулась ошибка 404. В моем случае я даже не смог его прочитать, а не просто забыл использовать его в работе :)
Выискивать код который написан "Не стандартно", по всей конфигурации, самостоятельно, сверяясь со всеми "стандартами" о которых было миллион раз написано на инфостарте, методолгами на сайте 1С и т.д не рационально и ОЧЕНЬ спорно и трудозатратно.
(92) Я как-то сидел, и думал, чем бы мне заняться и решил что буду программировать на 1С, сегодня решил, а на следующий день сразу запрограммировал, и сразу по стандартам 1С. Всему нужно учиться, и ко всему нужно привыкать это долгий и требующий усилий процесс. Сразу ничего не бывает.
(96) Я хочу сказать что самому контролировать это тяжело. Различных правил для модулей, процедур, функций мне кажется больше 200 можно собрать. Даже после долгой практики, всё равно умудряешься ошибаться. Человеческий фактор будет всегда присутствовать. Я за автоматизированные средства.
* Что делать с частью выражения, переносимой на следующую строку
* Не выравнивайте правые части выражений присваивания (Как видите, актуально)
* Размещение каждого оператора на отдельной строке
Первая строка из этой цитаты - рекомендация, утверждение, ошибка форматирования?
Вторая строка запрещает делать так?
// Неправильно?
Переменная = Новый Структура;
ПеременнаПодлиннее = Новый ТаблицаЗначений;
СовсемДлиннаяПеременная = Новый Запрос;
// Правильно?
Переменная = Новый Структура;
ПеременнаПодлиннее = Новый ТаблицаЗначений;
СовсемДлиннаяПеременная = Новый Запрос;
* Что делать с частью выражения, переносимой на следующую строку
* Не выравнивайте правые части выражений присваивания (Как видите, актуально)
* Размещение каждого оператора на отдельной строке
Это тезисы из "Совершенный код". Первая строка - открытый вопрос, вторая - рекомендация. На сайте ИТС написано "допускается", а не "рекомендуется". На мой взгляд, это свидетельствует, что выравнивание вправо не является предпочитаемым методом.
(105)Мне тоже очень нравится выравнивание. А для работы в 1С предпочитаю использовать ультраширокоформатные мониторы - и сразу ограничение в 120 символов длинны строки кажется неоправдоно жёстким.
К вопросу объектное чтение vs чтение запросом.
1) Придирка. Утверждать что объектное чтение медленнее, поскольку вместе с нужным реквизитом тянется весь объект (если не учитывать кэш), а запрос читает только то что заказали немного некорректно. СУБД оперирует страницами. Для нашего любимого MS SQL по умолчанию 8 кб. При выполнении запроса на чтение скуль прочитает в память минимум 1 страницу. Что (скорее всего) с запасом перекроет разницу. Поэтому объявлять крестовый поход против объектного чтения все же не стоит. Код усложнится, а будет ли заметная выгода еще не факт.
2) Не отмечено важное отличие 2 техник. Возможность читать запросом только РАЗРЕШЕННЫЕ данные. Есть ли на сайте люди, не наступившие ни разу на эти грабли? Когда разрабатываем - все хорошо, передаем изменения бесправным юзерам - пошли баги.
1) Придирка. Утверждать что объектное чтение медленнее, поскольку вместе с нужным реквизитом тянется весь объект (если не учитывать кэш), а запрос читает только то что заказали немного некорректно. СУБД оперирует страницами. Для нашего любимого MS SQL по умолчанию 8 кб. При выполнении запроса на чтение скуль прочитает в память минимум 1 страницу. Что (скорее всего) с запасом перекроет разницу. Поэтому объявлять крестовый поход против объектного чтения все же не стоит. Код усложнится, а будет ли заметная выгода еще не факт.
Так и в первом и во втором случае SQL прочитает страницу. Объектный режим чтения это тот же запрос к БД.
Только в случае объектной модели платформа прочитает весь объект, создаст его структуру и тд. При чтении запросом мы получим только значение указанных нами реквизитов.
Или нет?
(112) Мы при обоих техниках чтения получим одинаковую дисковую операцию - чтение 1 страницы с диска в память сервера. Для небольших объектов ессно. Поэтому для тривиальных случаев, типа примеров в статье, получить заметную разницу в производительности не выйдет.
Поэтому для тривиальных случаев, типа примеров в статье, получить заметную разницу в производительности не выйдет.
Так обсуждается не конкретный пример, а подход в целом.
И сколько страниц будет прочитано SQL сервером при объектной модели если объект будет содержать несколько табличных частей?
А нам например нужны только значения реквизитов документа.
(115) Подход в целом - использовать запросы вместо объектного чтения не оспаривается. Учение Ленина истинно, потому что верно! Предлагается в применении подхода не доходить до фанатизма. Время, потребное на искоренение всех обращений через точку, можно потратить более продуктивно. Например на профилирование и оптимизацию "горячего" кода
Время, потребное на искоренение всех обращений через точку, можно потратить более продуктивно. Например на профилирование и оптимизацию "горячего" кода
Так можно сразу писать "не через точку", без всякого фанатизма, тогда ничего искоренять и исправлять не придётся и можно спокойно заниматься оптимизацией и профилированием "горячего" кода.
Так можно сразу писать "не через точку", без всякого фанатизма, тогда ничего искоренять и исправлять не придётся и можно спокойно заниматься оптимизацией и профилированием "горячего" кода.
Конечно лучше. Еще лучше сразу писать код не нуждающийся в тестировании и отладке. Недавно тут пробегал такой материал, как правильно прогов нанимать, там такое проповедовалось. Жаль что не всегда получается.
(117) Привет Рома. Выше холиварили про объектное чтение vs запрос на разовой операции чтения. Непонятно, что ты хотел сказать своим примером? Зачем гонять цикл по СправочникВыборка вместо ВЫБРАТЬ Контрагент.ИНН ИЗ Справочник.Контрагенты?
на разовой разницы нет, это да. Но ты пишешь процедуру-функцию, в ней вот такой код. Завтра твоя процедура очень кому-то понравится и он будет ее в цикле гонять... Поэтому лучше сразу писать через БСП-шные функции. Рисков меньше
90 процентов всех "ускорений" решается убиранием объектного чтения
(123) Давай не будем до абсурда доводить. Исходный тезис был, если ты забыл, что чтение запросом в примере из статьи не дает выигрыша в производительности. Что ты и показал в тесте, время на операцию < 0,01 сек Я еще не сошел с ума и не предлагаю запросы переписывать на объектное чтение.
Завтра твоя процедура очень кому-то понравится и он будет ее в цикле гонять...
А за такое надо бить по рукам не зависимо от стиля чтения в процедуре. Запрос в цикле это бяка в любом случае. Даже БСП-шный.