■

「早すぎる最適化」がダメだってことはよく知られてるけど、
「早すぎる抽象化」がダメだってことはあまり知られてない。


「早すぎる抽象化」の害悪は、システムが必要以上に複雑に
なること。YAGNIといえばそうなんだけど。たとえば余計な
階層を作っちゃうとか。


「早すぎる抽象化」が起こるのは、インフラを先に作ろうと
するときに多い。


振り返ってみると、「早すぎる抽象化」は長いこと「善」と
されていた。一昔前のOOA/OODブームのときもそうだったし、
それよりももっと前からも。


個人的には、やりすぎた抽象化を取り除くリファクタリングは
とっても苦労する感じ。それで結局「ほっとけ」になりがち。

■

おー、コメントがついてた。プリコンパイルヘッダについて勉強しておきます。

  • -


上のは置いといて、size_tはintなんかと違って組み込み型じゃない。
ってことはヘッダをインクルードしなきゃいけないんだけど、どれ？
stddef.hなんだろうなぁ。

  • -


おー、正直すまんかった。


プロジェクトのプロパティでプリコンパイルヘッダを止めて、stdafx.hを
インクルードするのを止めたら、フツーにコンパイルできたよ。

勉強になりました。ありがとうございました。

■

stdafx.hって、プロジェクトで一回インクルードするだけでいいと
思ったら違うのな。


標準ライブラリを使うときは必ずインクルードしないといけないのな。


これ見ると、MSが標準をバカにしてるのがよくわかるよな。


C++プログラマのほとんどはWindowsプログラマなんだろうけど、
そのほとんどが標準なんか気にしてねーんだろーなー。

■

わかりにくいテクニックのことをワカリニクテクと名づけるのはどうだろう。

  • -


「カネがねー、カネがねー」って
これだから技術者1.0はダメなんだよ。


カネがねーのはテメーが売れるもん作ってねぇからだろ。
売れるもんバンバン作ってみろって。

  • -


こっちに書いちゃったから、こっちに続きを書くけど。


XPE2のCorollary Practicesの1つにPay-Per-Useがある。
これは、作ったシステムを顧客が使う分だけ料金を
もらうってことだ。お客さんが使えば使うほど儲かるっ
ていう仕組みのこと。これはお金をシステムのフィード
バックとして使うっていう狙いがある。


この考えを推し進めると、お客さんにたくさん使って
もらう、あるいはたくさんのお客さんに使ってもらうっ
ていうことが、開発側の課題にもなるってことだろ。
システムの開発にはフィードバック、しかも精度の高い
フィードバックが必要なわけで、お金は精度の高さで
いえばかなりものだ。


これまではお客さんの獲得っていうのは営業の仕事だっ
て思われてたんだけど、それじゃダメなわけだ。


もちろん、技術者には技術者の本分というものがある。
でも、その技術の方向っていうのは、お客さんの獲得に
向いたもんじゃないといけないってことだろ。


品質を上げるのは何のためだ？ 開発者から見たら、
第一に働きがいを高めるためだ。でも、二番目
くらいにはお客さんを獲得するためっていうのが
来るだろう。そうでなけりゃ技術者側と企業側との
Mutual Benefitは生まれないわけだ。


だから、『カネがねー、カネがねー』と口に出すなら
そのすぐあとに『売れるものを作れなくて
ゴメンナサイ』というのが続いて出てこなきゃいけない。
『カネがねー』っていうのを他人のせいにするんじゃない。
技術が未熟だから売れないんだと。

■

なんか向こうにアップロードできなくって。
ヤバイ気もするんだけど、出先じゃどうしようもない。

  • -


なんかもう、C++とかで「引数はコピー渡しでも全然
いいじゃん？」と思うようになってきた。
vectorとかstringとか。


だって、そんなん最適化じゃん？ コピー渡しだろうが
参照渡しだろうがポインタ渡しだろうが問題は解ける
わけだから。
早すぎる最適化は諸悪の根源じゃん。