12

私はしばらくの間組み込みスペースにいましたが、私が話すほとんどのプログラマーは、15年以上前とほぼ同じように物事を行っているようです:Waterfall(ish)Development、コマンドラインツール少人数のグループはlintを使用します。

これを、プログラミングのあらゆる種類の側面に関連する多くのアクティビティがあるように見えるサーバー/デスクトップ環境と比較してください。

  • XP、スクラム、反復、リーン/アジャイル
  • 継続的インテグレーション
  • 自動ビルド
  • 自動化されたユニットテストフレームワーク
  • リファクタリングツールのサポート

組み込み環境によって、新しいプラクティスやツールの実装がより困難になるだけですか?組み込みプログラマー
の考え方は、新しいツール/概念から彼らを遠ざけるということですか? ITに焦点を当てた分野と比較して、典型的な組み込み業界の管理は時代遅れですか?

これは一般化であり、一部の組み込みプロジェクトではスクラム、アジャイル、CI、自動ビルドを使用していることを認識しています(実際、私は80年代からそれを導入している会社で働いていました)。しかし、私の印象では、それはごくわずかな割合です。

4

10 に答える 10

14

私たちは皆、デスクトップ PC がときどきクラッシュする (または少なくともデスクトップ上のアプリケーションが突然消える) という事実に慣れています。それは大したことありません。次のパッチで修正されます。

埋め込みスペースでは、パッチを適用できないものを構築しています。命はあなたのデバイスに依存する可能性があります(車、エレベーター、または医療システム内)。ほとんどのデバイスは、インストールされた後、何年も無人で実行する必要があります。そのため、エンベデッドの人々は非常に保守的になりがちです。TCP/IP はしばしば「あまりにも現代的」です。彼らは、およそ 50 行のアセンブラ コードである通信「スタック」を使用して、信頼できるシリアル バスに固執します。

さらに悪いことに、デバイスに十分なスペースがないということは、TDD と自動ビルドを至福にする最新のプログラミング言語の 1 つを使用できないことを意味します。

次に、組み込み開発環境の多くは独自仕様です。サプライヤーがサポートしていない場合は、入手できません。Linux はここ数年でこの傾向を弱め始めていますが、多くのデバイスはまだ Linux を実行できるほど強力ではありません。仮にそうであったとしても、CPU パワーは、ソースに付属する派手な OS を実行する代わりに、別のことに使用されるでしょう。

そうです、バックグラウンドで強力な力が働いて、埋め込まれたスペースをそのまま維持しています。

于 2009-02-12T13:47:23.000 に答える
13

組み込み開発者はデスクトップ開発者よりも保守的ですか?

はい、彼らは間違いを犯した場合の結果により関心があるからです。組み込みデバイスにパッチを適用するのは大変なことです。デスクトップアプリとしてはそれほどではありません。

組み込みの世界では、一般的にソフトウェアと同時にハードウェアを構築するため、滝のような開発が必要です。メモリの量、プロセッサの速度、フラッシュのサイズ、特別なハードウェアが必要かどうかなどをできるだけ早く知る必要があります。これらの答えがわかるまで、ハードウェアの設計は完了しません。決めたら、それで終わりです。ボードをやり直すためのリードタイムが長すぎます。失敗した場合、ソフトウェアは欠点を回避する必要があります。通常、理想的な状況ではありません。

ツールに関しては、それは主にサプライヤーが提供するものと開発者のバイアスに基づいています. 一部のプロジェクトでは、XP Embedded を使用しており、デスクトップ開発者が得るほとんどすべてのものを手に入れました。

XP、スクラム、反復、リーン/アジャイル:

ほとんどの設計は (必要に応じて) 前もって行われ、通常、コードを作成するときにハードウェアが動作していないため、迅速なターンアラウンド プロセスはあまりメリットをもたらしません。

継続的インテグレーション/自動ビルドあると便利 ですが、必ずしも必要ではありません。なんと…IDEを開いてコンパイルボタンを押すのに約15秒かかります。

自動単体テスト

これを行うべきではない理由はありませんが、コードの一部のみが実際に自動的にテストされます。他の部分はハードウェアに依存しているか、タイミングなどの他の依存関係があるためです。そのため、自動テストではコードが機能しているかどうかを実際に判断することはできません。

リファクタリング ツールのサポート

組み込みプロセッサ製品のベンダーは、プロセッサです。プロセッサの購入を促すために、IDE サポートを提供しています。彼らは、Visual Studio 規模の開発チームに、彼らの製品でさえない IDE にすべての付属機能を追加するための費用を支払う余裕はありませんでした。

于 2009-02-12T21:32:57.780 に答える
6

私が考えることができるこれらのいくつかの理由:

  • 組み込みチームは通常、デスクトップ/Web チームよりも小規模です。コードベースは小さくなります。
  • システム テストは、単体テストよりもはるかに重要です。ソフトウェアはハードウェアと一緒にテストする必要があります。自動テストは不可能であり、コード ベースのごく一部にしか適用できません。
  • 組み込みエンジニアは、ソフトウェア エンジニアとは異なるスキル セットを持っています。彼らはハードウェアと対話し、オシロスコープとロジック アナライザーの使い方を知っています。通常、彼らの仕事で難しいのは、ハードウェアの不具合を見つけることです。彼らには、最新のソフトウェア手法を採用する時間がありません。
