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

Ответ 1

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

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

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

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

XP, Scrum, Iterative, Lean/Agile:

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

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

Автоматическое тестирование устройств

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

Поддержка инструмента Refactoring

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

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

• MPLAB
• AVR Studio

Ответ 5

Разве только встроенная среда затрудняет реализацию новых практик или инструментов?

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

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

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

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

Это то, что мышление встроенных программистов отводит их от новых инструментов/понятий?

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

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

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

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

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

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

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

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

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

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

-Adam

Ответ 6

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

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

Ответ 7

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

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

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

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

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

Ответ 8

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

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

Ответ 9

Я бы сказал, что разные типы проблем.

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

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

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

Ответ 10

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