Являются ли разработчики встроенных программ более консервативными, чем их настольные собратья?

Question

Я уже некоторое время нахожусь во встроенном пространстве, и кажется, что большинство программистов, с которыми я общаюсь, делают то же самое, что и 15 или более лет назад: разработка Waterfall (ish), инструменты командной строки и небольшая группа использует lint.

Сравните это со средой сервер / рабочий стол, где, похоже, существует много активности, связанной со всеми видами аспектов программирования:

• XP, Scrum, итеративный, Lean / Agile
• Непрерывная интеграция
• Автоматизированные сборки
• Автоматизированные рамки модульного тестирования
• Поддержка инструмента рефакторинга

Это просто, что встроенная среда затрудняет внедрение новых методов или инструментов?
Неужели мышление встроенных программистов отвлекает их от новых инструментов / концепций?
Является ли управление в типичной встраиваемой отрасли за кривой по сравнению с сферами, ориентированными на ИТ?

Я понимаю, что это обобщение, и некоторые встраиваемые проекты используют Scrum, Agile, CI, Automated Builds (фактически я работал в компании, у которой это было с 80-х). Но у меня сложилось впечатление, что это очень маленький процент.

Answer 1

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

Во встроенном пространстве вы создаете что-то, что не может быть исправлено. Время жизни может зависеть от вашего устройства (в автомобиле, лифте или медицинской системе). Большинство устройств установлено и затем должно работать без присмотра в течение многих лет. Так что встроенные люди, как правило, очень консервативны. TCP / IP часто "слишком современный". Они придерживаются своей надежной последовательной шины с «стеком» связи, который составляет примерно 50 строк кода ассемблера.

Что еще хуже, у вас просто нет достаточного места на устройстве, что означает, что вы не можете использовать один из последних языков программирования, который делает TDD и автоматизированное создание блаженства.

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

Так что да, есть мощные силы, работающие в фоновом режиме, чтобы удерживать встроенное пространство там, где оно есть.

Answer 2

Являются ли разработчики встраиваемых систем более консервативными, чем их настольные братья?

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

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

Что касается инструментов , то это в значительной степени основано на том, что предоставляет поставщик, и на любых пристрастиях разработчиков. В некоторых проектах я использовал XP Embedded и получил почти все, что получает разработчик настольных систем.

XP, Scrum, итеративный, Lean / Agile:

Поскольку большая часть проектирования выполняется заранее (по необходимости), и у вас обычно нет работающего оборудования, когда пришло время кодировать, быстрые процессы возврата не дают больших преимуществ.

Непрерывная интеграция / Автоматизированные сборки Приятно иметь, но не очень нужно. Что ... требуется около 15 секунд, чтобы открыть IDE и нажать кнопку компиляции.

Автоматическое модульное тестирование

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

Поддержка инструментов рефакторинга

Поставщиком продукта встраиваемых процессоров является процессор. Они предоставляют поддержку IDE, чтобы побудить вас купить их процессор. Они не могли позволить себе заплатить за команду разработчиков размером с Visual Studio, чтобы добавить в IDE все навороты, которые даже не являются их продуктом.

Answer 3

Вот несколько причин, по которым я могу придумать:

• Встраиваемые команды обычно меньше, чем настольные / веб-команды. Кодовая база меньше.
• Системное тестирование гораздо важнее модульного тестирования. Программное обеспечение должно быть протестировано вместе с оборудованием. Автоматическое тестирование невозможно и может быть применено только к небольшой части базы кода.
• Инженеры по встраиванию имеют другой набор навыков, чем инженеры-программисты. Они взаимодействуют с оборудованием, умеют пользоваться осциллографом и логическим анализатором. Обычно трудная часть их работы - найти сбой в оборудовании. У них нет времени принимать современные методологии программного обеспечения.

Answer 4

Встраиваемые программисты в основном инженеры-электрики, а не компьютерщики или программисты.

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

Вот некоторые вещи, которые я заметил, что инженеры-электрики делают в C:

• Весь код в одном файле
• Математические имена переменных: x, y, z
• Нет или отсутствует отступ
• Нет стандартных заголовков комментариев
• Комментариев нет вообще
• Слишком много комментариев

В их защиту EE не обучались программистам, это не их работа. Я думаю, что программное обеспечение является самой сложной частью создания встроенных устройств. Проектирование печатных плат и выбор компонентов требует навыков, но меркнет по сравнению со сложностью в 10 000 строк кода.

Встраиваемые программисты также должны иметь дело с IDE, которые выглядят и ведут себя как IDE 90-х годов.

