О плохом и хорошем коде для чайников. Часть 2

Предисловие

Нет плохих и хороших языков программирования,

есть неразумное использование их возможностей.

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

Дьявол, как известно, кроется в деталях: если раньше мы говорили о культуре кода в целом, то теперь настало время поговорить о хорошем коде на ISBL. Как и любой другой язык программирования, он имеет свои особенности и ограничения, о которых и пойдёт речь.

ISBL

А что это за девочка, и где она живёт?

Какая-то не очень новая песня

Прежде чем пуститься в рассуждения об особенностях программирования на ISBL, следует сказать, чем он является. Не будем ходить далеко, обратимся к справке:

ISBL, IS-Builder Language – встроенный в IS-Builder высокоуровневый язык программирования, предназначенный для описания алгоритмов работы прикладных задач.

На языке ISBL задаются все программные вычисления внутри систем, разработанных на платформе IS-Builder:

• обработка событий при работе со справочниками и карточками документов;
• подготовка данных для отчетов;
• тексты сценариев и прикладных функций;
• задание логики работы типовых маршрутов и их отдельных блоков;
• вычисление ролей и описание поисков объектов в системе.

Объектная модель

Весь мир – GUI, и люди в нём – объекты.

Совершенно точно не Уильям Шекспир

ISBL вполне можно назвать объектно-ориентированным языком программирования в широком смысле этого слова, но вы не сможете написать новый класс или кардинально изменить возможности уже существующих (доступно только расширение возможностей путём добавления новых реквизитов/действий). Однако в пределах платформы IS-Builder его возможности достаточно широки и позволяют решить практически любую задачу при наличии у разработчика определённой фантазии.

Базовым классом для большинства объектов системы является, как несложно догадаться, IObject. В общем случае это одна запись набора данных (IDataSet) и одно или несколько представлений (IView) со своими свойствами и методами для работы. Представления содержат методы и свойства для визуальной работы с компонентами, наборы данных, очевидно, - для работы с самими данными.

Рассмотрение схемы наследования классов во всех подробностях занимает немало времени и вряд ли годится для этой статьи. Поэтому чтение справки по этому вопросу останется на совести читателей, а пока можно просто перечислить основные объекты, с которыми приходится иметь дело прикладному разработчику на ISBL. Это уже упомянутые IObject, IView и IDataSet и вдобавок к ним:

• ITask – задача;
• IJob – задание (дополнительно IControlJob и INotice – соответственно задание-контроль и уведомление);
• IEDocument – документ;
• IReference – справочник;
• IUser – пользователь/группа пользователей;
• IList, IStringList – список и список строк;
• И многие, многие другие, о которых можно прочитать в справке по ссылке
  https://club.directum.ru/webhelp/directum/5.4/index.html?om_obekty_directum.htm.

Для получения объектов используются служебные объекты – фабрики, к которым можно обратиться при помощи предопределённых переменных: Tasks, Jobs, Notices, References, EDocuments, ServiceFactory (позволяет получать пользователей и не только) и др.

А что произойдёт с объектом после его получения?

Работа с объектами

- Что же мы с тобой сегодня напишем, ручечка?

Неизвестный графоман

Всё, что угодно! В пределах возможностей платформы, разумеется, но тем не менее. Общая схема такова: разработчик должен получить объект, сделать с ним что-то в рамках имеющейся задачи, сохранить при необходимости, закрыть при возможности и очистить переменные (восстановить состояние объектов для корректного освобождения памяти).

Встроенная сборка мусора в IS-Builder срабатывает только при завершении вычислений, и это значит, что если состояние объектов необходимо восстановить до этого момента, то это придётся сделать вручную:

• для каждого вызова функции Open, AddSelect, AddWhere, AddOrderBy, AddJoin и т.п. вызвать Close, DelSelect, DelWhere, DelOrderBy, DelJoin;
• при завершении работы с объектом присвоить ему значение nil;
• для всех созданных объектов выполнить их освобождение путем присвоения nil.

Пример работы с объектом IReference:

  RefRecord = References.Assignments.GetObjectByID(AssignmentID) //Получили объект

  ... //Сделали что-то

  RefRecord.Save() //Сохранили

  RefRecord.CloseRecord() //Закрыли запись справочника

  RefRecord.Close() //Закрыли справочник

  RefRecord = nil //Очистили ссылку

Почему настолько важно восстановление состояния объектов и освобождение переменных? Как минимум потому, что выполнение любых программных вычислений требует аппаратных ресурсов. Открытый без фильтра (что, кстати, тоже неправильно, но об этом чуть позже) справочник на 200 тысяч записей занимает 600 МБ оперативной памяти. Если его не закрыть после использования, когда он станет уже не нужен, оставшиеся вычисления, во-первых, будут выполняться медленнее, чем могли бы, а во-вторых, могут затребовать себе для выполнения аналогичное количество памяти, и в совокупности потребление памяти процессом SBRte превысит максимально допустимый порог в 1Гб (в новых версиях – 4Гб, на workflow – настраиваемое количество), что приведёт к аварийному завершению процесса.

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

  RefRecord = References.Assignments.GetObjectByID(AssignmentID)

  foreach DDSRow in RefRecord.DetailDataSet(1)

  ...

  endforeach

  RefRecord = nil 

