Олег Витальевич Хачкинаев

Выпускник физического факультета Ростовского госуниверситета (ныне ЮФУ), отделение "Радиофизика и электроника". Ныне старший научный сотрудник ФГАНУ НИИ "Спецвузавтоматика".

Начинал с разработки аналоговых приборов для физических экспериментов. Когда стали доступны первые микропроцессоры (примерно 1982 год), начал осваивать цифровую схемотехнику, и это стало призванием на всю жизнь.

Часть времени мне приходилось писать код для машин побольше (включая приложения корпоративного уровня), и в эти периоды эмбед продолжал был со мной в качестве хобби. Сейчас, к счастью, это снова мое основное занятие.

Сегодня мое кредо - agile подход к разработке встроенных систем. Оказывается, что инструменты, изначально разработанные для "чистого" программирования, неожиданно хорошо подходят и для разработки аппаратной части. Конечно, есть нюансы (например, рефакторить "железо" дольше и дороже, особенно когда печатные платы приходится заказывать на стороне), но их просто нужно учитывать, а не отказываться от самой идеи использовать методики agile для эмбеда. Тем более что вопрос качества кода в эмбеде стоит еще острее: когда зависнет микроконтроллер, вы не увидите аварийный дамп (за неимением консоли) и вряд ли проанализируете лог (обычно его просто негде вести).

Я не склонен к ультиматумам и скорее предпочитаю компромиссы, однако есть ряд аксиом, которых я неуклонно придерживаюсь и не готов на уступки:

- Кое-какерство недопустимо в программной инженерии вообще и в эмбеде особенно.

- Необходимо знать основные стандарты. Не обязательно слепо следовать им в любых ситуациях; однако, если допустить отступление от стандарта, это должно быть сделано по веской причине, а не по невежеству.

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

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

- Миф о превосходстве эффективности программ, написанных на ассемблере, на программами на C не имеет под собой реальной почвы, по крайней мере сегодня. Превзойти качественный оптимизирующий компилатор по качеству кода очень трудно на коротком участке кода; с увеличением объема кода это становится невозможно (хотя можно сильно затруднить оптимизацию незнанием особенносттей языка высокого уровня).

- То же самое относится к мнимому превосходству в эффективности кода на C перед C++.

- Дурная работа отнимает много сил и приносит раздражение. Она обязательно должна быть автоматизирована.

- Ручное тестирование - одна из наиболее дурных работ. Поэтому (см. предыдущий пункт) она подлежит автоматизации в первую очередь.

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

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

- То же самое касается термина "ТЗ". Сплошь и рядом кодеры используют это слово все, не понимая, что на самом деле видят перед собой спецификацию требований. Настоящим ТЗ манипулируют с уровня владельца продукта (либо менеджера проекта) и выше.

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