イメージ
トヨタ自動車等の自動車メーカーでは3D CADの作業者に手作業で木型を製作するトレーニングがあるそうです。
手作業ではCAD上のようにやり直しやコピーなどが出来ないため行き当たりばったりでは目的の物は作れません。
作る物の全体のイメージをしっかりと持っていないと製作途中で破綻することがあるからです。
1つのアセンブリモジュールを構成する部分であっても組み付けられる時、組み付け後のイメージがないと生産に使用できるものは出来ないのです。
これはプログラミングでも同じです。
現在はVisual BasicやJavaや.NETなどメモリ管理をコンパイラや実行環境が行いメモリリークの心配がなくなるなど作業は軽減されていますが動作中のメモリのイメージがないと完成近くで破綻してしまうことがあるからです。
最近のオブジェクト指向言語ではオブジェクトがメモリ上でどのように展開されているかを知らないとマルチスレッド上でのバグに対応できません。
データベース等でもADO等の強力なミドルウェアでもレコードセットがどこでメモリ展開されているかをわからないといくらSQLをチューニングしてもパフォーマンスがあがりません。
組み込みでない限りアセンブラまでは必要ないと思いますがCやC++言語等の自分でメモリを管理することを経験しているのとしていないのとでは大きな差があると思います。
手作業ではCAD上のようにやり直しやコピーなどが出来ないため行き当たりばったりでは目的の物は作れません。
作る物の全体のイメージをしっかりと持っていないと製作途中で破綻することがあるからです。
1つのアセンブリモジュールを構成する部分であっても組み付けられる時、組み付け後のイメージがないと生産に使用できるものは出来ないのです。
これはプログラミングでも同じです。
現在はVisual BasicやJavaや.NETなどメモリ管理をコンパイラや実行環境が行いメモリリークの心配がなくなるなど作業は軽減されていますが動作中のメモリのイメージがないと完成近くで破綻してしまうことがあるからです。
最近のオブジェクト指向言語ではオブジェクトがメモリ上でどのように展開されているかを知らないとマルチスレッド上でのバグに対応できません。
データベース等でもADO等の強力なミドルウェアでもレコードセットがどこでメモリ展開されているかをわからないといくらSQLをチューニングしてもパフォーマンスがあがりません。
組み込みでない限りアセンブラまでは必要ないと思いますがCやC++言語等の自分でメモリを管理することを経験しているのとしていないのとでは大きな差があると思います。
