オブジェクト指向システムの設計 170

1 名前：デフォルトの名無しさん mailto:sage [2016/05/30(月) 23:08:42.31 ID:pIEuB3Z3.net] オブジェクト指向に限らず、理由もなく小さく細分化させるのはアホ オブジェクト指向は役割でオブジェクトに分割するものであって 処理で分割するものではない。 82 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 18:00:45.49 ID:z0ZguSAo.net] オブジェクト指向言語を採用していながら 設計がオブジェクト指向を活かしてないプロジェクトは山ほどあるからなあ 83 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 18:27:58.89 ID:HPDljpqn.net] >>79 確かにｗ おまけにオブジェクト指向の主要な目的についてすら答えないという… 知識がないくせに自信満々で書き込みする連中って何なんだろうな 84 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 20:33:09.19 ID:+XfJxtAA.net] オブジェクト指向しか眼中にないバカは洗脳されていていくら言っても無駄だから諦めろ ソースコードを読んでもわからない仮想関数による潜在的な分岐が恐ろしいと感じるのは当たり前 それでもそうするだけのメリットがあった場合は仮想関数も使うというだけ 欠点も理解できていないようでは道具は使えないよね、まったく 85 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 20:50:11.93 ID:S7oA8kB+.net] >>80 それっぽい言葉並べただけで 全然関係無いよね?（笑） ソースからテスト起こしたとして各メソッドの入力に対する出力は何でチェックするつもりなの? 君、ソースコードからテスト起こしたんだよ チェックできないよね? っていうかまともに会社でテストしたことあるの? 86 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 20:55:39.47 ID:HPDljpqn.net] >>83 そりゃお前の設計がおかしいだけだろ メソッドの目的が明らかでないとは終わってる 87 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 21:13:59.06 ID:BenfpwXE.net] >>84 テストって入力に対して出力をチェックするものじゃん 単体テストも然りだよ 88 名前：80 mailto:sage [2016/05/31(火) 21:30:14.57 ID:tiFC9Nv1.net] >>84 議論の最中に知らない言葉が出てきたのにググらずレス出来ちゃう所は素直にスゴいと思うけどもうちょっと調べた方が良いと思うよ 関数内にIfなりswitchなりがあってどのルートを通っても想定通りの動きをしてるか確認したい場合どうやって試験するの？コード見てテストケース作るよね？ 君の会社ではシステムテストしかしないみたいだけど普通はもうちょっと粒度の小さいテストもやるからね 89 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 21:50:02.34 ID:+XfJxtAA.net] このように、オブジェクト指向から抜け出せなくなります オブジェクト指向に凝るのは麻疹みたいなものっていうけど 万年麻疹では仕方がない 90 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 21:53:42.78 ID:HPDljpqn.net] >>88 いやお前の設計がアホなだけだって 体験談がアホなんだもんｗ 91 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 21:58:58.52 ID:tiFC9Nv1.net] >>88 内心オブジェクト指向と全然関係無い話で申し訳ないと思ってたけどお楽しみ頂けたようで何よりです 92 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 22:08:54.95 ID:BenfpwXE.net] 別にオブジェクト至上主義じゃないし、たった数十行くらいのプログラムでOOD()とか思うけど 複数のswitchにcaseが1000やら10000ぶら下がってても並んでたほうが一目瞭然とかいう>>27の物言いに ついカッとなってしまった。今は反省している 93 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 22:40:38.43 ID:/+1mPN+r.net] switchおじさん登場 「わしのcaseは1080まであるぞ」 94 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 23:07:32.14 ID:bQbJ8LGw.net] >>87 ううん コードからテストなんて絶対作らない ってか作れない 正しい出力って何? 仕様書か設計書にしか俺には見当たらないけど? ソースコードからどうやって正しい出力なんてわかるの? そんなトンチンカンな仕事してて恥ずかしくないの? 95 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 23:16:01.35 ID:bQbJ8LGw.net] そもそもユニットテストとか出してるけど お前ユニットテストやったことあるのかよ あれさメソッド毎に 入力値とそれに対する出力値を求められるわけじゃん 入力値に対する正しい出力値ってソースコードから生成してくれんの? それともお前のやってるユニットテストってただ通して死ななきゃOKみたいな感じなの? 96 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 23:21:08.77 ID:HPDljpqn.net] >>93 コードを書いてから、あるいはコードを見ながらテストを書く場合もあると言ってるだけだろ 言葉尻をとらえたら確かにおかしいけど、普通に考えてコードだけを見てテストを作る訳ないじゃん… 97 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 23:38:05.03 ID:4qIp1aFV.net] まあコードからテストが自動生成できるならそれはそれでリファクタリングの際には 役立つけどな。 とくにレガシーコードをいじる場合。 98 名前：デフォルトの名無しさん [2016/05/31(火) 23:41:19.77 ID:KvOshn77.net] >>93 テスターなの？ 99 名前：デフォルトの名無しさん [2016/05/31(火) 23:42:12.84 ID:KvOshn77.net] ソースコードみれば意図する出力はわかりそうなもんだけど わからないところならコメントで補ってあるはずだよ 100 名前：デフォルトの名無しさん [2016/05/31(火) 23:42:46.24 ID:KvOshn77.net] いまどき詳細設計書なんて書かないでしょ コードとペアでテスト作ってるはずだよ 101 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 23:49:54.85 ID:4qIp1aFV.net] >>91 そもそも 1000 や 10000 に分岐する時点で 仮想にするとか switch にするとか以前の問題があるだろうに。。 設計をしっかりするって別にオブジェクト指向がどうのこうの言う事じゃなく、 こういう分類をうまくやって、あほみたいな数の分岐をなくしたり整理することなんじゃないのかね。 102 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 23:53:29.29 ID:HPDljpqn.net] このスレってスレタイのオブジェクト指向設計について語る人は少ないよな オブジェクト指向設計は初心者には無理だからだろうか 失敗する奴は理解できていないのが原因 103 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 00:08:57.03 ID:DVl/WGs1.net] >>101 お前が言うか 人の批判に終始してるだけじゃねーかよ 知識豊富な君は何か語りたいことがあるのかよ？ 以下の用語を使い100字以内でどうぞ。 オブジェクト趣向分析 オブジェクト嗜好設計 オブジェクト施工プログラミング 104 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 00:23:11.27 ID:iqAUu6wp.net] >>102 あと30字程度しかないじゃないかｗｗｗ 105 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 00:31:30.60 ID:m3KkndXk.net] ↑算数も出来ない プログラミング以前だね 106 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 00:33:43.37 ID:iqAUu6wp.net] >>104 たしかに……SJISバイト数で数えてしまった 107 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 00:35:54.30 ID:XVpspPb0.net] >>26 > 一つのswitch文にcaseが10個あったら？20個だったら？100個だったら？ それだったら関数テーブルに置き換えるな。 var f = { 　　case1: func1, 　　case2: func2, 　　case3: func3, 　　case4: func4, 　　： 　　： } switch文なんて簡単になくせるよ。 108 名前：デフォルトの名無しさん [2016/06/01(水) 02:54:32.51 ID:RDQRhO1c.net] >>103 わろたｗ 109 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 07:17:52.51 ID:3uAWtRHV.net] >>94 それはブラックボックステストでしょ 俺がコード見てテストケース作るって言ってるのはホワイトボックステストだよ 110 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 07:49:26.90 ID:eXE7t88x.net] >>95 なんだこいつただの馬鹿じゃん 111 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 09:09:11.45 ID:MqC7NAR1.net] 将棋の合法手については駒自体の動きと盤面の両方を考慮して決まる。 クラス構成はどうする？ 112 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 09:49:07.08 ID:OaTzWyfO.net] OOにすることって事前に決めるようなナンセンスな話題にしたいなら将棋の話でいいんだけど、違うでしょ？ 自動車とか鳥をクラスでとかいう入門書でよくやる例が、実際にOOで設計する例と乖離しているんじゃないかって話でしょ？ どうしてOOで設計するのかをはっきりさせないと、何をどういうクラスにするかも不明瞭になるよ。 お遊びで将棋を例にするなら、自分なら駒をクラスにして階層構造を作ったりはしない。 駒はプレイヤーが動かすものであり、ルールで動かし方が決まっている、どこまでも受動的なものだから、 あたかも主体にするような勝手な解釈を作ることになる。 つまりルール上に無い階層構造を作ることになり、設計段階で指し方のアルゴリズムに制限がかかる。 駒クラスにメソッドを定義しても、現在の棋譜が必要になるから、盤面を常に引数で受け取るか状態として保持しないといけないので、旨味も少ない。 駒はsum type相当でコンパクトに表現して、ルールをクラス化する方がいい。 113 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 09:58:23.00 ID:5B+GU3AB.net] なんかよく分からんけど 盤クラス、駒クラス、ルールクラスではイカンのか？ 114 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:00:59.02 ID:MqC7NAR1.net] >>111 駒をクラスにしろなんて言ってない。 115 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:10:44.41 ID:MqC7NAR1.net] >>112 明確な正解はなさそうだから、意見交換するにはいい話題だと思って。 駒の動きを駒に持たせるのは自然だけど 局面による制約はあるから盤、駒、ルールの割り振りがはっきりしない。 王手放置、二歩、打ち歩詰めの禁止は盤に紐づいてるように思える。 どちらもルールって考えもありそう。 [] [ここ壊れてます] 117 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:19:46.05 ID:MqC7NAR1.net] >>111 受動的なものだからクラスにならないってのは違うだろ。 MVCもMは受動的なクラスの典型。 駒をクラスにするって制約を勝手に想定して反発してる感じだから それがないと認識した上で意見を書いて欲しい。 118 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:20:56.38 ID:370Huk/V.net] >>84 お前それ@t_wadaに対して言えんの？ 119 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:23:44.00 ID:5B+GU3AB.net] >>114 >王手放置、二歩、打ち歩詰めの禁止は盤に紐づいてるように思える。 個人的にはそれがルールかな 駒は動ける方向を持つ、 盤は駒の位置を保持する （存在しない位置に駒が動こうとしたらエラーを返す）、 ルールが禁じ手かどうか判定する、 って感じだろうか 120 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:29:02.31 ID:HJuydxx6.net] 確かにロジック面では意義が薄いかもしれんが、表示面ではクラス化が有効だと思う。 設計の仕方はいろいろあるけど、一般論として柔軟性を確保しつつ短くてシンプルなコード になることが一番大事だわな。 で、何をもってシンプルというかが知識量や技術力によって違うだけだと思う。 例えば、ある性質を伝えてもらうとして、普通のエンジニアには微分方程式で示されたほうが シンプルで使いやすいと思うけど、文系の人はExcelの計算シートで示されたほうが分かりやすい と思うのかもしれない。 121 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:30:10.54 ID:MqC7NAR1.net] >>117 駒の動きを表現する方法はどう考える？ 金の動きは概念的には分かるけど、金クラスに問い合わせたときにどうやって返すんだろ？ 配置が決まっていないならマスとして返すことはできない。 金オブジェクトは配置されたマスの情報まで持っているとするのか？ 122 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:39:44.99 ID:KWV9l2rU.net] 駒は相対的に移動できる箇所を返して はみ出た部分とかを判定・表示するのはUIの責任かなと 123 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 10:49:52.11 ID:MqC7NAR1.net] 電王戦に参加する将棋ソフトという想定。 >>8-9 124 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 11:04:15.23 ID:3Uom60Ul.net] >>114 盤にひも付いてない 盤は駒の位置しか知らない どちらもルール 125 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 11:05:23.92 ID:RnjmzRnq.net] 将棋を知ってるやつなら飛角香と合駒まで考えが及ぶはず 126 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 12:00:09.01 ID:MqC7NAR1.net] >>122 >>123 とすると、どうなる？ 127 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 12:18:23.72 ID:3Uom60Ul.net] 駒は自分がいるマス目と 動ける範囲を知っている 128 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 12:53:57.88 ID:63gTfooz.net] 駒は条件判断の材料なだけでその後の処理は駒の担当ではないから、条件判断しやすい型にする Javaならenumにしてメソッド追加するならgetDisplayName()程度 将棋盤は9*9のマトリクス情報と手数、棋譜情報( 駒、FromPos , ToPos、時間のリスト)を保持するデータクラス Playerは持ち駒と評価情報とか。この辺は思考ロジックが分からないから適当だけど打ち筋の傾向とか情報があれば保持って感じでデータクラス 129 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 13:12:22.20 ID:3Uom60Ul.net] 棋譜と時計は独自クラスを持つ 持ち駒は持ち駒台があるし 盤の一部だと考える 130 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 14:06:20.72 ID:MqC7NAR1.net] なんとなくは分かるんだが、明確には分からない。 以下のケースのそれぞれの場合に、どのクラスのメソッドを呼び出して、 そのメソッドはどのクラスのどんな情報を参照するのか説明して欲しい。 �@盤上のすべての合法手を列挙する。王手放置などはしないようにする。 �Aある駒が移動できるマスを列挙する。 �Bあるマスに移動できる手を列挙する。大駒を取れる手があるなら優先的に考慮するとかあるだろう。 131 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 14:21:18.72 ID:MqC7NAR1.net] >>128の例を書こうと思って書き始めたけど、文章で書くよりUMLを書いたほうが早そう…。 �@合法手をどのクラスに問い合わせるのか？ �A盤、駒、ルールはクラスとするのか？駒には金は合計4枚とか複数枚あるけど それぞれごとにオブジェクトがあるのか？、 �B盤、駒、ルールの間の参照は？ といった点について考えを聞きたい。 132 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 14:28:22.36 ID:MqC7NAR1.net] 合法手のルールとして 駒ごとの動き。 縁にあれば動きが制約される。 他の駒によって動きが制約される。 二歩による制約。 王手放置は禁止。 打ち歩詰めの禁止。 とかいろいろあって、駒だけに関係するものから盤全体に関するものまで レベルがいろいろあるのをそれぞれどのクラスに担当させるんだろう？ >>125とするなら 駒ごとの動き。 縁にあれば動きが制約される。 は駒オブジェクトが返せるけど、他を考慮するには盤の情報が必要。 上の2つは駒クラスに担当させるのか、それともルールクラスが担当するのか、などなど。 133 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 16:55:28.98 ID:9b+rCIOV.net] どういう方向性で組むか次第だろうが… 実際の将棋であればルールを知っているのは棋士であって、駒台を含む盤や駒はすべて表示のためのものに過ぎないんじゃない？ 目隠し将棋の例がある様に、盤や駒などは将棋というゲームを成立させる必須条件ではないよな 情報を分散して持つのは将棋の様な評価すべき選択肢が多い場合には多くのオーバーヘッドを生むため処理速度的にも好ましくないと思う 134 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 17:07:40.64 ID:3Uom60Ul.net] >>128 合法手は「手」クラスのメソッドに問い合わせる 2. は手が駒クラスのメソッドに問う 1. は2を全駒に問い合わせた後、ルールでフィルタして完了 3. も1の後、マス目でフィルタすれば完了 ＞大駒を取れる手があるなら優先的に考慮する のは駒でなく手や形勢判断とか上位クラスの責務 135 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 17:08:56.70 ID:3Uom60Ul.net] >>129 1. 「手」に問い合わせる。手は盤、駒、ルールに問い合わせる 2. クラスにする。1枚1つで、40枚の駒は40個のオブジェクト 3. 盤と駒は相互に参照。手はその2つとルールを参照。 136 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 17:09:22.17 ID:3Uom60Ul.net] >>130 ＞合法手のルールとして 前半3つは駒と盤 後半3つはルールと手が判断 137 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 17:10:02.02 ID:3Uom60Ul.net] >>131 目隠し将棋はプレイヤーへの表示を UIでカットしてるだけで 内部処理的には盤と駒（の概念）が必要 なお処理速度は考慮せず スレタイに沿って純粋にOOだけ考えている 138 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 20:47:21.69 ID:9b+rCIOV.net] >>135 >>1にはそういうアホな事すんなって書いてあるぞ？w 駒や盤面なんかUI部分を除けばビットフラグの集合で事足りる、内部処理をリアルの構造と同じにする必要なんかないだろう だいたい>>132-134を忠実に実行したら1手指すまでに何回の移譲が入るのよ？ 内部処理に関して言えば効きテーブルや過去の棋譜データの探索等の棋士の脳内の思考の動きを分析してオブジェクト化してコンポジットした方がなんぼかまし OOP自体は否定しないが、ダメ設計は迷惑だ 139 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 20:51:02.12 ID:cinc5ABC.net] >>108 自分の意見を正当化するために必死すぎるだろ if文の条件1つとっても仕様が無いのにどうやってソースだけで判断するんだ? 死ねよ 140 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 22:33:58.92 ID:KWV9l2rU.net] >>136 委譲の数についてはそこまで気にすることはないのでは？ もちろ� 141 名前：�デメテルの法則なんかは意識しないとだけど パフォーマンスの話をすると早すぎる最適化の議論が絡んでくるからややこしい 必要なら全部出来たあとにロファイルとってやろうねってことになる [] [ここ壊れてます] 142 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 22:44:47.80 ID:3uAWtRHV.net] >>137 正当化もなにも、もともと >>73 >コーディングの仕方でテスト項目は変わらない この発言に対する反論としてホワイトボックステストを挙げただけだよ かなり脱線してOOと関係無くなってるからこの話題はもういいよ 143 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 23:32:23.85 ID:cinc5ABC.net] >>139 でも変わらないんだぜ ちゃんと仕様に基づいた意味のある条件分岐であるなら どう組んでもチェック項目は絶対同じ数と内容になる 増えたりも減ったりもしない 記述する場所が違うだけ だから反論にはなっていない もし違うのであればそれは違う仕様のものを作っているんだよ 144 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 23:57:23.45 ID:MqC7NAR1.net] う〜ん。よく分からん。 しっかりした設計者なら自分の理解をUMLでモデリングするんだろうなと思った…。 145 名前：デフォルトの名無しさん mailto:sage [2016/06/01(水) 23:58:26.59 ID:Q91V44dw.net] 同じ「駒」でもロジック部分とUI 部分じゃ持ち方が異なって当然でしょ。 てかそのためのモジュール分けだと思うんだが。 UI とは独立に最適化できるっつーのがこういうモジュール分けの良いところな訳で。 146 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:02:22.14 ID:qX3K4vQy.net] >>140 > どう組んでもチェック項目は絶対同じ数と内容になる そうでもないというか、その発想は抜けがあるよ。 たとえば数値が偶数か奇数かを文字列で返す関数があったとしよう。 function foo(value) { 　　return (value % 2 == 0) ? 'even' : odd'; } これのチェック項目はfoo(0)とfoo(1)の2つで十分だろう。 だけどさ、関数の中身がこうなっていたらどうする？ （1レスに収めるためにわざと改行せずに一行にしたけどそこは無視して） function foo(value) { 　　var i = value % 10; 　　if (i == 0) return 'even'; if (i == 1) return 'odd'; 　　if (i == 2) return 'even'; if (i == 3) return 'odd'; 　　if (i == 4) return 'even'; if (i == 5) return 'odd'; 　　if (i == 6) return 'odd'; if (i == 7) return 'odd'; 　　if (i == 8) return 'even'; if (i == 9) return 'odd'; } わざとバグを入れたけど、バグが無ければこの関数は仕様どおりに動くしfoo(0)とfoo(1)のテストにも通る。 だけどこの関数にはバグがあるし、だからチェック項目は2つでは十分ではないということになる。 コーディングの仕方でチェック項目数は変わらないっていうのは、半分は正しい。 もし2つあるコードのどちらも同じぐらい正しい品質であればその通り。 だけどこの例の場合は違う。2つのテストでは足りないということになっている。 この例のあるべき姿はチェック項目数を増やすのではなくて、コードをリファクタリングしてシンプルにすること。 そうすることでチェック項目は2つになるわけだが、ここまでの話で明らかなように 「コーディングの仕方でテスト項目は変わる」というか「悪いコードだとバグがないことを担保するためのテスト項目は増える」 147 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:06:33.20 ID:IPFd2Mdr.net] >>143 これはコードがアホだとテストも必要って言ってるだけのような。 一般論としてここまでアホなコードに対応することを要求するのは違う気がする。 148 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:11:25.02 ID:qX3K4vQy.net] >>144 これはわかりやすい例にしたからアホに見えるけど似たようなことはある。 もう一つの例が関数やコードのコピペ。 関数やコードがコピペされていると本来一箇所でいいテストを 何箇所でもやらないといけないはめになる。 テスト項目っていうのは無駄なコードがないという前提で仕様書から起こされている。 だから無駄なコードがあれば仕様書から起こしたテスト項目をテストしてもテスト項目が足りない。 正確に言えば理論上テスト項目は足りるはずなのだが、それでは品質を担保できないという現実に直面する。 だからテストする前にコードに無駄がないかを見ないといけない。 コードが想定通りでないとテストしても想定どおりの品質を保つことが出来ない。 149 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:15:44.44 ID:NmrKPHaw.net] >>136 盤や駒をクラスにするのは 責務の分散協調の結果だが OOの設計を知らないのは分かった まあ将棋のように仕様が固定しているなら 高速化を重視するのはいいが RPGのように仕様変更が想定できる場合 構造化で済ましてると書き直しで汚くなる 150 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:16:54.66 ID:IPFd2Mdr.net] >>145 これあるいはこのようなバグによりテストができていないことが判明した場合、 テストが漏れていると判定するか、コードがおかしいと判定するかということ。 条件の境界のテストが漏れているのはテスト漏れだと思うけど、コード固有の境界線のテストが不十分だった場合 本来の仕様とは違うことを境界線にしているコードがおかしいと判断すると思う。 151 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:22:21.92 ID:NDe+tfkH.net] >>143 > function foo(value) { > 　　return (value % 2 == 0) ? 'even' : odd'; > } > これのチェック項目はfoo(0)とfoo(1)の2つで十分だろう。 テストは仕様を満たすかどうかを確認するのが目的だから想定される入力を出力を 出来れば全部それが無理なら適当に間引いてテスト項目を作る必要がある 仕様が良く分からないけど入力は正の整数なのか自然数なのかあるいはもっと別か きちんと仕様を確認した上でないとfoo(0)とfoo(1)の2つで十分とは言えない 152 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:23:27.91 ID:qX3K4vQy.net] >>144 逆に無駄なテストっていうのもある。 たとえば、入力画面に数値入力項目が複数ある。 たとえば「原価」「定価価格」「値引価格」みたいに。 で仕様書では、それぞれの入力項目は数字しか入力できないこと。 という仕様だったとする。 このテストに「原価」「定価価格」「値引価格」の三箇所を それぞれ数字しか入力できないことをチェックするのか？ということ。 同じ画面ならば省こうと思うかもしれないが、 これが違う画面にある「年齢」だったらどうするか？ 仕様書から起こせば、それぞれの項目でチェックしようってなりそうだろう？ だけど開発者がこれらを、数値入力項目用の汎用コンポーネントで実装すれば 数字しか入力できないというテストは無駄でしかない。 ・・・が、開発者が馬鹿で、一箇所だけ普通の入力項目を使って 独自で数字のみ有効なんてコードを書いていたら？ 153 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:27:08.04 ID:IPFd2Mdr.net] >>149 テストスクリプトとしては数字以外が入力されたらエラー処理がなされることを確認する以外の対応がむしろないな。 154 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:27:39.75 ID:qX3K4vQy.net] >>147 > これあるいはこのようなバグによりテストができていないことが判明した場合、 いや、だからテストは通ったって書いたじゃんｗ テストは通るけど、バグがある場合があるんだよ。 そして、テスト仕様書自体は正しく、コードが間違っている。 だから正確に言えばコードによってチェック項目が変わるのではなくて、 そのチェック項目では、コードに問題がないことを担保できない。 チェック項目が十分かつコードにも問題がないことを担保するには あらかじめコードのチェックが必要って話。 もし「コードの方を直さない」ならば、コーディングによって 問題がないことを担保するための、チェック項目は変わってしまう。 155 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:31:00.69 ID:IPFd2Mdr.net] >>151 概念的にはテスターとコーダーは違う人。 テスターは仕様の境界でテストするのであって、コードの境界でテストすることをようきゅうするのはおかしい。 テスターとコーダーが同一人物であったとしたらコーダーがアホだとテストが漏れるのはどうしようもない。 156 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:35:08.33 ID:qX3K4vQy.net] >>152 担当範囲がおかしいかどうかは議論するべき所じゃないよ。 問題が起きた時に誰に責任があるかの話なんかするつもりはない。 今話しているのは、こういう問題をどうやって解決するか 現実の話として、コードのコピペ等によって 仕様書から起こされたテスト項目では、バグがないことを担保できない場合がある。 （逆にコードが汎用化されていたりで、無駄なテストをしている場合もある） バグがないことを担保するにはどうするか？ コードのレビューを行って、コードに問題がないことを 確認するしかないだろうね。 それをしないならば（つまり開発者の書いたコードを信用するならば） コードにバグがないことを担保するためのテスト項目数は変わってしまう。 （ついでに言えば、どういうテストをすればいいかはコードを見ないとわからないので、やっぱりコードのレビューが必要） 157 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:37:15.86 ID:IPFd2Mdr.net] >>153 コードの条件がおかしい場合にテストで検知できるかって話。 要件にしたがってテストしていれば分かる。 要件にしたがってテストしたけどコードがアホ過ぎて検知できない場合もあるとしてもどうしようもない。 どうやって検知すんだ？って話。 158 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:40:13.45 ID:IPFd2Mdr.net] コードレビューで問題が見つかったらコードを直すだけ。 テスト漏れだとは思わない。 もちろんテスト項目として追加するなら追加して。 でも、テストが漏れていたとは思えない。 159 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:42:01.42 ID:9Sgsnltg.net] 後で拡張することが無い部分をswitchで書くのは全然問題無いと思うが。 どこにOOによる拡張性を持たせるかが問題になるから、要件とか設計からの要請で判断するべき。 Expression Problemで明確になることだけど、 OOPは子クラスを新たに追加するのは簡単な一方、新しいメソッドを追加するには既存のソースを変更しないといけない。 親クラスに共通の処理を書いたとしても、他と違うことをしたい子クラスの数だけ変更箇所が散らばる。 どの子クラスがオーバーライドしてるのかを把握するのに手間がかかるし、 追加するメソッドによってはクラス階層を更に分けてコピペを減らすべきかもしれない。 enumとswitchを使っている場合は逆になって、メソッドの追加や変更部分は一箇所にまとまっていて把握と追加が楽。 新しい種類のデータを追加するのは面倒。 ちなみにHaskellの型クラスやOCamlのvariant typeを使うとデータの種類も処理の種類も楽に増やせる。 Javaだとジェネリクスを使えばできないことはないけど、汚くなる。 160 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:42:37.96 ID:qX3K4vQy.net] >>154 > 要件にしたがってテストしたけどコードがアホ過ぎて検知できない場合もあるとしてもどうしようもない。 だからそのどうしようもないことが、現実として起きてるんだよ。 開発者の言う「このコードは汚い」というのはそういうこと。 コードの無駄やコピペがあって、本来十分であるはずのテスト項目では バグがないことを担保できない。 言い換えると、コードに問題がある場合のバグは、仕様書から起こしたテストでは検出できない。 バグが検出できない（問題ないと判断される）のだから、当然コードの問題もテストでは検出できない > どうやって検知すんだ？って話。 コードレビュー以外にも検知する方法はあるぞ。 コードメトリクス（複雑度）の測定や コードの重複の検出ツールなどを使えば良い。 161 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:45:18.72 ID:IPFd2Mdr.net] >>157 コーダーがアホ過ぎたらそういうことも起きるって言ってるじゃん。 そこまでアホなコーダを想定してテストしろって要求するのはおかしいって話。 コーダーが犯すあらゆる過ち対応したテストを作成するのは不可能。 162 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:46:19.41 ID:IPFd2Mdr.net] >>157 ツールがあるならコードを直そうね。 テストが漏れていると思うのはおかしい。 >コードレビュー以外にも検知する方法はあるぞ。 >コードメトリクス（複雑度）の測定や >コードの重複の検出ツールなどを使えば良い。 163 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:48:15.80 ID:55Jnw5v7.net] >>143 関係無いよね チェック項目は増えてない 仕様書から起こす入力に対する正しい出力をチェックするだけ 164 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:50:43.52 ID:qX3K4vQy.net] >>155 > コードレビューで問題が見つかったらコードを直すだけ。 > テスト漏れだとは思わない。 > もちろんテスト項目として追加するなら追加して。 > でも、テストが漏れていたとは思えない。 だからそういったじゃんｗ 正確にはテスト漏れじゃないが、開発者の書いたコードを素直に受け入れるならば、 コードによって問題がないことを担保するためのテスト項目は変わる。 コーディングによってテスト項目は変わるか？質問に対していうと、 「コードレビューで問題が見つかったらコードを直すだけ。」というならば 直さないならばテスト項目は変わるってことでしょう？ テスト項目を変えないためにコーディングを直すっていうのは、 テスト項目が変わる原因の一つがコーディングであると言ってるのと 微妙にニュアンスは違うけど、結果として殆ど変わらないよ。 165 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:53:04.14 ID:qX3K4vQy.net] >>160 > 仕様書から起こす入力に対する正しい出力をチェックするだけ それはなんのためにやっているの？ テストはバグを検出するためにやっていると思ったが、 コードに問題があると、バグを検出できないってことだよね？ 166 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:53:06.73 ID:IPFd2Mdr.net] >>161 コーディングによってテスト項目は変わるか？云々は知らない。 お前が言ってることがおかしいってだけ。 テスターは要件の境界線をテストする。 コードが異常な境界線を基準としていたためにバグを見逃していたとしてもテスターの責任ではない。 どうしようもない。 167 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:58:20.11 ID:55Jnw5v7.net] >>163 それも違う 境界なんてものは存在しない 本来は取り得る値すべてをチェックしなければならない でも客とテスターの間の取引で暗黙に間引いてるってだけの話 168 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:59:05.09 ID:qX3K4vQy.net] >>163 だから責任問題の話なんかするつもり無いってばｗ どんなコードであっても、同じテストをすれば 同じ品質（バグがない）を担保できるような話をしてるから、 同じテストをしたとしても（そのテストに漏れがなかったとしても） コードにバグがないことを担保できないし、 コードの品質も同じにはならないよって話をしてるんだよ。 コードが悪ければ、品質を保つために必要なテスト項目は増えるし、 コードを直すことで、必要なテスト項目は減る。 （正確に言えば仕様書から起こした本来の最低限のテスト項目だけで済む） 169 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:01:46.10 ID:IPFd2Mdr.net] >>165 責任だけの話じゃない。対応のしようがないって話。 要件上引数は正の数でなければならないとする。 ところがコードがアホで引数が100だとバグが発生するとする。 テストではそれが分からなかった。 どうすんの？って話。 170 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:03:06.15 ID:55Jnw5v7.net] >>165 何度も言うけどソースコードからテスト項目は増えない ソースからテスト仕様書作ってる会社なんてないだろうよｗ 171 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:07:07.95 ID:T7FoO03Y.net] だんだん ID:qX3K4vQy ID:IPFd2Mdr の主張がこんがらがってきた…… 172 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:08:17.44 ID:qX3K4vQy.net] >>166 だからテストとは別にコードレビューをテスト前に行い、 悪いコードをあらかじめ直すしかないだろ？ 俺が品質ベースで考えてるから話がずれてるのか？ 俺はバグがないようにすることを目標として どんなテストが必要か？を考えてる。 だからバグを無くすためには、コードによって必要なテスト項目が変わってくる。 そしてコードを良くすることで、必要なテスト項目が減るという話をしてるんだよ。 仕様書からテストを起こすっていうのは、当然コードは見てないから 必要な（最低限の）テストは何か？だけを考えてる。 テストの効果（バグを見落とすかどうか）は考えておらず、 その効果はコードによってばらばらで、テストしてもバグを検出できるとは限らない。 この場合のテストの目的は何なんだろうかねｗ 173 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:08:59.38 ID:IPFd2Mdr.net] >>169 うん。だからコードを直そうね。 テスト漏れじゃないね。 174 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:12:05.80 ID:qX3K4vQy.net] >>167 > 何度も言うけどソースコードからテスト項目は増えない それはテストの効果（バグがないことの担保） を無視すればそうなるよね。 ソースコードからテスト項目は増えないが ソースコードが悪ければ、その増えないテスト項目では バグを見逃す可能性が高くなる。 テストの効果を低くしていいならば、 テスト項目は増やさなくていいよ。 そしてソースコードが汚いならばソースコードの方を直すんだろう？ なぜなら、ソースコードが汚ければテスト項目を 増やさなければならなくなるから（アレ？ｗ） 175 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:12:26.96 ID:T7FoO03Y.net] 俺の理解 ID:qX3K4vQyの主張はコードからテストケース作る ID:IPFd2Mdrの主張は設計書からテストケース作る コードが設計書に書かれてることを満たしてるかどうかって コードから作ってたらわからないのでは……って疑問が…… なぜかコードだけ、設計書だけの0か100かに見えてしまってるので 勘違いしてたらごめん 176 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:13:23.53 ID:qX3K4vQy.net] >>170 > うん。だからコードを直そうね。 > テスト漏れじゃないね。 コードを直さないとどうなる？ 同じ品質を保つにはテストを増やす必要があるよね？ えーと、それがコーディングによってテスト項目は 変わるってことだよねｗ コーディングによってテスト項目が増えるから コーディングを直すんだよね？ｗ 177 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:14:50.74 ID:55Jnw5v7.net] >>169 どうにでも好きなように組んだらいいよ チェック項目は変わらない オブジェクト指向でも関数型でも これが設計の本質だ 単にソースコードに書く場所が違うだけ それがオブジェクト指向 こんなもんにマジになっちゃってどうするの? っていうIT業界の黒歴史 178 名前：デフォルトの名無しさん [2016/06/02(木) 01:16:20.73 ID:IPFd2Mdr.net] >>173 >>166 そりゃバグがあることが判明したらテストを追加すべきだろうね。 でも、そもそもテストが不足していたということじゃないね。 179 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:18:59.63 ID:qX3K4vQy.net] >>172 俺の意見としては、テストとは別にコードレビューが必須であるということ。 仕様書からテストをおこすのは問題ないんだが、 そのテストで品質が保てるかどうかは コードで左右される。 コードが汚ければいくらまともなテスト行ったとしても それで品質を保つことは出来ない。 俺は品質を保つことを第一に考えてるので コードを直さずに品質を保つならばテスト項目� 180 名前：ｪ増えてしまうという話をしてる。 だからテスト項目を増やさずに品質を保つために、コードを直しましょうという話をしている。 で、最初の疑問「コーディングによってテスト項目は変わるか？」の 答えは、（品質を保つことを前提にすると）コーディングによってテスト項目は変わる。 悪いコードだと（品質を保つために）テスト項目が増えてしまう。だからコーディングを直しましょう。 [] [ここ壊れてます] 181 名前：デフォルトの名無しさん [2016/06/02(木) 01:21:24.41 ID:IPFd2Mdr.net] >>176 コードレビューで仕様の境界とは違うところで問題が見つかったらコードを直すだけ。 そんなのテスト作成とは関係ない。 182 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:23:15.23 ID:qX3K4vQy.net] >>175 > そりゃバグがあることが判明したらテストを追加すべきだろうね。 リリースした後で、バグが有りました。すいません。ですむ会社なら それでもいいけどさぁｗ 「ちゃんとテストしたの？」の答えに テストは不足していません！ちゃんとテストしました！ ちゃんとテストしたのに、コードが悪かったんです！ ですむなら、それでもいいけどさぁｗ 理想の世界であれば、テストが不足してないのは事実だろうが、 そのテストで十分であるためには、コードが綺麗でなければならず、 コードが汚ければ、多くのテストが必要になるから コードレビューをして綺麗なコードにしましょうや。 それができて初めて、テストする意味が生まれる。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef