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

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

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

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

---

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

 

По моим наблюдениям, в среднем инсталлятор 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, «‘отладочная информация’«;