Оптимизация на лету: Как правильная методология разработки в 1С сокращает отчетность с минут до секунд
Автоматизация процессов выглядит как задача без конца, не так ли?
Давайте подумаем, как можно упростить этот путь.
Существуют определенные стандарты программирования, которым нужно следовать разработчикам — зачем же они нужны?
Ответ лежит на поверхности: целью наших разработок, создаваемых совместно с вами, является облегчение ваших повседневных дел во внутренней энергетике бизнеса.
Когда программное решение превращается в препятствие, вместо того чтобы быть инструментом, возникает вопрос — зачем оно вообще нужно?
Недавно к нам обратился клиент с запросом на разработку отчета, который позволял бы без труда просматривать важную информацию. В ходе создания раздела «Бонусы менеджеров», был адаптирован стандартный алгоритм от другой группы разработчиков.
Когда отчет стал оперативным, оказалось, что он работает верно, но крайне медленно, 3 минуты.
Отчет формировал информацию в течение трех минут. Заметив этот момент, мы решили расследовать причины замедления.
Оказалось, что команда, ответственная за этот функционал, сделала несколько критических ошибок в коде.
Среди них:
1. В запросах использовались неоптимальные методы, обозначаемые как »…» и »…».
2. В коде была нарушена логика исполнения:
«цикл»
» Цикл»
То есть происходил вызов цикла внутри цикла.
3. И самое губительное: вложенные циклы с множественными запросами.
После применения разработческой методологии нашей команды и исправления всех трех ошибок, мы добились того, что отчет за 2023 год формировался всего за 15 секунд!
Обратите внимание: производительность работы заказчика сократилась с трех минут до 15 секунд на одном только примере качественно выполненного исправления. Мы изначально не целились в оптимизацию существующего кода, но полученный результат стоит того, чтобы задуматься о выборе команды разработчиков и их работы.
Проведение технического аудита системы, как на уровне кода, так и на уровне аппаратного обеспечения, позволяет заказчику получить понимание того, какие шаги нужно предпринять для ускорения работы системы.
Такой аудит выявляет слабые места и, что более важно, как их преодолеть.
Каждая команда, в любом отделе компании, должна стремиться к прогрессу, а в IT-сфере необходимо всегда быть готовым к изменениям и переосмыслению устоявшихся методов.
В контексте последних тенденций в нашей стране многие компании предпочитают переходить на альтернативную СУБД — PostgreSQL, ценимую за её качество, особенно начиная с версии 12.
Разработчикам, работающим с различными базами данных, следует не только писать код, но и понимать, как разные системы, будь то PostgreSQL или MS-SQL, обрабатывают запросы. Между версиями, например, PostgreSQL 12 и 14, также может быть значительная разница в обработке информации.
Ваши стандарты разработки должны учитывать подобные аспекты, а ваша команда разработчиков — быть способной их применять, тем самым упрощая работу сотрудников других компаний. Важно стремиться к тому, чтобы пользовательский интерфейс был как можно более удобным, а код — свободным от ошибок.
В сложных случаях рекомендуем обратиться к специалистам.
