プログラミング・スタイル？

以前は、かなりソフトウェア・プログラミングをしていたのに、最近はめっきりしなくなった。

元々、アセンブリ言語使いで、ハードウェアに直接アクセスするようなソフトウェアを書いており、
いわゆる、デバイスドライバーと呼ばれる、アプリケーションと、ハードウェアを結びつける中間、
すなわち、ミドルウェアと呼ばれる領域のソフトウェアを書いていました。

最近のコンピューターでは、それらのミドルウェアと呼ばれるモノは、OSの一部として用意されており、
アプリケーションプログラマは、それらの入出力用関数を叩くだけです。

なんというか・・・面白みを感じないのです。

というよりは、ソフトウェアの勉強というより、「ＯＳの勉強」という気がします。
自分の頭の中でのソフトウェアとは、

「　この命令を実行すると、CPUのA0～A16端子にBCレジスターの値が出力されて、
　IORQ端子とRW端子がLレベルになって、D0～D8端子にAレジスターの値が出力されて、
　IORQ端子とRW端子がHレベルになる。　」

というレベルで覚えてしまっています。プログラマーの方々、どうですか？
恐らく、プロのプログラマーの方々でも、宇宙人の言葉に感じるかも知れません。
何せ、ハードウェアの領域なので。

どうやら自分の頭は、理屈や原理から覚えないと、頭の中に記憶してくれないっぽいです。
ＯＳやライブラリの機能が全然覚えられないのです。
ソースリストを全部公開してくれれば、解析してどういう処理をしているのか調べて覚えれるのですが…。
そんなものは、メーカの特有技術なので、教えてくれるわけがありません。
（機能一覧から、機能ブロックくらいは推測できますが）

＃まぁ、そんなこんなで、ソフトウェアの道に進むよりは、ハードウェアの道にいくかぁ～と思い、
＃今の仕事に就いていますが・・・

とはいいつつ、最近思うことは…自分が昔やっていたような、ミドルウェアを書ける人というのは居るのだろうか？
MS-DOS以前の時代は、ハードウェアを直接叩かないと何も出来ないので、
自ずとハードウェアや、LSIの制御方法を勉強していた人がいるでしょうが・・・

最近、組み込み系ソフトウェアに、バグが多いような気がします。
何でもかんでも、ブラックボックス化する弊害が出てきたかなぁ～と思う、今日この頃。

人命が関わってくる開発現場では、やはりそれらを認識しているようで、
そのライブラリや部品を使う際は、認証として、こういったデータや物が必要らしいです。（以下一例）
（人命が関わって無くても、不良がでたら、それはそれで問題。やはり要求する所は有るようです。）
※Webでの調査。 ISO9000 や、 QS9000 で検索。

　・サンプル製品
　・適合性証明書
　・設計記録
　・工程変更資料
　・テスト結果
　・ＱＣ工程図
　・工程FMEA
　・設計FMEA
　・管理計画
　・工程能力調査
　・評価システム調査
　・設計技術承認

やはり、ブラックボックスは怖いと言うことで、どんどんその中身を聞いてきます。
その中身を答えないと、お客様は、その製品・ライブラリを承認しないので、売ることが出来ません。
やはり、回路図やソースリストレベルでは隠しますが、その他はブラックにはしないのが一般なのでしょうか？

医療機器メーカに勤める技術者が言うには、ソフトウェアでもこういったものが有ると言うが、
そういった所でないソフトウェアでは、全然聞かないです。
それどころか、設計ドキュメントすら作らない企業も有り（主にゲーム開発業）、
アプリケーション・ゲームソフトウェア業界は、本当に大丈夫なのか？と、思ってしまう今日この頃です。

バグ多すぎですよ！！