バグ対策とバカ対策

個人レベルでのソフトウェア管理に関する議論あれこれ

詳細は
>>2

ソフトウェア工学では
バカ対策がメインに研究されてきた感がある。
XPにしろ、オブジェクト指向にしろ、テスティングフレームワークにしろ
８割のバカと共同作業をする事を前提に作られた
手法である。

一方で、どんな天才でも
３０００行ものコードを書けば
多くのバグが出る。
これらのバグをとる、あるいはバグが問題とならないようにする
手法はあまり注目されていない。
その証拠に、Javaにはロギング機能が言語機能として
提供されなかった。
(今はassertが使えるが）

さすがに3000行程度で多くのバグを出したらそいつは使えないだろ

ソフトウェア管理には２つのアプローチがあると思われる。
一つは
コーディングレベルのアプローチ
もう一つは
実装レベルのアプローチ

コーディングレベルのアプローチとは
見通しの良いコードを書くことでバグを減らす事である。
例えば、オブジェクト指向プログラミングは有効な手段となる。

一方で、実装レベルのアプローチは
実際にプログラムを走らせた後、
プログラム自身でエラーを検出し、修正する方法である。

>>1
何が個人レベルで、そんでなぜ個人レベル？
それと、ソフトウェアと議論のどちらが個人レベル？

>>3
例えば、素因数分解のプログラムは２００行程度だと思うけれど
バグを出さずに作る事は困難だと思う。

問題を逆に見れば、
実際にプログラムを走らせる事なく、
そのプログラムを納品するにはどうしたらよいか？
という事になる。

プログラムを実際に走らせて動作チェックをするという事は、
プログラムに多少のバグが潜んでいる可能性があると
判断したからだろう。
違うかい？

３０００行のプログラムを書いて、
一度も実行せずに納品する自信があるなら
それは天才に違いない。

テストファーストってやつはバグ対策じゃないの？

個人レベルで出すバグと
集団レベルで出すバグは異なる。

ゆえに、
個人レベルでのバグ対策と
集団レベルでのバグ対策は異なる。

例えば、個人レベルのプログラムには
将棋やオセロ、winnyや2chブラウザなどがある。

これらは、個人がプログラムを書き
その後、ひたすら動作チェックを繰り返しバグをとるわけだ。
このバグ取りには、多大な時間がかかる。
したがって、この時間を減らす事には意義がある。

これらのバグは
従来のソフトウェア工学が扱ってきたバグとは
種類が違う物だと思う。
もちろん、オブジェクト指向のようなモジュール化は
バグ対策には有効だ。
しかし、これらの対策だけではどうにもならない事は
３０００行程度の趣味プログラムを一つ作ればわかるだろう。

>>8
具体的に説明してください。

デバッグが簡単なプログラムは
全ての入力に対して、それぞれ出力が定義されているケース。

逆に、全ての入力に対して
出力が定義されていない物は非常にデバッグが困難である。

たとえば、物体が運動方程式に従って落下するシミュレーションを
したとしよう。
はたして、運動方程式を正確にシミュレートできているだろうか？
これを調べる方法はない。

たとえば、５００００行のデータベースから
ある列の平均をとるプログラム。
これのデバッグはどうすればいいだろうか？
３００行で動いたからといって、５００００行で動く保証はない。

こちらへどうぞ

『夢・独り言＠2ch掲示板』
http://life.2ch.net/yume/

一つの方法として
コードに制限を加える方法がある。
prologにはコードの整合性をチェックする
アルゴリズミックデバッギングというものがある。
ある種の制約を入れる事により、ある種の論理的な整合性を
チェックする事ができる事を示唆している。

実装レベルで、エラーに強いプログラムの事を
ロバストであると呼ぶ事がある。
例えば、ロボットを制御するプログラムは
ロバストである必要性がある。
なぜなら、プログラマーの想定しない環境は
いくらでも起こりうるからである。

ロバストでないサーバープログラムは
簡単にハッキングされる。

>>1
ソフトウェア管理じゃなくてソフトウェア開発プロセス管理でないの？
個人を対象としたものでは Humphrey の Personal Software Process がある。

>>2
｜８割のバカと共同作業をする事を前提に作られた
｜手法である。
どこからこういう結論に至ったわけ？
ソフトウェア工学では開発者の能力についての前提を設けていない。
ソフトウェアという工業製品を作るためのプロセスの学問であって、
開発者についての学問ではなかった。
個々の開発者の存在を考えず、
人月や FP で定量化可能な労働力としていたアンチテーゼとして
XP などが注目を浴びたわけなんだが。

｜これらのバグをとる、あるいはバグが問題とならないようにする
｜手法はあまり注目されていない。
とりあえず 「基本から学ぶソフトウェアテスト」 「ソフトウェアテスト技法」 を読め。

「動作チェックをする時間を節約したい。どうすればいい？」
�@言語レベル、コーディングレベルでなんとかならないか？
�Aエラーが出ても自動で検出して、復帰する方法はあるか？

物量を減らすことだな。
まわりくどい論理をいかに単刀直入な論理に書き直すかだな。
仕様書もページ数が増えるほど誤読の危険が増す。

>>4
それは管理とはいわない。
実装段階、テスト段階において＿しなければならないこと＿に過ぎない。

｜見通しの良いコードを書くことでバグを減らす事である。
｜例えば、オブジェクト指向プログラミングは有効な手段となる。
オブジェクト指向を採用すればすなわちコードの質があがるということにはならない。
「リファクタリング」 「デザインパターン」 などを読んでくれ。

｜実際にプログラムを走らせた後、
｜プログラム自身でエラーを検出し、修正する方法である。
ソフトウェアテストは静的テスト、動的テストに分類できる。
コードの文面からバグを検出するのが静的テストであり、
その一番簡単なものがコンパイル時のエラーや警告。
実際に動かして確かめるのが動的テスト。

>>6
｜実際にプログラムを走らせる事なく、
｜そのプログラムを納品するにはどうしたらよいか？
無理。

>>9
バグはバグ。何をもって種類が違うと言っているのか不明。

>>11
「単体テスト」 「統合テスト」 を調べてくれ。

>ソフトウェア管理じゃなくてソフトウェア開発プロセス管理でないの？
いいえ。
プロセス管理ではない。

>ソフトウェア工学では開発者の能力についての前提を設けていない。
最近のはそうでもない。

>それは管理とはいわない
それは従来の管理という概念ではないね。
でも、しなくてはいけない。
でも、手法が確立されていない。

>オブジェクト指向を採用すればすなわちコードの質があがるということにはならない。
なる。
例えば、変更の多い部分と変更の少ない部分の切り分けができていれば
見通しのよいプログラムが書ける。
でも、これだけじゃダメだと言ってるわけだが。

>>17
従来の概念に縛られすぎ。
俺が指摘しているのは、
静的テストでも、動的テストでもとれないバグの事を言ってるわけ。

>｜実際にプログラムを走らせる事なく、
>｜そのプログラムを納品するにはどうしたらよいか？
>無理。
じゃあ、走らせる回数を減らす努力をしようじゃないか。

縮小戦線だな。

君が３０００行のプログラムを書き
それをフリーウェアとして公開したとしよう。
この時、必ず第三者が使うとバグが見つかる物だ。
このバグはいったいなぜ出るのだろうか？
このバグを減らす方法はないだろうか？
これが>>9の言い換え

>逆に、全ての入力に対して
>出力が定義されていない物は非常にデバッグが困難である。
つまり、これは単体テストができない事を意味している。
単体テストができなければ、統合テストは言うまでもない。

3000行云々いってるけど中身によるだろバグがでるかでないかは･･･

コード量とバグの量を比例させるやり方もまちがってない？

>>18
論点が違うのだろうから否定するのは別にいいけど、
何故そうでないのかさっぱりわからんが。

>>19
｜それは従来の管理という概念ではないね。
どういう概念なのか説明してくれ。

｜例えば、変更の多い部分と変更の少ない部分の切り分けができていれば
｜見通しのよいプログラムが書ける。
別にオブジェクト指向ではなくてもそれができれば見通しはよくなるでしょ。

>>20
他に人に通じない言葉を使っても仕方がない。

｜静的テストでも、動的テストでもとれないバグの事を言ってるわけ。
それはつまりコードを読んでも実行しても取れないバグのことを意味しているのだが。

｜じゃあ、走らせる回数を減らす努力をしようじゃないか。
何で？昔はマシンの能力が限られていたから一々走らせていては時間も金もかかったが、
今は一昔前のスパコン並のリソースを注ぎ込めるのだから、
好きなだけ走らせればいいじゃん。

>>22
工エｴェｪ（´д｀）ｪェｴエ工
そうだったの？全然わからなかった。

>>1はバカなのでバカ対策をとる必要がある


まあそれはさておき、お題として
バグ対策とバカ対策というのは
かなり面白いと思う。
割と本質をついた問題じゃない？

>3000行云々いってるけど中身によるだろバグがでるかでないかは･･･
それはその通り。
でも、そこまで細かく言わなくてもわかると思ったし。

ソフトウェアを管理するという事は
ソフトウェアの動作を想定していたものに近づけるという事が
目標の一つである。
バージョンアップを繰り返すソフトウェアの多くは
バグフィックスである。
実際に動かしてみると、想定しない動作をする事はよくある事だ。
これを減らすと言う意味での管理

>他に人に通じない言葉を使っても仕方がない。
適切な単語があれば、とっくに使ってる。
そうじゃないから、説明してるんだろ？

>>22
｜このバグはいったいなぜ出るのだろうか？
・OS やライブラリなどの環境に存在するバグ
・処理系のバグ
・プログラムの仕様がおかしい
・コーディングで作りこんだバグ

｜このバグを減らす方法はないだろうか？
・枯れた OS、ライブラリ、処理系を使う
・仕様を見直す、よりましな開発手法を採用する
・リファクタリングする、テストする、デバッグする
ユーザに使ってもらってフィードバックをもらう

>>23
入力の量が異なるなら、入力の量に影響を受ける部分を洗い出して、同値分類をしてテストを作る。
入力に対する出力を機械的にすべて確かめるようなやり方は組み合わせ爆発が起きるので
現実的でないということはすでに分かっている。

一番の根本は官僚の作文のような仕様書を書かせない事。
（憲法の解釈論のような問題を発生させないこと）
二番目にはアルゴリズムの基本を知っておくこと。
（図形描画でもデータ処理でも良い計算式を熟知していること）
三番目はモジュールの相互作用および依存関係を最適化できること。
（回路設計で言えばLSI間の配線パターンをシンプルにデザインすること）

>それはつまりコードを読んでも実行しても取れないバグのことを意味しているのだが。
ある意味正しくて、ある意味間違っている。

静的テストのもっとも原始的なものには
文法チェックがある。
また、文法チェックよりもほんの少し高度な物に
到達しないコードを検出するものがある。
また、これよりほんの少し高度な物に
prologのアルゴリズミックデバッギングがある。

動的テスト（というか対応）の
もっともと原始的なものには、if/thenでの例外対処法がある。
(try/catchでもいいけど）
で、もう少し高度な物にはロギングがある。
また、関数の入出力をチェックするassertionというのもある。
もう少し高度になると、統計を使った異常検出というものがある。

趣味のプログラム遊びの話しかできない、
個人レベルに限定してるわけか・・・

>何で？昔はマシンの能力が限られていたから一々走らせていては時間も金もかかったが、
>今は一昔前のスパコン並のリソースを注ぎ込めるのだから、
>好きなだけ走らせればいいじゃん。
だから、入力に対して、出力が定義されていれば問題はない。
（問題になるくらい大きい入力次元だったら、問題になるかもしれない）

じゃあ、例えば文字を識別するプログラムを作るとしよう。
「あ」と「い」という手書き文字を識別するプログラムである。
入力には、ビットマップが与えられる。
で、出力は「あ」か「い」である。
いったいどうやってデバッグをするのだろうか？
何度も自分で文字を書いて、出力を確認するのかい？

>・OS やライブラリなどの環境に存在するバグ
>・処理系のバグ
>・プログラムの仕様がおかしい
>・コーディングで作りこんだバグ
この２点が重要だと思う。
プログラムの仕様がおかしい
コーディングで作りこんだバグ

>・仕様を見直す、よりましな開発手法を採用する
>・リファクタリングする、テストする、デバッグする
>・ユーザに使ってもらってフィードバックをもらう
その通り。
個人レベルでの開発手法はそれほど問題にならない。
ましてや、たかだか３０００行のプログラムである。
重要なのは、デバッグ（実際に動かしてみる事）だろう。
で、この手間を減らそうと試みているわけである。

>>31
ふむ。知識がないわけじゃないんだね。
切り分ければ
・仕様がおかしい
・それらのチェック手法自体が原理的に不完全である
・チェックの内容を作るときに不完全なものを作ってしまう
となるが、2-3 を解決したいのかな？

>>33
入力も出力もビットマップなら、仕様を満たすだけの入力と出力の対を用意してテストすればよいのでは？
もちろん仕様外のバグについては見つからないが。

>入力の量が異なるなら、入力の量に影響を受ける部分を洗い出して、同値分類をしてテストを作る。
これはいい方法だと思う。
でも、出力を定義するのが困難ならどうだろうか？
あるいは、ハードウェアの制約を考えるとどうだろうか？
ＯＳでもいいけど。
やってみなきゃわからない事はたくさんある。
（やってみなきゃわからないと定義した時点で無理なんだけど
言いたい事を汲み取ってもらえるとうれしいな）
それをどうするかを考えるわけだ。

>入力に対する出力を機械的にすべて確かめるようなやり方は組み合わせ爆発が起きるので
>現実的でないということはすでに分かっている。
そうだね。
だから、アルゴリズムの正当性を調べる方法があるとうれしいね。
平均をとるプログラムを作っても、
５００個までが正しく処理できたからといって、
５００００００個までもきちんと処理できるだろうか？

>個人レベルに限定してるわけか・・・
個人レベルとは書いたものの、
プログラムの根本的な問題なんだけどね。

>>35
そんな感じかな。
要するに、入力と出力の組を列挙する事ができないプログラムに対して、
いかに完全なプログラムを作るか。
おそらく、完全なプログラムはできないし
多項式時間で、チェックする方法がないので
NP-HARDである事は言うまでもない。

>入力も出力もビットマップなら、仕様を満たすだけの入力と出力の対を用意してテストすればよいのでは？
>もちろん仕様外のバグについては見つからないが。
そうそう。
それが原始的なやり方なんだけどね。
例えば白黒の100*100だとするよね。
すると入力のパターンとしては、2^10000個だけある。
で、1000000個のテストを通り抜けても
2^(10000-20)=2^9980個だけ未チェックの入力があるわけ。

>>38
｜すると入力のパターンとしては、2^10000個だけある。
｜で、1000000個のテストを通り抜けても
｜2^(10000-20)=2^9980個だけ未チェックの入力があるわけ。
同値分類して減らせなくて、統計的に正しそうというのでも満足できないなら
完全にチェックして全部調べるしかないでしょ。
あるいは、特定のアルゴリズムなら数学的に正しいかどうかを証明できる可能性はある。
それとも、Prolog のごとくプログラムを書いた時点で論理的な正しさが
証明されているような方法を採る？

いい方法がないから、議論しましょう
っていう感じかな。

すでに書いたとおりＮＰなんだから
完璧は無理。
問題が小規模でない限り、完全にチェックはできない。

サーバーハッキングの話であれば、
例えば、想定した動作だけをインプリメントする方法が有効（かもしれない）
つまり、想定してない物に関してはエラーにする。
普通のプログラミング言語だと、想定してないものに関しては
if/thenで対処するわけだけど、普通は想定してないものは
莫大にあるわけだ。
だから、逆ができたらどうだろうか？
という提案をしてみる。

数学的に正しいかの証明も一つのやり方だと思う。
その一つがアルゴリズミックデバッギング。
↓アルゴリズムデバッギングの事かな？
>それとも、Prolog のごとくプログラムを書いた時点で論理的な正しさが
>証明されているような方法を採る？

アルゴリズムの分割方法と言う意味で、
関数型言語というのは一つの方法提示している。

テストしにくい関数こそ、
ステートレスな関数の集合にしなくてはいけない。

でも、ＧＡのデバッグはどうやっても難しいよな・・・
ニューラルネットもどうやって、デバッグすればいいんだろう・・・

アルゴリズムデバッギングの紹介ページを挙げようとしたら
一個しかなかった・・・
http://hp.vector.co.jp/authors/VA016875/try16.html

で、このページには
テストファーストvsアルゴリズムデバッグ
なんていう項目でコラムがあったりしました。

バカ対策としてオブジェクト指向否定派に喝を入れよう。
こいつらがバグの温床になっている。
しっかりとオブジェクト指向教育でしごいてやらねばならん！

ﾋﾞｼｯ! ﾊﾞｼｯ!

とくにCOBOLerやVB厨、C厨にはしっかり教育してやらねばならん！！！！
しかしC++厨の大半はオブジェクト指向を理解せず使いこなしていない、化けの皮を
はがすとただのC厨程度のレベルの低脳しかいないケースが多すぎる。
C++ができるといえば周りが高く評価されると思い込んで背伸びをしているC厨が多すぎる。
こいつらこそ抵抗勢力だ！　こいつらがもっともタチが悪い！

いまこそ

　　C++厨に

　　　　喝　ー　ー　ー　ー　ー　ー　ー　ー　ー　ー　ー　　ー　ー　！！！！！！！

Cでもオブジェクト指向できるべ
多少やりにくいってだけで

ハゲ対策も

assertionって関数の入出力チェックのことじゃないよ。

Cでオブジェクト指向なんてできねーよ
やりにくさ多少どころじゃねー、めんどすぎ

>>46
普通は関数の入出力のチェックに使うよ。

>>43
教えても無駄だからバカ対策なんだろう。
天才がオブジェクト指向で頑強なプログラムを書き、
バカが触っても大丈夫なところを、バカに任せる。
フレームワークってまさにそんな感じだよね。
骨組みを作っておいて、組み立ては素人に任せるような。
自作ＰＣみたいだｗ

でも、このスレはバカ対策ではなくて
バグ対策だぞ。
流れ嫁。

>>48
それは君の普通。

関数の入出力チェックでassertionを使うというならまだしも、

> また、関数の入出力をチェックするassertionというのもある。

というのは間違い。

>>49
他にどんな使い方するの？

>>52
try,catchでいいじゃん

>>51
finallyが欲しい

assertionは実行中の異常事態に対して使うもんだろう。
パラメータチェックくらいでいちいちabortしてたまるかよ。

>>50
例えば、「契約による設計」 の手法でアサーションを使うならば、
少なくとも事前条件・事後条件・クラス不変条件の三種をチェックする。
http://www.shudo.net/java/assert/assert.html
http://www.kmonos.net/alang/d/cppdbc.html
http://www.ipa.go.jp/security/awareness/vendor/programming/a03_05_main.html

アサーションに力を入れるよりはユニットテストを十分に行った方が
コードも汚れないし良いと思うけどね。

>>53
それは例外機構かと。
アサーションは実機では無効にできるし。

アルゴリズムデバッギングや関数型言語のようなアプローチと逆を考えると、
GC や Electric Fence、イテレータによるループの抽象化など、
間違いを犯しやすい事柄について個別に対策するという手もあるね。

あるいは Java や .NET のような膨大なクラスライブラリ群を使えば
（クラスライブラリ自身にバグがなければ） 使わないよりもバグを減らすことができる。
これを推し進めるとコンポーネント指向になるが。

>>55
> （クラスライブラリ自身にバグがなければ）

これが問題だよねえ。がくっとくる。

>>54
事前条件＝入力
事後条件＝出力
副作用も考えると、
その副作用の範囲がクラス不変条件

でも、普通副作用までassertionでチェックしないよね。
（てか、できない）

だから、普通は関数の入出力チェックに使うわけだ。

>>57
こういうのは？

const double LARGE_PI = 3.1416;
class Complex
{
    double absolute, argument;
public:
    void display()
    {
        assert(0 <= argument && argument < 2 * LARGE_PI);
        ...
    }
    ...
};

assertionは不変条件チェックにつかうものだと思っている
Garbage in, garbage out.

つーか、assertionを辞書で引け。

>>57
きみが普通、関数の入出力チェックにassertionを使うのはいいが、
関数の入出力のチェックに使うものがassertionであるというのは間違いだって
いってるのだが。

>>58
argumentを書き換えるところで検査するほうがいいんじゃないの？

出力はともかく入力は assertion とは別にチェックしないとまずいでしょ。

>>58
副作用の意味わかってる？

>>61
他に何に使うか上げればいいんじゃない？

>>63
なんで？

一応、アドバイスをしておくと
副作用のない関数に関して言うと、
予期できない事は入力のみである。
だから、チェックするものは入力以外はない。
入力が決まれば、出力が決まる。
入力に条件をつける事と、出力に条件をつける事は等価。

> 予期できない事は入力のみである。
こういうやつがバグを埋め込む。

>>58
普通、absolute, argumentはprivateにするだろｳﾞｫｹ

>>65
おまえはコミュニケーションスキルが足りないようだ。
話の流れを読む練習をしよう。

入力に対する出力ってのは仕様では決まっているが、
必ずしも仕様通りに実装できているとは限らない。
限らないから assertion をして検証する。
そういうことだと思っていたんだが。

馬鹿対策っていうことは、ここの連中自体の対策となることだろう。。

おまえらにはお前ら自身がさばける程、自分を客観的に見れないと思うのだが。

アサーションとチェックが直交する概念だってわかってない人が多いですね。
まあチェックすればアサートする必要はあまりないけど。

アサーションをチェック代わりに使うのは論外。

あー「直交」なんて言葉出したら、>>67が暴れちゃうよ（ｗ

for (i = 0; i < 10; i++) {
...
}
assert(i != 10);

67よ、assertionは辞書で調べてみたか？

このスレは>>64対策スレに変更されました。

>必ずしも仕様通りに実装できているとは限らない。
>限らないから assertion をして検証する。
それはテストでやるもんであって、assertionでやるもんじゃないよｗ
テスト（チェック）とassertionは直交している理由がわかる人なら
意味がわかるだろうけど・・・

>>75
さっぱりわからんので詳しく説明してくれ。

XPのユニットテストはAssertionじゃねーのか？

それはテスト時の目的（関数が正しい出力を返すこと）が
テスト関数への入力の用件だから、assertionで正しいんだと思うが

>>77
違うよ。

テストの場合は代表値を用いるけど、アサーションはもっと定義的なのかな。

日 本 語 書 け よ

必死な馬鹿がいるスレハここですか？

>>67
つーかさー、ちょっとしたことで自分の言っていることを
理解してくれないだけで「コミュニケーションスキルが足りない」と
こぼして逃げるこういう奴ってどうよ？

自己厨

関数型言語で書けば
バッチリ。

そして馬鹿対策を怠りバッチリ馬鹿になる

馬鹿には使えないから無理

>つーかさー、ちょっとしたことで自分の言っていることを
>理解してくれないだけで「コミュニケーションスキルが足りない」と
>こぼして逃げるこういう奴ってどうよ？
実際にコミュニケーションスキルが足りてない人には
どう対応すればいいんだろう・・・
現実を見つめない人には何を言っても無駄なんだろうな。

それはさてどうだろうなあ。
コミュニケーションスキルの定義を履き違えている馬鹿が多く、
ボディランゲージや表情の動きを読み取れない奴はコミュニケーションスキルがないと
言い張る馬鹿もいるからなあ。

表情の見えない2chでも同じのりで振舞おうとする馬鹿が多く、
自分の主観だけでものをいってコミュニケーションスキルがないとほざく馬鹿がいるからなあ。

2chは、脳内論理展開しまくりの論理破綻な文章を書いて、相手に日本語できますかなどと
ほざくやつらばかりだからなぁ。

結局おまえら友達いないんだろ？
それって、コミュニケーションスキルの問題じゃない？

学校とか会社に知り合いがいるくらいなんだろうな・・・
所属を超えたつながりがないって悲しいね

>>91
お前も友達いそうにないもんなー。
お互い様なんじゃねーの？

>>91
> 学校とか会社に知り合いがいるくらいなんだろうな・・・
> 所属を超えたつながりがないって悲しいね
まさにこういうのを脳内(ry というんだな。
友人の定義も知らないんじゃないかな。

エンジニアと顧客との間のコミュニケーションを高めるために
UMLというものが生まれた。
オブジェクト指向否定派がUML使っても
コミュニケーションはろくに取れないけどな。

>>94
別にUMLはオブジェクト指向だけってわけじゃないけど。
客によってはあんなもん出されてもわからん、けど結果には文句いうなんていうのはざらだし。

>エンジニアと顧客との間のコミュニケーションを高めるためにUMLというものが生まれた。

受け売り、鵜呑み・・・
こいつ救いようがねーな。

とりあえず、バカ対策はいいとして
バグ対策って何使ってるの？

>>96
反論になってないね。

ここで一つ
関数単位の設計書を渡されたら、
コンパイルすら出来ない状況で作成し、
成果物を提出しなければならない開発もある

数週間後に、ある程度の集団が出来上がったら担当が結合しコンパイル。
まずはコンパイルエラーの修正依頼票があがってくる
（人によっては完全作り替えないといけないことも。　そいつが悪いが）
つぎに致命傷のバグの時期が過ぎて「とりあえず動く」ものが出来上がる

ここから試験チームによる嫌になるような試験期間で、
仕様漏れや変更、実装漏れの多種にわたるバグが延々と出現

俺自身、
　現象　　　　ある条件の処理が行われない
　調査結果　if( a = b)
の修正依頼票をこなしたことがある（情けない）

> 関数単位の設計書を渡されたら、
> コンパイルすら出来ない状況で作成し、
> 成果物を提出しなければならない開発もある
スタブとかドライバとか言う用語知っているか？
知らないのなら基本情報受けろ。

>>100
そういうレベルじゃねえんだよ、必要となるテーブル群、ライブラリ郡だけでも大量
しかも完全には決まってない
（決まってない変数名で作成したりすらある）

>>99
Σ( ﾟДﾟ)ﾅﾆｿﾚ
…退職するのが最適解だと思うんだが。

>>99 >>101 地獄のような状況だな…

まあそういう前提として、この板的にはどういう対処が最適解？
おっと、>102の次の最適解だった(w

まあ、適度にスタブ・ドライバを作ったりする場合もあるが、
基本的にパーツ製作みたいなものだからどうしようもない

新人他、あまりに成果物の品質が悪いということで
　設計書の説明＞コーディング＞コードレビュー
は徹底されるようになっていったよ（過去だよ過去）

携帯アプリ開発ではどこも同じような状態だと思っていたが

テンプレートでジェネレイティブに作っておけば
あとからどんな実装を持って来られても
あらかじめ作っておいたコンセプトが要求に耐えるよな

>>95
なあに、「UML」を知ればオブジェクト指向へと
必然的に興味がわいてくる可能性が高まる。

オブジェクト指向否定派はフローチャート好きが多いだけに
彼らにはアクティビティ図しか興味を示さないこともあるけどな。

>>106
中年層にそういうやついっぱい居る居る。
UMLを使えとあちこちに推奨してる割にはアクティビティ図だけだし
オブジェクト指向は駄目だとか無駄だとか否定する。
そして酔うと「オブジェクト指向はよくわからない」と曝露する。

いるいる
オブジェクト指向についてやたら語るくせに
いざ実践となると構造化にすらなってない
ぐだぐだの実装するやし。

おまいらほとんどそうだろｗ

　　　　　　　　　無党派は選挙に行けば、絶対に政権は変えられます。
　　　　　　　　　貴方の一票は日本を変える本当に大事な一票です。

　　　　　　　　　　　　　　　　　選挙だワッショイ！！
　+　　　　　　　　　　　　＼＼　 選挙だワッショイ！！　／／
　 　　　　　+　　　　　　　　＼＼　選挙だワッショイ！！／ 　　　　　　　　　　　　+
　　+ 　　　　　　　　　　　　　　　　　　　　　　　　　+／■＼　　／■＼
　+　 ／■＼　　　　／■＼　　／■＼　 ／■＼ （　´∀｀∩∩´∀｀ ）　∩ /■＼　+
.　　 （　´∀｀）　　　（　´∀｀∩（´∀｀∩）（　´∀｀） （つ　　 丿ヽ　 ⊂丿　 ヾ(ﾟДﾟ　)
　（( （ つ 　~つ )） （つ　　　ノ （つ　　丿（つ　　つ　（　（　ﾉ　 （　（　ﾉ　)）　 /　　 ⊃ )） +
　　　乂　　((⌒) )）　ヽ　 （　ﾉ　（　ヽノ　　）　）　）　　し'し'　　　し'し' 　　　０＿　〈
　　　　（＿_）　　　／■＼）し'　し（／■＼＿）＿）　 ／■＼　 　ﾋﾟｮｰﾝ 　　.　　 `Ｊ　　*
　　　　　　　 　(( ｎ´∀｀ｎ）　))　　（ ´∀｀ ）　　　　　（　´∀｀）　　　 /■ヽ
　 ／■＼○　　 ヽ　　 　）　　　 と　　　　⊃　　　 _ /　つ　つ )） 　(ﾟーﾟ*)　　　　　　／■＼
と（´∀｀と~⌒つ　(⌒(⌒）　　　　 /　 ,､　ヽ　 （( （ `（　 Ｙ　　　　（( とと　ヽ　　と⌒~つ´∀｀）つ
　 　 　 　 　／■＼　　　∩■＼（＿_） ／■＼ﾞ　 　　 ／■＼　 　 　 ／■＼
　　　　　　 （ ´∀｀ ） 　　| |.´∀｀） 　　（´∀｀　）　　　 （　´∀｀.） 　 　 （´∀｀　）
　　　　　 ⊂ 　　　 づ 　/　　　 ,⊃ （⊂、　　　づ　 　O 　　 ,Oﾞ　　　 ⊂　 ⊂ヽ
　　　　（( ⊂,,,　　ノﾞ　((（　　,,_,,つﾞ　 （(⊂,,,_,,　）　 （( （　 ,,_,,つ　）　　（(⊂,,__,,　）)）
　　　　　　　（__/　　　　創価学会と同じでｲｲ人　→自民党に投票！　　（__/
　　　　　　　 　　　　　　新しい空気にしたい人　　→民主党に投票！

　　　　　　　　　　　　　　　　　カルト支配から日本を救え！！

バグ対策age

仕事を依頼した場合、質問が多くて受け答えするのに疲れるけど、
想定しておいた範囲には収めてくれる人と、
黙々と仕事進めるけど、想定できない結果になる人がいるね。
黙々としてても、想定範囲内というのは希少。

最初に素性を見極めて、
それに応じて進捗管理するのがバグ対策かなと思うが実践できてないな。

>>111
それはもまえが素人なんだと思うけど。
例えば、仕様書がかけない人から依頼が来たとき
こっちから仕様書だせよとはいえないから、
ゆっくりゆっくり話しを聞きだしていかなきゃならない。

大体の場合、依頼主がプログラムの実態がつかめてないから
こっちから提案していかないといけないんだけど。

要求分析って言葉を知ってれば、
依頼主はバカであると仮定した、バカ対策が必要な事くらいは
わかるよね。

>>112
このスレの趣旨はそういう依頼主対策について語ることだったのか。
まるでマ板的ネタに見えないことも無いのだが。

>>113
まさにマ板っぽくなってきたな。
プログラム技術板でやるからには
技術的なバカ対策法の話題に転がってくれた方が役立つんだが

聞かないバカより聞いてくるバカの方が好き

聞いている風に見せかけて出来上がってみると・・・って奴も痛い

説明できないバカ最悪

>>99
スレタイには合ってるけど地獄の環境だな。
っていうか何度もネタか？って思ったよ。

なに？携帯アプリとかいうやつはこんなレベルなの？

携帯アプリはエミュでさっくり作ってその後実機でテストでしょ。
PC上とそんなにかわらん。

実機の性能が恐ろしくバラバラな以外は。

>>119
それはiアプリとかの、エンドユーザーコンピューティングに属するようなアプリのことでしょ。
きっと>>99のは携帯上の電話帳とか、そういう組込みアプリのことだと思われ。

>>120 Yes どことかは言えんが
「音量調節の画面動作」だけのロジックを作成したりだ
呼び元のメニュー、画像表示処理、音設定の実際の変換処理、
などは未完成だったりするんだな

骨組みが出来上がってくるとエミュがあるのだが、エミュ開発も同時進行なのだ

❂ฺ

>>122 ｽｹﾍﾞ

ここで言い争ってる奴らは纏めて使えないと思う

俺は生まれついての使う側の人間だからね。

お前ら「には」使えないだけさage

ハゲ対策も教えてください。
マジでお願いします（泣）

>>99
オレが一人で全部書いたほうが早そうだ。

>>126
「髪の毛の数を数えてください」で24時間未満で数え終わったらハゲ判定

>>126
頭を焼いちまえば
みんな元からハゲだとは気づかないぜ？

>>129
でも、元からバカなのがばれるYO！

最も効果的なバグ対策は
とっとと定時に帰ってしっかり寝て
休日出勤はしないってことかもね

遊ぶ時間を減らしてその分寝ろよｗ

仕事が忙しいから遊ぶ時間を減らすというのは本末転倒な気もするが
板違いか

仕事を減らして収入が減って遊ぶ時間も減るというのが正しいありかたですね。