16/05/30 23:08:42.31 pIEuB3Z3.net
オブジェクト指向に限らず、理由もなく小さく細分化させるのはアホ
オブジェクト指向は役割でオブジェクトに分割するものであって
処理で分割するものではない。
2:デフォルトの名無しさん
16/05/30 23:09:37.69 Usq7Wp/A.net
要件定義を書け
3:デフォルトの名無しさん
16/05/30 23:11:13.19 8pkfhQuv.net
170って何だよｗ
Aperyがクラスに分かれていたのがよっぽど悔しかったのか？
4:デフォルトの名無しさん
16/05/30 23:14:33.08 pIEuB3Z3.net
そりゃAperyは将棋ソフトであって思考ロジックじゃないんだから
将棋ソフトの部分は複数のクラスに分かれているだろうさｗ
5:デフォルトの名無しさん
16/05/30 23:15:27.06 8pkfhQuv.net
>>4
え？
6:デフォルトの名無しさん
16/05/30 23:16:07.45 ILfmqIwk.net
次スレ乙ｗｗｗ
170!?
7:デフォルトの名無しさん
16/05/30 23:17:30.10 ILfmqIwk.net
ああなんか©ってスレタイについてて
次スレたてる専ブラの機能で170になったんね
理解した
8:デフォルトの名無しさん
16/05/30 23:52:44.45 j9NktVXe.net
要件定義
(必須機能)
第5条 参加ソフトは、次の各号に掲げる機能を持たなければならない。
一 任意の局面・手番・残り時間からの将棋の対局の開始と継続。
二 任意の時点での対局中断。
三 対局中の現在局面の表示。テキストでも良い。
四 第 19 条の規定による、1 手毎の消費時間の計測、及び累計消費時間の画面への表示。
五 1 手毎の指し手と消費時間の記録。対局中断時も、そこま
9:でのすべての指し手と消費時間を取り出せなければならない。 六 CSA サーバプロトコル ver.1.1.3 に基づく、LAN による対局。 七 相手の指し手の手入力による対局。
10:デフォルトの名無しさん
16/05/30 23:53:11.34 j9NktVXe.net
(推奨機能)
第6条 参加ソフトは、次の各号に掲げる機能を持つことが推奨される。ただし、機能を持たないことによって不利になることはない。
一 千日手の検出。
二 LAN による通信で送受信した文字列の必要に応じた表示。
三 任意の局面・手番・残り時間からの LAN による通信での将棋の対局の開始と継続。
URLﾘﾝｸ(denou.jp)
11:デフォルトの名無しさん
16/05/30 23:56:25.79 8pkfhQuv.net
将棋ソフトはオブジェクト指向設計の例として適切だと確認されたけど
それを認められずに喚いてる連中がたくさんいるのが
12:デフォルトの名無しさん
16/05/31 00:26:54.61 ZlkkiL++.net
誰も説得できてないし納得してないのに勝利宣言とか恥ずかしいわ
将棋ソフトはオブジェクト指向で作る旨味も意義も薄すぎるって散々言われてるのに読んでないのか？
出てきた反論は「じゃあ他の例を出せよ」と「aperyはオブジェクト指向」だけ。
後者に対してソースがC++だからOOだと短絡的な勘違いをしてることも丁寧に説明してるのに反論しないの？
まあ他人を否定したいがために要件定義しろとか誰も前提にしてなかった電王戦のルール出すのも馬鹿なんだけどな
13:デフォルトの名無しさん
16/05/31 00:30:39.71 HPDljpqn.net
>>11
こいつも見苦しい
将棋ソフトをオブジェクト指向で作る意義が分からないとは…
14:デフォルトの名無しさん
16/05/31 00:36:09.45 9fus3M7D.net
前スレで出てきたFizzBuzzEnterpriseの将棋版を目指すって感じかしら？
性能度外視の練習的な意味で
15:デフォルトの名無しさん
16/05/31 01:12:39.02 tMa64zwE.net
あくまで大真面目にシュールまたはシニカルな面白さを追求する設計方針
16:デフォルトの名無しさん
16/05/31 01:13:54.56 yByP5MuE.net
>>12
意味ないよ
そもそもオブジェクト指向の利点って何なのさ
将棋を作ることで何か見えてくんの?
駒なんか絶対クラスにしないし
駒をクラスにしないならオブジェクト指向じゃないし（笑）
17:デフォルトの名無しさん
16/05/31 01:27:56.86 BenfpwXE.net
UIとネットワークまわりはとりあえず分けよう
棋譜ファイル読み書きもわけよう
18:デフォルトの名無しさん
16/05/31 03:35:29.23 9wsPGZ+1.net
駒はクラスにするだろ
switch 王: 飛車: 角:
など、駒の種類数だけの、分岐を書くことがなくなる
if・switch が消えるから、バグが減る。
これがオブジェクト指向の利点の一つ
RPGなんて、キャラクター・モンスター・魔法・アイテムなど、
オブジェクト指向の宝庫
19:デフォルトの名無しさん
16/05/31 03:55:32.81 /+1mPN+r.net
>>17
激しく同意
駒はクラスにするよな
20:デフォルトの名無しさん
16/05/31 06:08:49.98 Q6hYp8jt.net
初心者は必ずそこにハマるよな
21:デフォルトの名無しさん
16/05/31 07:10:00.11 pY1i4wnE.net
将棋の思考ルーチンなんて素人のオレでも出来るぞ
全部乱数によるランダム挙動
ただコマが動くだけ、人工無知能ｗｗ
>>17
たぶん、プログラムを記述する上でどの様に整理整頓するかって事ちゃう
ここら辺の記述スタイルは宗教論争っぽくなっている
私は記述からの読解力が高いので短く記述させろ～から
他人が保守することを考えろ～で物凄いタイプ量を伴うスタイルと長い名前を要請するタイプ
C++は長い方だね
class 歩
bool と金=false;
int 移動歩[9]={0,1,0, 0,0,0, 0,0,0};
int 移動と金[9]={1,1,1, 1,0,1, 0,1,0};
22:デフォルトの名無しさん
16/05/31 07:30:54.26 DWw0UGY/.net
>>17
は?ifとswitchはてめーが隠したから見えねーだけで実際には分岐はあるだろ
単にコードから見えにくいだけでテストは思いっきり漏れてる
そして設計書には絶対記述しなければならないないようなのにコードでは見つからないようにする
その利点が俺には全くわからない
不具合が増えるだけちゃうの?
それこそ知らん奴が見た時それが設計書のそれであることはソース中を追い回さないといけないんだろ?
23:デフォルトの名無しさん
16/05/31 08:30:44.01 BenfpwXE.net
分岐はあるけど
どこに分岐を書くかが重要なんじゃないの？
メソッド毎に10個の分岐をそれぞれ書くよりも
最初にサブクラスを決める分岐を1つ書いたほうが楽じゃん
24:デフォルトの名無しさん
16/05/31 08:35:46.53 QN5Mj7aA.net
>>22
switchで並んでたほうが一目瞭然だよね
25:デフォルトの名無しさん
16/05/31 08:40:38.99 BenfpwXE.net
>>23
抽象化とか理解できない人？
26:デフォルトの名無しさん
16/05/31 08:51:13.02 QN5Mj7aA.net
>>24
抽象化のために一目瞭然でわかるコードをわざわざ改悪しない人
27:デフォルトの名無しさん
16/05/31 08:56:25.89 BenfpwXE.net
>>25
どこまでが一目瞭然？
一つのswitch文にcaseが10個あったら？20個だったら？100個だったら？
28:デフォルトの名無しさん
16/05/31 09:01:48.42 QN5Mj7aA.net
>>26
1000でも10000でも仕様である限り
チェックは必要
だったら並んでたほうがいい
逆になんで抽象化したらそのチェックをしなくていいと思ってるのか?
頭悪いんじゃないのお前
29:デフォルトの名無しさん
16/05/31 09:08:23.90 BenfpwXE.net
>>27
チェックって何を指していってるの？
switch文レベルでチェックが必要な状況を知りたい
サブクラスのユニットテストじゃ駄目なの？
30:デフォルトの名無しさん
16/05/31 09:11:20.37 GPXTRY73.net
俺も駒はクラスにするわ。
で、moveメソッドを定義してその中にそれぞれの動きや制限を書くわ。
その方がソースコード内で各駒に付随する情報や手続きがコンパクトにまとまると思う。
31:デフォルトの名無しさん
16/05/31 09:12:07.95 QN5Mj7aA.net
>>28
設計書にこの時はこの処理をしますって書いたからそれがソースにも
わかる形であったほうが
後から読む人がわかりやすいでしょ?
俺は設計書とソースを一致させることに全力を尽くす
32:デフォルトの名無しさん
16/05/31 09:14:05.76 QN5Mj7aA.net
逆に抽象化してる奴は設計書にも書いてるの?
33:デフォルトの名無しさん
16/05/31 09:18:40.51 QN5Mj7aA.net
>>28
ユニットテストでいいわけねーじゃん
5種類処理が通るのに1つしかチェックしませんって言ってるんだろ?
食わせるパラメータが変わったら死ぬかもしんねーじゃん
34:デフォルトの名無しさん
16/05/31 09:21:30.75 BenfpwXE.net
>>30
この「時」はこの処理をします
この「サブクラス」はこの処理をします
普通に一対一の対応だけど
35:デフォルトの名無しさん
16/05/31 09:23:07.14 BenfpwXE.net
>>32
食わせるパラメータっていうのはつまりサブクラスが変わったらだよね
ユニットテストでカバーしてるよ
36:デフォルトの名無しさん
16/05/31 09:39:19.63 aqblqKlU.net
て…テストって…目視じゃあ…ないの？
37:デフォルトの名無しさん
16/05/31 09:57:36.10 GPXTRY73.net
何となくだけど>>32はオブジェクト指向の利点やプログラミングの仕方そのものを
理解してない気がする。
まずはオープンソースのライブラリを眺めてくれば良いんじゃないかな？
たとえばGUI関連とかだと駒=Widgetの対応で分かりやすいと思うよ。
38:デフォルトの名無しさん
16/05/31 09:58:36.80 HPDljpqn.net
>>15
そもそもオブジェクト指向の意義を分かってないだろ？
自分が理解していないだけなのに価値がないって言っちゃう奴
39:デフォルトの名無しさん
16/05/31 10:03:35.71 HPDljpqn.net
>>20
設計なんてしないでも構築できちゃうと言っちゃう奴っぽいな
前スレで３行の疑似コード書いて設計が完了したとのたまって失笑された君ｗ
40:デフォルトの名無しさん
16/05/31 10:04:52.49 HPDljpqn.net
>>21
こいつもオブジェクト指向の意義が分かってない
41:デフォルトの名無しさん
16/05/31 10:11:20.80 HPDljpqn.net
>>32
それぞれのクラスについてテストするに決まってるだろ…
自分の技術力が低いだけなのに技術が悪いって言っちゃう奴の典型だな
42:デフォルトの名無しさん
16/05/31 10:16:39.60 HPDljpqn.net
全然分かってないやつがswitchについてあれこれ語ってるのがうざいから教えてやると
switchが一箇所しかないって思い込みが間違ってんだわ
それとオブジェクト指向の意義について勉強してから書き込めよ
デザインパターンの最初の何章か読めば分かるだろ
デザインパターンは初心者が読んでも理解できないから理解できてないだけかもしれんが
43:デフォルトの名無しさん
16/05/31 11:30:30.06 QN5Mj7aA.net
>>34
できてないよ
タイミングもA処理とB処理とで違うじゃん
記述の仕方によるテストの数は変わらないよね?
したら違いはswitchで明示的に処理の種類がわかるか否かじゃないの?
44:デフォルトの名無しさん
16/05/31 11:44:47.87 BenfpwXE.net
>>42
明示的に処理の種類がわからなくても済むというのが抽象化のいいところなんだよ
45:デフォルトの名無しさん
16/05/31 11:46:26.65 QN5Mj7aA.net
>>43
読み手にとってなんのメリットもないじゃん
知らん人がそこいじったときにわからないのはメリットなの?
46:デフォルトの名無しさん
16/05/31 11:55:41.59 BenfpwXE.net
>>44
メリットだよ
車を運転するときにアクセル踏めばスピードあがるってのに
エンジンやギアがどう動いてるかを理解する必要ないでしょ
47:デフォルトの名無しさん
16/05/31 11:57:05.52 QN5Mj7aA.net
>>45
いや、バグったのお前が組んだところみたいだけど
48:デフォルトの名無しさん
16/05/31 11:57:58.21 BenfpwXE.net
>>46
バグった条件教えてくれれば
ユニットテスト追加して検証するよ
49:デフォルトの名無しさん
16/05/31 11:58:25.34 QN5Mj7aA.net
お前にしかわかんないようにしてあるのね
なんのためか知らんけど
設計書には書いてあるの?
50:デフォルトの名無しさん
16/05/31 11:59:53.24 BenfpwXE.net
>>48
>>33
51:デフォルトの名無しさん
16/05/31 12:03:15.69 BenfpwXE.net
デザパタの典型だから
ちょっとでも勉強すれば理解できると思うよ
52:デフォルトの名無しさん
16/05/31 12:12:14.38 QN5Mj7aA.net
>>50
でも理解する必要ないんでしょ?
さっきそう言ったよね?
53:デフォルトの名無しさん
16/05/31 12:17:00.42 BenfpwXE.net
>>51
抽象化されたのはそうだね
抽象化のデザイン自体は理解しないといけないよ
switch文の使い方を学ぶようなもん
54:デフォルトの名無しさん
16/05/31 12:19:33.48 NDGHRGCl.net
駒のインスタンスを生成するときに一回だけファクトリクラス内でswitch通すだけ。駒種別による動きの違いは各クラスが持ってる。あとはインターフェイス越しに操作する
歩は歩の動きをするし桂馬は桂馬の動きをする。動きがおかしい駒が有るなら対応するクラスを直せばいいんだよ
別に隠れて無いと思うけどね
55:デフォルトの名無しさん
16/05/31 13:16:21.12 QN5Mj7aA.net
>>53
最悪だよ
結局そこの処理って何種類あるの?
ってクラス生成してる箇所全部探すんだよね?
ヘタしたらソース全域じゃん
だったらswitchでまさにそこに一覧を置いておいてもらったほうが絶対読みやすいよ
56:デフォルトの名無しさん
16/05/31 13:37:41.62 BenfpwXE.net
>>54
そんなことにならないためのモジュール化だよ
クラス間の依存を局所化するんだよ
57:デフォルトの名無しさん
16/05/31 13:46:17.91 QN5Mj7aA.net
>>55
だからswitchでいいじゃん（笑）
すべてにおいてベターな方法があるのに脳ミソ腐ってるの?
58:デフォルトの名無しさん
16/05/31 13:54:42.25 BenfpwXE.net
>>56
あなたの言い方だとクラスの生成＝switch文はソース全域にあるんだよね？
caseが一つ増えることになったらどうするの？
全部のswitch文を探してcase一つづつ足してくの？そっちのが最悪じゃん
サブクラスにしとけば>>53のファクトリー内のswitch一つの修正でいいんだよ
59:デフォルトの名無しさん
16/05/31 13:56:27.56 HPDljpqn.net
ID:QN5Mj7aAのやり方じゃあちこちにswitchがあるくそコードになるのが欠点
指摘されても理解できない奴って…
60:デフォルトの名無しさん
16/05/31 14:10:04.79 QN5Mj7aA.net
>>57
お前も理解が足りんな
処理やチェックが増えることも減ることも無いよね
ってさっき確認したよね?
君のは俺と同じことやっててテスト項目が減るの?
61:デフォルトの名無しさん
16/05/31 14:14:19.90 HPDljpqn.net
>>59
コードの話だろ
コードの変更箇所が減ればテストが必要な箇所も減る
よってテストも減る
こんな常識も知らんとは
62:デフォルトの名無しさん
16/05/31 14:28:31.17 wvPr5zWv.net
駒を分岐をvtable使うなんてしないだろ
63:デフォルトの名無しさん
16/05/31 14:28:53.26 QN5Mj7aA.net
>>60
残念ながら減りません
影響範囲のテストをサボってるだけ
64:デフォルトの名無しさん
16/05/31 14:31:45.60 HPDljpqn.net
>>62
え？何言ってんのｗ
オブジェクト指向について何も分かってないのに語るなよ…
間抜け過ぎてまともな会話にならない
65:デフォルトの名無しさん
16/05/31 14:33:15.42 HPDljpqn.net
>>61
AIが書き込みをする時代になったのか
66:デフォルトの名無しさん
16/05/31 14:40:25.73 BenfpwXE.net
>>62
サブクラスに局所化されるから影響範囲は小さくなるよ
67:デフォルトの名無しさん
16/05/31 14:40:48.35 LdI3VN67.net
>>62
開放/閉鎖原則 (Open-Closed Principle(OCP))って知ってる？
知らないなら調べて見ると良いよ。
URLﾘﾝｸ(ja.wikipedia.org)
> 開放/閉鎖原則に従ったソフトウェアは、既存のソースコードを変更することなく、振る舞いを
> 変更することができる。
> 開放/閉鎖原則に沿ったソフトウェアは、既存のソースコードを変更せずに機能修正や機能追加を
> 行うことができる。そのため、品質検査を再実行する必要がない。
つまり、既存のコードに一切影響を与えることなく、新規に機能追加ができる。既存コードには
影響がないので、再テストも不要。
（自動テストがあるなら、実行するのはおおいに結構）
一方、switch-caseで処理を振り分けていたりする場合、新規に追加した機能のcaseが増え、
原理的には、その変更されたswitch-caseを含むメソッド/クラスを再テストする必要がある。
68:デフォルトの名無しさん
16/05/31 14:47:50.86 QN5Mj7aA.net
>>63
は?
ていうか同じ仕様のもん作っててなんでテスト項目変わるの?
だから少なくなってるとしたらｎ種類のうちの1種類しかチェックしてない箇所が大量にあるだけ
呼ばれるタイミングや状況の変化を考慮できてない
単にコードがいっしょだからテストも同じと誤魔化してるだけ
実際は起動直後に死ぬ
1秒待つと上手く行く
69:デフォルトの名無しさん
16/05/31 14:47:52.46 LdI3VN67.net
OCPの例：
URLﾘﾝｸ(objectclub.jp)
class Note, Quater, Half, Staffがあり、Staff::Play()で演奏するが、ここに8分音符や16分音符
クラスを追加しても、class Staffを含め既存クラスの変更・テストは不要。
70:デフォルトの名無しさん
16/05/31 14:50:42.43 NDGHRGCl.net
>>54
そこの処理ってどこのこと？
71:デフォルトの名無しさん
16/05/31 14:51:48.20 HPDljpqn.net
>>67
だからさ、基礎くらい勉強してから書き込もうね
お前の知識レベルが低過ぎて会話にならない
テストが減る理由については他の人の書き込み含めてよく読もう
それでも分からないならお手上げ
72:デフォルトの名無しさん
16/05/31 15:27:02.55 QN5Mj7aA.net
>>70
お前こそいっぺんでも設計書書いたことあるの?
記述の違いでテスト項目が減るわけないだろ
ちゃんとテストやれ
73:デフォルトの名無しさん
16/05/31 15:32:23.92 Q6hYp8jt.net
>>30
に同意できるやつは少数派
74:デフォルトの名無しさん
16/05/31 15:36:36.68 QN5Mj7aA.net
俺コーディングの仕方でテスト項目が変わる現場いたことないわ
仕様書や設計書から起こすだろ常考
75:デフォルトの名無しさん
16/05/31 15:41:46.58 LdI3VN67.net
>>73
その設計書がコードと1:1でないなら、プログラマは普通コードを元にテストを書く。
>>68の例で言えば、8分音符を追加するという変更の時、どのコードがテスト対象になるのかを
知っているのは、実装したプログラマだけ。
設計書がコードと1:1なら設計書からテストを起こせるが、そんな現場はないだろう。
76:デフォルトの名無しさん
16/05/31 15:52:32.77 rtPt6hUE.net
>>74
>プログラマは普通コードを元にテストを書く
そんなマー見た事いよ。先にテスト書いちゃうじゃん。
テストに合わせて実装が現場だと普通だよ。
分るでしょう？
77:デフォルトの名無しさん
16/05/31 15:53:45.05 LdI3VN67.net
>>75
> そんなマー見た事いよ。先にテスト書いちゃうじゃん。
> テストに合わせて実装が現場だと普通だよ。
sine
78:デフォルトの名無しさん
16/05/31 16:19:39.18 HPDljpqn.net
ID:QN5Mj7aAは自分が知らないものは間違っていると思う性質だから始末が悪い
お前がなっとくできるように説明してやるにはお前に理解させてやる必要があるという…
順番に理解させてやるからまずはオブジェクト指向の主要な目的を述べよ
まともな本なら書かれていることだからちゃんと読んで書くように
どうせ知らないから答えられなくてスルーするんだろ？
知識がない上に向上心がない情けない奴
79:デフォルトの名無しさん
16/05/31 17:10:12.18 QN5Mj7aA.net
コードからテスト起こしたら全部○だよな（笑）
80:デフォルトの名無しさん
16/05/31 17:19:55.49 GPXTRY73.net
>>77
面倒見良いなｗ
81:デフォルトの名無しさん
16/05/31 17:26:36.18 NDGHRGCl.net
>>78
粒度でかいテストしかしないの？
関数増やせば普通に単体テスト増えるよ
>コードからテスト
ホワイトボックステストとかカバレッジとか聞いたこと無い？
82:デフォルトの名無しさん
16/05/31 18:00:45.49 z0ZguSAo.net
オブジェクト指向言語を採用していながら
設計がオブジェクト指向を活かしてないプロジェクトは山ほどあるからなあ
83:デフォルトの名無しさん
16/05/31 18:27:58.89 HPDljpqn.net
>>79
確かにｗ
おまけにオブジェクト指向の主要な目的についてすら答えないという…
知識がないくせに自信満々で書き込みする連中って何なんだろうな
84:デフォルトの名無しさん
16/05/31 20:33:09.19 +XfJxtAA.net
オブジェクト指向しか眼中にないバカは洗脳されていていくら言っても無駄だから諦めろ
ソースコードを読んでもわからない仮想関数による潜在的な分岐が恐ろしいと感じるのは当たり前
それでもそうするだけのメリットがあった場合は仮想関数も使うというだけ
欠点も理解できていないようでは道具は使えないよね、まったく
85:デフォルトの名無しさん
16/05/31 20:50:11.93 S7oA8kB+.net
>>80
それっぽい言葉並べただけで
全然関係無いよね?（笑）
ソースからテスト起こしたとして各メソッドの入力に対する出力は何でチェックするつもりなの?
君、ソースコードからテスト起こしたんだよ
チェックできないよね?
っていうかまともに会社でテストしたことあるの?
86:デフォルトの名無しさん
16/05/31 20:55:39.47 HPDljpqn.net
>>83
そりゃお前の設計がおかしいだけだろ
メソッドの目的が明らかでないとは終わってる
87:デフォルトの名無しさん
16/05/31 21:13:59.06 BenfpwXE.net
>>84
テストって入力に対して出力をチェックするものじゃん
単体テストも然りだよ
88:80
16/05/31 21:30:14.57 tiFC9Nv1.net
>>84
議論の最中に知らない言葉が出てきたのにググらずレス出来ちゃう所は素直にスゴいと思うけどもうちょっと調べた方が良いと思うよ
関数内にIfなりswitchなりがあってどのルートを通っても想定通りの動きをしてるか確認したい場合どうやって試験するの？コード見てテストケース作るよね？
君の会社ではシステムテストしかしないみたいだけど普通はもうちょっと粒度の小さいテストもやるからね
89:デフォルトの名無しさん
16/05/31 21:50:02.34 +XfJxtAA.net
このように、オブジェクト指向から抜け出せなくなります
オブジェクト指向に凝るのは麻疹みたいなものっていうけど
万年麻疹では仕方がない
90:デフォルトの名無しさん
16/05/31 21:53:42.78 HPDljpqn.net
>>88
いやお前の設計がアホなだけだって
体験談がアホなんだもんｗ
91:デフォルトの名無しさん
16/05/31 21:58:58.52 tiFC9Nv1.net
>>88
内心オブジェクト指向と全然関係無い話で申し訳ないと思ってたけどお楽しみ頂けたようで何よりです
92:デフォルトの名無しさん
16/05/31 22:08:54.95 BenfpwXE.net
別にオブジェクト至上主義じゃないし、たった数十行くらいのプログラムでOOD()とか思うけど
複数のswitchにcaseが1000やら10000ぶら下がってても並んでたほうが一目瞭然とかいう>>27の物言いに
ついカッとなってしまった。今は反省している
93:デフォルトの名無しさん
16/05/31 22:40:38.43 /+1mPN+r.net
switchおじさん登場
「わしのcaseは1080まであるぞ」
94:デフォルトの名無しさん
16/05/31 23:07:32.14 bQbJ8LGw.net
>>87
ううん
コードからテストなんて絶対作らない
ってか作れない
正しい出力って何?
仕様書か設計書にしか俺には見当たらないけど?
ソースコードからどうやって正しい出力なんてわかるの?
そんなトンチンカンな仕事してて恥ずかしくないの?
95:デフォルトの名無しさん
16/05/31 23:16:01.35 bQbJ8LGw.net
そもそもユニットテストとか出してるけど
お前ユニットテストやったことあるのかよ
あれさメソッド毎に
入力値とそれに対する出力値を求められるわけじゃん
入力値に対する正しい出力値ってソースコードから生成してくれんの?
それともお前のやってるユニットテストってただ通して死ななきゃOKみたいな感じなの?
96:デフォルトの名無しさん
16/05/31 23:21:08.77 HPDljpqn.net
>>93
コードを書いてから、あるいはコードを見ながらテストを書く場合もあると言ってるだけだろ
言葉尻をとらえたら確かにおかしいけど、普通に考えてコードだけを見てテストを作る訳ないじゃん…
97:デフォルトの名無しさん
16/05/31 23:38:05.03 4qIp1aFV.net
まあコードからテストが自動生成できるならそれはそれでリファクタリングの際には
役立つけどな。
とくにレガシーコードをいじる場合。
98:デフォルトの名無しさん
16/05/31 23:41:19.77 KvOshn77.net
>>93
テスターなの？
99:デフォルトの名無しさん
16/05/31 23:42:12.84 KvOshn77.net
ソースコードみれば意図する出力はわかりそうなもんだけど
わからないところならコメントで補ってあるはずだよ
100:デフォルトの名無しさん
16/05/31 23:42:46.24 KvOshn77.net
いまどき詳細設計書なんて書かないでしょ
コードとペアでテスト作ってるはずだよ
101:デフォルトの名無しさん
16/05/31 23:49:54.85 4qIp1aFV.net
>>91
そもそも 1000 や 10000 に分岐する時点で
仮想にするとか switch にするとか以前の問題があるだろうに。。
設計をしっかりするって別にオブジェクト指向がどうのこうの言う事じゃなく、
こういう分類をうまくやって、あほみたいな数の分岐をなくしたり整理することなんじゃないのかね。
102:デフォルトの名無しさん
16/05/31 23:53:29.29 HPDljpqn.net
このスレってスレタイのオブジェクト指向設計について語る人は少ないよな
オブジェクト指向設計は初心者には無理だからだろうか
失敗する奴は理解できていないのが原因
103:デフォルトの名無しさん
16/06/01 00:08:57.03 DVl/WGs1.net
>>101
お前が言うか
人の批判に終始してるだけじゃねーかよ
知識豊富な君は何か語りたいことがあるのかよ？
以下の用語を使い100字以内でどうぞ。
オブジェクト趣向分析
オブジェクト嗜好設計
オブジェクト施工プログラミング
104:デフォルトの名無しさん
16/06/01 00:23:11.27 iqAUu6wp.net
>>102
あと30字程度しかないじゃないかｗｗｗ
105:デフォルトの名無しさん
16/06/01 00:31:30.60 m3KkndXk.net
↑算数も出来ない
プログラミング以前だね
106:デフォルトの名無しさん
16/06/01 00:33:43.37 iqAUu6wp.net
>>104
たしかに……SJISバイト数で数えてしまった
107:デフォルトの名無しさん
16/06/01 00:35:54.30 XVpspPb0.net
>>26
> 一つのswitch文にcaseが10個あったら？20個だったら？100個だったら？
それだったら関数テーブルに置き換えるな。
var f = {
case1: func1,
case2: func2,
case3: func3,
case4: func4,
：
：
}
switch文なんて簡単になくせるよ。
108:デフォルトの名無しさん
16/06/01 02:54:32.51 RDQRhO1c.net
>>103
わろたｗ
109:デフォルトの名無しさん
16/06/01 07:17:52.51 3uAWtRHV.net
>>94
それはブラックボックステストでしょ
俺がコード見てテストケース作るって言ってるのはホワイトボックステストだよ
110:デフォルトの名無しさん
16/06/01 07:49:26.90 eXE7t88x.net
>>95
なんだこいつただの馬鹿じゃん
111:デフォルトの名無しさん
16/06/01 09:09:11.45 MqC7NAR1.net
将棋の合法手については駒自体の動きと盤面の両方を考慮して決まる。
クラス構成はどうする？
112:デフォルトの名無しさん
16/06/01 09:49:07.08 OaTzWyfO.net
OOにすることって事前に決めるようなナンセンスな話題にしたいなら将棋の話でいいんだけど、違うでしょ？
自動車とか鳥をクラスでとかいう入門書でよくやる例が、実際にOOで設計する例と乖離しているんじゃないかって話でしょ？
どうしてOOで設計するのかをはっきりさせないと、何をどういうクラスにするかも不明瞭になるよ。
お遊びで将棋を例にするなら、自分なら駒をクラスにして階層構造を作ったりはしない。
駒はプレイヤーが動かすものであり、ルールで動かし方が決まっている、どこまでも受動的なものだから、
あたかも主体にするような勝手な解釈を作ることになる。
つまりルール上に無い階層構造を作ることになり、設計段階で指し方のアルゴリズムに制限がかかる。
駒クラスにメソッドを定義しても、現在の棋譜が必要になるから、盤面を常に引数で受け取るか状態として保持しないといけないので、旨味も少ない。
駒はsum type相当でコンパクトに表現して、ルールをクラス化する方がいい。
113:デフォルトの名無しさん
16/06/01 09:58:23.00 5B+GU3AB.net
なんかよく分からんけど
盤クラス、駒クラス、ルールクラスではイカンのか？
114:デフォルトの名無しさん
16/06/01 10:00:59.02 MqC7NAR1.net
>>111
駒をクラスにしろなんて言ってない。
115:デフォルトの名無しさん
16/06/01 10:10:44.41 MqC7NAR1.net
>>112 明確な正解はなさそうだから、意見交換するにはいい話題だと思って。 駒の動きを駒に持たせるのは自然だけど 局面による制約はあるから盤、駒、ルールの割り振りがはっきりしない。 王手放置、二歩、打ち歩詰めの禁止は盤に紐づいてるように思える。 どちらもルールって考えもありそう。
117:デフォルトの名無しさん
16/06/01 10:19:46.05 MqC7NAR1.net
>>111
受動的なものだからクラスにならないってのは違うだろ。
MVCもMは受動的なクラスの典型。
駒をクラスにするって制約を勝手に想定して反発してる感じだから
それがないと認識した上で意見を書いて欲しい。
118:デフォルトの名無しさん
16/06/01 10:20:56.38 370Huk/V.net
>>84
お前それ@t_wadaに対して言えんの？
119:デフォルトの名無しさん
16/06/01 10:23:44.00 5B+GU3AB.net
>>114
>王手放置、二歩、打ち歩詰めの禁止は盤に紐づいてるように思える。
個人的にはそれがルールかな
駒は動ける方向を持つ、
盤は駒の位置を保持する
（存在しない位置に駒が動こうとしたらエラーを返す）、
ルールが禁じ手かどうか判定する、
って感じだろうか
120:デフォルトの名無しさん
16/06/01 10:29:02.31 HJuydxx6.net
確かにロジック面では意義が薄いかもしれんが、表示面ではクラス化が有効だと思う。
設計の仕方はいろいろあるけど、一般論として柔軟性を確保しつつ短くてシンプルなコード
になることが一番大事だわな。
で、何をもってシンプルというかが知識量や技術力によって違うだけだと思う。
例えば、ある性質を伝えてもらうとして、普通のエンジニアには微分方程式で示されたほうが
シンプルで使いやすいと思うけど、文系の人はExcelの計算シートで示されたほうが分かりやすい
と思うのかもしれない。
121:デフォルトの名無しさん
16/06/01 10:30:10.54 MqC7NAR1.net
>>117
駒の動きを表現する方法はどう考える？
金の動きは概念的には分かるけど、金クラスに問い合わせたときにどうやって返すんだろ？
配置が決まっていないならマスとして返すことはできない。
金オブジェクトは配置されたマスの情報まで持っているとするのか？
122:デフォルトの名無しさん
16/06/01 10:39:44.99 KWV9l2rU.net
駒は相対的に移動できる箇所を返して
はみ出た部分とかを判定・表示するのはUIの責任かなと
123:デフォルトの名無しさん
16/06/01 10:49:52.11 MqC7NAR1.net
電王戦に参加する将棋ソフトという想定。
>>8-9
124:デフォルトの名無しさん
16/06/01 11:04:15.23 3Uom60Ul.net
>>114
盤にひも付いてない
盤は駒の位置しか知らない
どちらもルール
125:デフォルトの名無しさん
16/06/01 11:05:23.92 RnjmzRnq.net
将棋を知ってるやつなら飛角香と合駒まで考えが及ぶはず
126:デフォルトの名無しさん
16/06/01 12:00:09.01 MqC7NAR1.net
>>122
>>123
とすると、どうなる？
127:デフォルトの名無しさん
16/06/01 12:18:23.72 3Uom60Ul.net
駒は自分がいるマス目と
動ける範囲を知っている
128:デフォルトの名無しさん
16/06/01 12:53:57.88 63gTfooz.net
駒は条件判断の材料なだけでその後の処理は駒の担当ではないから、条件判断しやすい型にする
Javaならenumにしてメソッド追加するならgetDisplayName()程度
将棋盤は9*9のマトリクス情報と手数、棋譜情報(
駒、FromPos , ToPos、時間のリスト)を保持するデータクラス
Playerは持ち駒と評価情報とか。この辺は思考ロジックが分からないから適当だけど打ち筋の傾向とか情報があれば保持って感じでデータクラス
129:デフォルトの名無しさん
16/06/01 13:12:22.20 3Uom60Ul.net
棋譜と時計は独自クラスを持つ
持ち駒は持ち駒台があるし
盤の一部だと考える
130:デフォルトの名無しさん
16/06/01 14:06:20.72 MqC7NAR1.net
なんとなくは分かるんだが、明確には分からない。
以下のケースのそれぞれの場合に、どのクラスのメソッドを呼び出して、
そのメソッドはどのクラスのどんな情報を参照するのか説明して欲しい。
①盤上のすべての合法手を列挙する。王手放置などはしないようにする。
②ある駒が移動できるマスを列挙する。
③あるマスに移動できる手を列挙する。大駒を取れる手があるなら優先的に考慮するとかあるだろう。
131:デフォルトの名無しさん
16/06/01 14:21:18.72 MqC7NAR1.net
>>128の例を書こうと思って書き始めたけど、文章で書くよりUMLを書いたほうが早そう…。
①合法手をどのクラスに問い合わせるのか？
②盤、駒、ルールはクラスとするのか？駒には金は合計4枚とか複数枚あるけど
それぞれごとにオブジェクトがあるのか？、
③盤、駒、ルールの間の参照は？
といった点について考えを聞きたい。
132:デフォルトの名無しさん
16/06/01 14:28:22.36 MqC7NAR1.net
合法手のルールとして
駒ごとの動き。
縁にあれば動きが制約される。
他の駒によって動きが制約される。
二歩による制約。
王手放置は禁止。
打ち歩詰めの禁止。
とかいろいろあって、駒だけに関係するものから盤全体に関するものまで
レベルがいろいろあるのをそれぞれどのクラスに担当させるんだろう？
>>125とするなら
駒ごとの動き。
縁にあれば動きが制約される。
は駒オブジェクトが返せるけど、他を考慮するには盤の情報が必要。
上の2つは駒クラスに担当させるのか、それともルールクラスが担当するのか、などなど。
133:デフォルトの名無しさん
16/06/01 16:55:28.98 9b+rCIOV.net
どういう方向性で組むか次第だろうが…
実際の将棋であればルールを知っているのは棋士であって、駒台を含む盤や駒はすべて表示のためのものに過ぎないんじゃない？
目隠し将棋の例がある様に、盤や駒などは将棋というゲームを成立させる必須条件ではないよな
情報を分散して持つのは将棋の様な評価すべき選択肢が多い場合には多くのオーバーヘッドを生むため処理速度的にも好ましくないと思う
134:デフォルトの名無しさん
16/06/01 17:07:40.64 3Uom60Ul.net
>>128
合法手は「手」クラスのメソッドに問い合わせる
2. は手が駒クラスのメソッドに問う
1. は2を全駒に問い合わせた後、ルールでフィルタして完了
3. も1の後、マス目でフィルタすれば完了
＞大駒を取れる手があるなら優先的に考慮する
のは駒でなく手や形勢判断とか上位クラスの責務
135:デフォルトの名無しさん
16/06/01 17:08:56.70 3Uom60Ul.net
>>129
1. 「手」に問い合わせる。手は盤、駒、ルールに問い合わせる
2. クラスにする。1枚1つで、40枚の駒は40個のオブジェクト
3. 盤と駒は相互に参照。手はその2つとルールを参照。
136:デフォルトの名無しさん
16/06/01 17:09:22.17 3Uom60Ul.net
>>130
＞合法手のルールとして
前半3つは駒と盤
後半3つはルールと手が判断
137:デフォルトの名無しさん
16/06/01 17:10:02.02 3Uom60Ul.net
>>131
目隠し将棋はプレイヤーへの表示を
UIでカットしてるだけで
内部処理的には盤と駒（の概念）が必要
なお処理速度は考慮せず
スレタイに沿って純粋にOOだけ考えている
138:デフォルトの名無しさん
16/06/01 20:47:21.69 9b+rCIOV.net
>>135
>>1にはそういうアホな事すんなって書いてあるぞ？w
駒や盤面なんかUI部分を除けばビットフラグの集合で事足りる、内部処理をリアルの構造と同じにする必要なんかないだろう
だいたい>>132-134を忠実に実行したら1手指すまでに何回の移譲が入るのよ？
内部処理に関して言えば効きテーブルや過去の棋譜データの探索等の棋士の脳内の思考の動きを分析してオブジェクト化してコンポジットした方がなんぼかまし
OOP自体は否定しないが、ダメ設計は迷惑だ
139:デフォルトの名無しさん
16/06/01 20:51:02.12 cinc5ABC.net
>>108
自分の意見を正当化するために必死すぎるだろ
if文の条件1つとっても仕様が無いのにどうやってソースだけで判断するんだ?
死ねよ
140:デフォルトの名無しさん
16/06/01 22:33:58.92 KWV9l2rU.net
>>136
委譲の数についてはそこまで気にすることはないのでは？
もちろ�
141:fメテルの法則なんかは意識しないとだけど パフォーマンスの話をすると早すぎる最適化の議論が絡んでくるからややこしい 必要なら全部出来たあとにロファイルとってやろうねってことになる
142:デフォルトの名無しさん
16/06/01 22:44:47.80 3uAWtRHV.net
>>137
正当化もなにも、もともと
>>73
>コーディングの仕方でテスト項目は変わらない
この発言に対する反論としてホワイトボックステストを挙げただけだよ
かなり脱線してOOと関係無くなってるからこの話題はもういいよ
143:デフォルトの名無しさん
16/06/01 23:32:23.85 cinc5ABC.net
>>139
でも変わらないんだぜ
ちゃんと仕様に基づいた意味のある条件分岐であるなら
どう組んでもチェック項目は絶対同じ数と内容になる
増えたりも減ったりもしない
記述する場所が違うだけ
だから反論にはなっていない
もし違うのであればそれは違う仕様のものを作っているんだよ
144:デフォルトの名無しさん
16/06/01 23:57:23.45 MqC7NAR1.net
う～ん。よく分からん。
しっかりした設計者なら自分の理解をUMLでモデリングするんだろうなと思った…。
145:デフォルトの名無しさん
16/06/01 23:58:26.59 Q91V44dw.net
同じ「駒」でもロジック部分とUI 部分じゃ持ち方が異なって当然でしょ。
てかそのためのモジュール分けだと思うんだが。
UI とは独立に最適化できるっつーのがこういうモジュール分けの良いところな訳で。
146:デフォルトの名無しさん
16/06/02 00:02:22.14 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:デフォルトの名無しさん
16/06/02 00:06:33.20 IPFd2Mdr.net
>>143
これはコードがアホだとテストも必要って言ってるだけのような。
一般論としてここまでアホなコードに対応することを要求するのは違う気がする。
148:デフォルトの名無しさん
16/06/02 00:11:25.02 qX3K4vQy.net
>>144
これはわかりやすい例にしたからアホに見えるけど似たようなことはある。
もう一つの例が関数やコードのコピペ。
関数やコードがコピペされていると本来一箇所でいいテストを
何箇所でもやらないといけないはめになる。
テスト項目っていうのは無駄なコードがないという前提で仕様書から起こされている。
だから無駄なコードがあれば仕様書から起こしたテスト項目をテストしてもテスト項目が足りない。
正確に言えば理論上テスト項目は足りるはずなのだが、それでは品質を担保できないという現実に直面する。
だからテストする前にコードに無駄がないかを見ないといけない。
コードが想定通りでないとテストしても想定どおりの品質を保つことが出来ない。
149:デフォルトの名無しさん
16/06/02 00:15:44.44 NmrKPHaw.net
>>136
盤や駒をクラスにするのは
責務の分散協調の結果だが
OOの設計を知らないのは分かった
まあ将棋のように仕様が固定しているなら
高速化を重視するのはいいが
RPGのように仕様変更が想定できる場合
構造化で済ましてると書き直しで汚くなる
150:デフォルトの名無しさん
16/06/02 00:16:54.66 IPFd2Mdr.net
>>145
これあるいはこのようなバグによりテストができていないことが判明した場合、
テストが漏れていると判定するか、コードがおかしいと判定するかということ。
条件の境界のテストが漏れているのはテスト漏れだと思うけど、コード固有の境界線のテストが不十分だった場合
本来の仕様とは違うことを境界線にしているコードがおかしいと判断すると思う。
151:デフォルトの名無しさん
16/06/02 00:22:21.92 NDe+tfkH.net
>>143
> function foo(value) {
> return (value % 2 == 0) ? 'even' : odd';
> }
> これのチェック項目はfoo(0)とfoo(1)の2つで十分だろう。
テストは仕様を満たすかどうかを確認するのが目的だから想定される入力を出力を
出来れば全部それが無理なら適当に間引いてテスト項目を作る必要がある
仕様が良く分からないけど入力は正の整数なのか自然数なのかあるいはもっと別か
きちんと仕様を確認した上でないとfoo(0)とfoo(1)の2つで十分とは言えない
152:デフォルトの名無しさん
16/06/02 00:23:27.91 qX3K4vQy.net
>>144
逆に無駄なテストっていうのもある。
たとえば、入力画面に数値入力項目が複数ある。
たとえば「原価」「定価価格」「値引価格」みたいに。
で仕様書では、それぞれの入力項目は数字しか入力できないこと。
という仕様だったとする。
このテストに「原価」「定価価格」「値引価格」の三箇所を
それぞれ数字しか入力できないことをチェックするのか？ということ。
同じ画面ならば省こうと思うかもしれないが、
これが違う画面にある「年齢」だったらどうするか？
仕様書から起こせば、それぞれの項目でチェックしようってなりそうだろう？
だけど開発者がこれらを、数値入力項目用の汎用コンポーネントで実装すれば
数字しか入力できないというテストは無駄でしかない。
・・・が、開発者が馬鹿で、一箇所だけ普通の入力項目を使って
独自で数字のみ有効なんてコードを書いていたら？
153:デフォルトの名無しさん
16/06/02 00:27:08.04 IPFd2Mdr.net
>>149
テストスクリプトとしては数字以外が入力されたらエラー処理がなされることを確認する以外の対応がむしろないな。
154:デフォルトの名無しさん
16/06/02 00:27:39.75 qX3K4vQy.net
>>147
> これあるいはこのようなバグによりテストができていないことが判明した場合、
いや、だからテストは通ったって書いたじゃんｗ
テストは通るけど、バグがある場合があるんだよ。
そして、テスト仕様書自体は正しく、コードが間違っている。
だから正確に言えばコードによってチェック項目が変わるのではなくて、
そのチェック項目では、コードに問題がないことを担保できない。
チェック項目が十分かつコードにも問題がないことを担保するには
あらかじめコードのチェックが必要って話。
もし「コードの方を直さない」ならば、コーディングによって
問題がないことを担保するための、チェック項目は変わってしまう。
155:デフォルトの名無しさん
16/06/02 00:31:00.69 IPFd2Mdr.net
>>151
概念的にはテスターとコーダーは違う人。
テスターは仕様の境界でテストするのであって、コードの境界でテストすることをようきゅうするのはおかしい。
テスターとコーダーが同一人物であったとしたらコーダーがアホだとテストが漏れるのはどうしようもない。
156:デフォルトの名無しさん
16/06/02 00:35:08.33 qX3K4vQy.net
>>152
担当範囲がおかしいかどうかは議論するべき所じゃないよ。
問題が起きた時に誰に責任があるかの話なんかするつもりはない。
今話しているのは、こういう問題をどうやって解決するか
現実の話として、コードのコピペ等によって
仕様書から起こされたテスト項目では、バグがないことを担保できない場合がある。
（逆にコードが汎用化されていたりで、無駄なテストをしている場合もある）
バグがないことを担保するにはどうするか？
コードのレビューを行って、コードに問題がないことを
確認するしかないだろうね。
それをしないならば（つまり開発者の書いたコードを信用するならば）
コードにバグがないことを担保するためのテスト項目数は変わってしまう。
（ついでに言えば、どういうテストをすればいいかはコードを見ないとわからないので、やっぱりコードのレビューが必要）
157:デフォルトの名無しさん
16/06/02 00:37:15.86 IPFd2Mdr.net
>>153
コードの条件がおかしい場合にテストで検知できるかって話。
要件にしたがってテストしていれば分かる。
要件にしたがってテストしたけどコードがアホ過ぎて検知できない場合もあるとしてもどうしようもない。
どうやって検知すんだ？って話。
158:デフォルトの名無しさん
16/06/02 00:40:13.45 IPFd2Mdr.net
コードレビューで問題が見つかったらコードを直すだけ。
テスト漏れだとは思わない。
もちろんテスト項目として追加するなら追加して。
でも、テストが漏れていたとは思えない。
159:デフォルトの名無しさん
16/06/02 00:42:01.42 9Sgsnltg.net
後で拡張することが無い部分をswitchで書くのは全然問題無いと思うが。
どこにOOによる拡張性を持たせるかが問題になるから、要件とか設計からの要請で判断するべき。
Expression Problemで明確になることだけど、
OOPは子クラスを新たに追加するのは簡単な一方、新しいメソッドを追加するには既存のソースを変更しないといけない。
親クラスに共通の処理を書いたとしても、他と違うことをしたい子クラスの数だけ変更箇所が散らばる。
どの子クラスがオーバーライドしてるのかを把握するのに手間がかかるし、
追加するメソッドによってはクラス階層を更に分けてコピペを減らすべきかもしれない。
enumとswitchを使っている場合は逆になって、メソッドの追加や変更部分は一箇所にまとまっていて把握と追加が楽。
新しい種類のデータを追加するのは面倒。
ちなみにHaskellの型クラスやOCamlのvariant typeを使うとデータの種類も処理の種類も楽に増やせる。
Javaだとジェネリクスを使えばできないことはないけど、汚くなる。
160:デフォルトの名無しさん
16/06/02 00:42:37.96 qX3K4vQy.net
>>154
> 要件にしたがってテストしたけどコードがアホ過ぎて検知できない場合もあるとしてもどうしようもない。
だからそのどうしようもないことが、現実として起きてるんだよ。
開発者の言う「このコードは汚い」というのはそういうこと。
コードの無駄やコピペがあって、本来十分であるはずのテスト項目では
バグがないことを担保できない。
言い換えると、コードに問題がある場合のバグは、仕様書から起こしたテストでは検出できない。
バグが検出できない（問題ないと判断される）のだから、当然コードの問題もテストでは検出できない
> どうやって検知すんだ？って話。
コードレビュー以外にも検知する方法はあるぞ。
コードメトリクス（複雑度）の測定や
コードの重複の検出ツールなどを使えば良い。
161:デフォルトの名無しさん
16/06/02 00:45:18.72 IPFd2Mdr.net
>>157
コーダーがアホ過ぎたらそういうことも起きるって言ってるじゃん。
そこまでアホなコーダを想定してテストしろって要求するのはおかしいって話。
コーダーが犯すあらゆる過ち対応したテストを作成するのは不可能。
162:デフォルトの名無しさん
16/06/02 00:46:19.41 IPFd2Mdr.net
>>157
ツールがあるならコードを直そうね。
テストが漏れていると思うのはおかしい。
>コードレビュー以外にも検知する方法はあるぞ。
>コードメトリクス（複雑度）の測定や
>コードの重複の検出ツールなどを使えば良い。
163:デフォルトの名無しさん
16/06/02 00:48:15.80 55Jnw5v7.net
>>143
関係無いよね
チェック項目は増えてない
仕様書から起こす入力に対する正しい出力をチェックするだけ
164:デフォルトの名無しさん
16/06/02 00:50:43.52 qX3K4vQy.net
>>155
> コードレビューで問題が見つかったらコードを直すだけ。
> テスト漏れだとは思わない。
> もちろんテスト項目として追加するなら追加して。
> でも、テストが漏れていたとは思えない。
だからそういったじゃんｗ
正確にはテスト漏れじゃないが、開発者の書いたコードを素直に受け入れるならば、
コードによって問題がないことを担保するためのテスト項目は変わる。
コーディングによってテスト項目は変わるか？質問に対していうと、
「コードレビューで問題が見つかったらコードを直すだけ。」というならば
直さないならばテスト項目は変わるってことでしょう？
テスト項目を変えないためにコーディングを直すっていうのは、
テスト項目が変わる原因の一つがコーディングであると言ってるのと
微妙にニュアンスは違うけど、結果として殆ど変わらないよ。
165:デフォルトの名無しさん
16/06/02 00:53:04.14 qX3K4vQy.net
>>160
> 仕様書から起こす入力に対する正しい出力をチェックするだけ
それはなんのためにやっているの？
テストはバグを検出するためにやっていると思ったが、
コードに問題があると、バグを検出できないってことだよね？
166:デフォルトの名無しさん
16/06/02 00:53:06.73 IPFd2Mdr.net
>>161
コーディングによってテスト項目は変わるか？云々は知らない。
お前が言ってることがおかしいってだけ。
テスターは要件の境界線をテストする。
コードが異常な境界線を基準としていたためにバグを見逃していたとしてもテスターの責任ではない。
どうしようもない。
167:デフォルトの名無しさん
16/06/02 00:58:20.11 55Jnw5v7.net
>>163
それも違う
境界なんてものは存在しない
本来は取り得る値すべてをチェックしなければならない
でも客とテスターの間の取引で暗黙に間引いてるってだけの話
168:デフォルトの名無しさん
16/06/02 00:59:05.09 qX3K4vQy.net
>>163
だから責任問題の話なんかするつもり無いってばｗ
どんなコードであっても、同じテストをすれば
同じ品質（バグがない）を担保できるような話をしてるから、
同じテストをしたとしても（そのテストに漏れがなかったとしても）
コードにバグがないことを担保できないし、
コードの品質も同じにはならないよって話をしてるんだよ。
コードが悪ければ、品質を保つために必要なテスト項目は増えるし、
コードを直すことで、必要なテスト項目は減る。
（正確に言えば仕様書から起こした本来の最低限のテスト項目だけで済む）
169:デフォルトの名無しさん
16/06/02 01:01:46.10 IPFd2Mdr.net
>>165
責任だけの話じゃない。対応のしようがないって話。
要件上引数は正の数でなければならないとする。
ところがコードがアホで引数が100だとバグが発生するとする。
テストではそれが分からなかった。
どうすんの？って話。
170:デフォルトの名無しさん
16/06/02 01:03:06.15 55Jnw5v7.net
>>165
何度も言うけどソースコードからテスト項目は増えない
ソースからテスト仕様書作ってる会社なんてないだろうよｗ
171:デフォルトの名無しさん
16/06/02 01:07:07.95 T7FoO03Y.net
だんだん
ID:qX3K4vQy
ID:IPFd2Mdr
の主張がこんがらがってきた……
172:デフォルトの名無しさん
16/06/02 01:08:17.44 qX3K4vQy.net
>>166
だからテストとは別にコードレビューをテスト前に行い、
悪いコードをあらかじめ直すしかないだろ？
俺が品質ベースで考えてるから話がずれてるのか？
俺はバグがないようにすることを目標として
どんなテストが必要か？を考えてる。
だからバグを無くすためには、コードによって必要なテスト項目が変わってくる。
そしてコードを良くすることで、必要なテスト項目が減るという話をしてるんだよ。
仕様書からテストを起こすっていうのは、当然コードは見てないから
必要な（最低限の）テストは何か？だけを考えてる。
テストの効果（バグを見落とすかどうか）は考えておらず、
その効果はコードによってばらばらで、テストしてもバグを検出できるとは限らない。
この場合のテストの目的は何なんだろうかねｗ
173:デフォルトの名無しさん
16/06/02 01:08:59.38 IPFd2Mdr.net
>>169
うん。だからコードを直そうね。
テスト漏れじゃないね。
174:デフォルトの名無しさん
16/06/02 01:12:05.80 qX3K4vQy.net
>>167
> 何度も言うけどソースコードからテスト項目は増えない
それはテストの効果（バグがないことの担保）
を無視すればそうなるよね。
ソースコードからテスト項目は増えないが
ソースコードが悪ければ、その増えないテスト項目では
バグを見逃す可能性が高くなる。
テストの効果を低くしていいならば、
テスト項目は増やさなくていいよ。
そしてソースコードが汚いならばソースコードの方を直すんだろう？
なぜなら、ソースコードが汚ければテスト項目を
増やさなければならなくなるから（アレ？ｗ）
175:デフォルトの名無しさん
16/06/02 01:12:26.96 T7FoO03Y.net
俺の理解
ID:qX3K4vQyの主張はコードからテストケース作る
ID:IPFd2Mdrの主張は設計書からテストケース作る
コードが設計書に書かれてることを満たしてるかどうかって
コードから作ってたらわからないのでは……って疑問が……
なぜかコードだけ、設計書だけの0か100かに見えてしまってるので
勘違いしてたらごめん
176:デフォルトの名無しさん
16/06/02 01:13:23.53 qX3K4vQy.net
>>170
> うん。だからコードを直そうね。
> テスト漏れじゃないね。
コードを直さないとどうなる？
同じ品質を保つにはテストを増やす必要があるよね？
えーと、それがコーディングによってテスト項目は
変わるってことだよねｗ
コーディングによってテスト項目が増えるから
コーディングを直すんだよね？ｗ
177:デフォルトの名無しさん
16/06/02 01:14:50.74 55Jnw5v7.net
>>169
どうにでも好きなように組んだらいいよ
チェック項目は変わらない
オブジェクト指向でも関数型でも
これが設計の本質だ
単にソースコードに書く場所が違うだけ
それがオブジェクト指向
こんなもんにマジになっちゃってどうするの?
っていうIT業界の黒歴史
178:デフォルトの名無しさん
16/06/02 01:16:20.73 IPFd2Mdr.net
>>173
>>166
そりゃバグがあることが判明したらテストを追加すべきだろうね。
でも、そもそもテストが不足していたということじゃないね。
179:デフォルトの名無しさん
16/06/02 01:18:59.63 qX3K4vQy.net
>>172
俺の意見としては、テストとは別にコードレビューが必須であるということ。
仕様書からテストをおこすのは問題ないんだが、
そのテストで品質が保てるかどうかは
コードで左右される。
コードが汚ければいくらまともなテスト行ったとしても
それで品質を保つことは出来ない。
俺は品質を保つことを第一に考えてるので
コードを直さずに品質を保つならばテスト項目�
180:ｪ増えてしまうという話をしてる。 だからテスト項目を増やさずに品質を保つために、コードを直しましょうという話をしている。 で、最初の疑問「コーディングによってテスト項目は変わるか？」の 答えは、（品質を保つことを前提にすると）コーディングによってテスト項目は変わる。 悪いコードだと（品質を保つために）テスト項目が増えてしまう。だからコーディングを直しましょう。
181:デフォルトの名無しさん
16/06/02 01:21:24.41 IPFd2Mdr.net
>>176
コードレビューで仕様の境界とは違うところで問題が見つかったらコードを直すだけ。
そんなのテスト作成とは関係ない。
182:デフォルトの名無しさん
16/06/02 01:23:15.23 qX3K4vQy.net
>>175
> そりゃバグがあることが判明したらテストを追加すべきだろうね。
リリースした後で、バグが有りました。すいません。ですむ会社なら
それでもいいけどさぁｗ
「ちゃんとテストしたの？」の答えに
テストは不足していません！ちゃんとテストしました！
ちゃんとテストしたのに、コードが悪かったんです！
ですむなら、それでもいいけどさぁｗ
理想の世界であれば、テストが不足してないのは事実だろうが、
そのテストで十分であるためには、コードが綺麗でなければならず、
コードが汚ければ、多くのテストが必要になるから
コードレビューをして綺麗なコードにしましょうや。
それができて初めて、テストする意味が生まれる。
183:デフォルトの名無しさん
16/06/02 01:24:18.99 qX3K4vQy.net
>>177
> コードレビューで仕様の境界とは違うところで問題が見つかったらコードを直すだけ。
だから何度もそう言ってるだろうが。
人の話聞けよｗ
184:デフォルトの名無しさん
16/06/02 01:24:53.24 IPFd2Mdr.net
>>178
だからさ、要件の境界とは違うところでコードがアホ過ぎるせいでバグがあったとして見つける手段は？
見つける手段がないのに直そうと言っても意味ない。
185:デフォルトの名無しさん
16/06/02 01:25:55.40 IPFd2Mdr.net
>>179
？？
だったらいちいち反論すんなよ。
186:デフォルトの名無しさん
16/06/02 01:26:39.31 qX3K4vQy.net
俺がはテストが足りないって言ってるんじゃないんだぜ？
品質を保つことを前提にするならば、
コードが汚ければ、品質を保つために必要なテストが増えてしまうから、
まずコードレビューしてコードを綺麗にしましょうって話。
コードが綺麗な状態であって初めて、仕様書から起こしたテストで十分だと言える。
187:デフォルトの名無しさん
16/06/02 01:29:14.56 qX3K4vQy.net
>>181
> だったらいちいち反論すんなよ。
お前が反論してるんだろｗ
っていうかお前のは反論じゃない。
俺が言っていることと違うことをぶつけているだけ。
俺が言ってるのは、コードが汚いならば（品質を保つために）
必要なテストは増えるって話。
コードが汚くても、テストは増やさないで品質が保てるような
話をしているから、その発想は抜けがあるよってこと。
188:デフォルトの名無しさん
16/06/02 01:29:26.96 soSMk704.net
そんなときこそユニットテスト
コード改変の前後でエンバグしたかどうかがすぐわかります
なおユニットテストそのものの品質を保つかが課題
189:デフォルトの名無しさん
16/06/02 01:30:23.03 T7FoO03Y.net
>>176
了解
回答ありがとう
190:デフォルトの名無しさん
16/06/02 01:30:30.71 qX3K4vQy.net
>>180
> 見つける手段は？
それもテスト前にコードレビューするって何度も言ったはずだが？
汚いコードは直さないと、テストした所で効果は低い
191:デフォルトの名無しさん
16/06/02 01:31:11.16 IPFd2Mdr.net
>>183
本来的にはテストは要件にしたがって動作することを確認するためのもの。
コードがきれいか汚いかとか関係ない。
192:デフォルトの名無しさん
16/06/02 01:32:06.67 IPFd2Mdr.net
>>186
コードレビューで見つかったなら直せ。以上。
テストとの直接の関係はない。
193:デフォルトの名無しさん
16/06/02 01:33:09.51 qX3K4vQy.net
>>187
> 本来的にはテストは要件にしたがって動作することを確認するためのもの。
その確認の手間がコードによって変わってしまうんだよ。
すでにコードで例示したけど？
194:デフォルトの名無しさん
16/06/02 01:33:30.12 dD1ozz1q.net
Haskellならテスト要らないですよ？
コンパイルできた時点でバグが無いことが保証されるから。
195:デフォルトの名無しさん
16/06/02 01:34:23.43 IPFd2Mdr.net
>>189
コードがアホなだけ。テストではどうしようもない。
と結論が出てる。
196:デフォルトの名無しさん
16/06/02 01:34:39.66 55Jnw5v7.net
>>189
だから変わらないって
本来は取りうる値の範囲をすべてチェックするんだから
197:デフォルトの名無しさん
16/06/02 01:34:52.13 qX3K4vQy.net
>>188
「直接の関係はない」ってことは
やっぱり間接的に関係があるって認めるんだｗ
そりゃコードによって品質を保つための
テストは変わりますからねｗ
バグが有るかどうか知ったこっちゃない。
俺はテストをちゃんとやった。
テストしたのに漏れたのはコードが悪いんだ！
ですむなら良い世界だねｗ
198:デフォルトの名無しさん
16/06/02 01:35:31.60 55Jnw5v7.net
勝手に間引いてるのはテスターの責任
199:デフォルトの名無しさん
16/06/02 01:36:12.80 IPFd2Mdr.net
>>193
コードレビューで問題が見つかったらテストケースを追加してもいいよねってだけ。
200:デフォルトの名無しさん
16/06/02 01:36:59.90 dD1ozz1q.net
これからは関数型ですよ。
Haskell以外淘汰されます。
201:デフォルトの名無しさん
16/06/02 01:37:36.91 IPFd2Mdr.net
>>196
Haskellとか既に淘汰されてるんだが。
202:デフォルトの名無しさん
16/06/02 01:38:47.83 qX3K4vQy.net
>>192
> 本来は取りうる値の範囲をすべてチェックするんだから
うん、ネタなのは分かってるよ（笑）
分かってて聞くけど、ある数値を二乗する関数があったとして
Rubyで取りうる値の範囲はどうなるかい？
なんでRubyと言ったかというと、RubyではIntの範囲を超えると
自動的にBignumに拡張されるからとても大きな整数を扱えるんだぜ！
203:デフォルトの名無しさん
16/06/02 01:39:44.45 qX3K4vQy.net
>>195
> コードレビューで問題が見つかったらテストケースを追加してもいいよねってだけ。
誰がやんの？ テスターのお仕事？
204:デフォルトの名無しさん
16/06/02 01:40:36.22 IPFd2Mdr.net
>>199
コードレビューって自分で言ったんだから知ってるだろ。
分かってることをいちいち聞くな。
205:デフォルトの名無しさん
16/06/02 01:40:47.43 dD1ozz1q.net
Haskell使えばテスト必要ないですよ？
206:デフォルトの名無しさん
16/06/02 01:42:30.76 55Jnw5v7.net
スレの本題にくっつけると
コードの記述方法でチェック項目は変わらない
つまりオブジェクト指向でも関数型でも品質は上がらない
言い換えればコードの記述方法で品質は上がらない
品質を上げるにはしっかり仕様書を書いて
しっかり書いた仕様書からテスト仕様書を起こすこと
ソースの記述方法は品質を決定する計算式に入ってません（笑）
おｋ?
207:デフォルトの名無しさん
16/06/02 01:43:13.49 qX3K4vQy.net
>>200
せやね。
コードが悪ければコードレビューで
テスト項目が追加される。
コードが悪ければ、テスト項目が追加される。
おや？
コーディングによってテスト項目が変わるって話に戻ったか。
208:デフォルトの名無しさん
16/06/02 01:44:21.91 IPFd2Mdr.net
>>203
「追加してもいい」
この意味が分からんの？
日本語からやり直せ。
209:デフォルトの名無しさん
16/06/02 01:46:16.79 55Jnw5v7.net
今回もオブジェクト指向が幻想技術ということが決定したな
210:デフォルトの名無しさん
16/06/02 01:46:33.24 IPFd2Mdr.net
>>205
基地外
211:デフォルトの名無しさん
16/06/02 01:47:36.18 3RkkmY6H.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つになるわけだが、ここまでの話で明らかなように
「コーディングの仕方でテスト項目は変わる」というか「悪いコードだとバグがないことを担保するためのテスト項目は増える」
212:デフォルトの名無しさん
16/06/02 01:49:05.94 3RkkmY6H.net
何だ俺、最初から一貫して同じこと言ってるやんｗ
213:デフォルトの名無しさん
16/06/02 01:50:22.82 55Jnw5v7.net
>>207
だからvalの取りうる範囲チェックするだろ
中間値だけとか間引くのはテスターが勝手にやってるだけの話
チェック項目は変わらない
214:デフォルトの名無しさん
16/06/02 01:51:43.92 3RkkmY6H.net
>>209
だから、そのvalの取りうる値ってなんだよ？ｗ
>>198の質問にも答えてないぞお前ｗ
215:デフォルトの名無しさん
16/06/02 01:53:10.76 ehI/NdEG.net
>>176
完全に横だが、、、
そちらの意見自体に文句はない。つまり、コード品質最優先で同意だ。
付け加えるとしたら、>>143の例ならカバレッジで確認できる。
つまりC1(方言かもしれんが各分岐）まで含めれば例示されたバグは落とせる。
あと、仕様から起こしたテストを一通りやらないと「実装忘れ」を検出できない。
例えば、関数電卓を作ったとして、色々ある関数の一つを実装し忘れたとか。
実装漏れをテストではなくコードレビューで落とすことは出来るが、これはポリシーの問題となる。
仕様から起こしたテストで品質が上がるかというと、多分無理だ。これは競合を落とせない。
各競合を全部コードレビュー時にテストに追加するという手もあるが、これは追加漏れが発生する。
だから品質を上げるためには結局ランダムテストしかないと俺は思っている。
216:デフォルトの名無しさん
16/06/02 01:55:40.16 55Jnw5v7.net
>>210
仕様書に書いてあるだろ?
ないの?
そしたら不具合ですらないんじゃない?
217:デフォルトの名無しさん
16/06/02 02:01:57.34 IPFd2Mdr.net
>>211
カバーできてないことが判明
コードを直す
テストを追加するかは任意
218:デフォルトの名無しさん
16/06/02 02:03:26.51 IPFd2Mdr.net
>>211
ランダムテストって謎。
ランダムテストでアホなコードが漏れたらって話だろ。
なんでランダムテストさえすればアホなコードがすべて網羅できるって前提なんだよ？
219:デフォルトの名無しさん
16/06/02 02:25:10.08 ehI/NdEG.net
>>213-214
いや、複数箇所に冗長に記述があった時、それらが整合しているかだろ？
見た瞬間分かればいいけど、クラスをまたいでいたりすると単純には削除できないケースもある。
この場合はカバレッジ100%なら整合している可能性が高い事は言える。
（ただし二重に冗長な場合は無理だが）
ランダムテストは動作の確認とカバレッジを稼ぐため。つまりバグの検出。
ランダムテスト自体では「品質の高い＝美しいコード」は得られない。
ただ、コードの品質って大前提として「バグがないこと」だろ？(コードが美しいことではなくて)
これについてはランダムテストが一番だと思っている。
すまんがもう寝る。
220:デフォルトの名無しさん
16/06/02 03:00:45.20 dD1ozz1q.net
あ、逃げた。
221:デフォルトの名無しさん
16/06/02 04:13:03.69 soSMk704.net
マジレスするとECPで大抵のテスト分けは解決できる
あとは重箱の隅をつつく価値があるかどうか
222:デフォルトの名無しさん
16/06/02 04:24:49.52 dD1ozz1q.net
マジレスするとHaskell使えばテストは必要ない。
テストでバグを発見できるというのは甘え。
223:デフォルトの名無しさん
16/06/02 06:09:23.71 a5hqyyy7.net
そう
Haskellを使っていれば交通事故を起こさない自動車だって作れた
なお完成は２４世紀ごろを予定しております
224:デフォルトの名無しさん
16/06/02 06:54:53.87 ehI/NdEG.net
すまぬ。「ランダムテスト」は方言で、標準語ではどうやら「自動テスト」と呼ばれるようだ。
(モデルを作成し、ランダムな入力を食わせて出力をチェックする）
混乱させてすまん。
225:デフォルトの名無しさん
16/06/02 08:36:32.58 jj0I32l4.net
>>207
＞たとえば数値が偶数か奇数かを文字列で返す関数があったとしよう。
＞これのチェック項目はfoo(0)とfoo(1)の2つで十分だろう。
充分じゃない、テスト仕様書がそうなってたらテスト仕様書書いた奴氏ねって言っていい、コードがどうなっているかはこの時点では関係ない
226:デフォルトの名無しさん
16/06/02 09:21:14.08 qVro3+K+.net
>>218
あんたHaskell信者に見せかけたアンチだろｗ
HaskellにはHaskellの良さがあるけど、俺は結局C++に戻ってきた。
最近はCまで戻ろうかと検討してる。
もしくはLispを試してみようかなと。
227:デフォルトの名無しさん
16/06/02 09:59:19.16 9Sgsnltg.net
設計=仕様書から書けるテストはブラックボックステストで、
コードから書けるテストはホワイトボックステスト。
ブラックボックステストで全ての取りうる値を入力するなんて非現実的だから、境界条件を考慮してテストセットを作る。
ホワイトボックステストはどれだけ網羅するかにもよるけど、条件分岐があったらその全てを通るテストセットを作る。
テストで得られる保証の度合いで言うならホワイトボックス>ブラックボックスなのは確かだけど、
中身まで見れる状態になっていないとホワイトボックステストは書けない。
開発プロセスがトップダウン方式だったりテスト駆動開発だと、書けるテストはブラックボックステストにならざるを得ない、という現実的な話。
そこで満足するか、更なる品質保証のためのホワイトボックステストを書くかはコストと相談しましょう。
Haskellでも同じ。テストを書く必要が無いのは依存型やRefinment typesを使える言語だけ。
228:デフォルトの名無しさん
16/06/02 10:42:12.02 x8NBN55x.net
>>182
> コードが綺麗な状態であって初めて、仕様書から起こしたテストで十分だと言える。
その仕様書とやらが、コードをC0カバレッジできるレベルで書かれてるならそうだろうな。
229:デフォルトの名無しさん
16/06/02 10:43:30.50 x8NBN55x.net
>>220
> すまぬ。「ランダムテスト」は方言で、標準語ではどうやら「自動テスト」と呼ばれるようだ。
いや、呼ばれない。自動テストとはマニュアルテストの反語。
230:デフォルトの名無しさん
16/06/02 10:58:37.56 HMnON+Ay.net
>>220
QuickCheckって呼んでるわ
231:デフォルトの名無しさん
16/06/02 10:59:58.45 qVro3+K+.net
俺もそれのことかなと思った。
data-driven testing toolと呼ぶらしい。
232:デフォルトの名無しさん
16/06/02 11:24:00.72 tJT0ttjQ.net
>>223
ある条件判定がfalseになったんだけど
それが正しいか間違ってるかってどうやって判定すんの?
ソースコードだけにその答えがあるの?
233:デフォルトの名無しさん
16/06/02 11:30:53.69 x8NBN55x.net
>>228
> ある条件判定がfalseになったんだけど
> それが正しいか間違ってるかってどうやって判定すんの?
もっと具体的に。
234:デフォルトの名無しさん
16/06/02 12:11:08.77 tJT0ttjQ.net
>>229
if（val==false）
235:デフォルトの名無しさん
16/06/02 12:34:31.31 j1kGed0y.net
朝。
さんさんと照り付ける太陽がS2715Hに映り込む。
純度100%のグレアモニター、S2715Hに自分の影がシャープに映り込むと、一日が始まる。
見ているものが正確で、映っているものは色が正確で、光量も正確。
よい生活はよい製品から得られる。
236:デフォルトの名無しさん
16/06/02 12:46:55.06 x8NBN55x.net
>>230
それは一体どこの話なんだ？
そもそも、（単体/unit）テストが何なのか理解してるか？
237:デフォルトの名無しさん
16/06/02 12:48:55.39 tJT0ttjQ.net
>>232
unkoクラスのgetPPメソッド
238:デフォルトの名無しさん
16/06/02 12:50:25.29 soSMk704.net
ifの中で真偽値と比較するコードなんて捨ててしまえ
239:デフォルトの名無しさん
16/06/02 12:54:33.11 x8NBN55x.net
>>233
ということであれば、単体/unitテストでは、正しいも間違っているも判定しない。
240:デフォルトの名無しさん
16/06/02 14:26:28.50 fuTkOmr9.net
このように意味のないことを堂々巡りに考えるのがOOP脳患者
無駄なことに時間を費やしたくない人は
OOPが得意な部分だけを上手に利用することだけを考えておけばよい
ほとんどの実用的な言語がマルチパラダイムを選択していることからもわかる通り
当たり前に得手不得手があるし
一つの考え方だけでうまくいくほど世の中単純ではないことは子供以外は誰でも知っている
241:デフォルトの名無しさん
16/06/02 16:51:41.22 9Sgsnltg.net
>>228
コードだけ見て判断できるものもあるし、仕様書読まないと判断できないものもあるとしか言えない。
どっちを参照しても分からないなら作った人に聞くべきだけど、それはテストじゃなくてレビューになる。
それとも仕様書無しでソースあり、さあテストを書けって場合を考えている？
そんな苦役を振られたら、仕様書を作って欲しいのか確実に動かないバグを潰して欲しいのか確認するところから始めましょう。
242:デフォルトの名無しさん
16/06/02 18:22:00.20 55Jnw5v7.net
>>237
いや、オブジェクト指向だとテストが減るとか言ってるアホがいたから
243:デフォルトの名無しさん
16/06/02 19:13:46.82 IPFd2Mdr.net
>>238
オブジェクト指向の目的聞かれて回答しないままトンずらした奴だろ。
244:デフォルトの名無しさん
16/06/02 22:51:27.39 3RkkmY6H.net
>>212
> 仕様書に書いてあるだろ?
仕様書には「整数」って書いてあるけど、
そしたら、無限にある整数を全部テストしろって話でしょう？ｗ
245:デフォルトの名無しさん
16/06/02 23:08:39.30 soSMk704.net
そんなときこそFormal methods
複雑になるとUndecidableなのが玉に瑕
246:デフォルトの名無しさん
16/06/02 23:26:10.98 55Jnw5v7.net
>>240
駄目な仕様書だな
上限も下限も定義されてないでモノなんて作れっかよ
全く仕事やってない証拠
オブジェクト指向なんかどうでもいいから
設計書きっちり書けよって話
247:デフォルトの名無しさん
16/06/02 23:37:42.96 3RkkmY6H.net
>>242
> 駄目な仕様書だな
> 上限も下限も定義されてないでモノなんて作れっかよ
作れるだろ？Pythonは無限リストを作れるのが特徴だ。
無限リストには上限も下限もない。
248:デフォルトの名無しさん
16/06/02 23:40:01.75 3RkkmY6H.net
RubyのBigNumも上限も下限もないな。
URLﾘﾝｸ(docs.ruby-lang.org)
あえて言えばメモリサイズによる制限は受けるが、
じゃあメモリサイズいっぱいの桁数の数値（何桁だと思う？ｗ）を
全部テストするのかとｗ
249:デフォルトの名無しさん
16/06/02 23:58:48.20 fuTkOmr9.net
ほら頭悪いでしょ
250:デフォルトの名無しさん
16/06/03 00:01:57.95 57ESL53T.net
>>245
仕方ないんじゃないかな？
馬鹿なんだからそういういちゃもんを付けるしかないんだと思うよ。
251:デフォルトの名無しさん
16/06/03 00:04:49.79 fpUAqgyP.net
そもそもテストを行う実時間の問題だから
組合せ爆発でも起こしたら、本当に何万年とか
かかってしまうのがテストなんだよね。
仕様書に上限や下限をつけた所でなんの対策にもなっていない。
252:デフォルトの名無しさん
16/06/03 00:08:30.87 LbxBbQld.net
下限や上限が決まっていたら、閾値界隈のテストできるでしょ
下限も上限も決まってなかったら本当にテストできない
下限も上限も決めないのは馬鹿
253:デフォルトの名無しさん
16/06/03 00:24:19.96 4VbjelCP.net
今話をしてるのはテストを行う実時間の話。
上限や下限が出てきたのは「整数」ではだめって文脈からだろ。
整数に上限や下限をつけた所でその範囲のすべての整数の
数は膨大なのだからテストに何万年もかかる。
そういう話をしてるのよ？わかる？
254:デフォルトの名無しさん
16/06/03 00:34:26.00 LbxBbQld.net
閾値近辺だけテストすりゃよいだろ
そりゃ君はクライアントに無限大を約束するらしいから無限のテストが必要なのかもしれないが
それは君だけの話であって
我々は上限を設けて、その範囲内でだけ動くことを約束するって言ってるんだから
閾値のチェックだけで済むわけだ
255:デフォルトの名無しさん
16/06/03 00:42:42.22 xWVfr+QL.net
ちょっとレベルが低過ぎる。
まったく意味がない話になってるからテストの話はいい加減にしろ。
オブジェクト指向設計と関係ないし。
256:デフォルトの名無しさん
16/06/03 00:55:16.41 4VbjelCP.net
>>250
上限下限がないならば、閾値の内側だけを調べればいいんだよ。
257:デフォルトの名無しさん
16/06/03 00:57:20.52 4VbjelCP.net
もう少し丁寧に書くわ
上限下限があるから、閾値近辺をテストしなければならないのであって、
上限下限がないならば、閾値近辺というのがそもそも存在しないので
任意の値でテストすれば十分
258:デフォルトの名無しさん
16/06/03 01:06:46.65 LbxBbQld.net
そんで、メモリが足りなくて動かなかった時のクライアントへの説明はどうなるの？
休日出勤するの？
入力の段階で「数値が大きすぎます、100未満にしてください」って弾いとけば
クライアントからしても何がダメだったか明確だろ
259:デフォルトの名無しさん
16/06/03 01:09:56.34 4VbjelCP.net
> そんで、メモリが足りなくて動かなかった時のクライアントへの説明はどうなるの？
なんでメモリの話が関係してくるんだ？
いみわからんｗｗｗ
260:デフォルトの名無しさん
16/06/03 01:10:26.17 4VbjelCP.net
> 入力の段階で「数値が大きすぎます、100未満にしてください」って弾いとけば
ある数値を二乗する関数があったとして
「数値が大きすぎます、100未満にしてください」ｗｗｗｗｗ
261:デフォルトの名無しさん
16/06/03 01:11:03.14 V5ojovFM.net
>>253
整数という条件だったら 0 とその前後、それから
SCHAR_MIN, SCHAR_MAX, UCHAR_MAX, SHRT_MIN, SHRT_MAX, USHRT_MAX
INT_MIN, INT_MAX, UINT_MAX, LONG_MIN, LONG_MAX, ULONG_MAX
LLONG_MIN, LLONG_MAX, ULLONG_MAX とその前後の48パターンくらいはテストしとけ
262:デフォルトの名無しさん
16/06/03 01:13:46.42 4VbjelCP.net
>>257
上限下限なくてもそれだけやればOKですよねｗｗｗ
263:デフォルトの名無しさん
16/06/03 01:42:13.61 V5ojovFM.net
>>258
> 任意の値でテストすれば十分
こんな事言うより100倍マシ
264:デフォルトの名無しさん
16/06/03 01:56:10.56 4VbjelCP.net
>>259
上限や下限がある場合は、その限界値で
動作を変えないといけないからテストする必要があるんだよ。
数学的に考えろ。nとn+1で何も違いがないならば、
そこはテストする必要ないんだよ。
265:デフォルトの名無しさん
16/06/03 02:08:57.65 V5ojovFM.net
もういいよ
266:デフォルトの名無しさん
16/06/03 02:20:08.63 4VbjelCP.net
いいならレスするなよｗ
267:デフォルトの名無しさん
16/06/03 02:53:40.31 aDP5A1Yp.net
結局>>217のECPと>>241のFormal methodsで済むところを
何レスも消費するんだから君たちはｗ
268:デフォルトの名無しさん
16/06/03 07:25:35.73 G3tCMEbl.net
オブジェクト指向はなんの品質も上げないカス技術って現実を直視しろよ
269:デフォルトの名無しさん
16/06/03 10:24:41.45 OvJcIN1K.net
>>264
じゃあ、どの技術が良いの？
270:デフォルトの名無しさん
16/06/03 12:36:11.91 PZUaPR2n.net
c++のオブジェクト機構をカス技術と言うのなら微妙にYes.
品質の向上≒自由度の制限って関係が成り立つので
c++は自由度が大きすぎて使用者が意識して制限しないと
容易に巨大なウンコが出来上がる
271:デフォルトの名無しさん
16/06/03 13:01:13.49 c8+13QXR.net
> オブジェクト指向はなんの品質も上げないカス技術って現実を直視しろよ
>>264 みたいなバカが使うとね w
272:デフォルトの名無しさん
16/06/03 13:17:35.90 LK0McYVX.net
>>264
煽るのもいい加減にしろ
己のキンタマでもかいて、糞して寝ろ
273:デフォルトの名無しさん
16/06/03 13:37:19.72 TPst5vg3.net
>>265
プログラムを組める設計書や仕様書を書く技術
設計書や仕様書通りにプログラムを組む技術
雑誌やインターネットには載ってないけど
一番大事な技術です
274:デフォルトの名無しさん
16/06/03 13:39:23.11 xWVfr+QL.net
具体的な例で意見交換しようとしてもさぼってUMLすら書かない。
抽象的な話をすると言葉尻と曲解に基づいて無意味な言い争いをする。
なかなか意味のある会話にならないなあ。
少し前提に帰ると設計のときはUMLあるいはなんらかのモデリングをしてるよな？
モデリングすらしてないで書き込んでる中学生がちらほら見受けられるのは生暖かく見守るとして
しっかりモデリングしてる印象を受けないんだが。
275:デフォルトの名無しさん
16/06/03 13:41:55.04 xWVfr+QL.net
>>269
>>264-265のやり取りに対する回答になってない。
まともなコミュニケーションすらできない中学生がいきがってるのはかっこ悪いぞ。
276:デフォルトの名無しさん
16/06/03 14:01:30.68 3R6cnOzA.net
>>254
なぜテストする側の都合で制限かけるんだ？休日出勤したくないから機能制約かけます？
話題にあった整数だってint全件でも2^32だぞ
drawText(String str)
str : ラテン語小文字(a - z)10文字まで
お望み通りすごい制限つけたぞ、10文字しか入力できない、しかもラテン小文字のみw
でテストケースは26^10
どっちが多いか分かりますか？
取りうる範囲の広さなんて関係ないんだよ
現実的に全件網羅テストできる場合の方が少ないんだから
限定的な組み合わせで最大限の効果があるものは何か？ってのを考えるのが筋だろ
277:デフォルトの名無しさん
16/06/03 15:08:06.73 OvJcIN1K.net
>>269
どゆこと？
オブジェクト指向の設計をしないとして、どういう手法の設計が
良いのか聞いたんだけど。
それと一番なのは人間を上手に使う技術でしょ。
雑誌やインターネットには載ってないけど、皆知ってることだよ。
278:デフォルトの名無しさん
16/06/03 15:40:36.20 xWVfr+QL.net
>>273
人間を上手に使う技術が設計で一番大事って…。
無能を何人管理しても無駄でしかないのが設計というもの。
279:デフォルトの名無しさん
16/06/03 15:45:
280:03.44 ID:xWVfr+QL.net
281:デフォルトの名無しさん
16/06/03 15:52:47.06 TPst5vg3.net
>>273
なんて言うんかな?
オブジェクト指向設計をしないでってのが正確かも
こいつはソフトウェア開発の歴史の中でもゴミ中のゴミ
普通に仕様書（こう動きます）書いて
データフロー図書いて
処理の入力、出力書いて
データのフォーマット（DB含む）書いて
シーケンス図とか状態遷移図書いて
って昔ながらのソフトウェア開発だけでいいよ
クラス設計するな
もしくは最後に回せ
それだけでうまく行くと思う
282:デフォルトの名無しさん
16/06/03 15:53:19.52 TPst5vg3.net
>>275
それじゃ金出す人いないよ（笑）
283:デフォルトの名無しさん
16/06/03 15:56:54.09 xWVfr+QL.net
>>276
それじゃ複雑な機能の整理が難しいんだよ。
ちょっと前に出てた>>129-130に対する設計案を作ってごらん。
284:デフォルトの名無しさん
16/06/03 15:57:42.23
285: ID:xWVfr+QL.net
286:デフォルトの名無しさん
16/06/03 16:55:55.15 iJVPPkrY.net
作ってごらんとか
287:デフォルトの名無しさん
16/06/03 17:23:11.56 OvJcIN1K.net
>>274
有能だろうが無能だろうが面従腹背されたら何の成果も出せない。
部下の能力・特性に合わせて仕事を振って上手に使うことこそが
一番大事な技術。設計書とか仕様書の書き方はその次。
>>276
ゴミ中のゴミが世の中の主流になれるわけがないだろｗ
もしかして自分がオブジェクト指向設計ができないからって
ディスってるだけじゃないだろうな？
288:デフォルトの名無しさん
16/06/03 18:20:54.89 G3tCMEbl.net
>>281
少なくともオブジェクト指向でテスト項目が減るとか品質が上がるとか言ってたクズよりは理解はしてると思ってまつよ
289:デフォルトの名無しさん
16/06/03 18:37:03.25 xWVfr+QL.net
>>281
無能な奴を従わせても無意味なんだよ。
それにその口調だとお前自身は設計能力がないだろ。
能力がない奴ほど人の管理と言うよね。
290:デフォルトの名無しさん
16/06/03 18:39:05.80 xWVfr+QL.net
>>282
で、>>278の回答は？
口だけかよｗ
291:デフォルトの名無しさん
16/06/03 18:57:10.17 OvJcIN1K.net
>>282
だったら、全否定の具体的な根拠を言ってみ。
理解してるなら当然、得意・不得意を理解してるだろうから簡単だよね。
>>283
どんな分野だろうと組織で仕事をするなら人間の制御が一番難しくて
重要なのは言うまでもない。
あんた設計以前に働いたことないのか？
それとも部下をもったことないのか？
292:デフォルトの名無しさん
16/06/03 19:02:51.57 xWVfr+QL.net
>>285
あのさー、もともと>>264-265の流れだろ。
設計技術について話してるのにどうして「組織で仕事」とかって出てくるの？
お前さあ、コミュニケーション能力が弱いよ。
そんなんでよく「組織で仕事」とか偉そうに言えると呆れる。
293:デフォルトの名無しさん
16/06/03 19:14:10.84 eHY6P3Rv.net
設計てクラス構成まで考えないなぁ
業界によるんだろう
294:デフォルトの名無しさん
16/06/03 19:17:02.92 xWVfr+QL.net
>>287
クラス構成を考えないオブジェクト指向設計プロセスなんて聞いたことないけど
誰が提唱してんだ？
295:デフォルトの名無しさん
16/06/03 19:28:25.70 eHY6P3Rv.net
>>288
誰も提唱してないと思うけど
Webだからかapiの仕様決めたら実装に入っちゃうな
ドワンゴやtwitterの活用事例なんかを聞いてもクラス構成まで設計するとはあんま聞かないからwebは緩いんだと思う
296:デフォルトの名無しさん
16/06/03 19:36:08.48 xWVfr+QL.net
>>289
単純なWebシステム限定では。
297:デフォルトの名無しさん
16/06/03 19:44:25.76 eHY6P3Rv.net
>>290
権限周りは割りと複雑だなー
仕様自体はしっかり詰めといてるし
Scalaの表現力と型安全性のおかげで割りと綺麗になってるしdocとテストは書いてる
関数型の設計てのは聞かないし
298:デフォルトの名無しさん
16/06/03 19:48:21.01 xWVfr+QL.net
>>291
権限周りが複雑だと思ってるだけで客観的に見たら大したことないんだろ。
複数のクラスが絡み合うような状況ならクラス設計が必要にならない訳がない。
299:デフォルトの名無しさん
16/06/03 19:52:01.46 eHY6P3Rv.net
>>292
ニコニコ動画の権限周り書き直した人もクラス図書いたとは聞いてないな
継続モナドを使って実装したって言ってた
300:デフォルトの名無しさん
16/06/03 19:52:37.00 eHY6P3Rv.net
認証だった
301:デフォルトの名無しさん
16/06/03 19:53:32.24 aDP5A1Yp.net
TDD・BDDでやってるからか最初にわざわざクラス図書いても結局かけ離れたものになる
302:デフォルトの名無しさん
16/06/03 19:54:00.85 xWVfr+QL.net
>>293
設計書は文章だけってこと？
図は？
303:デフォルトの名無しさん
16/06/03 19:57:21.13 eHY6P3Rv.net
表は書いたけど図は書いてない(うちの場合)
インフラ周りの構成は図を書いてる
304:デフォルトの名無しさん
16/06/03 19:57:58.75 xWVfr+QL.net
>>295
複数人が関わる場合、何かなけりゃ協業は不可能だと思うんだけど…。
どうしてるの？
305:デフォルトの名無しさん
16/06/03 20:02:05.59 aDP5A1Yp.net
強いて言うならコンポーネントレベルでパッケージ階層化かな
ここに関してはドキュメントあるし更新もされる
306:デフォルトの名無しさん
16/06/03 20:02:18.65 OvJcIN1K.net
>>286
>>269,>>283の流れだけど？
元々皮肉のつもりだったんだけどねｗ
てかお前のほうこそコミュ症じゃね？ｗ
307:デフォルトの名無しさん
16/06/03 20:07:09.66 xWVfr+QL.net
>>299
公開されてるメソッドも分からないのにどうすんだ？
308:デフォルトの名無しさん
16/06/03 20:09:46.25 xWVfr+QL.net
>>300
意味不明。
皮肉だかなんだか知らないけど、そもそもスレタイを関係ない会話をするのは
ほめられたことじゃないからやめようね。
309:デフォルトの名無しさん
16/06/03 20:13:31.79 xWVfr+QL.net
>>297
そんな会社もあるのか…。
多少なりとも複雑なプロセスがあるなら文章だけで正確に表現するように工夫するより
モデリングしちゃったほうがむしろ簡単じゃないかな。
310:デフォルトの名無しさん
16/06/03 20:13:43.10 eHY6P3Rv.net
guiプログラミングならクラス図欲しいかも
でもサーバーって状態が少ないからね
コントローラーがサービスをサービスがdaoを呼ぶみたいに関数を呼び感じになりやすいし
状態扱いたいならactorとか使うかな
311:デフォルトの名無しさん
16/06/03 20:17:06.64 aDP5A1Yp.net
>>301
公開されてるメソッドには全部ユニットテストあるし
結合テストにもユーザーシナリオを網羅するようにはしてる
312:デフォルトの名無しさん
16/06/03 20:19:12.10 xWVfr+QL.net
>>305
メソッドの一覧は？って話だぞ。
他の人が担当しているクラスを呼び出したいこともあるだろ。
メソッドが決まってなけりゃ作れないだろ。
クラスを作る側だって何を用意すりゃいいのか分からないし。
313:デフォルトの名無しさん
16/06/03 20:26:19.40 aDP5A1Yp.net
>>306
コンポーネント間のAPIはわかりやすくするようには努力してる
その下のクラスは基本単一責任だからそのクラスにどんなメソッドがあるかは何となくわかる
そもそもクラスやメソッドなんてリファクタリングでどんどん変化してくものだし
314:デフォルトの名無しさん
16/06/03 20:31:12.76 xWVfr+QL.net
>>307
プログラムって何となくでどうにかなるものじゃないだろ。バグ量産だと思うぞ。
どんどん変わってちゃ工数が増えるし。
開発チームは何人くらいで期間はどのくらい？
開発者が多いプロジェクトでリファクタリングでどんどん変化するというのは不可能だと思うんだけど。
315:デフォルトの名無しさん
16/06/03 20:35:06.28 7emugrZg.net
そのためのテスト
後そのためのレビュー？
316:デフォルトの名無しさん
16/06/03 20:42:25.76 aDP5A1Yp.net
一つのコンポーネントにつき5、6人のチームだけど2つのチームに入ってるメンバーもいる
アクティブに開発されてるコンポーネントは今は3つくらいかな
スクラムなんで2週間のイテレーションをぐるぐる回す
もちろんレビューもあるけど、そもそもテスト全部通らないとコミット&デプロイできないようになってるから
バグ量産ということはないかな
317:デフォルトの名無しさん
16/06/03 20:42:40.50 xWVfr+QL.net
>>309
テストが自動化されていてもコーディングを変更する手間はかかるし
メソッドが変わればテストも変更必要になるんだが。
318:デフォルトの名無しさん
16/06/03 20:45:59.26 xWVfr+QL.net
>>310
コンポーネントの単位は？
クラス、コンポーネントをまたがる場合、クラスが事前に明確になってないのに
どうやって開発するんだ？
テストは何を見て開発するのか？
319:デフォルトの名無しさん
16/06/03 20:49:30.78 OvJcIN1K.net
>>302
話膨らませてきたのおまえだろｗ
ほんとコミュ症だなｗ
今後は無駄に突っかかってくるの辞めようねｗ
320:デフォルトの名無しさん
16/06/03 20:51:52.67 xWVfr+QL.net
>>313
「人の管理」だの「組織の仕事」だのお前以外の誰が言ってんだよ？
読み直してから書き込めよ。
頭おかしい奴みたいだから相手するのやめる。
レスつけられても無視するから。
321:デフォルトの名無しさん
16/06/03 20:55:39.30 c8+13QXR.net
外部に公開してるメソッドがころころ変わるとか
どうみてもニートが妄想全開で書いてるだけ
そもそも TDD やってたらテストから書き直しになるしな
322:デフォルトの名無しさん
16/06/03 20:59:39.13 aDP5A1Yp.net
>>312
コンポーネント化の判断基準は他のプロジェクトでも再利用できるんじゃね？(するとは言っていない)
最初にわかればいいんだけど後々分割することもあった。多分これが一番労力かかる
一つのユーザーストーリーがそのままテストになる。
>>315
もちろんテストもリファクタリングするけど
それが負担になるような現場はテストの書き方がなってないと思うよ
xUnit test patternsを読むべし
323:デフォルトの名無しさん
16/06/03 21:05:16.92 PB6+Z1HI.net
>>284
>>282じゃないが将棋は手の評価ロジック自体が本体であり全てみたいな感じだからOOPに向いてないと思うよ
OOPL前提で書くにしても駒に合法手の問い合わせなんかしない、盤面も移動範囲も整数配列でいい
以前遊びで組んだのはこんな感じだった
思考モジュール
※ルールと棋譜DB盤面テーブルなどをコンポジットしたクラス
・盤面テーブル =11×11の整数2次元配列+手駒リスト
→※駒の種別や盤外、効きの有無、成り、どちらの駒か等全てここにビットフラグで持つ
→9×9でないのは外周を外周を示す駒で埋める事で外周かどうかの判定を省くため
・ルール判定各種
→※局面によってルールの適用の要不要があるのでそれぞれ独立して持つ
→・駒の移動範囲テーブル
→・各種禁じ手判定など
・棋譜DB
→・定石を抽出して探索の枝切りや手抜きに使う
・評価関数
→※思考の本体であり盤面テーブルから次の手を探索する
→・ルール、DB、盤面テーブルは全てここで使う
・探索ツリー
→評価関数が吐き出した結果の保持用
→手番ごとに1から探すのは無駄なので探索結果はツリーの状態で保持
UI(表示)モジュール
※こいつらは表示専用でルールや思考ロジックには感知しない
・駒クラス
・盤クラス
・駒台クラス
など
UI側はともかく思考側は細かくクラス分けするメリットは殆ど感じられない、OOPの例題としては向いてないと思うんだ
これが実装中にルールに仕様変更の入るボードゲームなら話は多少違うだろうが…