Советы по борьбе с хаосом при программировании AMX-систем

Гилязетдинов Марат,
ведущий программист компании iRidium Mobile Ltd.

Советы по борьбе с хаосом при программировании AMX систем

«Порядок освобождает мысль»

Королёв Сергей Павлович 


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

 

По моим наблюдениям, в среднем инсталлятор AMX-систем ведет от 3 до 5 проектов одновременно. Соответственно, очень тяжело сосредоточится на одном проекте и заниматься только им. Обычно, работая над несколькими проектами, инсталляторы «разносят» фазы работы над объектом, используют только знакомое оборудование и материалы, делегируют части задач по монтажу и наладке другим компаниям. При создании систем автоматизации на базе контроллеров AMX есть, пожалуй, самый непредсказуемый этап — это программирование системы. Дело в том, что при большом количестве объектов программисту приходится переключатся между задачами, из-за чего нужно каждый раз вспоминать, что было сделано, что нужно сделать, какие ошибки нужно исправить и так далее. Это, в свою очередь, приводит к тому, что на разработку тратится драгоценное время. Потеря времени приводит к тому, что приходится либо увеличивать сроки, либо поднажать с программированием, то есть перевести работы в авральный режим. Работа в авральном режиме приводит к увеличению количества ошибок, созданию «программных костылей» (временных, ненадежных решений, которые нужно впоследствии заменить на постоянные и надежные), общей усталости программиста. Как следствие всего этого, недовольство заказчика по поводу качества работы, усталость команды от объекта, постоянные доделки (как правило, добавление новых «костылей»). Из-за этого компания не может взять больше объектов или сдать объект в срок.

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

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

Приведу пример электронного журнала созданного в MS Excel:

06.03.2012 Добавил модуль Panasonic PT-AR100EA на 1 порт RS232.
Разъем 1 порта RS232 контакты 2 и 3 перевернуты, поставил переходник. Сказать монтажникам чтобы перепаяли контакты.
Добавил управление BR плеером SONY BDP-S495 на 1 IR-порт.
Добавил управление ресивером Marantz SR7005 на 2 порт RS232.
В модуле управления ресивером нужно дописать часть для работы с радио.
Заказчик попросил кроме режима просмотра кинотеатра добавить режим прослушивания BR-Audio и Радио.
Добавить в дизайн страницу ожидания включения/выключения проектора.
В дизайне управления BR плеером были перепутаны коды Play и Pause.
Заказчик попросил добавить 6 спортивных каналов на главную страницу кинотеатра.
11.03.2012 Подключили панель CV5 в проект, залили дизайн.
На iPad панели залили дизайн с исправлениями, 6 спортивных каналов на главной кинотеатра, окно ожидания включения/выключения проектора.
Монтажники разъем так и не перепаяли.
Залил модуль для ресивера с радио.
Проверил включение/выключение кинотеатра, поправил время поднятия/опускания экрана.
Проверил управление воспроизведением BR-Audio
В страницу управления ресивером добавить смену акустической модели.
Проверил управление радио на ресивере.
Нашел ошибку: при нажатии на пустое место на странице управления радио выключается ресивер. Оказалось, не удалили невидимую кнопку, а на ней был код выключения ресивера.

 

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

 

Стандарт оформления кода. Каждый программист имеет свои привычки, как называть переменные, функции и процедуры, каким образом оформлять код. Большинство программистов Умных домов скептически относятся к стандартам оформления кода, меняя их от объекта к объекту. Как показала практика, наличие стандарта существенно облегчает понимание кода, особенно если код пишет не один человек. С помощью стандарта оформления кода можно повысить информативность, то есть для понимания функционала кода не нужно просматривать весь контекст, тем самым экономится время.

Приведу для примера фрагмент кода для контроллера AMX:

define_function ot(char i, integer a, integer val)

{

    char t;

    if(i == 0)

    {          for(t =1; t <= 64; t++)

                    send_string 5001:1:0,»‘d:’,itoa(t),‘:’,itoa(a),‘:’,itoa(val)»;

    } else { send_string 5001:1:0,»‘d:’,itoa(i),‘:’,itoa(a),‘:’,itoa(val)»; }

}

У данного кода сразу несколько недостатков:

 

  1. Нет описания функции.
  2. По названию функции не понятно, что она делает.
  3. Присутствуют «магические» цифры.
  4. Входящие параметры функции не информативны.
  5. Исходный код плохо отформатирован, и его неудобно читать.

Вот тот же самый по функционалу код для AMX контроллера, но уже с примененным стандартом оформления кода.

/**

    Отправка данных

    на входе           :              in_cPoint              — точка устройства (0 отправить на все точки устройства)

                                           in_iAddress          — адрес устройства в точке

                                           in_cValue             — значение для установки

    на выходе        :              *

    примечание     :              у in_cPoint не проверяется область допустимых значений

*/

define_function SetValue(char in_cPoint, integer in_iAddress, char in_cValue)

