Автоматизация процессов выглядит как задача без конца, не так ли?
Давайте подумаем, как можно упростить этот путь.
Существуют определенные стандарты программирования, которым нужно следовать разработчикам — зачем же они нужны?
Ответ лежит на поверхности: целью наших разработок, создаваемых совместно с вами, является облегчение ваших повседневных дел во внутренней энергетике бизнеса.
Когда программное решение превращается в препятствие, вместо того чтобы быть инструментом, возникает вопрос – зачем оно вообще нужно?
Недавно к нам обратился клиент с запросом на разработку отчета, который позволял бы без труда просматривать важную информацию. В ходе создания раздела "Бонусы менеджеров", был адаптирован стандартный алгоритм от другой группы разработчиков.
Когда отчет стал оперативным, оказалось, что он работает верно, но крайне медленно, 3 минуты.
Отчет формировал информацию в течение трех минут. Заметив этот момент, мы решили расследовать причины замедления.
Оказалось, что команда, ответственная за этот функционал, сделала несколько критических ошибок в коде.
Среди них:
1. В запросах использовались неоптимальные методы, обозначаемые как ".." и "...".
2. В коде была нарушена логика исполнения:
"цикл"
" Цикл"
То есть происходил вызов цикла внутри цикла.
3. И самое губительное: вложенные циклы с множественными запросами.
После применения разработческой методологии нашей команды и исправления всех трех ошибок, мы добились того, что отчет за 2023 год формировался всего за 15 секунд!
Обратите внимание: производительность работы заказчика сократилась с трех минут до 15 секунд на одном только примере качественно выполненного исправления. Мы изначально не целились в оптимизацию существующего кода, но полученный результат стоит того, чтобы задуматься о выборе команды разработчиков и их работы.
Проведение технического аудита системы, как на уровне кода, так и на уровне аппаратного обеспечения, позволяет заказчику получить понимание того, какие шаги нужно предпринять для ускорения работы системы.
Такой аудит выявляет слабые места и, что более важно, как их преодолеть.
Каждая команда, в любом отделе компании, должна стремиться к прогрессу, а в IT-сфере необходимо всегда быть готовым к изменениям и переосмыслению устоявшихся методов.
В контексте последних тенденций в нашей стране многие компании предпочитают переходить на альтернативную СУБД – PostgreSQL, ценимую за её качество, особенно начиная с версии 12.
Разработчикам, работающим с различными базами данных, следует не только писать код, но и понимать, как разные системы, будь то PostgreSQL или MS-SQL, обрабатывают запросы. Между версиями, например, PostgreSQL 12 и 14, также может быть значительная разница в обработке информации.
Ваши стандарты разработки должны учитывать подобные аспекты, а ваша команда разработчиков – быть способной их применять, тем самым упрощая работу сотрудников других компаний. Важно стремиться к тому, чтобы пользовательский интерфейс был как можно более удобным, а код – свободным от ошибок.
В сложных случаях рекомендуем обратиться к специалистам.
Комментарии (25)
MaximRV
28.12.2023 12:51+1Статью можно было и пополезнее сделать. Например что в запросах не комильфо обращаться к значениям через многое количество точек. Лучше присоединять таблицы. Бывает что лучше сначала сформировать временные таблицы. Чтобы соединения не были объёмными. Особенности выборки из Регистров. Формирование виртуальных таблиц по ним с ограничением по условиям. И т.п.
А так. Статья для самого базового уровня. Ну типа не ходи в лужу, сапоги замараешь. Не ешь жёлтый снег...
В конце вообще - делайте хорошо, не делайте плохо.
Хоть бы немного раскрыли бы тему про отличия в версиях постгреса. Ну или сделали отсылку на последующие статьи - типа ожидайте будет интересно. Хотя бы так.
mixsture
28.12.2023 12:51+3В ходе создания раздела "Бонусы менеджеров", был адаптирован стандартный алгоритм от другой группы разработчиков.
Когда отчет стал оперативным, оказалось, что он работает верно, но крайне медленно, 3 минуты.
Вы поменяли методику работы => возникли новые ограничения для системы => какие-то части системы требуется переделать. Вобщем-то неудивительно.
Оказалось, что команда, ответственная за этот функционал, сделала несколько критических ошибок в коде.
Не оказалось. Они не могут угадать ваше переделывание системы в будущем времени. Наверное, их можно упрекнуть за отступление от гайдов (запрос к бд из цикла) - но если это вписывается в ограничения и не мешает бизнесу, а в реализации дешевле для всех сторон - то зачем оптимизировать этот участок? Чтобы денег побольше потратить на начальных этапах?
MaximRV
28.12.2023 12:51ну я за такое студентам на защитах двойки ставлю.
за запрос к бд из цикла.
akabrr
28.12.2023 12:51Что будете делать когда количество получаемых записей будет несколько миллионов?
ukved Автор
28.12.2023 12:51То, что можно заложить в запросы и соединить, заложим, далее индексация и получение результат.
akabrr
28.12.2023 12:51Не понял, зачем индексация перед получением результата?
ukved Автор
28.12.2023 12:51К примеру Вы понимаете, что у Вас таблица будет более 10 тысяч строк, вы ее вкидываете в запрос, потом в запросе в временную таблицу, обе на индекс, соединяете с значениями расчетов, и на выходе получаете быструю обработку результата
Isiirk
28.12.2023 12:51Много раз видел без дела индексацию, которая съедала массу времени для получения результата, всё же надо это делать по делу
mixsture
28.12.2023 12:51+2Потому что у вас цели не совсем совпадают. У бизнеса очень часто цель - дешевый прототип. Хорошие практики же часто требуют и затрат побольше - поэтому если бы вы не создавали давление на студентов двойкой, то они и делали бы как быстрее и проще, никогда не пробуя другие подходы. Что противоречит вашей цели - дать им попробовать разные подходы.
А для бизнеса - вот надо им идею опробовать. Они этот прототип вполне вероятно выкинут через полгода и никаких выгод из оптимизации извлечь не выйдет. Поэтому моя точка зрения: выбирать подходящие для ситуации инструменты, смотря на объемы данных, их потенциальный рост и методику использования инструмента.
Особенно актуальным это считаю для РФ, т.к. горизонт планирования бизнеса и был-то небольшой - ниже 10 лет, а сейчас вообще врятли больше 1 года имеет смысл.
akabrr
28.12.2023 12:51Сам по себе запрос в цикле не ошибка, на практике, в определенных случаях, применяется. Жаль ваших студентов.
Kahelman
28.12.2023 12:51+1Опять, Господи: «Недавно к нам обратился клиент с запросом на разработку отчета, который позволял бы без труда просматривать важную информацию.»
давайте нормальным языком писать…
К вам когда нибудь обращался клиент, которому нужно отчёт чтобы «с трудом просматривать неважную информацию»?
Можно упростить предложение до «обратился клиент за разработкой нового отчёта»
Кстати не ясно как часто ему этот отчёт нужен. Поскольку это 1C и в отчете раздел «Бонусы Менеджера» то предположу что отчёт раз в месяц запускают.
Запустил - и пошёл кофе попить. Съэкономленное на рефакторинг отчёта время лучше бы выяснили зачем ему отсечёт вдруг понадобился, если раньше без него обычно обились.
Кстати во сколько клиенту ваша оптимизация обошлась?
CrushBy
28.12.2023 12:51+1Запустил - и пошёл кофе попить. Съэкономленное на рефакторинг отчёта время лучше бы выяснили зачем ему отсечёт вдруг понадобился, если раньше без него обычно обились.
Как Вы думаете, а приложение в это время тоже пьет кофе ? Или "насилует" CPU и память ? Запустят так сотрудники десяток отчетов и уйдут пить кофе. Тем самым забьют все CPU. А в это время операторы и прочие люди будут плеваться, почему так все тормозит. Офигенный подход...
nowm
28.12.2023 12:51Язык 1С сам по себе разрушает когнитивность, так что любые просветления, связанные с правильными методологиями разработки — это случайности, и они долго не длятся.
Если день за днём слушать фразы, вроде «в одном из лучших мест у вас может быть живот, наполненный разумной ценой», или «ты такой красивый, я хочу быть счастливый с тобой» (девушке), или «для каждого строка выборки из выборка по документам цикл», вряд ли получится написать книгу уровня «Войны и мира» с таким опытом.
itmind
28.12.2023 12:51В статье нужно было написать: было вот так, сделали вот так и это дало ускорение на хх%. А вы только проблему обозначили, а решение не расписали.
GarIlia
28.12.2023 12:51Статья на самом деле является пустой и немного вредной.
Использование неявного левого соединения - да, может аффектить, но тут все зависит от наложенных отборов на выборку и возможностей отсекания лишних данных условиями соединений, наличия индексов по соединяемым полям и тд. Само многоточие не является преступлением и аффектит далеко не всегда, выглядит так себе, тут без вопросов, сам нелюблю подобное многоточие.
Ну и циклы в цикле тоже не преступление в ряду случаев, банальный обход результата сгруппированой выборки запроса. Подача в статье такая - что это зло, а оно таковым не является.
Запросы в цикле - тут без разговоров, это плохо, но опять же все индивидуально, да, в 90% случаев такое можно оптимизировать и перестроить без использования запроса в цикле.
Вобщем нужно просто понимать что и когда можно делать, статья целиком применима под один конкретно описанный автором кейс, именно в его случае проблема заключалась в вышеперечисленных моментах.
В статье нет ни слова про способ поиска неоптимального участка кода, да, бывает такое что проблему видно сразу, но если рассматривать статью как нечто образовательное - такое должно быть, хотя бы упомянуть что сделали замер времени конфигуратором\ключевыми операциями\собрав ТЖ в конце концов.
alan008
>>Разрабочик программы 1С, ситсемный архитектор.
Понятно, что из песочницы, но уж хотя в описании себя любимого в профиле можно не допускать столько ошибок? :)
ukved Автор
опечаточка )))