Очистка переменной RefRecord, хранящей единственную ссылку на запись справочника, приведет к попытке платформы освободить и сам объект IReference. Однако цикл foreach имеет неочевидную особенность: его переменные по завершению цикла не очищаются, и тогда наличие ссылки на детальный набор данных в переменной цикла DDSRow помешает освобождению объекта, что в конечном итоге приведёт к возникновению ошибки ESBWrapperAlive. Такие ошибки возникают в результате некорректной работы с объектами и сами по себе не страшны, но могут приводить к другим, уже более серьёзным и критичным ошибкам в работе системы (например, Access Violation).

Работа с данными

640 килобайт оперативной памяти хватит всем!

Билл Гейтс (но это не точно)

Как уже было сказано ранее, большой массив данных требует большого количества аппаратных ресурсов для их обработки. Отсюда вывод - при работе с любым набором данных нужно постараться максимально ограничить его объём. Какими средствами это можно сделать:

· Для справочников – использование метода AddWhere перед открытием. Применение комбинации Filter + Filtered = TRUE после открытия никак не повлияет на потребление памяти уже открытым набором данных.

· Для SQL-запросов – ограничение выборки наложением дополнительных условий в предложении WHERE. Лайфхак: для перебора результатов запроса в цикле можно использовать ISBL-объект IQuery, который работает быстрее, чем функции SQL() и CSQL().

Пример из жизни – у клиента дала сбой настроенная интеграция DIRECTUM версии 5.1 и SAP по справочнику «Контрагенты». Как выяснилось, в сценарии интеграции справочник (тот самый, на 200 тысяч записей) открывался для загрузки данных без фильтра, и в один прекрасный момент стал занимать всю память, выделенную под процесс SBRte. Процесс завершался по превышению максимально допустимого объёма занимаемой памяти, интеграция не отрабатывала, и спустя некоторое время пользователи забили тревогу, обнаружив, что данные контрагентов стали неактуальны. Исправление ситуации заняло 1 час анализа и программирования и 3ч нагрузочного тестирования на реальных данных, после чего интеграция восстановилась и продолжает благополучно работать и по сей день.

Помимо объёма данных, на потребление памяти и, как следствие, на производительность могут влиять и сторонние вычисления. К примеру, при сохранении записи справочника выполняются три события: Сохранение Возможность, Сохранение До и Сохранение После. Чаще всего при программном внесении изменений в справочник необходимости в их отработке нет, поэтому их можно отключить:

  RefRecord = References.Assignments.GetObjectByID(AssignmentID) //получить запись

  RefRecord.Events.AddCheckPoint() //запомнить состояние событий

  RefRecord.Events.DisableAll() //отключить все события

  ... //сделать что-то с записью

  RefRecord.Save() //сохранить изменения

  RefRecord.CloseRecord() //закрыть запись

  RefRecord.Close() //закрыть справочник

  RefRecord.Events.ReleaseCheckPoint() //восстановить состояние событий

  RefRecord = nil //очистить переменные

Самые внимательные читатели, скорее всего, уже заметили, что в некоторых приведённых примерах кода используются методы Close() и CloseRecord(), но нет предшествующих им Open() и OpenRecord(). Почему? Потому что использование метода GetObjectByID практически эквивалентно коду:

  AssignmentsRef = References.Assignments.GetComponent()

  AssignmentsRef.AddWhere(“dbo.MBAnalit.Analit = “ & AssignmentID)

  AssignmentsRef.Open()

  AssignmentsRef.OpenRecord()

Как можно увидеть, при вызове метода GetObjectByID() отрабатывают методы Open() и OpenRecord(), но события, соответствующие этим методам (Набор данных. Открытие, Запись.Открытие и, в некоторых случаях, Форма-карточка. Показ) не отключаются. Поэтому в случаях, когда счёт времени выполнения идёт на секунды или миллисекунды, лучше использовать приведённый выше пример, добавив перед вызовом Open() отключение событий.

Вместо заключения

У всех участников процесса разработки ПО есть свои маленькие профессиональные радости. Ничто так не радует разработчика и заказчика, как работающая быстро (даже на компьютерах в бухгалтерии) и безошибочно (особенно с первого раза, хотя это впечатление и бывает ошибочным) программа.  Аналитик (он же консультант) придёт в буйный восторг от грамотно составленного ТЗ, которое не надо исправлять. Пользователь будет просто счастлив, если ему не придётся долго искать ответы на неминуемо возникающие у него вопросы. А тестировщику придётся по душе как отсутствие ошибок, так и их грамотная обработка. Но это уже совсем другая история, которую мы расскажем в следующий раз.