я не буду задавать риторические вопросы из серии «зачем вы используете такой код». вероятно, это не ваше решение
Ну это просто данность. Скажем BSP от производителя с его же SDK.
В книгах так хорошо пишут о том как избегать цикломатичности, но что-то умалчивается о проклятии макросов.
Тексты BSP наводнены макросами условной компиляции чтобы быть портируемыми под все семейство чипов производителя или под 3-4 е типа сред разработки. Мусор макросов (поскольку это вставки не относящиеся ни к проекту, ни к целевому чипу) загромождает поле зрения, не дает понять логику, утомляет.
И это точно никто не собирается исправлять или делать «красивее»
Огромные HAL-ы, именования в которых никак не коррелирует с именованиям в мануалах на чипы. Вынуждающие делать двойную работу по изучению платформы разработки.
Или вот в последнее время началось применение текстов автосгенерированных в Matlab-Simulink-Stateflow. Там цикломатичность в принципе не соблюдается никак.
По моему битва за «красоту» уже проиграна. Что толку если только 10% текстов будут красивыми?
Напишите пожалуйста что делать если 90% проекта состоит из стороннего опенсорсного «вонючего кода»?
Надо ли его рефакторить и если да, то как потом его апгрейдить из тех же сторонних источников.
А если нет, то как вы боретесь с когнитивным диссонансом, когда в вашем проекте столько «вонючего кода»?
Нет, контакторы не гудят если они питаются от 24V DC. Т.е. от обычного PLC.
Потом риск у них залипнуть гораздо ниже.
Это надо чтобы они на КЗ включились. В здравом уме так делать никто не будет.
А реле до 10А легко залипают не только от светодиодных блоков питания но и от любых моторчиков с конденсаторами, в частности от жалюзи и ролл-ставней.
А если реле больше 10А, то будет стоить как контактор с учетом колодки под реле.
Гребенки применяем обычные от автоматов. Никакого дефицита нет.
Реле неудобны в инсталляции.
Гораздо удобнее модульные контакторы специально предназначченные для инсталляции — www.lovatoelectric.com/One-or-two-pole/340005005/spd
Они объединяются специальными шинными гребенками и не надо делать вводной проводной монтаж. Это и удобней и надежней.
Не буду спорить про цену. Может быть.
Но, как известно, скупой платит дважды.
Самый ненадежный элемент в автоматике — реле.
Поэтому когда все реле стоят дискретные и отдельные вы значительно облегчаете последующее обслуживание, ремонт и модернизацию системы.
Не то что бы я специально не отвечал на ваши комментарии, но просто не так много времени имею.
Я уважаю людей способных организовать продуктивную работу команды.
Если вам такие тесты помогают это сделать, то я ничего возразить не могу.
Я вообще не спец в организации коллективного программирования.
Поэтому и очертил свою организацию работы чтобы не спорить о несоотносимых вещах.
Но память — хитрый механизм. И она затачивается.
Какой бы способ не применили память заточится под него.
Поэтому да, история ошибок важна и я ее храню в архиве версий.
На самые распространенные типа утечек памяти или пустых указателей у меня выработан рефлекс автоматической 10-и кратной самопроверки и аскетизм синтаксиса. С++ ни в коем разе — это мультипликатор забивающих память сущностей. (но в коллективном программировании — ничего против)
На сложные автоматы состояний, я вообще не пишу код, а генерирую его из моделей в MATLAB-е. Тут, кстати, не поуправляешь простой функций. MATLAB запросто выдаст портянку на 100 кБ содержащую только одну функцию!
И наконец для кусков коммуникационных стеков, файловых систем и прочих крупных модулей у меня всегда в релизном приложении храняться интеграционные тесты, которые запускаются из закрытого для юзеров меню.
И все, места юнит-тестам нет. Есть только короткие исследовательские тесты.
Если нужно они остаются в ветках хранилища версий.
Минус — надо выделять место под небольшой щиток в каждой комнате и софт.
Это часто не минус, а просто уже крест на идее.
Ну кто будет дырявить стены в доме ради контроллеров неизвестного размера.
При том что подвод цепей 220 всегда теребует значительного места.
В умном доме самый дефицитный ресурс — место.
Выделяя один ящик под все в результате экономим место.
Плюс — не надо столько проводов, нет единой точки отказа
ПЛК сделаны очень технологично. Их можно менять как пробки (раньше предохранители пробками называли). Просто снимаем один модуль и ставим резервный.
В случае же распределенного управления типа KNX надо будет бегать по точкам в поисках проблемы. При том что в распределенных системах приходится каждый контроллер программировать или настраивать отдельно. Это гораздо хлопотней.
Просто есть обоснованное подозрение что цену и размеры вы себе увеличили применив более сложные и более габаритные модули чем простые реле и контакторы.
А почему не взяли номальный промышленный ПЛК и дискретные реле и контакторы?
Тоже делаю умный дом, но не нашел более гибкого и компактного варианта чем мощный ПЛК и дискретные реле —
Я понимаю что ваши вопросы появились из-за того что статью вы не поняли, но обычно тон комментариев в таких случаях вопросительный, а не поучающий всех подряд что и как правильно.
Понять это видимо в вашем понимании — принять.
Я собственно в вопросительном тоне и пишу. Автор отвечает что я неправильно спрашиваю. Как вам это?
Да, мелкие тесты удаляются беспощадно.
Вы привели пример удивительно мелких тестов.
Это перерасход рабочего времени на поддержку и на рефакторинг.
Какие есть основания так мелко гранулировать тестирование?
И как у автора везде сквозит — это всего лишь административные меры для навязывания стиля остальным программистам.
Но к счастью в embedded есть огромное поле работы для индивидуальных программистов, где не надо бороться за свой стиль.
И я говорю именно о таком сценарии.
Как могут рухнуть такие мелкие функции если вы их сами написали, сами поддерживаете и сами рефакторите? Это что не то уже с памятью. Так тут не помогут никакие тесты.
Но если у вас реально сложные функции с большим количеством состояний, то юнит-тестирование предложенное здесь — детский лепет.
А упомянутые вами авторы занимаются проблемами командного программирования. Но есть просто огромная разница между методами командного программирования и индивидуального.
Моделирование подразумевает описание реакции модели на все возможные ситуации в которых она может оказаться.
Я с этим не согласен.
Моделирование — это реализация некоторых известных вам аспектов поведения с возможностью коррекции, ради чего моделирование и устраивается.
Если вы «тестируете» датчик которого не держали в руках, то это моделирование датчика, а не тестирование.
Все возможные ситуации для реальных моделей описать нереалистично.
Как говорят Томас и Хант в «Прагматичном рпограммисте» — качественный код это такой код, который легко поддаётся изменению.
Здесь я с Томасом и Хантом полность согласен.
И устроенный автором процесс минимум в два раза усложняет изменения, в чем он и признался.
Приведенный вами список функций интересен.
Я тоже широко использую GUI, работаю с энкодерами и часами и много с чем.
Но считаю что юнит-тестировать такие функции GUI не имеет особого смысла.
Они тестируется в режиме Test-driven development. И оставлять рудименты в виде юнит-тестов после этого не нужно.
И некоторые ваши функции без аргументов.
Т.е. к ним неприменимо юнит-тестирование, как тут его описывают.
Что же за тестирование у вас в таком случае?
Очеь много непонятных терминов применяете. Не из embedded.
Поэтому не вижу пока предмета обсуждения. Перечислите хотя бы вы десяток «чистых» функций.
Но поскольку автор не привел списка функций (ибо думает что никто не занимается тем же чем и он) считаю что этого списка нет. Откуда резонное подозрение — а было ли тестирование?
А то что он привел — есть иммитационное моделирования. Я всеми руками за иммитационное моделирование, но не в таком урезанном виде как у автора.
Оно должно быть гораздо обширней.
Вообще тестирование такая важная вещь что лучше его встраивать в релизный код как это и делается в отвественных системах.
Но это же не тестирование, а моделирование.
Причем модель датчика может быть ошибочной.
Скажем тоже работал с китайскими дешевыми лазерными лидарами.
Они могут выдать непредсказуемые строки, которые неточно приведены в документации.
Т.е. моделирование датчиков без их наличия настолько рисковано, что не вижу смысла этим заниматься.
BLDC мотор в этом плане проще моделируется.
И почему вам сложно просто накидать десяток наименований тестируемых функций если вы так широко применяете юнит-тестирование?
Или это все таки не юнит-тестирование?
Прочитал и не понял что конкретно тестировалось.
Хотя бы привести пример десятка функций подвергавшихся тестированию и что они должны были делать.
Не ясна совокупная выгода такого подхода и контекст.
Всегда работаю по MODBUS на скрости 115200. С частотными преобразователями для двигателей.
С циклом управления 20 мс.
Скорость MODBUS точно рассчитать невозможно.
На каждую команду и на доступ к определенным группам данных у слэйвов отдельно специфицируются таймауты реакции.
Например, одно дело записать в рабочий регистр, а другое в NV регистр.
Поэтому если требуется жесткий риалтайм, то надо непосредственно в софте мастера реализовывать измеритель таймаутов, кторый нужен для экспериментального подбора состава пакетов и организации их отправки.
Из-за такого запоздалого квитирования MODBUS не рекомендуют для управления движущимися объектами (но я нарушаю рекомендацию).
Лучший выбор будет CAN, где квитирование сразу во время передачи пакета слэйвам, и EtherCAT где квитирование мгновенное и сразу от всех слэйвов.
А что им тут делать?
Применяемую матмодель уже объясняют математики на пресконференциях.
Применяется обычная SEIQRDP модель.
Модель показывает завышенную смертность чем наблюдается в реальности
Между тем на Diamond Princess спустя почти 50 дней появляются новые жерты вируса.
Уровень летальности растет и через пару лет приблизится возможно даже к 50%.
Я поддерживаю точку зрения автора статьи.
Кто бы сомневался.
САN либо вы знаете заранее, либо начинаете тестовые исследования.
Просто заседанием или приглашением "'экспертов" такие вещи не решаются.
Эксперт просто скажет что надо исследовать и это будет только частью мозаики с кучей компромисов.
А лучшим вариантом будет наладить обоюдные отношенния с первым заказчиком чтобы он разрешил исследования проводить на себе после выпуска продукта.
Думаю вы так и делаете, только политкорректно умалчиваете.
Кроч статья должна была называться — «как мы ввязываемся в авантюру за неделю без всяких представлений о ее исходе»
Нет это не то тестирование о котором я говорю.
Я говорю о тестировании и испытании решений, а не плат.
Скажем кто решил использовать CAN если у вас с ним судя по всему нету опыта?
А на какой скорости CAN? И сколько отдельных сегментов CAN? И почему нет отдельных каналов диагностики по другим шинам? А где вопросы унификации?
Все это вам надо не просто пообсуждать, а протестировать.
А у вас нету даже отдельных пунктов на исследования (тестирование)!
Платы протестировать может и контрактный разработчик у которых сборку заказываем, они в этом большие спецы.
И тотальное тестирование плат должно основываться на оценках надежности.
Кстати об оценке надежности и безопасности у вас тож речи как-то не ведется. А во многих системах это забирает львиную долю времени.
Интересно также почему у вас проект кончается на выпуске изделий.
А где время на гарантийное обслуживание и выплату «технического долга»? Где время и расходы на модернизацию, где время на ремонт, где на выпуск и поддержку актуальной документации?
Не сомневаюсь что все перечисленное вы делаете, но видимо поленились написать.
Это еще один плохой знак заказчику.
Да, и нигде нет про ответсвенность заказчика.
Вы же так требовательны к заказчикам.
Но по вашему выходит что на заказчике нет вообще никой ответсвенности кроме как платить заранее оговоренные деньги.
Ну это просто данность. Скажем BSP от производителя с его же SDK.
В книгах так хорошо пишут о том как избегать цикломатичности, но что-то умалчивается о проклятии макросов.
Тексты BSP наводнены макросами условной компиляции чтобы быть портируемыми под все семейство чипов производителя или под 3-4 е типа сред разработки. Мусор макросов (поскольку это вставки не относящиеся ни к проекту, ни к целевому чипу) загромождает поле зрения, не дает понять логику, утомляет.
И это точно никто не собирается исправлять или делать «красивее»
Огромные HAL-ы, именования в которых никак не коррелирует с именованиям в мануалах на чипы. Вынуждающие делать двойную работу по изучению платформы разработки.
Или вот в последнее время началось применение текстов автосгенерированных в Matlab-Simulink-Stateflow. Там цикломатичность в принципе не соблюдается никак.
По моему битва за «красоту» уже проиграна. Что толку если только 10% текстов будут красивыми?
Надо ли его рефакторить и если да, то как потом его апгрейдить из тех же сторонних источников.
А если нет, то как вы боретесь с когнитивным диссонансом, когда в вашем проекте столько «вонючего кода»?
Потом риск у них залипнуть гораздо ниже.
Это надо чтобы они на КЗ включились. В здравом уме так делать никто не будет.
А реле до 10А легко залипают не только от светодиодных блоков питания но и от любых моторчиков с конденсаторами, в частности от жалюзи и ролл-ставней.
А если реле больше 10А, то будет стоить как контактор с учетом колодки под реле.
Гребенки применяем обычные от автоматов. Никакого дефицита нет.
Гораздо удобнее модульные контакторы специально предназначченные для инсталляции — www.lovatoelectric.com/One-or-two-pole/340005005/spd
Они объединяются специальными шинными гребенками и не надо делать вводной проводной монтаж. Это и удобней и надежней.
Но, как известно, скупой платит дважды.
Самый ненадежный элемент в автоматике — реле.
Поэтому когда все реле стоят дискретные и отдельные вы значительно облегчаете последующее обслуживание, ремонт и модернизацию системы.
Я уважаю людей способных организовать продуктивную работу команды.
Если вам такие тесты помогают это сделать, то я ничего возразить не могу.
Я вообще не спец в организации коллективного программирования.
Поэтому и очертил свою организацию работы чтобы не спорить о несоотносимых вещах.
Но память — хитрый механизм. И она затачивается.
Какой бы способ не применили память заточится под него.
Поэтому да, история ошибок важна и я ее храню в архиве версий.
На самые распространенные типа утечек памяти или пустых указателей у меня выработан рефлекс автоматической 10-и кратной самопроверки и аскетизм синтаксиса. С++ ни в коем разе — это мультипликатор забивающих память сущностей. (но в коллективном программировании — ничего против)
На сложные автоматы состояний, я вообще не пишу код, а генерирую его из моделей в MATLAB-е. Тут, кстати, не поуправляешь простой функций. MATLAB запросто выдаст портянку на 100 кБ содержащую только одну функцию!
И наконец для кусков коммуникационных стеков, файловых систем и прочих крупных модулей у меня всегда в релизном приложении храняться интеграционные тесты, которые запускаются из закрытого для юзеров меню.
И все, места юнит-тестам нет. Есть только короткие исследовательские тесты.
Если нужно они остаются в ветках хранилища версий.
Это часто не минус, а просто уже крест на идее.
Ну кто будет дырявить стены в доме ради контроллеров неизвестного размера.
При том что подвод цепей 220 всегда теребует значительного места.
В умном доме самый дефицитный ресурс — место.
Выделяя один ящик под все в результате экономим место.
ПЛК сделаны очень технологично. Их можно менять как пробки (раньше предохранители пробками называли). Просто снимаем один модуль и ставим резервный.
В случае же распределенного управления типа KNX надо будет бегать по точкам в поисках проблемы. При том что в распределенных системах приходится каждый контроллер программировать или настраивать отдельно. Это гораздо хлопотней.
Тоже делаю умный дом, но не нашел более гибкого и компактного варианта чем мощный ПЛК и дискретные реле —
Понять это видимо в вашем понимании — принять.
Я собственно в вопросительном тоне и пишу. Автор отвечает что я неправильно спрашиваю. Как вам это?
Да, мелкие тесты удаляются беспощадно.
Вы привели пример удивительно мелких тестов.
Это перерасход рабочего времени на поддержку и на рефакторинг.
Какие есть основания так мелко гранулировать тестирование?
И как у автора везде сквозит — это всего лишь административные меры для навязывания стиля остальным программистам.
Но к счастью в embedded есть огромное поле работы для индивидуальных программистов, где не надо бороться за свой стиль.
И я говорю именно о таком сценарии.
Как могут рухнуть такие мелкие функции если вы их сами написали, сами поддерживаете и сами рефакторите? Это что не то уже с памятью. Так тут не помогут никакие тесты.
Но если у вас реально сложные функции с большим количеством состояний, то юнит-тестирование предложенное здесь — детский лепет.
А упомянутые вами авторы занимаются проблемами командного программирования. Но есть просто огромная разница между методами командного программирования и индивидуального.
Я с этим не согласен.
Моделирование — это реализация некоторых известных вам аспектов поведения с возможностью коррекции, ради чего моделирование и устраивается.
Если вы «тестируете» датчик которого не держали в руках, то это моделирование датчика, а не тестирование.
Все возможные ситуации для реальных моделей описать нереалистично.
Здесь я с Томасом и Хантом полность согласен.
И устроенный автором процесс минимум в два раза усложняет изменения, в чем он и признался.
Приведенный вами список функций интересен.
Я тоже широко использую GUI, работаю с энкодерами и часами и много с чем.
Но считаю что юнит-тестировать такие функции GUI не имеет особого смысла.
Они тестируется в режиме Test-driven development. И оставлять рудименты в виде юнит-тестов после этого не нужно.
И некоторые ваши функции без аргументов.
Т.е. к ним неприменимо юнит-тестирование, как тут его описывают.
Что же за тестирование у вас в таком случае?
Поэтому не вижу пока предмета обсуждения. Перечислите хотя бы вы десяток «чистых» функций.
Но поскольку автор не привел списка функций (ибо думает что никто не занимается тем же чем и он) считаю что этого списка нет. Откуда резонное подозрение — а было ли тестирование?
А то что он привел — есть иммитационное моделирования. Я всеми руками за иммитационное моделирование, но не в таком урезанном виде как у автора.
Оно должно быть гораздо обширней.
Вообще тестирование такая важная вещь что лучше его встраивать в релизный код как это и делается в отвественных системах.
Причем модель датчика может быть ошибочной.
Скажем тоже работал с китайскими дешевыми лазерными лидарами.
Они могут выдать непредсказуемые строки, которые неточно приведены в документации.
Т.е. моделирование датчиков без их наличия настолько рисковано, что не вижу смысла этим заниматься.
BLDC мотор в этом плане проще моделируется.
И почему вам сложно просто накидать десяток наименований тестируемых функций если вы так широко применяете юнит-тестирование?
Или это все таки не юнит-тестирование?
Хотя бы привести пример десятка функций подвергавшихся тестированию и что они должны были делать.
Не ясна совокупная выгода такого подхода и контекст.
С циклом управления 20 мс.
Скорость MODBUS точно рассчитать невозможно.
На каждую команду и на доступ к определенным группам данных у слэйвов отдельно специфицируются таймауты реакции.
Например, одно дело записать в рабочий регистр, а другое в NV регистр.
Поэтому если требуется жесткий риалтайм, то надо непосредственно в софте мастера реализовывать измеритель таймаутов, кторый нужен для экспериментального подбора состава пакетов и организации их отправки.
Из-за такого запоздалого квитирования MODBUS не рекомендуют для управления движущимися объектами (но я нарушаю рекомендацию).
Лучший выбор будет CAN, где квитирование сразу во время передачи пакета слэйвам, и EtherCAT где квитирование мгновенное и сразу от всех слэйвов.
Применяемую матмодель уже объясняют математики на пресконференциях.
Применяется обычная SEIQRDP модель.
Модель показывает завышенную смертность чем наблюдается в реальности
Уровень летальности растет и через пару лет приблизится возможно даже к 50%.
Я поддерживаю точку зрения автора статьи.
САN либо вы знаете заранее, либо начинаете тестовые исследования.
Просто заседанием или приглашением "'экспертов" такие вещи не решаются.
Эксперт просто скажет что надо исследовать и это будет только частью мозаики с кучей компромисов.
А лучшим вариантом будет наладить обоюдные отношенния с первым заказчиком чтобы он разрешил исследования проводить на себе после выпуска продукта.
Думаю вы так и делаете, только политкорректно умалчиваете.
Кроч статья должна была называться — «как мы ввязываемся в авантюру за неделю без всяких представлений о ее исходе»
Я говорю о тестировании и испытании решений, а не плат.
Скажем кто решил использовать CAN если у вас с ним судя по всему нету опыта?
А на какой скорости CAN? И сколько отдельных сегментов CAN? И почему нет отдельных каналов диагностики по другим шинам? А где вопросы унификации?
Все это вам надо не просто пообсуждать, а протестировать.
А у вас нету даже отдельных пунктов на исследования (тестирование)!
Платы протестировать может и контрактный разработчик у которых сборку заказываем, они в этом большие спецы.
И тотальное тестирование плат должно основываться на оценках надежности.
Кстати об оценке надежности и безопасности у вас тож речи как-то не ведется. А во многих системах это забирает львиную долю времени.
Интересно также почему у вас проект кончается на выпуске изделий.
А где время на гарантийное обслуживание и выплату «технического долга»? Где время и расходы на модернизацию, где время на ремонт, где на выпуск и поддержку актуальной документации?
Не сомневаюсь что все перечисленное вы делаете, но видимо поленились написать.
Это еще один плохой знак заказчику.
Да, и нигде нет про ответсвенность заказчика.
Вы же так требовательны к заказчикам.
Но по вашему выходит что на заказчике нет вообще никой ответсвенности кроме как платить заранее оговоренные деньги.