2010/6/4
技術というのは面白いもので、普及すれば、するほど本当に理解することが難しくなってしまう。
そんなことを思ったので書いてみました。
話のネタはこちらを参考にしています。
volatileで最適化を抑制する
さて、ここで、CやJavaでvolatileという修飾子があるのですが、
これでコード最適化を抑制するとのことです。
なんでそんなことが必要になるかですが、それは
紹介したサイトがすごくわかりやすいので、その説明はしません。
さて、そもそも、コード最適化の恩恵を受けるのが、
私のような
「プログラムはきれいに、わかりやすく作ることが大切だ！」
「CPUがどういう順番で命令が来ることが望ましいなんて興味ないよ！」
なんて方が多くなって、いわゆる、ハードの動きを意識しないソフトウェアエンジニアが多くなると
じゃ、そういうんじゃ、それらを気にしなくてもコンパイラがやってあげますよ。
気にしないでください。これで多くのみなさんが使えるようになるでしょう！！
ということになる。
複雑なことを、簡単にしている場合、たいていは例外ができてしまいます。
これは、日々ソフトウェアエンジニアだったら、そういう物を作っているのでその事情は理解はできます。
ただ、その例外ができた背景まで含めた技術の理解をすることが非常に難しくなってしまうということです。
しかも、今までコンパイラのコード最適化があることしか知らない私などは、
さらにそのような恩恵に助かったという実感もないので、その理解を難しくさせます。
今回の例では、コード最適化が動いた後のコードをイメージして、コードを書くということが一部必要になってしまう。
ということです。
コード最適化によっていろいろなことから解放され、複雑で難解なことから解放され簡単になったのに、
すごく簡単なことが、複雑で難解になってしまったということです。
余談ですが・・・
こういうことって、すごくたくさんあるんだけど、多くの人の理解を超えているので、
開発工数とかも読めなくなるんですよね。
開発工数についての記述を以前「開発工数と期間（納期）と人数の関係について」というのを書きましたが、さらにこういうケースも含めると
Ａ案）100ある機能のうち、99の機能が1日ですが、1の機能が10日から200日です。
Ｂ案）100ある機能のうち、99の機能で99日ですが、1の機能は1日です。
って話になり、
余計、関係者を混乱させる原因になる。
Ａ案は、あわよくば、結構速く終わる。でも最悪１の機能が一生できないこともあり得るという意味の10から200日という幅。
Ｂ案は、確実にできるが、確実に時間がかかる。あわよくば早く終わるということはない。
じゃ、Ａ案のいいところと、Ｂ案のいいところを取り入れられれば11日で終わるかもじゃん！。
ってこと言うが、たいていは無理なんだよね。
たまーに見つかりますが・・・・
でも、これを見つけるときには、技術的視点じゃなく、ビジネス的視点が必要になるんだすよね。たいていは・・・
Posted in 
