Каталог решений - Распространенные ошибки разработчиков, приводящие к проблемам производительности

В данной статье коснемся проблемной стороны разработки кода. Посмотрим на примеры кода и ситуаций, которые могут привести или приводят к проблемам производительности. Диалог будем вести от «простых» ситуаций к сложным.

В следующей статье проведем анализ проблем с использованием профайлера и плана запросов, т.е. посмотрим как это все выглядит со стороны SQL сервера.

Думаю, что актуально для специалистов начального уровня и среднего, а сеньоры могут дополнить примерами из своего опыта. Господа сеньоры возможно для вас это банально и стандартно, но для меня когда я начинал работать с управляемыми формами и платформой 1С — это бы очень пригодилось, поэтому давайте общаться в конструктивном диалоге, спасибо.

Коллеги делитесь в комментариях описанием Ваших вариантов/ситуаций, будем рады почитать, спасибо!

О чем поговорим?

I) Разбор ситуаций

Типы ошибок.

• Проблемы знаний – привносит нам проблемы, связанные с неопытностью разработчика. Иногда вместо правильного решения мы можем увидеть брутфорс и т.п. Свойственно в основном разработчику начального уровня. 
  Исключение таких ошибок решается повышением квалификации специалистов. Список мероприятий:
  • курсы,
  • патронаж/наставничество,
  • тех-часы,
  • самообучение,
  • код-ревью (обзор-кода),
  • парное кодирование (очень мощная практика, но дорогая тратится время сразу двух специалистов).
  • другие.
• Ошибки кодирования – ошибки, допускаемые любыми специалистами. Это могут быть опечатки, проблемы копирования/вставки или другие подобного рода. 
  Мероприятия для их отлова:
  • проверка статическим анализатором 1С,
  • запуск тестов (тестирование),
  • обзор-кода.
• Быстрое решение – свойственно создание костыльного, не масштабируемого, плохого решения, в котором в угоду скорости (нужно было вчера) приносится в жертву качество. В результате в дальнейшем сталкиваемся с обрастанием костылями и проблемами в работе. Эта ошибка всегда увеличивает технический долг.
  Могут быть исправлены процедурой, которая называется — рефакторинг кода. 
• Архитектурные – самые страшные ошибки. Исправление этих ошибок самый трудоемкий процесс иногда может означать полностью переделку системы. Если система модульная, то исправление еще возможно в обозримые сроки. 
  Недопущение:
  • проведение архитект-ревью,
  • заимствование решений из проверенных конфигураций,
  • мозговой штурм,
  • консультаций и технический аудит опытными специалистами.

1. Храним файлы в реквизитах объекта

Постановка задачи: 

• Заказчик попросил добавить картинку – фотографию пользователя и/или дополнительное изображение товара в номенклатуру. 

Реализация:

• Добавляем реквизит с типом «Хранилище Значений» и храним картинку в объекте.

Проблема: 

• Картинки могут быть большие и при обращении к данным объекта через точку (это тоже плохо) или при открытии карточки объекта мы будем каждый раз перекачивать мегабайты изображений.

Реализация данного решения свойственна новичку в разработке.

Решение: 

• Откатываем механизм хранения файлов в объекте.
• Используем из БСП подсистему файлов (ссылка на ИТС БСП подсистема файлов): 
  • Добавляем новый справочник «Пользователи Присоединенные Файлы»;
  • Добавляем реквизит ссылку в самом справочнике;
  • Добавляем обвязку подсистемы.

Мероприятия:

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

2. Забыли добавить условие отбора

Что происходит: 

• О проблеме сообщили, когда накопился большой объем данных более 200 тысяч документов. 
• При выводе на печать состава товаров документа «Маршрутный лист» время печати возросло с 2 до 40 секунд.

Проблема: 

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