于 2009-02-12T13:55:04.323 に答える
4

組み込みプログラマーは、ほとんどが電気エンジニアであり、コンピューター科学者やソフトウェア エンジニアではありません。

彼らは専門分野で優れています。彼らは、ほとんどのコンピューター プログラマーよりもゆっくりとした方法論的アプローチをもたらします。ファームウェアのプログラミングに関して言えば、電気技術者は危険であることを十分に知っています。

以下は、電気技師が C で行っていることに気づいたことの一部です。

  • すべてのコードを 1 つのファイルに
  • 数学のような変数名: x、y、z
  • インデントがない、または欠けている
  • 標準的なコメント ヘッダーはありません
  • コメントは一切ありません
  • コメントが多すぎる

彼らの弁護では、EE はコンピューター プログラマーになるための訓練を受けていません。それは彼らの仕事ではありません。ソフトウェアは、組み込み機器を作成する上で最も難しい部分だと思います。PCB の設計とコンポーネントの選択にはスキルが必要ですが、10,000 行のコードの複雑さに比べると見劣りします。

組み込みプログラマーは、90 年代の IDE のように見えて動作する IDE も扱う必要があります。

于 2009-02-12T19:48:16.487 に答える
3

組込み環境が新しいプラクティスやツールの実装を難しくしているというだけでしょうか?

それは部分的に規模の問題です。ソフトウェアは製品ではなく、製品は製品です。ただし、数千の異なるタイプのマイクロコントローラーとマイクロプロセッサーがあり、最も人気のある数千のものには、完全に互換性のない 3 ~ 4 種類のコンパイラーがあります。

したがって、特定のツールを使用するのは、数百または数千のエンジニアだけです。

ただし、Windows の開発では、さまざまなレベルの何百万人ものプログラマーがいます。ツールは、製品であるソフトウェアを直接生成するため、より多くの注目を集め、より多くのお金を獲得することになります。

エンジニアが発表する各新製品には、異なるプロセッサが搭載されている場合があります。

組み込みプログラマーの考え方が新しいツールや概念から遠ざけているのでしょうか?

エンベデッド プログラマーは、一般的に、プログラマーではなく、ソフトウェアまたはファームウェア エンジニアです。エンジニアリングとは、実装前にある程度の設計、設計分析、および設計証明を行うことを意味します。つまり、コードの最初の行が記述される前に大量の作業が行われます。ドキュメントは、理想的には、実装が簡単に変更できるほど具体的です。ドキュメンテーションのような疑似コードをコンパイル可能なコードに変換します。

新しいツールと概念は、実装段階ではなく、設計段階で必要になります。Intellisense を備えた IDE は素晴らしいかもしれませんが、コードが書かれる頃には役に立たない粗雑なものです。彼らは必要なものをすでに知っています。

CAD - コンピュータ支援設計 - ファームウェア エンジニア向けのツールが開発されており、設計段階でモデルやシミュレーションを直接コードに変換するために使用されます。Matlab と simulink はこの良い例です。システム全体が設計されています。

実際、エンジニアがデータ/プログラムのフローチャートやステート マシン図を作成しているのに、なぜソフトウェア開発者はいまだにコードを書いているのか疑問に思う人もいるかもしれません。アプリケーションの世界で UML の取り込みが遅いのはなぜですか? アプリケーション開発者は、組み込みシステム エンジニアの間で一般的に使用されているツールのいくつかを使用できるように思えます...

典型的な組込み業界のマネジメントは、IT 中心の分野に比べて後れを取っているのでしょうか。

実際、それはおそらく逆です。プロジェクトが開始されると、エンジニアはプロセッサを選択する必要があります。

プロセッサ メーカーは、古いチップで得られる金額が少なくなるため、最新かつ最高のチップを売り込みます。一般に、以前の設計で使用されていたチップよりも全体的に安価です (ダイの縮小、統合の増加などにより)。

そのため、設計には実際に最新かつ最高のチップが使用されています。

欠点は、コンパイラとツールが未熟であることが多いことです。彼らは古いツールでしか構築できず、新しいプロセッサーごとにターゲットが移動するため、アプリケーション プログラマーが好む多くの優れた機能に集中することができません。特に、これらの機能の多くは組み込みエンジニアにとって役に立たないためです。

他にも多くの要因があり、そのうちのいくつかは他の回答で列挙されていますが、両方ともプログラミングが関係しているとはいえ、実際には別の分野です。

-アダム

于 2009-02-12T20:02:02.053 に答える
2

