Как тестировать код для встраиваемых систем Опции

[Муравей]

Здравствуйте.
Уже достаточно давно пишу код для всяких контроллеров, но задачи были малой и средней сложности. Хватало функционального тестирования, написал программку, протестировал на весь описанный в ТЗ функционал, прошёлся по всему пользовательскому интерфейсу и Ок. Т.е. программные модули по серьёзному, раздельно, не тестировал, только прошивку целиком прямо на конечной платформе.
Как-то взяло сомнение, что это правильный подход , особенно если сложность задач возрастёт и если в проекте будет больше одного программиста :)
Посмотрел на книгу Мартин Р. - Чистый код. Создание, анализ и рефакторинг (Библиотека программиста) - 2010. Целая теория правильного программирования. Но применима ли эта теория для embedded кода?
В общем посоветуйте плз. какую-то литературку на эту тему, может быть какие-то жизненные советы как повысить качество кода, как гарантировать , что программный модуль будет нормально стыковаться с другими модулями и в случае необходимости портироваться на другие системы, и т.д......
Заранее спасибо.

[AlexandrY]

Посмотрел на книгу Мартин Р. - Чистый код. Создание, анализ и рефакторинг (Библиотека программиста) - 2010. Целая теория правильного программирования. Но применима ли эта теория для embedded кода?

Да книжонка забавная. Но акценты для embedded не совсем актуальны, ИМХО.

Важнее становятся аппаратные ошибки и даже не из-за невнимательности, а из-за не полной документированности аппаратной среды в которой
работает программа.
Скажем что делать когда модуль DMA выдал ошибку доступа к шине, и при этом не известно ни кто ни что там пересылал по DMA, и что пропало и что передалось.
И как правильно построить архитектуру чтобы справляться с такими ошибками и не затормозить систему до нуля, и не дать другим процессам уйти в состояние underflow?

Потом много рассуждений о чистоте кода с точки зрения использования его группой. Тогда каждому участнику надо жертвовать своими предпочтениями ради общих правил. Это снижает производительность однозначно. Лучше думать как максимально изолировать разработчиков друг от друга чем заставлять применять общие стандарты. Во встраиваемых системах это вполне возможно использованием нескольких микроконтроллеров.
Встраиваемый код не такой большой чтобы обращать внимание на его удобочитаемость. Инструменты рефакторинга из любого кода конфетку сделают за считанные часы.
А вот применять как можно меньшее разнообразие синтаксический конструкций важно. Т.е. чем меньше нагружена память программиста распознаванием разных кодовых слов, макросов и знаков тем лучше.
Лучше потерять переносимость, но не применять макросы и разные чудные прокладки увеличивающие вложенность функций только ради того чтобы те же указатели правильно формировались на разных архитектурах.
Имена не то что должны быть удобочитаемые и понятные их просто должно быть меньше.

Да, а насчет тестирования ничего сказать не могу. Не оправдывается какое-то другое тестирование кроме как на живом объекте.
Лучше сконцентрировать усилия на способах надежного накопления и передачи отладочной информации с объектов и обновления firmware.

[neiver]

По моему одна из лучших книг по тестированию встроенного ПО:
Testing embedded software - Bart Broekman and Edwin Notenboom
Наити ее в свободном доступе не очень просто, если кто не найдет, пишите в личку - вышлю мылом.

...
Потом много рассуждений о чистоте кода с точки зрения использования его группой. Тогда каждому участнику надо жертвовать своими предпочтениями ради общих правил. Это снижает производительность однозначно. Лучше думать как максимально изолировать разработчиков друг от друга чем заставлять применять общие стандарты. Во встраиваемых системах это вполне возможно использованием нескольких микроконтроллеров.
Встраиваемый код не такой большой чтобы обращать внимание на его удобочитаемость. Инструменты рефакторинга из любого кода конфетку сделают за считанные часы.
...

Я бы к вам не пошел работать. На проекте, где я сейчас работаю, диаметрально противоположная организация рабочего процесса. Идёт постоянный обмен опытом и ротация зон ответственности, чтоб ни один сотрудник не становился незаменимым носителем уникальных знаний. Даже если половина сотрудников отдела пойдёт в отпуск или заболеет, оставшиеся смогут выполнить их работу, пусть и медленнее.
А с такой организацией труда как вы описываете, я имел "счастье" сталкиваться на прошлой работе. Больше не хочется.
Этот подход работает в небольших локализованных компаниях, а в более-менее крупных и тем более распределённых, не работает даже на простых проектах.
С наступающим Вас!