Complain

ITproの記事でこんなことが書いてあった。日本のソフトウェア製品について、

アーキテクチャーが崩れていても、テストを重ねて品質を磨くので、問題が表に出ることがない。
その結果、アーキテクチャーはさほど重要ではない、と思われてしまった。

「テストを重ねて品質を磨く」ってことが、「設計を見直すことも含めたプログラムの修正」なら良いんだけど、「ちょっとしたバグの修正」と「『if』で条件分岐を増やす」だけなことが多いんだもんなぁ。設計上どうしてもダメなら「設計から大きく変えないとダメだから無理、出来ない」ってよく聞くんだけど、なんで「じゃ設計から見直して作り直すよ」にならんかな…
プログラムってそんなに作るの大変かなぁ？

建築物の建造なら、一度木材をある長さに切っちゃったら、もっと長いのが必要だったってときは新しい木材が必要だし、壁を作って壁紙張った後で中の配線を変えるときは壁を壊さないと出来ないし、配線直して新しい壁を作るのにはまたコストが掛かるし。それに下手に壊すと周りの新品の床に傷が付くとか厄介なことが多いんだけど、プログラムって「Ctrl+A」「Ctrl+C」「Ctrl+V」で今あるのを壊さずに新しいのを作り直せるんだよね。 今あるのを活かして作り直すとかも簡単に。
建築物なら納入時は壁も床もピカピカの状態でお客に渡さないとダメだけど、プログラムは傷とか、雑に扱ったから品質が悪くなるなんてこと無いんだから、作って壊して作って壊してガンガンやりゃーいんだよね。コーディングの前にきっちりした仕様書が必要だという主張はプログラムを建築物のようなものだと勘違いしてるんじゃないかという話。
どちらかというと「建築物の設計図」こそが「プログラム」に相当するもので建築物の建造はコンパイルに相当する、と考えた方が正しい。とすると、あとは建築物の建造とコンパイルの違いを考えると、ほんとうはプログラム作成とはどう向き合うべきか分かりそうだ。
と、建築物との比較の例はある本の内容そのままなのでこれ以上はまずい。面白いしそんなに高くない本なので是非。
さて、どんなに酷いプログラムに見えてもテストで全て「○」が付いた製品は正しい…
ましてや正しい製品なのにプログラムを修正してテストをやり直す手間を発生させるなど許されるはずもない…
この開発方針は正しいのかな？という愚痴でした。

「保守性の向上とか潜在バグの回避とか幾らでも説得材料はある」
　VS
「客にとって大事なのは、動いてる部分の維持保障とコストの増大を防ぐこと」
「壊れていないものを修理するな」
この辺は2chのまとめ。みんな不満を持ってるのだ。

---

ListLength(std::list<> )みたいな関数が有った。 中身は

long ListLength(std::list* list)
{
 return (long)list->size();
}

だった。わーぉこの方法なら無限にコード行数を稼げるね!!凸（ー_ー）