アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
安全係数 (スコア:3, 興味深い)
ギリギリの安全係数で設計して、その代わりに検査で問題点を摘出するというアプローチしか取れません。
また、いったん飛び立ってしまえば着陸するまで修理は出来ないし、あちこち飛び回っているので、
どの時点で修理をするかを決め、必要機材を先回りして準備しておかなければいけないといった事情あり、
予測ということが重要でしょう。
これが地上の構築物であれば思いっきり安全係数を掛けて、検査を軽くするという
ライフサイクルコストを考えたアプローチも取れるのですが。
ソフトウェアのいいところはバグを潰しきれれば、その部分は安全であり、経年劣化や疲労などの心配をしないで済むということですね。
事前検査できる、個体差を考えなくてもいいというのも大きな特徴です。
Re:安全係数 (スコア:2, 興味深い)
裏を返せば恐ろしい事実が浮かび上がってきますね。
つまり、ソフトウェアでは、
上の人たちが話していたようなリアル物と違い、
「予測不可能な」壊れ方が大半を占める、ということになるので。
リアル物の疲労とかの壊れ方は、ある意味で予測可能なんですよね。
これくらいの力がかかってるから確率的にこれくらいの時期に駄目になるだろうとか。
ところがソフトはその発想が通用しない。
時間によって壊れるのではない。
実は最初から壊れてるだけで、それが発覚
Re:安全係数 (スコア:0)
> #バグが多いならまだしも、少な「すぎ」てもペナルティを科されたんだよね…
> #もしウチの社員がテメーラより3倍優秀だったらバグも1/3になることは全然おかしくないだろうに…
多分そこの中の人の上の人です。
コードの品質が高いことを客観的に示せば受け入れてもらえたはずですよ。
データに基づいて説得できなかった時点で負けですね。
せっかくコーダは優秀なようなのに、マネージャがゴミじゃダメだよな。
Re:安全係数 (スコア:0)
客観的に示したところでやっぱり主観的に否定されて終わってたでしょうねw