• MPLAB
• AVR Studio

Answer 5

Просто ли встроенная среда затрудняет внедрение новых методов или инструментов?

Это частично вопрос масштаба. Программное обеспечение НЕ продукт, продукт продукт. однако существуют тысячи различных типов микроконтроллеров и микропроцессоров, а самые популярные тысячи имеют 3-4 различных компилятора, которые не полностью совместимы.

Таким образом, данный инструмент будет использоваться только несколькими сотнями или тысячами инженеров.

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

Каждый новый продукт, выпускаемый инженером, может иметь другой процессор.

Разве мышление встраиваемых программистов отвлекает их от новых инструментов / концепций?

Встроенные программисты, как правило, являются программистами или программистами, а не программистами. Инжиниринг подразумевает определенный объем проектирования, анализа проектирования и проектирования до реализации - иными словами, перед написанием первой строки кода проделана тонна работы, а документация, в идеале, достаточно специфична, чтобы реализация просто поворачивалась документация в виде псевдокода в компилируемый код.

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

CAD - автоматизированное проектирование - для инженеров-программистов разрабатываются инструменты, которые используются на этапе проектирования для разработки моделей и симуляций, которые непосредственно превращаются в код. Matlab и simulink являются хорошими примерами этого. Система в целом спроектирована.

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

Является ли управление в типичной встраиваемой отрасли за кривой по сравнению с сферами, ориентированными на ИТ?

На самом деле, скорее всего, все наоборот. Когда проект начинается, инженеры должны выбрать процессор.

Производители процессоров получают меньше денег на старые чипы, поэтому они выбирают новейшие и самые лучшие чипы, и в целом они дешевле, чем чипы, использованные в предыдущем дизайне (либо из-за сжатия матрицы, большей интеграции и т. Д.).

Таким образом, в дизайне используются новейшие и лучшие чипы.

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

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

-Adam

Answer 6

Я согласен со многим, что здесь написано:

• Старые инструменты без наворотов (гораздо меньше доступных рефакторингов из-за директив препроцессора C / C ++, если они вообще есть) (отнимает много времени на выбор инфраструктуры модульного тестирования по сравнению с простым использованием JUnit).

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

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

• Я добавлю еще один; язык agile / scrum в терминах программиста рабочей станции. Разработчику встроенных программ, который знает достаточно C, чтобы выполнить работу, что такое класс, объект или метод? Когда «пользователь» обычно рассматривается как физическое лицо, которое нажимает и печатает, а продукт не имеет пользовательского интерфейса, легко отклонить идею как неприменимую. Это может измениться с выходом книги Джеймса Греннинга о TDD в C . Я читал бета-книгу, и она довольно хорошая.

Answer 7

Я бы также добавил пару пунктов здесь:

• Как правило, встроенные проекты обычно меньше настольных. Это уменьшает потребность в очень сложных программных процессах.
• Требования к встроенному проекту часто точны и лучше определены. Поэтому SCRUM и Agile не так важны
• Наконец, встроенные проекты, как правило, представляют собой сочетание программного и аппаратного обеспечения. Программное обеспечение, являющееся лишь частью проекта, разработчики встраивают меньше времени в программные процессы

Answer 8

Я бы сказал, что больше не хватает хороших наборов инструментов. Это действительно расстраивает, когда вы хотите использовать C ++ для его функций времени компиляции, отсутствующих в C (шаблоны, пространства имен, объектно-ориентированность и т. Д.), А не для функций времени выполнения (исключения, виртуальные функции) - но производители устройств Сторонние разработчики просто предоставляют вам компилятор C, а не C ++. Вероятно, это больше связано с размером рынка (сотни миллионов ПК под управлением Windows с сотнями тысяч или даже миллионами разработчиков - против сотен тысяч Chip X с сотнями или менее тысячами разработчиков), чем с возможностями устройств.

edit: w / r / t надежность: есть разные рынки. Рынок автомобилей / лифтов / аэронавтики / медицинского оборудования должен быть строгим, чтобы избавиться от ошибок. Другие рынки (игрушки, MP3-плееры и другая бытовая электроника) могут быть менее строгими, особенно если возможно обновить код на месте. («К сожалению! Мы сожалеем, что удалили вашу музыкальную библиотеку! Мы только что исправили эту ошибку, вы можете получить последнюю версию на нашем веб-сайте для вашего удобства!»)

Answer 9

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

Answer 10

Я бы сказал, что существуют разные виды проблемных сред.

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

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

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