Оптимизация на лету: Как правильная методология разработки в 1С сокращает отчетность с минут до секунд

>>Разрабочик программы 1С, ситсемный архитектор.

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

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

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

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

Вы поменяли методику работы => возникли новые ограничения для системы => какие-то части системы требуется переделать. Вобщем-то неудивительно.

Оказалось, что команда, ответственная за этот функционал, сделала несколько критических ошибок в коде.

Не оказалось. Они не могут угадать ваше переделывание системы в будущем времени. Наверное, их можно упрекнуть за отступление от гайдов (запрос к бд из цикла) - но если это вписывается в ограничения и не мешает бизнесу, а в реализации дешевле для всех сторон - то зачем оптимизировать этот участок? Чтобы денег побольше потратить на начальных этапах?

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

давайте нормальным языком писать…

К вам когда нибудь обращался клиент, которому нужно отчёт чтобы «с трудом просматривать неважную информацию»?

Можно упростить предложение до «обратился клиент за разработкой нового отчёта»

Кстати не ясно как часто ему этот отчёт нужен. Поскольку это 1C и в отчете раздел «Бонусы Менеджера» то предположу что отчёт раз в месяц запускают.

Запустил - и пошёл кофе попить. Съэкономленное на рефакторинг отчёта время лучше бы выяснили зачем ему отсечёт вдруг понадобился, если раньше без него обычно обились.

Кстати во сколько клиенту ваша оптимизация обошлась?

@sp0ck заменил левым соединением.

1с ники открывают n+1 problem...

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

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

Почему автор не на инфостарте это разместил? Можно догадаться. Там, да и здесь есть статьи гораздо более глубокие по содержанию и смыслу в теме ускорения работы 1С, в частности ускорение на Postgres

В статье нужно было написать: было вот так, сделали вот так и это дало ускорение на хх%. А вы только проблему обозначили, а решение не расписали.

Статья на самом деле является пустой и немного вредной.

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

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

Запросы в цикле - тут без разговоров, это плохо, но опять же все индивидуально, да, в 90% случаев такое можно оптимизировать и перестроить без использования запроса в цикле.

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

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

Чем вы заменили «...»?

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

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

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

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

Статья явно написана для целей "партизанского маркетинга" и к программированию имеет весьма опосредованное отношение. Чего так возбудились программисты?

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