Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(75) Люди, у которых "время-деньги", должны понимать других людей, что у них тоже "время-деньги", и не писать заведомо медленный и неправильный код.
Тем более, что в БСП это тоже делается одной строчкой, хоть и более длинной. А если конфа без БСП, стоит подумать хотя бы о переносе модуля ОбщегоНазначения. Там вообще много хороших функций.
Тем более, что в БСП это тоже делается одной строчкой, хоть и более длинной. А если конфа без БСП, стоит подумать хотя бы о переносе модуля ОбщегоНазначения. Там вообще много хороших функций.
(90) Строго говоря это неправда, потому и не "итак понятно". Банальный пример: простой запрос в цикле зачастую оказывается гораздо более ресурсоемкой операцией, нежели выполнение одного сложного запроса. И чем больше активных пользователей, работающих в базе, чем больше таких "мелочей" оказывается разбросанными в модулях конфигурации, тем более вероятно они складываются в одни общие "тормоза".
За исключением некоторых примеров - спорно. Читаемость кода ухудшается, что усложняет поддержку. Скорость разработки также ухудшается. Если смотреть со стороны франчей, то все так и должно быть. Сделать как можно сложнее, чтобы не слезли с крючка, а потом доить..
Как по мне, код нужно писать на идеально, а оптимально. Для разных задач может использоваться разный подход написания.
И да, не нужно слепо следовать стандартам 1С.
Как по мне, код нужно писать на идеально, а оптимально. Для разных задач может использоваться разный подход написания.
И да, не нужно слепо следовать стандартам 1С.
(89)
Как по мне, код нужно писать на идеально, а оптимально. Для разных задач может использоваться разный подход написания.
И да, не нужно слепо следовать стандартам 1С.
Эти оптимизации помогают на приличных базах сократить сотни секунд серверных вызовов. Вы недооцениваете эти рекомендации.
Как по мне, код нужно писать на идеально, а оптимально. Для разных задач может использоваться разный подход написания.
И да, не нужно слепо следовать стандартам 1С.
Эти оптимизации помогают на приличных базах сократить сотни секунд серверных вызовов. Вы недооцениваете эти рекомендации.
(145)
Я не очень понимаю, почему вы считаете, что тут дело в стандартах кода. Не использовать запрос в цикле при печати массива документов это не стандарт кода, это элементарно квалификация, во всех типовых так применяется. Да и код не усложняется, по крайней мере, если написал так хотя бы два три раза. Писать ПолучитьЗначениеРеквизита не вопрос стандарта, это вопрос того, как будет ваше приложение медленно работать.
Да, некоторые не знают, что запрос в цикле нужно избегать, но это не вопрос к их стандартам, это вопрос к квалификации. Кто хоть раз делал замеры по производительности, на любой базе, тот всегда будет писать один запрос для всех объектов.
ются о принципах кодинга!
...бывают проекты, когда по приоритетам внедрить как
...бывают проекты, когда по приоритетам внедрить как
Я не очень понимаю, почему вы считаете, что тут дело в стандартах кода. Не использовать запрос в цикле при печати массива документов это не стандарт кода, это элементарно квалификация, во всех типовых так применяется. Да и код не усложняется, по крайней мере, если написал так хотя бы два три раза. Писать ПолучитьЗначениеРеквизита не вопрос стандарта, это вопрос того, как будет ваше приложение медленно работать.
Да, некоторые не знают, что запрос в цикле нужно избегать, но это не вопрос к их стандартам, это вопрос к квалификации. Кто хоть раз делал замеры по производительности, на любой базе, тот всегда будет писать один запрос для всех объектов.
(146) я не спорю. вы все правильно пишите.
(146)
при внедрениях я порой не слежу за стандартами, и могу запросто использовать запрос в цикле для разовой обработки данных.
Запрос в цикле - это плохо, я знаю. Но в моем случае скорость разработки намного важнее, чем скорость обработки данных.
давайте закроем тему.
(146)
Я не очень понимаю, почему вы считаете, что тут дело в стандартах кода
при внедрениях я порой не слежу за стандартами, и могу запросто использовать запрос в цикле для разовой обработки данных.
Запрос в цикле - это плохо, я знаю. Но в моем случае скорость разработки намного важнее, чем скорость обработки данных.
давайте закроем тему.
Хочу немного раскритиковать данную статью по некоторым параметрам.
1. Для подобного рода синтаксического контроля есть SonarQube (возможно есть еще что-то...), причем правил по написанию кода не 3 а, 233. Вплоть до отчетов по качеству когда и созданного технологического долга.
Выискивать код который написан "Не стандартно", по всей конфигурации, самостоятельно, сверяясь со всеми "стандартами" о которых было миллион раз написано на инфостарте, методолгами на сайте 1С и т.д не рационально и ОЧЕНЬ спорно и трудозатратно.
2. Дело не в "клиповом" мышлении, а дело в том, что 1 содержательная картинка, лучше чем 100 (или больше) слов. Именно по этому бизнес аналитики пользуются различными нотациями при описании бизнес-процессов, по этому инструкции для пользователей нарезаются из скриншотов, именно по этому вы подключаетесь к клиенту по удаленному доступу и смотрите в его экран, это удобно и информативнее. Именно по этому я дочитал эту статью до конца.
3. Тема с разыменованием полей не до конца раскрыта.
3.1 Когда вы пишете запрос следующего вида:
т.е. где больше одного разыменования поля, следует все таблицы дополнительные присоединять через левое соединение. "ЕщеЧтоТо" должно быть отдельным левым соединением. В противном случае весь смысл использования запроса теряется.
3.2 Например получилась такая ситуация и я вынужден использовать "НайтиПоКоду"имею полное право, есть такая функциональность, почему и нет. То в данном случае место цифр кода, я должен передавать переменную, в которой будет код и выглядеть это должно следующим образом:
При таком написании не важно где вы используете этот стандарт например:
... получаем код возврата
И вот это правильно.
Подведя черту хочу сказать следующее:
Возможности платформы, которые доступны разработчикам "из коробки", в области автоматизированной проверки качества кода, автоматизированного тестирования, версионирования кода и .т.п убогие и требуют серьезных трудозатрат по автоматизации этого процесса.
Можно написать миллион статей и комментариев про то "как надо" и это не будет выполняться в следствии понятных всем причин. Как минимум можно все эти "надо" оспорить в одностороннем порядке и не делать, просто потому что я считаю что вы не правы, кто-то не прочитает статью, кто-то забудет, не заметит, пропустит, отвлечется в момент того когда надо будет проконтролировать качество написания когда и все, создан технологический долг, которыйточно не возможно будет исправлен.
p.s. пока пиал комментарий, попытался перейти на ИТС и прочитать , на что мне вернулась ошибка 404. В моем случае я даже не смог его прочитать, а не просто забыл использовать его в работе :)
1. Для подобного рода синтаксического контроля есть SonarQube (возможно есть еще что-то...), причем правил по написанию кода не 3 а, 233. Вплоть до отчетов по качеству когда и созданного технологического долга.
Выискивать код который написан "Не стандартно", по всей конфигурации, самостоятельно, сверяясь со всеми "стандартами" о которых было миллион раз написано на инфостарте, методолгами на сайте 1С и т.д не рационально и ОЧЕНЬ спорно и трудозатратно.
2. Дело не в "клиповом" мышлении, а дело в том, что 1 содержательная картинка, лучше чем 100 (или больше) слов. Именно по этому бизнес аналитики пользуются различными нотациями при описании бизнес-процессов, по этому инструкции для пользователей нарезаются из скриншотов, именно по этому вы подключаетесь к клиенту по удаленному доступу и смотрите в его экран, это удобно и информативнее. Именно по этому я дочитал эту статью до конца.
3. Тема с разыменованием полей не до конца раскрыта.
3.1 Когда вы пишете запрос следующего вида:
|ВЫБРАТЬ
|СУММА(Документ.Ссылка.ЕщеЧтоТо.Контрагент.ИНН) КАК Сумма
т.е. где больше одного разыменования поля, следует все таблицы дополнительные присоединять через левое соединение. "ЕщеЧтоТо" должно быть отдельным левым соединением. В противном случае весь смысл использования запроса теряется.
3.2 Например получилась такая ситуация и я вынужден использовать "НайтиПоКоду"
КодВалютыРубля = "000000001";
Рубль = Справочники.Валюты.НайтиПоКоду(КодВалютыРубля);
При таком написании не важно где вы используете этот стандарт например:
HTTPЗапрос = Новый HTTPЗапрос(СтруктураURI.ПутьНаСервере);
... получаем код возврата
НеверныйЗапрос = 400; //HTTP 400 Bad Request
Если Результат.КодСостояния = НеверныйЗапрос Тогда
//что-то делаем
КонецЕсли;
И вот это правильно.
Подведя черту хочу сказать следующее:
Возможности платформы, которые доступны разработчикам "из коробки", в области автоматизированной проверки качества кода, автоматизированного тестирования, версионирования кода и .т.п убогие и требуют серьезных трудозатрат по автоматизации этого процесса.
Можно написать миллион статей и комментариев про то "как надо" и это не будет выполняться в следствии понятных всем причин. Как минимум можно все эти "надо" оспорить в одностороннем порядке и не делать, просто потому что я считаю что вы не правы, кто-то не прочитает статью, кто-то забудет, не заметит, пропустит, отвлечется в момент того когда надо будет проконтролировать качество написания когда и все, создан технологический долг, который
p.s. пока пиал комментарий, попытался перейти на ИТС и прочитать , на что мне вернулась ошибка 404. В моем случае я даже не смог его прочитать, а не просто забыл использовать его в работе :)
(91)
Можно писать код по стандартам сразу.
Выискивать код который написан "Не стандартно", по всей конфигурации, самостоятельно, сверяясь со всеми "стандартами" о которых было миллион раз написано на инфостарте, методолгами на сайте 1С и т.д не рационально и ОЧЕНЬ спорно и трудозатратно.
Можно писать код по стандартам сразу.
(92) Я как-то сидел, и думал, чем бы мне заняться и решил что буду программировать на 1С, сегодня решил, а на следующий день сразу запрограммировал, и сразу по стандартам 1С. Всему нужно учиться, и ко всему нужно привыкать это долгий и требующий усилий процесс. Сразу ничего не бывает.
(95)
Так про то и речь. Сонары это прекрасно, но это сторонний и платный продукт. Конфигурировать придерживаясь стандартов это относительно бесплатно.
Да "сразу" ничего не бывает. Инструкцию обычно читают или когда не получается или когда сломал.
А должно быть бесплатно ?
Так про то и речь. Сонары это прекрасно, но это сторонний и платный продукт. Конфигурировать придерживаясь стандартов это относительно бесплатно.
Сразу ничего не бывает.
Да "сразу" ничего не бывает. Инструкцию обычно читают или когда не получается или когда сломал.
(96) Я хочу сказать что самому контролировать это тяжело. Различных правил для модулей, процедур, функций мне кажется больше 200 можно собрать. Даже после долгой практики, всё равно умудряешься ошибаться. Человеческий фактор будет всегда присутствовать. Я за автоматизированные средства.
(93) Есть открытый плагин для сонара подключающий открытую реализацию LSP для BSL со своими реализациями проверок.
В него же можно загружать через generic issue результаты статанализа EDT и АПК тоже все открыто и бесплатно.
В него же можно загружать через generic issue результаты статанализа EDT и АПК тоже все открыто и бесплатно.
Это спорная рекомендация. Строка есть строка, убирать отступ из текста запроса эквивалентно такой записи:
ИмяПеременной =
"https://its.1c.ru/db/content/v8std/src/200/200/i8100655.htm?_=1557240531";
Что не кажется правильным...
* Что делать с частью выражения, переносимой на следующую строку
* Не выравнивайте правые части выражений присваивания (Как видите, актуально)
* Размещение каждого оператора на отдельной строке
Первая строка из этой цитаты - рекомендация, утверждение, ошибка форматирования?
Вторая строка запрещает делать так?
// Неправильно?
Переменная = Новый Структура;
ПеременнаПодлиннее = Новый ТаблицаЗначений;
СовсемДлиннаяПеременная = Новый Запрос;
// Правильно?
Переменная = Новый Структура;
ПеременнаПодлиннее = Новый ТаблицаЗначений;
СовсемДлиннаяПеременная = Новый Запрос;
ПоказатьБез выравнивания правых значений код становится трудно читаемым и противоречит рекомендациям 1С - .
(103)
Здравствуйте !
Это тезисы из "Совершенный код". Первая строка - открытый вопрос, вторая - рекомендация. На сайте ИТС написано "допускается", а не "рекомендуется". На мой взгляд, это свидетельствует, что выравнивание вправо не является предпочитаемым методом.
Здравствуйте !
* Что делать с частью выражения, переносимой на следующую строку
* Не выравнивайте правые части выражений присваивания (Как видите, актуально)
* Размещение каждого оператора на отдельной строке
* Не выравнивайте правые части выражений присваивания (Как видите, актуально)
* Размещение каждого оператора на отдельной строке
Это тезисы из "Совершенный код". Первая строка - открытый вопрос, вторая - рекомендация. На сайте ИТС написано "допускается", а не "рекомендуется". На мой взгляд, это свидетельствует, что выравнивание вправо не является предпочитаемым методом.
К вопросу объектное чтение vs чтение запросом.
1) Придирка. Утверждать что объектное чтение медленнее, поскольку вместе с нужным реквизитом тянется весь объект (если не учитывать кэш), а запрос читает только то что заказали немного некорректно. СУБД оперирует страницами. Для нашего любимого MS SQL по умолчанию 8 кб. При выполнении запроса на чтение скуль прочитает в память минимум 1 страницу. Что (скорее всего) с запасом перекроет разницу. Поэтому объявлять крестовый поход против объектного чтения все же не стоит. Код усложнится, а будет ли заметная выгода еще не факт.
2) Не отмечено важное отличие 2 техник. Возможность читать запросом только РАЗРЕШЕННЫЕ данные. Есть ли на сайте люди, не наступившие ни разу на эти грабли? Когда разрабатываем - все хорошо, передаем изменения бесправным юзерам - пошли баги.
1) Придирка. Утверждать что объектное чтение медленнее, поскольку вместе с нужным реквизитом тянется весь объект (если не учитывать кэш), а запрос читает только то что заказали немного некорректно. СУБД оперирует страницами. Для нашего любимого MS SQL по умолчанию 8 кб. При выполнении запроса на чтение скуль прочитает в память минимум 1 страницу. Что (скорее всего) с запасом перекроет разницу. Поэтому объявлять крестовый поход против объектного чтения все же не стоит. Код усложнится, а будет ли заметная выгода еще не факт.
2) Не отмечено важное отличие 2 техник. Возможность читать запросом только РАЗРЕШЕННЫЕ данные. Есть ли на сайте люди, не наступившие ни разу на эти грабли? Когда разрабатываем - все хорошо, передаем изменения бесправным юзерам - пошли баги.
(111)
Так и в первом и во втором случае SQL прочитает страницу. Объектный режим чтения это тот же запрос к БД.
Только в случае объектной модели платформа прочитает весь объект, создаст его структуру и тд. При чтении запросом мы получим только значение указанных нами реквизитов.
Или нет?
1) Придирка. Утверждать что объектное чтение медленнее, поскольку вместе с нужным реквизитом тянется весь объект (если не учитывать кэш), а запрос читает только то что заказали немного некорректно. СУБД оперирует страницами. Для нашего любимого MS SQL по умолчанию 8 кб. При выполнении запроса на чтение скуль прочитает в память минимум 1 страницу. Что (скорее всего) с запасом перекроет разницу. Поэтому объявлять крестовый поход против объектного чтения все же не стоит. Код усложнится, а будет ли заметная выгода еще не факт.
Так и в первом и во втором случае SQL прочитает страницу. Объектный режим чтения это тот же запрос к БД.
Только в случае объектной модели платформа прочитает весь объект, создаст его структуру и тд. При чтении запросом мы получим только значение указанных нами реквизитов.
Или нет?
(112) Мы при обоих техниках чтения получим одинаковую дисковую операцию - чтение 1 страницы с диска в память сервера. Для небольших объектов ессно. Поэтому для тривиальных случаев, типа примеров в статье, получить заметную разницу в производительности не выйдет.
(114)
Так обсуждается не конкретный пример, а подход в целом.
И сколько страниц будет прочитано SQL сервером при объектной модели если объект будет содержать несколько табличных частей?
А нам например нужны только значения реквизитов документа.
Поэтому для тривиальных случаев, типа примеров в статье, получить заметную разницу в производительности не выйдет.
Так обсуждается не конкретный пример, а подход в целом.
И сколько страниц будет прочитано SQL сервером при объектной модели если объект будет содержать несколько табличных частей?
А нам например нужны только значения реквизитов документа.
(115) Подход в целом - использовать запросы вместо объектного чтения не оспаривается. Учение Ленина истинно, потому что верно! Предлагается в применении подхода не доходить до фанатизма. Время, потребное на искоренение всех обращений через точку, можно потратить более продуктивно. Например на профилирование и оптимизацию "горячего" кода
(119)
Так можно сразу писать "не через точку", без всякого фанатизма, тогда ничего искоренять и исправлять не придётся и можно спокойно заниматься оптимизацией и профилированием "горячего" кода.
Время, потребное на искоренение всех обращений через точку, можно потратить более продуктивно. Например на профилирование и оптимизацию "горячего" кода
Так можно сразу писать "не через точку", без всякого фанатизма, тогда ничего искоренять и исправлять не придётся и можно спокойно заниматься оптимизацией и профилированием "горячего" кода.
(120)
Конечно лучше. Еще лучше сразу писать код не нуждающийся в тестировании и отладке. Недавно тут пробегал такой материал, как правильно прогов нанимать, там такое проповедовалось. Жаль что не всегда получается.
Так можно сразу писать "не через точку", без всякого фанатизма, тогда ничего искоренять и исправлять не придётся и можно спокойно заниматься оптимизацией и профилированием "горячего" кода.
Конечно лучше. Еще лучше сразу писать код не нуждающийся в тестировании и отладке. Недавно тут пробегал такой материал, как правильно прогов нанимать, там такое проповедовалось. Жаль что не всегда получается.
(114)
очень даже выйдет
3500 строк в выборке
36 секунд в первом варианте и 27 во втором.
Справочник "Контрагенты", как Вы изволили выразиться - "небольшой объект"
очень даже выйдет
ВремяНачала = ТекущаяДата();
СтрокаРезультата = мРезультатЗапроса.Выбрать();
Пока СтрокаРезультата.Следующий() Цикл
Сообщить(СтрокаРезультата.Контрагент.Инн);
//Сообщить(ОбщегоНазначения.ЗначениеРеквизитаОбъекта(СтрокаРезультата.Контрагент, "ИНН"));
КонецЦикла;
ВремяВыполнения = ТекущаяДата() - ВремяНачала;
Сообщить(ВремяВыполнения);
Показать3500 строк в выборке
36 секунд в первом варианте и 27 во втором.
Справочник "Контрагенты", как Вы изволили выразиться - "небольшой объект"
(118)
на разовой разницы нет, это да. Но ты пишешь процедуру-функцию, в ней вот такой код. Завтра твоя процедура очень кому-то понравится и он будет ее в цикле гонять... Поэтому лучше сразу писать через БСП-шные функции. Рисков меньше
90 процентов всех "ускорений" решается убиранием объектного чтения
на разовой разницы нет, это да. Но ты пишешь процедуру-функцию, в ней вот такой код. Завтра твоя процедура очень кому-то понравится и он будет ее в цикле гонять... Поэтому лучше сразу писать через БСП-шные функции. Рисков меньше
90 процентов всех "ускорений" решается убиранием объектного чтения
(123) Давай не будем до абсурда доводить. Исходный тезис был, если ты забыл, что чтение запросом в примере из статьи не дает выигрыша в производительности. Что ты и показал в тесте, время на операцию < 0,01 сек Я еще не сошел с ума и не предлагаю запросы переписывать на объектное чтение.
А за такое надо бить по рукам не зависимо от стиля чтения в процедуре. Запрос в цикле это бяка в любом случае. Даже БСП-шный.
Завтра твоя процедура очень кому-то понравится и он будет ее в цикле гонять...
А за такое надо бить по рукам не зависимо от стиля чтения в процедуре. Запрос в цикле это бяка в любом случае. Даже БСП-шный.
Вопросы с вознаграждением
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|