ここに書かれていることの多くに同意します:

  • 付属品のない古いツール (C/C++ のプリプロセッサ ディレクティブがあったとしても、使用可能なリファクタリングがはるかに少ない) (ユニット テスト フレームワークを選択するのに時間がかかり、単純に JUnit を使用するのと比べて時間がかかる)。

  • ウォーターフォールの方が効率的だと感じるのは事実です。ボンネットを開けてアクセスしにくい場所に入る場合は、各タスクの後にボンネットを出て閉めるのではなく、そこにいる間にできる限りのことをしたいと思います。もう一度。最も重要な機能を最初に作成すると、遅れる代わりに約束されたときに出荷するという選択肢が得られるという考えは、何もオプションではないと信じている場合、理解するのが難しい場合がありますが、これは真実かもしれません. ただし、IME では、締め切りが近づくと、常に何かが不要になります。

  • システムの可視性が低下すると、既存のコードを再検討してリファクタリングや機能の変更を行うリスクが高くなります。スタブとモックを使用してホストで実行されている自動化されたテストではキャッチできないタイミングの問題がよくあります。これらの問題に悩まされている人にとって、別の見方をするのは難しい場合があります.

  • もう 1 つ追加します。アジャイル/スクラムの言語は、ワークステーション プログラマーの用語です。仕事を成し遂げるのに十分なCを知っている組み込み開発者にとって、クラス、オブジェクト、またはメソッドとは何ですか? 「ユーザー」が通常、クリックして入力する物理的な人間と見なされ、製品に人間のユーザー インターフェイスがない場合、そのアイデアを適用外として却下するのは簡単です。これは、James Grenning のC での TDDに関する近刊の本で変更される可能性があります。私はベータ版の電子ブックを読んでいますが、とても良いです。

于 2011-02-02T20:28:23.423 に答える
2

また、ここでいくつかの点を追加します。

  • 一般に、埋め込みプロジェクトはデスクトップ プロジェクトよりも小さい傾向があります。これにより、非常に複雑なソフトウェア プロセスの必要性が減少します。
  • 多くの場合、組み込みプロジェクトの要件は正確で、より適切に定義されています。したがって、スクラムとアジャイルはそれほど重要ではありません
  • 最後に、組み込みプロジェクトは通常、ソフトウェアとハ​​ードウェアが混在しています。ソフトウェアはプロジェクトの一部にすぎない組み込み開発者は、ソフトウェア プロセスに費やす時間が少なくなります。
于 2009-02-15T19:38:22.603 に答える
1

良いツールセットが不足していると言えます。実行時の機能 (例外、仮想関数) ではなく、C にはないコンパイル時の機能 (テンプレート、名前空間、オブジェクト指向性など) に C++ を使用したい場合は、本当にイライラしますが、デバイスの製造元とサードパーティは、C++ ではなく C コンパイラを提供するだけです。これはおそらく、デバイスの機能よりも市場規模 (Windows を実行する何億台もの PC と、何十万人または何百万人の開発者がいるのに対し、何十万台またはそれ以下の開発者がいる数十万台の Chip X) に起因する可能性があります。

編集: w/r/t 堅牢性: そこにはさまざまな市場があります。自動車/エレベーター/航空/医療機器の市場は、バグを取り除くことに厳格でなければなりません。他の市場 (おもちゃ、MP3 プレーヤー、およびその他の家電製品) は、特に現場でコードをアップグレードできる場合は、それほど厳格ではない可能性があります。(「おっと! あなたの音楽ライブラリを削除して申し訳ありません! そのバグを修正しました。最新のリリースは当社の Web サイトでいつでも入手できます!」)

于 2009-02-12T13:48:29.737 に答える
0

さまざまな種類の問題環境があると思います。

ウォーターフォール方式の最大の問題は、要件が変化することです。私が経験したすべての環境で、少なくとも要件が変更される可能性がありました。つまり、成功する方法論とは、可能な限り柔軟性を維持する方法論です。顧客が血で同意し、変更を提案した場合、左手を放棄する立場にある場合でも、将来変更が発生します。

組み込みプログラミングでは、要件を事前に明確にすることができます。それらはシステム全体の動作から生じ、エンジニアはシステム要件を突き止めるのが得意です。誰も途中で、受信者が踊っている間にペースメーカーにシンコペーションのインパルスを送りたいと言っているわけではありません。

人間が使用するように設計されたソフトウェアでは決して起こらない解凍を超えて要件が凍結されると、ウォーターフォールは非常に効率的な方法論となります。チームは、明確に指定された要件から全体設計、詳細設計、コーディングに進み、段階が正しく行われたことをすべて検証します。次に、コードをデバッグし (記述した時点で完全ではないため)、コードが要件を満たしていることを確認するための最終テストを行います。

于 2009-02-12T20:18:57.707 に答える
0

また、一部の分野は本質的に保守的であると仮定します。たとえば、電車や飛行機の寿命が 30 年ほどの運輸業界です。顧客は、おそらく IEEE から派生した、実証済みの真のプラクティスを要求する傾向があります。ウォーターフォールは顧客が知っているものであり、ウォーターフォールは顧客が要求するものです。

于 2014-10-15T21:35:24.807 に答える