{

    char i;

    if(in_cPoint == 0)

    {

                // Отправка данных на все точки устройства

                for(i = 1; i <= 64; i++)

                    send_string dvAMX_RS232_PORT_1, «‘d:’,itoa(i),’:’,itoa(in_iAddress),’:’,itoa(in_cValue)»;

    } else

    {

                // Отправка данных на указанную точку

                send_string dvAMX_RS232_PORT_1, «‘d:’,itoa(in_cPoint),’:’,itoa(in_iAddress),’:’,itoa(in_cValue)»;

    }

}

Как вы можете заметить, этот код более понятен, а на его изучение и понимание требуется значительно меньше времени. По своему опыту могу сказать, что разница во времени на изучение аналогичного по функционалу кода со стандартом оформления кода и без может составлять разы. Если вы работаете в команде, то без соглашения о стандарте оформления кода будет значительно сложнее сопрягать части кода или многократно использовать уже существующий. Огромную роль в оформлении кода играет комментирование кода, чем больше комментариев вы сделаете, тем лучше — не ленитесь. Возвращаясь к коду или дополняя функционал, вы не раз поблагодарите себя за то, что не поленились и описали работу программы. Мало того, создавая комментарии, вы сами себе объясняете, что делает тот или иной узел программы, а значит лучше понимаете механику программы.

Многократное использование кода. Для ускорения разработки очень действенной мерой является многократное использование кода. То есть использование модулей, функций и процедур, разработанных ранее и/или разработанных сторонними компаниями или людьми. Как правило, компании работают с ограниченным набором «железа», поэтому имеет смысл спроектировать, написать и отладить модули для работы с наиболее часто используемым набором устройств. Кроме того, большинство оборудования работает по определенной логической схеме, оно отличается только синтаксисом команд и/или их количеством. Поэтому рекомендую разработать один модуль, «болванку», для создания на ее базе других модулей под конкретное устройство. Но будьте внимательны: при таком подходе очень часто возникает ошибка «copy & paste» (когда программист копирует схожий код, но забывает его модифицировать под новое оборудование). Очень важно иметь собственную библиотеку наработанных функций и алгоритмов, чтобы можно было обратиться к ней в любой момент.

Использование окна диагностики. Очень важным моментом является отладка созданного кода. Для отладки программы AMX-контроллера можно использовать следующую конструкцию:

// Отладочная информация

if(m_bDebug)

 send_string 0, «‘отладочная информация’«;


Как вы заметили, присутствует флаг отладки m_bDebug. При значении флага не равном 0 включается режим вывода отладочных сообщений. Запись в 0 порт контроллера AMX — это вывод информации в окно диагностики, что очень удобно. Можно реализовать и более продвинутую систему вывода информации, сделать несколько уровней отладки. Например, так:

0 — уровень отсутствие отладки

1 — вывод ошибок

2 — вывод ошибок и предупреждений

3 — вывод ошибок, предупреждений и всего остального

В таком варианте все будет выглядеть так:

// Вывод ошибок

if(m_cDebugLevel >= DEBUG_LEVEL1)

send_string 0, «‘::error::’«;

// Вывод предупреждений

if(m_cDebugLevel >= DEBUG_LEVEL2)

send_string 0, «‘::warning::’«;

// Вывод всего остального

if(m_cDebugLevel >= DEBUG_LEVEL3)

 send_string 0, «‘::other::’«;

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

Хранение версий. Одним из важных моментов программирования является сохранения исходного кода на разных стадиях разработки. Хранение старых версий может показаться глупой затеей, но это только на первый взгляд. Бывают такие случаи, когда после некоторых изменений пропадает функционал, который работал в предыдущей версии. В итоге, если вы не сохранили старую версию, то понять, что и где вы испортили будет крайне затруднительно. Кроме того, если вы что-то не успели, а заказчику надо что-то оставить, проще всего оставить предыдущую версию. Для решения данной проблемы я использую два способа сохранения версий:

 

  1. Архивирование. В конце рабочего дня или по достижении некой версии можно архивировать данные. Для более удобного архивирования я пишу bat-файл для конкретного проекта. Этот bat-файл будет архивировать важные файлы и помещать их в архив с указанием имени, даты и времени. Впоследствии, по мере необходимости, можно в любой момент посмотреть, что было сделано в той и или иной версии.
  2. Использование систем управления версиями, например SVN. В этом случае все исходники будут находится не только на вашем компьютере, но и в некотором сетевом хранилище. Основное достоинство данного метода в том, что вы в любой момент можете синхронизировать исходники, из любого места, если есть доступ до SVN. К недостаткам можно отнести то, что нужно уметь настроить SVN-сервер и постоянно держать его в сети. Кроме того, SVN хранит все версии, помнит когда и какие файлы были изменены, кто это сделал, что, согласитесь, очень удобно.

Еще один момент, который имеет значение.

Место работы. Большинство программистов AMX-систем пишут программу прямо на объекте, это очень неудобно. Часто на объекте нет ни стола, ни стула, ни интернета. Конечно, все это можно привезти, но ни какой стул и стол не заменит удобного рабочего места программиста. Старайтесь всю основную работу сделать в офисе, в комфортных условиях. Если есть возможность, постарайтесь выстроить копию будущей AMX-системы и отладить все в офисе. Распишите регламент проверки AMX-системы по шагам, это позволит вам не забыть о всех важных функциях Умного дома.

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