16/05/22 01:34:21.91 mLM/Nu20.net
>>256
ソースも読めない営業と仕事してんのか
優れたコードは素人でも部分的にソースを読めるもんだぞ
逆に素人がみても全くわからんようなコード書くから無意味なドキュメントがないと安心できなくなってるんだろうな
263:デフォルトの名無しさん
16/05/22 01:35:55.78 sxeEi6BC.net
>>259
笑わせに来てるだろｗ
264:デフォルトの名無しさん
16/05/22 01:39:45.41 SSySxKMQ.net
>>259
これはさすがに苦しい言い分だと思うが……
printf("hello world\n");
これすらわからねえなんてザラじゃね?
265:デフォルトの名無しさん
16/05/22 01:40:32.08 mLM/Nu20.net
>>258
文章がいかに曖昧なものか理解してない時点で素人丸出しだな
ブツとして無意味と思いつつ形式的に書いて渡す事はあれどそれを真面目に解釈してモノを作るなんてバカな真似はアマチュアで卒業しとけよ
システム開発ってのは進路調整の連続なんだよ
ドキュメントの更新日がちょっと古かったらもう信用できない
どのみち直接対話で確認を取りに行くしかない
266:デフォルトの名無しさん
16/05/22 01:42:37.38 sxeEi6BC.net
>>262
お前の目的は何なんだよｗｗ
さすがに釣りだろ？
267:デフォルトの名無しさん
16/05/22 01:55:46.57 mLM/Nu20.net
>>261
苦しくないって
例えばこんなコードは素人にゃわけわからん
int x = 0;
for(i = 0; i < len(a); ++i) x += a[i][IDX_UP] * a[i][IDX_PRC];
でも素人でもこれは理解できる
購入品リスト.合計金額()
客と密接に対話して作りあげたモデルから生成されるコードは客でも読める
というか素人でも読めるように書くためのモデリングとコーディングがOOPの真髄だろ
268:デフォルトの名無しさん
16/05/22 01:58:22.26 sxeEi6BC.net
>>264
漢字オブジェクト名ｗｗｗ
269:デフォルトの名無しさん
16/05/22 01:58:50.19 mLM/Nu20.net
>>263
ドキュメント文化をやめてほしい
少なくとも疑問を持ってほしいだけだよ
もし業界全体で馬鹿馬鹿しいドキュメント文化から解脱できたなら
それはいったいどれだけの国益になるか
そこを考えてほしいんだ
270:デフォルトの名無しさん
16/05/22 01:59:51.63 mLM/Nu20.net
>>265
もしかしておじいちゃん？
271:デフォルトの名無しさん
16/05/22 02:02:04.15 sxeEi6BC.net
272:="../test/read.cgi/tech/1463663267/266" rel="noopener noreferrer" target="_blank">>>266 楽しませてもらってるけどスレと関係ない目的だから別のスレ立ててやってもらえるかな。
273:デフォルトの名無しさん
16/05/22 02:03:26.44 mLM/Nu20.net
>>268
関係はあるだろう
さっきも言ったがOOPの真髄はドキュメント不要論にリンクするんだからさ
274:デフォルトの名無しさん
16/05/22 02:03:45.85 WwOYSBmy.net
客がドキュメントを読むんだよ。
知らないのか？
客がドキュメントを読むんだよ。
275:デフォルトの名無しさん
16/05/22 02:05:22.19 sxeEi6BC.net
>>269
頼むからそんなとんでも理論で絡んで来ないで。
お前は自分のスレを立てるに足る逸材だから。
276:デフォルトの名無しさん
16/05/22 02:15:56.49 mLM/Nu20.net
>>270
客がドキュメント読みたきゃ読めばいい
客が客の時間使ってドキュメントを読もうがサボって漫画を読もうがそれは客の勝手だ
だけどこっちの開発はそれじゃ進まねえんだよ
277:デフォルトの名無しさん
16/05/22 02:20:15.89 sxeEi6BC.net
>>272
客の期待通りの設計になっているかを確認するためにもドキュメントを作成する。
なんとそのドキュメントがメンバー間で理解を共有するための役にも立ってしまう。
すごいじゃん。
278:デフォルトの名無しさん
16/05/22 02:25:01.82 WwOYSBmy.net
ドキュメントを読む時間 × メンバーの数 = コスト
279:デフォルトの名無しさん
16/05/22 02:29:51.66 mLM/Nu20.net
>>273
ドキュメントを正確に書ける保証はない
客がドキュメントを正確に読める保証はない
保証はないと言ったが実際には正確でないほうが多い
本当の意味で客が期待する設計はドキュメントからは生まれない
お互いが認識するモデルをすり合わせるために対話の時間をいかに多くとるかで決まる
280:デフォルトの名無しさん
16/05/22 02:33:12.47 mLM/Nu20.net
ましてや開発メンバー全員が同じ文章から同じ意図を読み取るなど夢のまた夢
281:デフォルトの名無しさん
16/05/22 02:37:48.99 sxeEi6BC.net
>>275
口頭じゃ後から確認できないんだから文書として残す必要があるよね。
ってことなんだけど、こいつはそんなちゃちな世界には生きてないんだろうな。
もう頼むからこのスレから巣立って。
282:デフォルトの名無しさん
16/05/22 02:43:09.84 WENufHUB.net
>>259
本当馬鹿馬鹿しいな
おまえの会社はソース読めるエンジニア上がりの営業かもしれんが
他行ったらそんな俺ルール通用しないからな
>>266
個人的希望をばら撒くスレじゃねーから
>>274
口伝のほうがコストかかるだろ
そもそもユニットテスト推奨してるやつが
口伝推奨するとか矛盾もいいとこ
283:デフォルトの名無しさん
16/05/22 05:16:18.29 PykTFw3U.net
口伝する人がいない。いなくなってしまった。
284:デフォルトの名無しさん
16/05/22 05:17:10.39 WwOYSBmy.net
結局ソースコードを読むのが
一番コストがかからない
285:デフォルトの名無しさん
16/05/22 06:36:24.05 OmI05SCB.net
なんでおまえらってオブジェクト指向が理解できないとOOPは甘えとか言って投げ出すの？マジで馬鹿なの？マジでﾀﾋぬしかないの？
286:デフォルトの名無しさん
16/05/22 10:29:24.79 sxeEi6BC.net
何をコーディングするか設計するのが設計なのにコードを読めってアホ過ぎる…。
うざいから素人は書き込むなよ。
287:デフォルトの名無しさん
16/05/22 10:41:33.67 vKoFE7Z9.net
死守すべき拠点・砦・戦線に当たる部分はドキュメントすべき
それ以上細かいのはいらない
288:デフォルトの名無しさん
16/05/22 10:48:03.65 sxeEi6BC.net
ドキュメントの範囲は好きにしていいから、どうやって設計するか語ろうぜ。
設計プロセスについて語れる奴はいないの？
289:デフォルトの名無しさん
16/05/22 11:42:56.90 0426LZJd.net
設計もTDDさえしてればなんとかなるんだよなあ
290:デフォルトの名無しさん
16/05/22 11:47:16.20 sxeEi6BC.net
具体的な話なしに略語しか書けない奴って経験があるように感じさせないんだよなあ。
291:デフォルトの名無しさん
16/05/22 11:50:37.50 0426LZJd.net
TDDをご存じない？
292:デフォルトの名無しさん
16/05/22 11:51:57.78 sxeEi6BC.net
経験ないと具体的な話はできないからなあ。
293:デフォルトの名無しさん
16/05/22 11:54:53.76 EaQ4G/f7.net
>>282
俺もそう思う
何を何のために設計してるのかと
それを知りたければソースコードを読めって破綻してる
じゃソースコードは何を実現するためのソースなのかと?
不具合もソースがそうだからそれが正しいとか言っちゃうのか?
294:デフォルトの名無しさん
16/05/22 11:56:01.52 EaQ4G/f7.net
設計書書かない奴は書き込み禁止
だって設計してないじゃん
295:デフォルトの名無しさん
16/05/22 12:35:41.84 sxeEi6BC.net
>>290
ほんとな。
オブジェクト指向設計について語ろうってスレにわざわざ書き込む意味が分からん。
興味がない、語る内容がないなら書き込む必要ないのに。
296:デフォルトの名無しさん
16/05/22 12:39:57.00 WwOYSBmy.net
>>289
> 何を何のために設計してるのかと
> それを知りたければソースコードを読めって破綻してる
概要をつかむためだよ。
だから設計書には概要しか書かれない。
実際の詳細はソースコードを読めになるのは当たり前。
297:デフォルトの名無しさん
16/05/22 12:42:21.47 WwOYSBmy.net
設計書は概要をつかむためで概要しかかかれないのだから
当然、設計書に書かれたものから、ソースコードを生成できるわけじゃない。
設計書は方針、こんな感じにしてくださいねっていうもの。
設計書を見て書くというのは、設計書に反しないように作るってことであって
設計書をソースコードに翻訳する作業じゃない。
そして往々にして、実際にソースコードを書いてると、
設計に問題が出てくる。
この時設計書も直さないといけない。
298:デフォルトの名無しさん
16/05/22 12:59:08.54 vqfBgWhe.net
>>277
何度言えばわかるのかなぁ
事後ならコードというその時点で最も信頼できる読みやすいドキュメントがあるだろう
>>278
文章のほうが遥かに高くつく
あんたもプロになればわかるけど設計書なんて１回書いたきりで終わりになんかならねえのよ
口頭ならミーティング１セッションで終わるやりとりがドキュメントだと何回ものファイル更新・交換になってしまう
あぁいちおうお前もバカそうだから念押しするがこれ設計～製造の話な
後に残す文章はコードがあるからまた別の話だ
299:デフォルトの名無しさん
16/05/22 13:02:48.15 JErM/sdi.net
日本語で書かれた設計書で概要をつかんで、ソースコードを書くフェーズは、”詳細設計”なんです。
単に、日本語で書かれた設計書をソースコードに単純翻訳しているのではありません。
「ソースコードを書く」＝「詳細設計」なんです。
だから、実際にソースコードを書いていると、詳細設計的に問題が発生して書き直しとなるし、場合によっては一つ前の日本語で書かれた設計書まで戻って直す必要も出てきます。
300:デフォルトの名無しさん
16/05/22 13:03:07.84 vqfBgWhe.net
>>280
正解
加えて言えば読めるコード書けないバカが日本語なら書けると勘違いしてドキュメントという幻想にすがりつく
馬鹿馬鹿しいよ
あいつらの書いたドキュメントなんてテストしてないスクリプトへのリプレースみたいなもんだ
読みやすくなるどころか開発言語より読みにくくなってる
読みにくいだけならまだしも開発言語で書いたコードと平気で剥離する
301:デフォルトの名無しさん
16/05/22 13:05:39.79 vqfBgWhe.net
>>282
>>289
設計するためにコードを読むんじゃない
設計するためにモデリングするんだよ
そしてモデリングの過程でコードを書くんだ
順番を間違えるな
302:デフォルトの名無しさん
16/05/22 13:13:22.82 WENufHUB.net
>>294
君が作ったソースの中身を説明するためにミーティング開催するの？
ドキュメント書かないわ、人件費の意識ないわ、終わってるな
303:デフォルトの名無しさん
16/05/22 13:28:40.61 k1JTbXad.net
じゃあ製造に失敗しないパーフェクトな設計書って具体的に何が書いてあるの？
304:デフォルトの名無しさん
16/05/22 13:44:35.01 sxeEi6BC.net
>>297
そんな言い合いしてても無意味だから設計のプロセスについて語ろうぜ。
どんな手順でやってて、それぞれのステップの成果物は？
305:デフォルトの名無しさん
16/05/22 13:51:29.86 WwOYSBmy.net
>>300
成果物なんて後から出てくるもの。
まずはステップの目的を考えなさい。
306:デフォルトの名無しさん
16/05/22 13:56:34.04 sxeEi6BC.net
>>301
ステップのゴールを決めるのがプロセスなんだけど…。
めんどくさいから素人は書き込むなよ。
307:デフォルトの名無しさん
16/05/22 14:02:56.02 6l64NX2q.net
コード＝ドキュメントってのは理想ではあるんだが
コードってのはこう動くってことしか書いてなくて、しかも実装者以外の人間が欲しい情報よりも粒度が細かい。
あと、その裏にある開発者の意図やシステム特有の事情とかは書かれないしコメントで補完するにも限界がある。
一方でドキュメントを手で作成しても改訂のたびに修正する労力と修正後にソースと同期をとる労力がバカにならないし
大量にドキュメントを書いてもそんなの見ない、見ようと思っても索引や検索が不十分で探し廻らなきゃならないで
結局知ってそうな人に聞くのが早い、ドキュメントの利点なんて新しく加入した人への説明を（形式上）省けるくらいの利点しかない、
てなことになる。
なので現実的な最適解としては、できるだけコードからリバースして「必要な情報だけ」を自動的に抽出する、
そのためのツールを用意し、また抽出しやすいようなコードを書く、それでは作成できないけど本当に必要なものは手で作成する、
て辺りになるんじゃないかと思う。
で必要な情報てのは、画面とか機能とかサブシステムとかの一覧とそれらの間のI/F詳細くらいで、
それ以上はソース読めでいいように思う。
308:デフォルトの名無しさん
16/05/22 14:07:39.59 WwOYSBmy.net
>>302
ステップの目的を成果物生成にしてはいけない。
そんなことをやると理由はないけど作りました。
作って終わり、使われないものが出来上がるだけ。
309:デフォルトの名無しさん
16/05/22 14:13:48.86 sxeEi6BC.net
>>304
開発プロセスの本くらい読みなよ。
まともな開発プロセスならステップと成果物が決まってるから。
そんなことすら知らない素人のくせに知ったかぶりすんなよ。
ちょっと勉強したらどんだけ恥ずかしい書き込みしてるか分かるから。
310:デフォルトの名無しさん
16/05/22 14:14:28.75 WENufHUB.net
>>304
成果物なしでどうやってプロセスの完了を判断する？
ソースコードも成果物だし、
成果物のチェックはどんなプロセスでも必要だよ
311:デフォルトの名無しさん
16/05/22 14:19:58.15 vKoFE7Z9.net
これだけ延々と中身の無いレスを垂れ流す奴が書くドキュメントを読まされるという苦行
312:デフォルトの名無しさん
16/05/22 14:29:28.77 sxeEi6BC.net
コードだけでいいって言ってる奴がしつこく書き込む矛盾なｗ
ドキュメントの範囲は好きにしていいからプロセスについて語ってくれって言ってんだけどなあ。
313:4qmWB+Wj
16/05/22 14:34:56.12 Pvh7yqZB.net
(..´・ω・).oO(今日も伸びてんなぁ
314:デフォルトの名無しさん
16/05/22 14:37:04.55 WwOYSBmy.net
>>305
> まともな開発プロセスならステップと成果物が決まってるから。
それはまともじゃない開発プロセスか、
お前が読み間違ってるだけだな。
読むといいよｗ
URLﾘﾝｸ(www.jaspic.org)
俺がいいたいことが書いてあった。
URLﾘﾝｸ(d.hatena.ne.jp)
CMMIの教本（PDFが配布されてますね）には、いろいろと”典型的な作業成果物”や”サブプラクティス”なんていろいろ書いてます。
が、そんなことはどうでもいい。参考にもなりません。
そんなことよりも、
そのプロセスエリアが「本質的に」何をすべきと主張しているかをじっくりと「考える」ことが大事。
そして、自分たちの組織文化的にどういうことがそれに当てはまるか「解釈」することがもっと大事。
バカなCMMI推進者たちは、すぐに文字通りにやろうとします。考えもせず。
これこそ、「形骸化のはじまり！」
「制度化」というCMMIでよく出てくる言葉の意味を理解してません。
逆説的ですが、「CMMIをやろうとすればするほど、CMMIを実装できない」
というジレンマに陥ります。
なぜか？
かんたん。「CMMIの本質を理解してないから？」
そもそも、組織のみんなは日々の業務を一生懸命こなしてます。日々、大小さまざまな改善を積み重ねてませんか？
なのに、CMMIでプロセス改善しよう、って言ったって、「いや、今だって改善してるけど？」的な議論になります。
つまり、CMMIなんて所詮枝葉、形つまり、方法論にすぎないのに、方法論の実装を目的にしちゃうCMMI推進者が「ガン」なわけですね。
315:デフォルトの名無しさん
16/05/22 14:40:22.53 sxeEi6BC.net
>>310
いろんなメンバーがかかわるプロジェクトでプロセスがないってねえ…。
ま、>>291だな。
不要って思うなら使わなきゃいいじゃん。
316:デフォルトの名無しさん
16/05/22 14:42:17.90 6l64NX2q.net
他人の作業を自動化・効率化するプログラムを作っているはずなのに
自分の作業の自動化・効率化を（自分の頭で）考えないで人力でなんとかする（しろ）
って人が結構いるよなぁ
317:デフォルトの名無しさん
16/05/22 14:47:32.63 EaQ4G/f7.net
>>308
でも彼の理論で言うと
もういきなりソースコード組むしかないよね
ファイルフォーマットも通信プロトコルもDBのテーブルも後から付いてくる心配するな!
突っ切れ!
筋肉でプログラミングするタイプかな?
318:デフォルトの名無しさん
16/05/22 14:50:18.38 sxeEi6BC.net
>>313
プロセスのステップが明らかになればそこもはっきりすると思ってさ。
お互いの頭の中にぼんやりとしたイメージしかない状態で設計から構築に進むって
プロセスがまったく想像できないから詳しく語って欲しいじゃん？
319:デフォルトの名無しさん
16/05/22 15:09:12.83 EaQ4G/f7.net
>>314
多分こちらが疑問に思ってるようなことは
彼にとっては「そんなのキーボードに手を置けばゴーストが囁くだろ常考」の一言なんだよ
そして粘土をこねるように彫刻を刻むように手を入れてって納期が来たらそこで完成
恐らくそんな開発を言ってる
受け取った客が検収すると不具合ばっかりで使い物にならないケース
320:デフォルトの名無しさん
16/05/22 15:11:50.07 SSySxKMQ.net
プロセスでふと思ったけど
まあ前提として要件がそこそこ決まってるとして
オブジェクトの洗い出しみたいなことするよね
でまあデザインパターンあたりかじってりゃ
たとえばここはテンプレートメソッドでがちがちにしちゃろーとか
ストラテジーにしてゆるーくしちゃろーとか
なんだけど
その判断のプロセスは自分でもわからんな
言語化できてねえ
321:デフォルトの名無しさん
16/05/22 15:13:18.77 SSySxKMQ.net
っつーか言語化できたら本書いて一儲けできそうだなｗｗｗ
322:デフォルトの名無しさん
16/05/22 15:17:51.26 sxeEi6BC.net
>>316
オブジェクトの洗い出しって具体的にどんな感じでやってる？
特に機能的なオブジェクトの洗い出しはアバウトにやってて、もうちょっと何かないかなあって感じてて。
323:デフォルトの名無しさん
16/05/22 15:24:46.95 SSySxKMQ.net
>>318
俺もその辺が明確にできればなーって期待してこのスレみてる
アプローチ方法的にはなんかER図作るときみたいになっちゃってるかもしんない
最初にエンティティ出してそれに振る舞いついたらオブジェクトみたいな
うん、うまく言語化できんやっぱり
上級者に期待だわ
324:デフォルトの名無しさん
16/05/22 15:27:46.05 k1JTbXad.net
設計書厨はまず設計書に書く内容をここで言ってみな
話はそれからだろう
325:デフォルトの名無しさん
16/05/22 15:32:18.74 sxeEi6BC.net
>>319
俺もER図書いてエンティティを洗い出すな。
そこからクラス図を書く感じ。
エンティティ的なクラスを決める基準はかなり明確なんだけど機能的なクラスは難しいよな。
デザインパターンを考えながらなんとなく決めてるけど、判断に悩むことが多い。
要件定義から設計へ移行する辺りの明快な指針があんまりないんだよなあ。
326:デフォルトの名無しさん
16/05/22 15:32:30.31 WwOYSBmy.net
> うん、うまく言語化できんやっぱり
そういや中二病っぽく「言語化」とか言ってる
アニメか漫画があったよな。
それのパクリかｗ
327:デフォルトの名無しさん
16/05/22 15:33:49.99 sxeEi6BC.net
要件定義から設計ってより構築の手前の具体的な設計の辺りかな。
328:デフォルトの名無しさん
16/05/22 15:34:57.20 WwOYSBmy.net
>>321
> 俺もER図書いてエンティティを洗い出すな。
俺は、rails generateでモデルを作るな。
そのコード上の定義からER図は rails-erdでモデルを
変更するたびに自動的に生成される。
見方を変えれば、コードを使ってER図を書いているだけ。
やってることは、あんたと一緒でそれがより効率的になっただけだね。
マウスでポチポチやらないで、コードを書くだけだから楽だよ。
修正履歴もわかるしね。
329:デフォルトの名無しさん
16/05/22 15:35:56.44 WwOYSBmy.net
ちなみに、モデルっていうのはクラスだから
Rubyコードを使ってER図を書くと同時にクラスも作れる。
330:デフォルトの名無しさん
16/05/22 15:38:48.31 sxeEi6BC.net
>>324
そこは好きなツールを使えばいいと思う。
それより設計指針的な話で、どういう基準でクラスを選択するかを聞きたい。
331:デフォルトの名無しさん
16/05/22 15:39:06.09 WwOYSBmy.net
rails-erdの動画があったよｗ
Create an ERD in Rails in under 30 seconds.
URLﾘﾝｸ(www.youtube.com)
332:デフォルトの名無しさん
16/05/22 15:43:24.37 WwOYSBmy.net
>>326
大概はモデルクラスだろ？
画面があれば、コントローラクラスが必要になる。
機能はメソッドだから機能ごとにクラスは作らない。
やることってその程度じゃね？
333:デフォルトの名無しさん
16/05/22 15:44:05.88 JaLdteXY.net
>>321
悩んでる時点でもうアウトだ�
334:� 幾ら悩んでも明確な答えは出てこない そんなフワッとした状態で設計書という名の便所の落書きを幾らかいてもなにも進展しない 結果はコードを書くしかないんだよ コードを実際に書けば次にどうするかの指針が見えてくる 基本中の基本だわな
335:デフォルトの名無しさん
16/05/22 15:49:05.35 sxeEi6BC.net
>>328
業務的の機能のきれいな構成だな。
336:デフォルトの名無しさん
16/05/22 15:50:23.31 SSySxKMQ.net
>>321
機能的なクラスって少し掘り下げて教えて欲しい
～Utilityとか～Helperとかの名前で実装する類のもの?
だとすると設計段階では洗い出さないかな……
337:デフォルトの名無しさん
16/05/22 15:51:55.61 sxeEi6BC.net
>>329
設計が決まってないのにどんなコードを書くのかな？
おおまなか設計がなくちゃコード書けない。
338:デフォルトの名無しさん
16/05/22 15:53:09.10 WwOYSBmy.net
> デザインパターンを考えながらなんとなく決めてるけど、判断に悩むことが多い。
デザインパターンを考えながら決めるのレベルで
まだ初心者なんだよな。
俺がデザインパターンを知ったのはもう15年ぐらい前になるけど、
その時の感想は、みんな（本の作者）も同じこと考えてるなぁ～。
俺が考えた「アレ」をこんなに体系的にまとめてくれて嬉しいわ。だった。
幾つか自分で同じようなものを実装したこともあったしね。
デザインパターンの解説にも書いてあるけど、
新しい何かではなくて、過去の人が考えていたことに名前をつけてまとめただけ。
だから俺の場合、作るときにああすれば良いんじゃね？って思いついて、
その後にデザインパターン本みて抜けや考慮漏れなどを補強する感じ。
339:デフォルトの名無しさん
16/05/22 15:54:42.20 sxeEi6BC.net
>>331
だいたいデザインパターンが扱ってるレベルのクラスと想定して欲しい。
業務ルールをチェックする機能をどうするかとか。
340:デフォルトの名無しさん
16/05/22 15:56:32.49 sxeEi6BC.net
>>333
デザインパターンのそんな当たり前の説明をドヤ顔でされても…。
341:デフォルトの名無しさん
16/05/22 15:58:10.11 WwOYSBmy.net
>>334
> 業務ルールをチェックする機能をどうするかとか。
Railsだとバリデーションを使う。
基本的なのはあるが、特殊な業務ルールであれば
カスタムバリデータを自作すればいい。
URLﾘﾝｸ(railsguides.jp)
標準のやり方がってそれに従えばクラスが出来上がるので
クラスをどうするか？とかを意識することは少ない。
342:デフォルトの名無しさん
16/05/22 15:58:39.18 WwOYSBmy.net
>>335
当たり前の説明をしただけだけど、
何か気に触ったの？ｗ
343:デフォルトの名無しさん
16/05/22 16:01:24.72 SSySxKMQ.net
>>334
難しい例だね……ちょっと実装よりというか
たいがいフレームワークで作られちゃってるというか
例に出してくれたバリデーションまわりって設計段階ではやっぱり洗い出さないなあ
要件みてこんなバリデーションいるよねー、程度
で、たいがいフレームワークにバリデーションの仕組みあるから
やっぱり自力で洗い出さない……
複雑なバリデーション作るにしてもフレームワークの流儀に沿うだけだしね
派生してちょろちょろ処理書いて決められたreturnするってだけの
344:デフォルトの名無しさん
16/05/22 16:03:43.19 sxeEi6BC.net
>>336
クラス内で完結しないチェックもできんの？
複数のクラスを参照することが必要な場合はどうするのかとか？
345:デフォルトの名無しさん
16/05/22 16:06:23.48 JaLdteXY.net
>>332
理解力ねえなあ
コード書きながら考えるんだよ
具体的なコードがあるから
この方向性はダメだなとか
これは行けそうだとか
これがありならこっちはどうだとか
思考が展開していく
簡単な話だろ
設計書屋さんって1手目から最後まで読み切ってから1手目を打とうとしてるんだよね
そんなんでうまくいくわけないでしょ
346:デフォルトの名無しさん
16/05/22 16:09:12.64 sxeEi6BC.net
>>338
税制の変更やら社内ルールの変更やらは想定される訳で
その場合の変更に対応できるきれいなデザインって何だろうっていつも悩む。
モデルとか画面の設計はわりと簡単で、業務ロジックの設計・構築がメインじゃない。
設計段階で洗い出さないならいつ設計するんだ？
設計と構築の区切りをどこまで明確にしてるか分からないけど、コーディングの前に
設計する必要はあるじゃん。
347:デフォルトの名無しさん
16/05/22 16:16:53.72 JaLdteXY.net
>>339
このレベルで偉そうにしてたのか
348:デフォルトの名無しさん
16/05/22 16:18:54.34 WwOYSBmy.net
>>339
複数のクラスを参照することが必要ならば、
参照すればいいだけだろう？参照するしかないし。
そんなのデザインパターンがでるまでもない。
349:デフォルトの名無しさん
16/05/22 16:20:48.62 sxeEi6BC.net
>>343
350:デフォルトの名無しさん
16/05/22 16:23:08.82 WwOYSBmy.net
>>344
それって、ぐうの音も出ないって意味？
351:デフォルトの名無しさん
16/05/22 16:27:04.89 sxeEi6BC.net
ちょうど今電王戦見てるから将棋ソフトで考えてみるとさ。
駒クラスがあって王・飛車とかは駒のサブクラスにしようかって感じだろ。
盤面情報と思考ロジックはどんな感じのクラスにするのがいいだろう？
352:デフォルトの名無しさん
16/05/22 16:28:08.95 sxeEi6BC.net
>>345
失礼。クリックミス。
353:デフォルトの名無しさん
16/05/22 16:28:29.75 JaLdteXY.net
>>345
このid sexさんはちょっと昔ながらの人なんだろうね
基本的なフレームワークの扱いもロクに知らんって露呈してしまった
おそらく設計書(笑)ばっかり書いてて最近の開発現場の常識知らないんだろうな
おそらくもうすぐ定年だろう
かわいそうだからあんまりいじめてやらんといて
354:デフォルトの名無しさん
16/05/22 16:29:56.23 sxeEi6BC.net
>>345
失礼。クリックミス。
355:デフォルトの名無しさん
16/05/22 16:30:23.58 sxeEi6BC.net
>>348
具体例を出したからお前の実力を見せ付けて欲しいな。
356:デフォルトの名無しさん
16/05/22 16:37:00.58 WwOYSBmy.net
フレームワーク＝設計だと考えればいいよ。
デザインパターンっていうのは設計するときに必要なものだけど、
フレームワーク作っている側がデザインパターンを使って設計してる。
こっちは、足りない部分を埋めるだけ。
もちろん、基礎知識としてデザインパターンは必要。
フレームワークに足りない部分を拡張するときには必要になる。
だけど定型的なそんな処理で設計なんて考える必要はない。
フレームワークを導入した時点でほとんどが終わっている。
357:デフォルトの名無しさん
16/05/22 16:40:12.95 MeU4g4+w.net
sexじゃなくてsxeやん
358:デフォルトの名無しさん
16/05/22 16:41:15.97 sxeEi6BC.net
>>351
ややこしい業務ロジックが色々あるときはどうしてる？
359:デフォルトの名無しさん
16/05/22 16:44:19.40 sxeEi6BC.net
>>351
具体例があったほうが分かりやすいから将棋ソフトの例で考えてみてよ。
思考ルーチンは定跡＋何らかのロジックがあるし、思考ルーチンのどんどん改修されるとして。
ロジックの細かい部分は俺も知らないし、大まかな構成で十分。
360:デフォルトの名無しさん
16/05/22 16:47:39.90 WF/9GeMl.net
まあそんな熱くなるなってｗ
361:デフォルトの名無しさん
16/05/22 16:51:47.45 EaQ4G/f7.net
俺は要件定義で
対象のシステムの構成図
ユースケース図
機能一覧
画面一覧
説明書
まで書く
設計書は頭に構成図貼り付けて
機能一覧に基づいて機能毎に
概要、機能詳細、画面詳細、データフロー、シーケンス図、ログ、メッセージ、ファイルフォーマット、テーブルetc
を書く
基本的にはログやメッセージみたいな共通部分以外で
機能より細分化したクラスは作らない
362:デフォルトの名無しさん
16/05/22 16:53:43.65 WwOYSBmy.net
>>353
> ややこしい業務ロジックが色々あるときはどうしてる？
ややこしい業務ロジックなどない。っていうのが答え。
処理が多くて面倒くさいだけだろう？
もしくは設計が必要な部分（フレームワーク）と
設計が必要ないような些細な部分が、ごちゃまぜになってる。
フレームワークを使ってなさそうだし、綺麗に分離できてないんだろう。
ちなみに「設計が必要ないような些細な部分」といったが
この部分が重要ではないという意味じゃないぞ。
むしろ顧客にとっては（当然だが汎用的なフレームワークより）
この部分の方にこそ価値があって重要な部分。
重要だからこそ、出来る限り汎用的な部分をそぎ落として
改修が入るコードのみにする。そこまで削ぎ落とすから設計なんぞ不要。
フレームワークを使うことで設計はどこかの誰かがやってくれるから
通常の開発で設計なんぞ、終わってることだから、やらない。
あんたは、この改修が入る部分と設計が必要な部分をあわせたままやってるから、
ロジックの改修時に設計をどうするかって話がでてくる。
363:デフォルトの名無しさん
16/05/22 16:54:30.16 sxeEi6BC.net
具体例を出したら途端に書き込みが減ったけど考えてくれてるかな？
盤面をクラスとして作るべきか、思考ルーチンの中で使われる情報に過ぎないのか？
って疑問がまず出てくるけどどう判断する？
364:デフォルトの名無しさん
16/05/22 16:56:03.51 sxeEi6BC.net
>>357
将棋ソフトの例で一緒に考えよう。
実際にきれいな考え方を示してくれたら素直に認めるから。
365:デフォルトの名無しさん
16/05/22 16:59:15.28 WwOYSBmy.net
>>354
> 具体例があったほうが分かりやすいから将棋ソフトの例で考えてみてよ。
将棋ソフトで設計が必要なのは、まずインターフェース部分。
コマの配置データから、盤面の画像を配置すればいいだけ。
ここは思考ルーチンの改修とは全く別の話だから、
思考ルーチンの改修時に触らなくていいように分離する。
ということで、インターフェース部分の設計は終わり。
思考ルーチンの改修時に考えなくていい。
他に何を設計するんだ？
あとは単なるアルゴリズムだけだろう。
やるとしてもデータを所持して、思考ルーチンを呼び出すだけの
単純なインターフェースを考えればおしまい。
366:デフォルトの名無しさん
16/05/22 16:59:59.08 WENufHUB.net
rails含めてMVCフレームワークで事足りる案件なら
すでに構成が確定してるから
クラス設計とかクラス図とか全く必要ないよな
俺は未だにクラス図が必要になるケースがわからん
科学計算とか人工知能とかそちら方面かな？
367:デフォルトの名無しさん
16/05/22 17:02:51.37 WENufHUB.net
プロセスの成果物については考え方違うが>>351は同意だわ
368:デフォルトの名無しさん
16/05/22 17:03:39.39 WwOYSBmy.net
>>358
> 盤面をクラスとして作るべきか、思考ルーチンの中で使われる情報に過ぎないのか？
> って疑問がまず出てくるけどどう判断する？
何度も同じような指摘をしてる気がするけど、
お前は役割の分離ができていない。
それらをの、改修が入る部分と設計が必要ない部分を合わせたままやってるから
ロジック（思考ルーチン）の改修時に設計をどうするかって話が出てきてる。
盤面なんて、コマの配置データさえあれば、再現できるだろ。
最悪文字だけのアスキーアートでもいい。
もしこれをアニメーションバリバリの3Dで表現しようと思ったら
設計が必要になるだろうけど、それはあくまでUIレベルの話。
思考ルーチンのことなんか考慮する話じゃない。
369:デフォルトの名無しさん
16/05/22 17:04:12.31 sxeEi6BC.net
>>360
電王戦は見てない人か？
こっちの説明不足だったけど棋譜をやり取りするインタフェースがあれば
UIはなくてもいいとする。
棋士の指した定跡とか駒の配置とかを元に手を決める思考ロジックがメイン。
基本はありえる手をたくさん読んで、なんらかの基準で点数をつけて、
最適な手を選択する。
370:デフォルトの名無しさん
16/05/22 17:06:42.51 sxeEi6BC.net
>>363
反応がないから話のきっかけとして書いた。
お前が違う考え方をするならお前の考える設計を出してよ。
371:デフォルトの名無しさん
16/05/22 17:06:55.21 WENufHUB.net
将棋ソフトってコア部分のアルゴリズムを一人か数人の天才が作ってそうで
チーム開発とか設計の議論には向いてなさそう
372:デフォルトの名無しさん
16/05/22 17:07:48.31 WwOYSBmy.net
>>364
盤面をクラスとして作るべきかなんていい出したのはお前だろ？
思考ロジックに必要な盤面のデータなんて
単なる2次元配列で十分だろ。
あえてクラスを持ち出すならば、
2次元配列クラスを作ればおしまい。
こんなの考えるまでもない。設計なんて呼べるほどのものじゃない。
片手間で簡単に書ける程度。
373:デフォルトの名無しさん
16/05/22 17:08:33.88 sxeEi6BC.net
>>366
設計って言い方が曖昧だったな。
きれいなクラス構成を考えて欲しい。
ステップとかの話じゃない。
374:デフォルトの名無しさん
16/05/22 17:10:20.90 sxeEi6BC.net
>>367
俺の考えと違うならお前の考えを出してって言ったろ。
将棋ソフトを構成するクラスは何？
スレでやり取りする内容だから厳密に詳細まで落とせないのは分かってるけど
ある程度のイメージがつかめるレベルで頼む。
375:デフォルトの名無しさん
16/05/22 17:12:08.26 WwOYSBmy.net
つーか、なんで思考ロジックって言ってるのに
クラスとか設計が出てくるのか？
システムっていうのは設計が必要な部分と
設計が必要ない部分に分けろよ。
そして普段は設計が必要ないようにしろよ。
そうやってるから俺は普段設計なんてしなくていいって言ってるわけで、
それはフレームワークがすでにやってくれてるからって話なんだが。
将棋ソフトで必要になる設計は、思考ロジック部分の外側だ。
仮に思考ロジックを入れ替えることが可能な "設計" の
将棋ソフトがあれば、各自が将棋ソフトを作ること無く、
ロジック部分に専念できるだろ。
フレームワーク導入っていうのはそういうこと。
376:デフォルトの名無しさん
16/05/22 17:12:10.64 EaQ4G/f7.net
俺だったら将棋クラス1つかな
377:デフォルトの名無しさん
16/05/22 17:13:27.05 sxeEi6BC.net
>>367
別の人と勘違いした。
盤面情報ってのは現在の盤面、何手か先の盤面の話。
どうやって持つかは設計によるけど情報としては必要だろ。
378:デフォルトの名無しさん
16/05/22 17:14:36.63 WwOYSBmy.net
>>369
> 将棋ソフトを構成するクラスは何？
将棋ソフトをどうするかで変わる。
作りたい機能によって設計は変わるからだ。
今は、思考ロジックを改修するって話しか出てないから、
思考ロジッククラスと、それ以外のクラス（UI担当クラス）しか言うべきことはない。
ちなみにUI担当クラスは、アスキーアートでやるなら
1クラスで十分だからな。
379:デフォルトの名無しさん
16/05/22 17:16:25.55 sxeEi6BC.net
>>370
画面と簡単なロジックしかないシステムばかりじゃないぞ。
設計もなしに開発できるほど将棋ソフトが簡単だとは思えないけどどうやって開発すんの？
380:デフォルトの名無しさん
16/05/22 17:17:48.33 WwOYSBmy.net
>>372
> 盤面情報ってのは現在の盤面、何手か先の盤面の話。
何手か先って未来の情報なんてわかるかよｗ
先を読んだ結果（つまりキャッシュ）の話でもしてるのか？
そんなの思考ロジックによって違うのだから、
思考ロジックとは別のクラスにすることはできん。
盤面情報をもった汎用的なキャッシュクラスというのであれば
2次元配列で十分だろ。
あえてクラスにするならば、2次元配列クラスだｗ
381:デフォルトの名無しさん
16/05/22 17:19:25.70 sxeEi6BC.net
>>373
思考ロジックの構成なんて俺も知らないから考えてってお題を出してる。
説明がないって言われても困るわ。
業務システムだって担当したことない業界のシステムを設計することだってあるんだから
将棋ソフトなんてむしろイメージしやすいだろ。
細かい点で揚げ足取るつもりはないから設計の腕を見せてくれ。
382:デフォルトの名無しさん
16/05/22 17:19:25.93 WwOYSBmy.net
>>374
お前、将棋のAIのアルゴリズムが難しい話と
ソフトウェア設計の難しさをごっちゃにしてるだろｗ
業務ロジックでも同じ間違いしてたよな？
業務ロジックがややこしくても、
設計自体は単純。
殆どが汎用的なフレームワークで終る程度。
383:デフォルトの名無しさん
16/05/22 17:20:29.91 sxeEi6BC.net
>>377
え？アルゴリズムクラス1つの設計にしちゃうの？ｗ
384:デフォルトの名無しさん
16/05/22 17:20:38.57 WwOYSBmy.net
>>376
まだ理解してないのか？
思考ロジックに必要なのはアルゴリズムであって
設計じゃない。
思考ロジックの中に設計はないって言ってるのに、
その設計を聞かれても、設計はないって答えるしかないだろｗ
385:デフォルトの名無しさん
16/05/22 17:20:58.83 WENufHUB.net
>>370
半分同意なんだけど
MVCフレームワーク使ったらクラスまわりの設計不要はそのとおり、
しかしだとするとこのスレは何を語るスレなのか
>>1の真意を知りたいわ
386:デフォルトの名無しさん
16/05/22 17:23:11.96 EaQ4G/f7.net
将棋は例が悪いよ
もっと万人が完成形を一致できるものじゃないと
将棋は何もやらないとテトリスみたいに詰め込むと短く終わるタイプじゃん
387:デフォルトの名無しさん
16/05/22 17:23:20.30 sxeEi6BC.net
>>375
あのさあ…、将棋ゲームはやったことないの？
相手がこうさしたら、こっちはこう指して、こうなると悪くなるから、こっちの手を選ぼう
ってロジックの話よ。
電王戦の将棋ソフトって言っても全然伝わらないもんなの？？
388:デフォルトの名無しさん
16/05/22 17:25:13.14 WwOYSBmy.net
>>378
むしろ、なんで1つのクラスにしないのかわからんのだが？
（2次元配列クラスぐらいなら言ったよ？）
お前、設計をしなくていい部分を無理やり設計しようとしてるから
わけわからんことになってるんだろｗ
アルゴリズムをクラスにするのは、
上で書いた思考ロジックを切り替えやすくする
将棋ソフトウェアのフレームワークを俺が設計したから。
思考ロジックの "中" には設計は不要で、
思考ロジックの "外" に設計を行うことで
簡単に思考ロジックを切り替えられるようにする。
業務システムも、通常は業務ロジック部分を作るのだから設計は不要。
設計とはこういうこと。
389:デフォルトの名無しさん
16/05/22 17:25:50.40 sxeEi6BC.net
>>381
他にいい例があるなら出してよ。
抽象的な議論だとくだらない言い争いになって不毛だから具体例で語りたい。
将棋ソフトはプログラマならイメージできると思って出したんだけど。
390:デフォルトの名無しさん
16/05/22 17:26:08.32 WwOYSBmy.net
>>382
> 相手がこうさしたら、こっちはこう指して、こうなると悪くなるから、こっちの手を選ぼう
> ってロジックの話よ。
だから、何度も言うように設計はいらねーよな？
391:デフォルトの名無しさん
16/05/22 17:27:28.13 sxeEi6BC.net
>>383
「将棋ソフトウェアのフレームワークを俺が設計したから」
！？？？
何言ってんだろ。
392:デフォルトの名無しさん
16/05/22 17:27:50.06 WENufHUB.net
>>376
あ、なるほど、ようやく意図を理解した
しかしやはり例が難しすぎるね
桂オブジェクト、銀オブジェクト、飛車オブジェクト、角オブジェクトなどに
今後どう動けばより有利になるかの計算メソッドが書いてあり、
それを自分と相手の持ち駒分を
アルゴリズムが入ったロジッククラスに食わせて、、、
あー、俺には無理だわw
393:デフォルトの名無しさん
16/05/22 17:29:57.58 sxeEi6BC.net
>>385
で、完成したコードはどういうクラス構成になってんの？
394:デフォルトの名無しさん
16/05/22 17:30:55.61 WwOYSBmy.net
>>386
日本語もわからんのかｗ
思考ロジックを切り替えなくていいなら、
わざわざ「思考ロジックを切り替えやすくする
将棋ソフトウェアのフレームワーク」を設計する必要はない。
そこまで来るとアルゴリズムクラスすら必要ない。
一枚岩に埋め込んじゃえばいい。
でも俺だったら（俺の設計の話を聞いたんだろ？）
思考ロジックを切り替えられるようにするから、
その部分（思考ロジックの外）は設計するって言ったんだが。
お前、やらなくてい仕事をやってるだけじゃねーの？ｗ
設計がいらないものを、むりやり設計しようとしているようにしか見えない。
395:デフォルトの名無しさん
16/05/22 17:31:47.21 sxeEi6BC.net
>>385
>>388は完成させろってことじゃないから。
現時点でどんなクラス構成になりそうだと考えてるの？って質問な。
頭の中に方向性がなきゃコーディングを開始すんのは無理だろ？
396:デフォルトの名無しさん
16/05/22 17:31:59.74 EaQ4G/f7.net
業務フローも含めた勤怠管理システムとかお題として優秀だと思う
397:デフォルトの名無しさん
16/05/22 17:33:26.59 WENufHUB.net
>>391
言い争いが終わらないからお題変えたほうが有益だね
勤怠管理程度だと逆にMVCの一言で設計終わっちゃうがw
398:デフォルトの名無しさん
16/05/22 17:34:07.26 sxeEi6BC.net
>>389
思考ロジックを切り替えられるようにするから、
その部分（思考ロジックの外）は設計する
ってのはどんな感じになるのか教えてくれ。
「俺はすごいんだー」って主張してるだけで何も出てこないんじゃさあ。
出てくれば素直にお前を評価するから。
出て来なきゃ口だけだなとｗ
399:デフォルトの名無しさん
16/05/22 17:34:29.93 WwOYSBmy.net
>>388
クラス構成だろ？
クラスの実装じゃなくて。
今まで出てる要件の将棋ソフトのクラス構成なら、
UIクラスと思考ロジッククラス程度で終わりだろ。
UIを3Dにして商用ゲームっぽくするならば、
UIを作り�
400:竄ｷいように、将棋盤クラス、 コマクラスとか作るけどな。 あと思考ロジックをネットワークを使って複数台で分散処理させるならば、 （汎用の）計算処理分散のための設計も入れるだろうな。 それ以外に必要な設計なんか思いつかん。
401:デフォルトの名無しさん
16/05/22 17:35:36.39 WwOYSBmy.net
>>393
> 思考ロジックを切り替えられるようにするから、
> その部分（思考ロジックの外）は設計する
> ってのはどんな感じになるのか教えてくれ。
ストラテジーパターンでいいやん。
こんなん数秒で思いつくレベルやでｗ
402:デフォルトの名無しさん
16/05/22 17:37:06.43 sxeEi6BC.net
>>392
勤怠管理はまあそうだけど、もっとややこしい業務システムもある。
株売買とかも分析があってややこしいとか。
でも、それより将棋のほうがみんな分かっていいだろ。
複雑なロジックを含むシステムなのは共通してる。
403:デフォルトの名無しさん
16/05/22 17:38:09.35 WwOYSBmy.net
数秒もいらんか？
前提知識として、将棋を知ってるから、
ソフトウェア化って聞いただけで
思考ロジックを切り替えられる設計は思いついてる。
仮に将棋を知らなかったとしたら、
将棋のルールを聞いてる途中で思いつく。
考えてください → 数秒後 → 考えつく。じゃなくて
将棋のルールを聞いてる途中で答えが出てる。
404:デフォルトの名無しさん
16/05/22 17:38:45.08 8h3SPrnH.net
いや～勉強になります
アルゴリズムのデザインにシステムの設計なんて関係ない
アルゴリズムが確定したあと初めてオブジェクト指向を待つ言語でどう詳細な設計に落とすかってことなんだ
アルゴリズムを実装するのに適した処理系があればそっちでやれって
405:デフォルトの名無しさん
16/05/22 17:39:44.42 WwOYSBmy.net
>>398
今の将棋の話で、アルゴリズムを確定させたか？ｗ
アルゴリズムを確定させない状態で、
アルゴリズムを切り替えやすくするための
設計の話をしていたはずなんだがｗｗｗ
406:デフォルトの名無しさん
16/05/22 17:39:53.11 WENufHUB.net
>>396
将棋は難しすぎると思うけどなあ
じゃあ叩き台としてどんなクラスが必要か出してみてよ
俺は>>387で適当に考えたけど挫折したよ
407:デフォルトの名無しさん
16/05/22 17:40:47.45 EaQ4G/f7.net
>>392
もちろん月次の勤怠報告書も各PCから出力できる
休日や休み時間、有給半休設定も設定可能
予定表機能もあって受付のねーちゃんがそれ見て在籍確認ができる
って程度ならあまり溢れず
設計書が必要なレベルではないだろか?
408:デフォルトの名無しさん
16/05/22 17:40:51.87 6l64NX2q.net
>>360
>他に何を設計するんだ？
将棋のルールを表現するモジュールが欲しいな。
これは変わらないものだし、ユーザ入力も思考ルーチンでもチェックに
利用できるようになっていると嬉しい。
あとソフトウェア内部での盤面や指し手についてのデータ構造だな。
プレイの間だけデータを持ってればいいのかセーブ・ロードが必要なのか
Redo/Undoが欲しいかなどの要求が考えられるから、それらに対応できるような
構造になってると嬉しい。
で、それらをモジュールとして分割するかレイヤとして分割するかだな。
で、そこまで決まると将棋のAIのロジックはデータ構造上のデータの変更のロジックに
容易に変換できるようになる。つまり>>377とかで言ってるフレームワークってことだね。
で、こういったことをコードを書きながら頭の中でやるかメモ書きでやるか、
それとも設計書に書いてからやるかって話だけど、いずれにしても仕事としてやる以上は
やったことを評価と保守ができる形で残さないといけない。
409:デフォルトの名無しさん
16/05/22 17:45:25.74 sxeEi6BC.net
>>394
ロジックが1つのクラスってのは違うだろうな。
局面：駒の位置、指せる手、駒の当たり、など
局面の点数化：持ち駒、駒の働き、囲い、駒の位置、など
手を考えるロジック：定跡との比較、候補手の選択、分岐の選択、捨てる手の選択、など
とかいくつかの機能に分かれているのに全部1つのクラスってだめだろ。
局面を管理してる部分は局面の点数化と手を考えるロジックが変わっても変更する必要はない
とかあるだろうし。
設計ってそういうことを考える作業なのに全然できてないなあ。
410:デフォルトの名無しさん
16/05/22 17:45:51.18 WwOYSBmy.net
× 将棋のルールを表現するモジュールが欲しいな。
○ 将棋のルールを表現したデータが欲しいな。
411: > これは変わらないものだし、ユーザ入力も思考ルーチンでもチェックに > 利用できるようになっていると嬉しい。 関係ないものを混ぜるな。 役割は分離させろ > あとソフトウェア内部での盤面や指し手についてのデータ構造だな。 > プレイの間だけデータを持ってればいいのかセーブ・ロードが必要なのか > Redo/Undoが欲しいかなどの要求が考えられるから、それらに対応できるような > 構造になってると嬉しい。 そんなの一瞬で思いつちゃったｗ 棋譜データを記録すれば再現できる。 ['７六歩', '８四歩', '６六歩', '６二銀', ・・・] こんな感じだな。
412:デフォルトの名無しさん
16/05/22 17:46:53.68 EaQ4G/f7.net
将棋の思考ルーチンなんて
rand（）% 動かせる駒の数
rand（）% 置ける場所の数
の2行で十分
413:デフォルトの名無しさん
16/05/22 17:47:15.33 WwOYSBmy.net
>>403
お前センス無いんじゃね？
1つのクラスでいいよ。
共通化するにしても、2つだな。
1つのベースクラスに、それらのデータを入れておき、
継承したクラスで、ロジックだけを実装する。
こんなの設計と呼べるレベルじゃない。一瞬で思いつく。
414:デフォルトの名無しさん
16/05/22 17:48:23.90 vKoFE7Z9.net
棋譜と手・盤面の評価値の読み書きとかリプレイとか必要だな
評価値のパラメータやアルゴリズムを差し替えて比較・統計する機能もほしいな
415:デフォルトの名無しさん
16/05/22 17:48:31.84 sxeEi6BC.net
>>401
簡単なパターンを考えてみるのも有益かもな。
そっちもやってみる？
同時並行でやるとごちゃごちゃになるかなあ？
416:デフォルトの名無しさん
16/05/22 17:49:31.44 WwOYSBmy.net
よく読んだら、>>403って1機能＝1クラスにしようとしてるのか？
あほだなぁｗ
関数で済むものを、デザインパターンに当てはめて
複数のクラスにしようとしてるから
わけわからんことになってるんだろうな。
417:デフォルトの名無しさん
16/05/22 17:49:38.59 WENufHUB.net
>>401
もちろん業務に関する設計書はひととおり必要
要件定義から画面設計、テーブル設計などいるだろうね
でもこのスレって「オブジェクト指向システムの設計」だから
業務の設計よりももっと技術寄りのクラス設計などを語る目的なのかなと
418:デフォルトの名無しさん
16/05/22 17:49:49.83 sxeEi6BC.net
>>406
あー、そういうレベルね。
了解ｗ
具体例を出して正解だった。
419:デフォルトの名無しさん
16/05/22 17:51:02.87 WwOYSBmy.net
>>407
機能はたくさん欲しいのはわかったｗ
設計は、機能の多さとは比例しない。
棋譜データクラス（さっきから2次元配列クラスと読んでるもの）を
作ってそれらのメソッドを実装しろ。
420:デフォルトの名無しさん
16/05/22 17:52:51.72 sxeEi6BC.net
>>409
1機能1クラスなんて言ってないからちゃんと読もうね。
で、俺を批判するのに頑張るよりお前の考えるクラス構成を出したほうがよっぽど評価されるぞ。
頑張れ！
421:デフォルトの名無しさん
16/05/22 17:53:50.83 WwOYSBmy.net
>>411
そうしない理由を聞きたいんだが？ｗ
お前は理由もなく、設計と評して、
過剰なモジュール分割をしようとしているに過ぎない。
目的が設計になってる。
だから設計が必要だって結論になってる。
俺はこんな部分に設計はいらないと最初から言ってる。
だから設計が出ないのは当たり前。
設計というのはフレームワーク部分に使うものなんだよ。
通常の開発はフレームワークを使うから、設計はほぼ不要になる。
一体俺からなにを聞こうとしてるんだ？ 最初から無いと言ってるだろ。
無いと言ってるのに、無いに等しい物を言ったら、そのレベルとか心外だわｗ
422:デフォルトの名無しさん
16/05/22 17:54:20.75 sxeEi6BC.net
機能が拡張しそうな箇所を意識して設計するのも設計上の大切な指針だね。
423:デフォルトの名無しさん
16/05/22 17:56:04.18 WwOYSBmy.net
>>413
> で、俺を批判するのに頑張るよりお前の考えるクラス構成を出したほうがよっぽど評価されるぞ。
すでに出しただろ？
将棋のAIのアルゴリズムが難しいからと言って
ソフトウェアの設計も難しくなるわけじゃない。
将棋の設計は簡単。ほんの少ししか無い。
だからほんの少ししか言えることはない。
お前は、むやみに複雑にしているようだがなｗ
自分で機能をあれこれ言って、
それを自分で設計できないでいるんだろ？
お前が、自分で出した機能を設計できない時点で
そこに設計はないという証拠になってるんだがｗ
424:デフォルトの名無しさん
16/05/22 17:56:41.71 WwOYSBmy.net
>>415
> 機能が拡張しそうな箇所を意識して設計するのも設計上の大切な指針だね。
だから思考ロジック部分を分離しただろｗ
425:デフォルトの名無しさん
16/05/22 17:57:12.46 sxeEi6BC.net
>>414
> そうしない理由を聞きたい
ストラテジーパターンとか適用できそうだね。
> 設計はいらない
>>390
426:デフォルトの名無しさん
16/05/22 17:57:57.65 WwOYSBmy.net
>>418
> ストラテジーパターンとか適用できそうだね。
それ俺が言ったセリフだｗｗｗ
パクるなよwww
427:デフォルトの名無しさん
16/05/22 17:58:01.83 6l64NX2q.net
>>404
変わらないもの共用化できるものは分離して共通化した方がいいだろ
＞そんなの一瞬で思いつちゃったｗ 棋譜データを記録すれば再現できる。
それをどこにどう持たせるの？
あとそれをどう決めてもいいけど、どう決めたかを自分にも他人にもわかる形で
残さないといけないね。単純でコード見ればわかるってんならそれでもいいけど。
428:デフォルトの名無しさん
16/05/22 17:59:25.73 WwOYSBmy.net
あ、もしかして
> 1つのベースクラスに、それらのデータを入れておき、
> 継承したクラスで、ロジックだけを実装する。
これがストラテジーパターンになってるの気づいてないの？
429:デフォルトの名無しさん
16/05/22 17:59:46.97 sxeEi6BC.net
>>417
>>407はどう考慮したんだ？
そもそも機能拡張がありそうな点を意識するって知ってた？
実力を証明するには設計案を提示するしかないぞ。
430:デフォルトの名無しさん
16/05/22 18:01:00.43 sxeEi6BC.net
>>421
>>403に
局面を管理してる部分は局面の点数化と手を考えるロジックが変わっても変更する必要はない
とかあるだろうし。
って書いてあげたのに…。
431:デフォルトの名無しさん
16/05/22 18:04:19.72 WwOYSBmy.net
>>420
> 変わらないもの共用化できるものは分離して共通化した方がいいだろ
そのための設計って単純だよな？
> それをどこにどう持たせるの？
少なくとも思考ロジック部分じゃないな。
どの将棋ソフトウェアでも共通で使えるものなんだから。
だから今の話、思考ロジック部分の設計（？）には登場しない。
将棋ソフトフレームワークと呼べるものを作って、
対局データを記録できる機能があるならば、
対局クラスとかの中だろう。
で、やっぱり思考ロジックの "外" の話なんだよ。
432:デフォルトの名無しさん
16/05/22 18:06:05.23 WwOYSBmy.net
>>423
> 局面を管理してる部分は局面の点数化と手を考えるロジックが変わっても変更する必要はない
局面を管理してる部分は2次元配列クラスだと言ったんだがｗ
局面をもっと便利に管理したいならば、
この2次元配列クラスを拡張してメソッドでも追加しろよｗ
この程度の話、設計と呼べるレベルじゃないよ。
え？普通そうするよね？ レベルの話だ。
433:デフォルトの名無しさん
16/05/22 18:06:17.27 6l64NX2q.net
>>424
ああ、思考ロジックの中の話なんか
思考ロジックを外と分離するための話かと思ってた
434:デフォルトの名無しさん
16/05/22 18:11:47.45 sxeEi6BC.net
>>425
将棋のルール的なロジック
駒がどこに効いてるか？
駒が移動できる場所は？
駒の位置は？
と
点数化
手の選択
を一緒くたにしちゃうのは汚いクラス設計だとしか思わん。
お前は機能の違いについてセンスがまったくないから
これ以上話しても無駄だからもういいや。
少しはましな設計を思いついたら書き込んでくれ。
435:デフォルトの名無しさん
16/05/22 18:14:56.13 WwOYSBmy.net
>>427
だから、ベースクラスを継承すればいいっていっただろ。
なんでこの程度のことを大げさに考えてるんだ？
436:デフォルトの名無しさん
16/05/22 18:18:27.84 sxeEi6BC.net
>>428
ベースクラス？？
そんなのどこにあんの？
クラス構成聞いてるのに出てないのに突然持ち出されてもさあ…。
ごちゃごちゃ言い訳してる暇があるならまともなクラス構成を提示しろ。
提示できないのに「俺はすごいぞお」って言い張っても滑稽。
437:デフォルトの名無しさん
16/05/22 18:21:40.13 WwOYSBmy.net
> ベースクラス？？
> そんなのどこにあんの？
>>406にあるけど・・・？
438:デフォルトの名無しさん
16/05/22 18:23:12.23 sxeEi6BC.net
話は戻るけど
ちょうど今電王戦見てるから将棋ソフトで考えてみるとさ。
駒クラスがあって王・飛車とかは駒のサブクラスにしようかって感じだろ。
盤面情報と思考ロジックはどんな感じのクラスにするのがいいだろう？
ってどうなんだろう？
こんな感じのところと将棋ソフトで言えば手の思考ロジックの分割みたいな
領域で悩むことが多い。
439:デフォルトの名無しさん
16/05/22 18:26:05.60 sxeEi6BC.net
>>430
？？？
だから>>427の機能が全部ぶちこまれたクラスがあんでしょ？
違うなら違うで何を考えているのか明示しないとお前の考えてることなんて分かるかよ。
実際のプロジェクトでもドキュメントがなきゃこんな感じになって
ぐだぐだになるから設計書が必要だと実感できてよかったな。
440:デフォルトの名無しさん
16/05/22 18:28:39.50 sxeEi6BC.net
>>431
間違った。
具体的な質問はこっちだった。
盤面をクラスとして作るべきか、思考ルーチンの中で使われる情報に過ぎないのか？
って疑問がまず出てくるけどどう判断する？
違うクラス構成でもいいけど。
441:デフォルトの名無しさん
16/05/22 18:29:02.46 WwOYSBmy.net
うーん、こういうのも経験の違いってことなのかな。
どうも ID:sxeEi6BC って
最初から、完全なものを作らないとだめって思ってるみたい。
要求に対して変化させる能力（仕様変更能力）がないんじゃないか？
一番プレーンな状態からやって、○○したくなったら
それにあわせて変化させれば良いんだよ。
最初から必要になるかわからないものまで作る必要はない。
（ただし考慮は必要。考えるだけでやらなくていい）
思考ロジックの話でも、最初はクラス一つでいいだろ。
で、あとから共通化がどうとか言ってきたから、
俺は、ベースクラスにまとめれば？って答えた。
それだけのことだよ。後から何か言われたら、それに対応させて変化さえればいい。
それができないのはいろんなものを一緒くたにしてやろうとしてるからで
俺は役割に応じて分ける（最初から分けるのではなくて、分けていく）って
考え方をしてるので、大幅な設計変更は発生しない。
ただ単に実現したいことを実現するシンプルな方法（これを正しく判断できるのが経験なのだろう）を
選んでいくだけのことなのに。さっきから「そうするだけじゃん」の連続だよｗ
442:デフォルトの名無しさん
16/05/22 18:30:13.36 WwOYSBmy.net
>>432
> だから>>427の機能が全部ぶちこまれたクラスがあんでしょ？
だからなんの理由で分けるんだよｗ
「役割」考えれば、一つにするのが正しいだろ。
まったく最初から複雑にしてるんじゃねーよ。
443:デフォルトの名無しさん
16/05/22 18:30:39.58 JaLdteXY.net
少し目を離してるうちにレス番進みすぎだろ
この短い間にもこれだけの応酬があったってことか
やっぱりシステム開発には対話が必要なんだな
横着してドキュメントで済ませようとすると破綻する事がよくわかった
444:デフォルトの名無しさん
16/05/22 18:32:15.49 EaQ4G/f7.net
まあ、ドキュメントを書かないと意思の疎通はできんよね
複数のクラスがあるとしてソースを見る人間と
いやいやこんなもんクラス1つで十分ですよって人間と
混ざって開発することもあんだしね
445:デフォルトの名無しさん
16/05/22 18:32:23.86 WwOYSBmy.net
>>433
どっちでも良い。最初はシンプルに作れ。
後で機能が欲しくなったことを想定してるのなら、その機能を言え。
その機能を実現するように変えるだけだからさ。
クラス設計なんて条件で変わるものなのに、
後出しで条件加えんなよ。
仕様としては単に将棋出来ればいいだけだろ？
446:デフォルトの名無しさん
16/05/22 18:34:07.77 sxeEi6BC.net
>>434
>>390
同じことを何度も言わせるな。
どうしようもない設計からスタートさせてくれって言う設計者はいらない。
>>435
こりゃだめだｗ
447:デフォルトの名無しさん
16/05/22 18:34:18.62 EaQ4G/f7.net
>>438
ちなみに実際の開発で後出しかどうかなんてドキュメントも書いてないのに
主張できんの?
448:デフォルトの名無しさん
16/05/22 18:36:52.59 8h3SPrnH.net
よく判らんけど将棋のコマに主体性があればクラスなりオブジェクトなり構成できると思うけど
将棋のコマって全体を表現するときの1要素、データに過ぎないじゃないの
コマの状態や全体を評価して処理するのは別のプログラムーアルゴリズム
コマが主体性をもって勝手に無双するなら関係があるかも知れないけど
コマの種類ー行動範囲ー状態(手ゴマ、版面での位置、成金など)の一覧で表現できる単純な1要素
肝は、それら要素を含む版面全体を評価処理する部分じゃないか
版面のリストデータを評価する関数部分かな
449:デフォルトの名無しさん
16/05/22 18:38:05.06 sxeEi6BC.net
>>438
これが後出しってさあ…。
まず、>>358
で将棋ソフトって言われたら簡単に予測できる。
実際の客なんてこっちが聞かなきゃ説明しないことなんて山ほどあるぞ。
もう語れば語るほど経験のなさが露呈するだけだからやめとけ。
450:デフォルトの名無しさん
16/05/22 18:39:04.38 WwOYSBmy.net
>.437
> 複数のクラスがあるとしてソースを見る人間と
> いやいやこんなもんクラス1つで十分ですよって人間と
そんなふうに考えてるやついないぞｗ
実際には複数のクラスに分かれているのを見て、
拡張性を考えた設計だなって読み取れる人と
なんでそうなってるのかわからない。
分ける理由もわからない。っていう技術力の低いやつだけだ。
451:デフォルトの名無しさん
16/05/22 18:40:13.61 WwOYSBmy.net
>>439
> どうしようもない設計からスタートさせてくれって言う設計者はいらない。
シンプルな設計からスタートさせてくれって話なんだが？
なんでシンプル＝どうしようもない設計なんだ？
根本的にお前おかしい。
世の中のありとあらゆるソフト見てみろよ。
最初はどれもシンプルだろ。
452:デフォルトの名無しさん
16/05/22 18:41:15.88 WwOYSBmy.net
>>442
> で将棋ソフトって言われたら簡単に予測できる。
じゃあ、将棋ソフトっていうからさ、
予測してみ。
もちろん実際の客（俺）が考えてるものの予測だ。
余計なもの作るなよｗ
453:デフォルトの名無しさん
16/05/22 18:42:12.34 WwOYSBmy.net
>>441
> 将棋のコマって全体を表現するときの1要素、データに過ぎないじゃないの
普通はその通り。
俺からすれば、普通そうするよね？の当たり前の連続でしか無い。
これを設計なんて感じたこともねーわｗ
454:デフォルトの名無しさん
16/05/22 18:42:22.89 sxeEi6BC.net
>>441
駒の動けるマスとか成りルールとかはクラスに持たせてもいい気がするなあ。
たいした情報じゃないからクラスにするまでもないけど。
ルールをどうやってクラスに割り当てるかも悩ましいな。
実装方法の候補はいくつか簡単に思いつくけど、どれを選択するかの基準は難しい。
455:デフォルトの名無しさん
16/05/22 18:42:52.06 sxeEi6BC.net
たいした情報じゃないからクラスにするまでもないのかもしれないけど。
456:デフォルトの名無しさん
16/05/22 18:45:23.45 WwOYSBmy.net
>>447
だからそんなの将棋ソフトの機能に合わせて
ごく普通に作ればいいだけだろｗ
今は超シンプルな将棋ソフトの話なんだから
複雑なクラスにする必要はない。
機能が増えたらそれを実現するように変えればいいだけ。
最初っからいろいろやろうとするから
お前は混乱して、何も手を付けられなくなってるんだよ。
457:デフォルトの名無しさん
16/05/22 18:48:50.87 WENufHUB.net
勝つまで言い争いをやめないID:sxeEi6BCもどうかと思うけど
ID:WwOYSBmyが逃げ回ってるようにしか見えないね
将棋ソフトって考慮時間が必要なくらい中身が複雑なものだから
ベースクラスと継承クラスの2つのシンプル実装で済むはずがない
将棋に勝つソフトではなくて
ルール通りにコマを進めるソフトぐらいならそれでもできるかもしれんが…
458:デフォルトの名無しさん
16/05/22 18:49:31.70 8h3SPrnH.net
クラスにして楽なのは、何らかのデータを保持させて
シンプルな問い合わせで有益な回答がもらえる状態
今回の将棋の場合、コマの種類ごとにクラスとオブジェクトを作って
版面データに配置して、飛車さん何処に動けますか？、何かコマは取れますか？
次の一手で取られるような危険な状態ですか？って問い合わせて
その情報を利用して版面全体を評価判断するプログラムーアルゴリズムが別途必要
だけど、この処理にコマのクラスとかは必須ではない
版面データを一桝ずつ調べて評価しても別にかまわない
459:デフォルトの名無しさん
16/05/22 18:51:31.18 6l64NX2q.net
設計の話をしているのかプロセスの話をしているのか。
設計の話をしているなら最終的な結果をある程度イメージしたクラス構造を提示してって話になるが、
プロセスの話をしているなら、将棋のAIなんてロジックによって処理の内容もデータの持たせ方も
変わる可能性があるから、設計やドキュメント作成をしっかりやろうとすると戻り作業の負荷が大きくなるので
>>434でいいってことになる。
460:デフォルトの名無しさん
16/05/22 18:53:08.67 sxeEi6BC.net
>>451
書かれている内容は同意なんだけどどちらかの方法を選択するわけじゃん。
そのときの指標ってどんなんだろ？って話がしたい。
将棋の場合に限定せずに、例えばそんな場合にって感じで。
461:デフォルトの名無しさん
16/05/22 18:55:00.41 sxeEi6BC.net
>>452
俺はクラス構成について意見聞きたい。
そう書いたのは流れたんだろうけど。
462:デフォルトの名無しさん
16/05/22 19:11:48.08 8h3SPrnH.net
クラスをデザイン、インスタンスを作ってデータを大量に食わせて
内部関数に知的判断をさせて答えを取り出す
小さな知的データベースみたいな振る舞いをさせた時が使うとき一番楽ができる
struct の内部手続きの管理を容易にするのがクラスだって部分に焦点を当てると
クラス内部のメンバ変数を利用した処理で知的判断が完結できる場合だと思う
アルゴリズムーデータ構造ー＞プログラム この関係がクラス内で完結する場合
一番力を発揮するんじゃないかな
C++始めて2週間だけど言ってみるｗ
463:デフォルトの名無しさん
16/05/22 19:13:56.11 fKm+A9/1.net
将棋AIは自社で作れないのでここは外部サービスになる
自社で作成しなければならない部分は将棋盤のMVCと将棋AIサービスのACLだけ
この案件は規模が小さすぎるから設計するまでもなくフレームワークを使って手短に仕上げて終わりかな
464:デフォルトの名無しさん
16/05/22 19:21:02.25 WwOYSBmy.net
>>450
> 将棋ソフトって考慮時間が必要なくらい中身が複雑なものだから
竹内関数も考慮時間が必要なぐらいですが、
設計は難しいですか？
なんで再帰処理に時間がかかるだけなのに
設計の話が出てくるんだよｗ
465:デフォルトの名無しさん
16/05/22 19:21:47.06 WwOYSBmy.net
>>454
> 俺はクラス構成について意見聞きたい。
だからクラス構成は搭載する機能によって変わってくる。
今はシンプルな機能でいいって話なんだから、クラス構成もシンプル。
何度も言わせんな。
466:デフォルトの名無しさん
16/05/22 19:27:38.99 WENufHUB.net
>>457
都合のいいとこだけ切り取るなよ
ユーザーに勝つアルゴリズムを
ベースクラスと継承クラスの2つだけで実装できんの？
1クラスに何十万行書くつもりかな？
467:デフォルトの名無しさん
16/05/22 19:28:21.77 fKm+A9/1.net
>>454
>>456が答え
AIサービスの内部の話をしてるなら
クラスもOOPも使われない、が答え
何故なら遅いから
468:デフォルトの名無しさん
16/05/22 19:32:21.96 WwOYSBmy.net
ここまでの流れでよく分かったろ？
あいつは将棋の思考ロジックの設計はどうすればいんだ？って
うんうんうなってばかりで、何も作れていない。
必要な理由もないくせに、小さなクラスに分けようとしている。
一方俺はシンプルな 1クラスから初めて、後出しで条件が出るたびに
その条件をみたすように、バージョンアップし続けていっている。
469:デフォルトの名無しさん
16/05/22 19:35:11.10 WwOYSBmy.net
>>459
実装できるだろ？
470:デフォルトの名無しさん
16/05/22 19:43:42.95 WwOYSBmy.net
「ユーザーに勝つアルゴリズム」をクラス2つで実装できんの？とか
言ってる時点で、普通の人は違和感持つよね？
その言い方だと、ユーザーに負けるアルゴリズムならば、
クラス2つで実装できる思ってるように聞こえる。
ユーザーに勝つかどうかは評価関数（繰り返すけど関数な）の
出来で決まるので、クラスの中の一関数にすぎない。
またコードが長ければ、ユーザーに勝てるとか思っていそう。
コードの長さと強さは関係ない。
471:デフォルトの名無しさん
16/05/22 19:57:01.68 EaQ4G/f7.net
>>444
それじゃ見積れないじゃん
今回の開発ですけど全部でどのくらいかかりますか?
概算でいいんでお願いします
472:デフォルトの名無しさん
16/05/22 20:05:41.89 WwOYSBmy.net
>>464
話がめんどくさくなりそうなので
あんたがこの話に同意すると言ってからねｗ
プログラマが知るべき97のこと.com/エッセイ/見積りとは何か
URLﾘﾝｸ(xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com)
473:デフォルトの名無しさん
16/05/22 20:07:14.83 WwOYSBmy.net
>>464
もう一つ。
開発の見積もりとスケジュール管理
見積もりとスケジュールとコミットメントは違う
URLﾘﾝｸ(techlife.cookpad.com)
474:デフォルトの名無しさん
16/05/22 20:11:54.86 EaQ4G/f7.net
>>465
他人のドキュメントが出てきちゃったぞ（笑）
475:デフォルトの名無しさん
16/05/22 20:12:46.40 WwOYSBmy.net
信頼できるソースを持ってくると、
他人のドキュメントとかいい出すやつかｗ
476:デフォルトの名無しさん
16/05/22 20:18:21.48 EaQ4G/f7.net
>>468
読んでないけど
お客さんにもそれ読ませて合意取ってるの?
477:デフォルトの名無しさん
16/05/22 20:18:56.63 WwOYSBmy.net
>>469
お前に読めって言ってるんだけど？ｗ
478:デフォルトの名無しさん
16/05/22 20:20:20.00 EaQ4G/f7.net
>>470
なんで?
設計書書かないでやるのにそんなの必要ないじゃん
479:デフォルトの名無しさん
16/05/22 20:21:47.98 SSySxKMQ.net
>>341
なんかめっちゃ進んでるｗｗｗ
> 税制の変更やら社内ルールの変更やらは想定される訳で
そういう類
480:なら設定ファイルなりイベントテーブルなり……オブジェクト指向とは別のところでどうにかするかな アルゴリズム云々は大量に出てると思うけどストラテジーを真っ先に考えると思うよ > 設計段階で洗い出さないならいつ設計するんだ？ バリデーションの例での話だけど バリデーションの為のオブジェクト洗い出しなんてしないなあ なぜならフレームワークで基底を提供してるから
481:デフォルトの名無しさん
16/05/22 21:33:06.14 sxeEi6BC.net
>>472
将棋ソフトのクラス構成って例で考えてみてよ。
業務システムの設計で悩むところとだいたい同じようなことは出てくるから。
482:デフォルトの名無しさん
16/05/22 21:46:19.29 bOnbURFw.net
ドキュメントのいるいらない話と設計のいるいらない話がやけに盛り上がってるけどスレチっていう。
483:デフォルトの名無しさん
16/05/22 21:53:33.02 SSySxKMQ.net
>>473
ゲームマスター……どこにどの駒があるとかどっちの番とかコントロールするやつ
ビュー……UI担当
思考……たぶんコンピューターの強さ別に思考ルーチン考える(か、深さを変える程度かどっちか)
ストラテジーするのは思考のところ
あんま練ってないから抜け漏れあるだろうけどぱっと考えておおまかにこんなもんじゃないかな
将棋だと後からプレイヤーが3人になるとか10×10になるとか駒の種類が増えるとかないから……
484:デフォルトの名無しさん
16/05/22 21:57:19.19 sxeEi6BC.net
>>475
思考部分がメインになるけどどう構成する？って疑問。
将棋ソフトについては観戦してちょこっとネットを読んだ程度で詳しくはないけど
将棋のルール
候補手の分岐
点数評価
駒の情報
盤面の情報
とかはあるでしょ。
485:デフォルトの名無しさん
16/05/22 21:59:56.19 sxeEi6BC.net
思考部分は定跡を考慮したり、
駒の配置を元に点数を評価したり、
詰み専用のルーチンがあったり、
パラメータを調整したり、
評価の際に考慮する要素を変えてみたり、
今は実現してるソフトはないみたいだけどディープラーニングを実装したり
と頻繁に改修されている模様。
486:デフォルトの名無しさん
16/05/22 22:03:46.50 SSySxKMQ.net
思考部分ってアルゴリズムをどうするかって話であって
OOPの設計とは違う話ではないかな?
487:デフォルトの名無しさん
16/05/22 22:06:26.17 sxeEi6BC.net
>>478
思考部分をどのようなクラスで構成するかって考えるのはオブジェクト指向設計だろ。
488:デフォルトの名無しさん
16/05/22 22:12:39.67 SSySxKMQ.net
>>479
構成はストラテジーパターンと思ってるよ
easyレベルの思考パターン、normalレベルの思考パターン……みたいな感じ
逆に聞くけど
将棋のルールオブジェクト、候補手のオブジェクト、点数評価オブジェクト……みたいなのを作るの?
489:デフォルトの名無しさん
16/05/22 22:14:07.31 sxeEi6BC.net
駒が何種類かあって
動きのルールがあって
盤面に配置されていて
配置された駒が動けるマスがあって
駒の配置とかを見て点数をつけて
ってのを
複数の商品があって
工場や倉庫があって
社内ルールがあって
流通があって
注文があって
最適な生産計画を立てる
みたいな話に置き換えれば思いっ切り業務システム。
業務より将棋のほうがみんな分かっているし、
顧客のルールのヒアリングとかする必要もないから将棋で考えてると思えば
十分現実的に有益な例と言える。
490:デフォルトの名無しさん
16/05/22 22:21:13.03 sxeEi6BC.net
>>480
そこまで具体的になっていないから他の人の考えを聞きたいってレベル。
機能的には
駒クラスと盤面クラス（データの集合でクラスにする必要はないかもしれない）
盤面クラスから合法手を抜き出す処理
抜き出した候補手を絞る処理
候補手を動かしてみた盤面を点数化する処理
最高点の手を選択
かなあと。多少漏れはあるかもしれないけど。
で、ルールについては駒クラスに一部持たせることもできるけど
ルールはまとめてどこがで持たせたほうがすっきりする気もするなあってぼんやり。
合法手を出す部分は手を考える部分とは関係なく共通だから
思考ルーチンのクラスとは分けたほうがいいだろうな。
って程度。
491:デフォルトの名無しさん
16/05/22 22:21:22.93 SSySxKMQ.net
>>481
これは>>480への回答……ではないよね
俺は現実的でないとも無益だとも主張してないので
俺の質問は>>481が設計者なら
将棋のルールオブジェクト、候補手のオブジェクト、点数評価オブジェクト……みたいなのを作るの?
ちょっと変えて どんな風に作るの? でもいいけど
492:デフォルトの名無しさん
16/05/22 22:21:45.17 SSySxKMQ.net
>>483
ごめん>>482見る前に書いたから見なかったことにして
493:デフォルトの名無しさん
16/05/22 22:25:17.11 SSySxKMQ.net
>>482
具体的になってないっていってるのにこう言っていいかわからんけど
クラスと処理が一緒に書かれてると
正直いまいちわからん
>>473の流れからクラス構成の話をしてるはずなので
クラスと処理は明確に分けてくれると嬉しい
494:デフォルトの名無しさん
16/05/22 22:28:36.60 sxeEi6BC.net
>>485
そこは俺自身がつめられていない。
明確になっていないのが現状であるのと
自分の考えを言っちゃうと他の人のアイデアが出ににくくなりそうだから
しばらく待ってみようとも思ってる。
495:デフォルトの名無しさん
16/05/22 22:31:43.20 SSySxKMQ.net
>>486
なるほど了解
とりあえず俺は>>475ってことで
他の人待ちになるよ
496:デフォルトの名無しさん
16/05/22 22:37:22.72 hyVMxkhK.net
で、>>1―>>487までのことをかる～く理解するには何が必要？
497:デフォルトの名無しさん
16/05/22 22:43:46.32 3jWKTqcS.net
誰に合わせてレベルが下がってるのか知らんが
デザパタという用語の飛び出し方と
ストラテジーというパターンの居座り方が不思議
小学生が得意げに掛け算の七の段暗唱してみせてるような不気味さがある
小学生が持ち寄った安モンのプラモをいつまでも机に乗っけてる不気味さがある
このゾッとする感じ分かる奴はROMってニヤニヤしてんだろうな
498:デフォルトの名無しさん
16/05/22 22:45:11.25 sxeEi6BC.net
>>488
ドキュメントなんて書く必要ないだろって主張する人がいた。
設計なんていらないって主張する人がいた。
肯定派と否定派で不毛な争いを続けた。
設計否定派「そんなのなくても設計できるんだ！」
だったら、不毛だから将棋システムのクラス構成をするってで考えてみようぜ。
>>346
>>431
あと、直近のレス10個くらい。
これでほぼ追いついた。
499:デフォルトの名無しさん
16/05/22 22:47:07.15 sxeEi6BC.net
>>489
こういう不毛なレスをする奴に送る言葉
「将棋ソフトの設計を提示してくれ」
できないならじゃまなだけだから黙ってて。
500:デフォルトの名無しさん
16/05/22 22:52:23.14 hyVMxkhK.net
>>490
だな
501:デフォルトの名無しさん
16/05/22 23:35:43.97 EaQ4G/f7.net
>>476
そんなとこメインに何の?
中身はどうあれ入力は将棋盤の現在の状況と両者の持ち駒とちょっとした設定（難易度とか?）
出力は次の一手って決定してるし
関数で中身が超絶長くてもクラス分ける必要は仕様によってはないと思うよ
502:デフォルトの名無しさん
16/05/22 23:44:55.34 sxeEi6BC.net
>>493
>>476読んで１つのクラスにまとめるって違和感ある。
>>481とかも読んで。
それでも全部１つのクラスにぶっこむって言うなら「あぁそう」って感じだ。
思うことはあるけど議論しても不毛だってこのスレで学んだから見解の相違ってことで。
503:デフォルトの名無しさん
16/05/23 00:10:47.30 oqijX3By.net
451で思ったのは、例えば
駒の動きのバリエーションが100パターン以上あるとか
もしくは仕様変更で追加されたり、局面により動的に動きが変わったり
といったことが頻発する場合にはオブジェクトに債務を任せるってのは有効だと思われる。
将棋くらいルールが固定されているものを取り扱っても
設計の善し悪しって意味を持たない気がするよ。
504:デフォルトの名無しさん
16/05/23 00:14:58.15 qUt6/ya8.net
>>495
そこは>>453
あと>>477
505:デフォルトの名無しさん
16/05/23 00:19:18.67 qUt6/ya8.net
あとは駒や盤面をクラスにするかどうかはさておき
それらを保持するためのデータ集合は必要だし、
それらを参照するロジック郡があることは確実。
その場合のきれいな構成はどうなるって話。
オブジェクトにしない設計選択するからって機能的に独立している部分も含めて
すべてを1つにつなげるのがきれいな設計だとは俺は思わない。
506:デフォルトの名無しさん
16/05/23 00:20:52.30 qUt6/ya8.net
オブジェクト指向以前の設計だって機能的に独立している部分はモジュールに分離することが推奨されていた。
507:デフォルトの名無しさん
16/05/23 00:36:52.91 oqijX3By.net
>>497
適当に作ってもこの場合、そこまで汚くはならんだろう。
逆に駄目な設計例を紹介する方が難しいんじゃないか。
何度も言うけど将棋くらい盤面、駒、ルールが固定されているものを例に
設計の善し悪しを語るのはあんま筋が良くないように思う。
508:デフォルトの名無しさん
16/05/23 00:40:16.62 qUt6/ya8.net
将棋ソフトが単純だと思ってるならその前提が俺とは違うんだろうね。
複雑なシステムを1つのクラスにまとめるのがいい設計だと思ってるなら
俺の知ってるオブジェクト指向設計とは違うな。
509:デフォルトの名無しさん
16/05/23 00:56:16.41 wJJwI8Yd.net
複数人で開発してもうまくいかない類のもの
設計も必要と思えない
510:デフォルトの名無しさん
16/05/23 01:17:43.31 2wwYSKoz.net
>>500
どう考えても将棋ソフトは単純だろｗ
511:デフォルトの名無しさん
16/05/23 01:19:28.34 2wwYSKoz.net
>>481
> 最適な生産計画を立てる
> みたいな話に置き換えれば思いっ切り業務システム。
なんで全く関係ない話を置き換えてるんだ？ｗ
512:デフォルトの名無しさん
16/05/23 01:20:59.57 2wwYSKoz.net
>>495
> 将棋くらいルールが固定されているものを取り扱っても
> 設計の善し悪しって意味を持たない気がするよ。
その通り。
ルールが固定されているものなのに、
それを業務システムの規模と同一視して
複雑な設計を作り出す
バァカ（笑）がいる。
513:デフォルトの名無しさん
16/05/23 01:21:26.32 DQBja8MH.net
MaxFlow書けば一発みたいなシステムだなw
514:デフォルトの名無しさん
16/05/23 01:29:00.13 qUt6/ya8.net
ID:2wwYSKozは昨日さんざん喚いていた奴だろ。
相手にするのは不毛だと分かったから頑張って書き込んでもらってもスルーするのであしからず。
515:デフォルトの名無しさん
16/05/23 03:34:57.55 7DLF1n9w.net
将棋ソフトの人間同士が対局する前提ならシンプル
コンピューター将棋の思考ルーチンをなにを使いどう実装するのかは別の話
ここら辺はマジ難しい部分
この難しい評価関数の構造に対してのオブジェクトのクラス構造を語るのは
騙るに等しい無為な行為
クラスの要件定義？を書き上げていくといきなりどう実装するか
これでよいのか判断できなくなっていきなり脳みそ爆発じゃないの
この場合の評価方法って膨大な組み合わせから条件事に状態を抽出
その集合へ評価関数で比較の為に数値化(この数値化の基準が凄く難しい肝の部分)
これを盤面全体かつ何手先まで計算するのかって事でここら辺に膨大な
処理速度なり消費メモリーなりのリソースが必要
516:デフォルトの名無しさん
16/05/23 07:54:00.86 RiQgyPKS.net
ゲーム開発者居ないのか
ボードゲームにOOPとかどんだけだよ
517:デフォルトの名無しさん
16/05/23 08:42:24.80 bDXz1lkX.net
ゲーム開発にOOPぶち込むのやめてください死んでしまいます
518:デフォルトの名無しさん
16/05/23 09:18:47.98 KJgou+2q.net
駒クラスみたいに全ての各駒クラスが実装するものはクラスじゃなくてインターフェースにするべきだし
もっと言うなら駒みたいに種類が限られてるいるものは列挙型にするべきだろう
関数型にしよう（提案）
519:デフォルトの名無しさん
16/05/23 09:31:33.26 2wwYSKoz.net
>>509
ゲーム開発にOOPを入れるのは常識なんだが。
思考ロジック（評価関数）の中身をOOPにするとかは意味不明
520:デフォルトの名無しさん
16/05/23 09:54:28.34 KJgou+2q.net
というかゲーム作るのに使う言語は大体OOPだと言う
Rustとか使うんならOOPじゃなくていいし（Rustの型システムは独特だから関数型と言っていいのかもわからんけど）
521:デフォルトの名無しさん
16/05/23 10:09:17.37 bDXz1lkX.net
ゲーム作るのに使う言語ってアセンブリとかCとかじゃないの？（すっとぼけ）
522:デフォルトの名無しさん
16/05/23 11:29:21.76 qUt6/ya8.net
将棋ソフトのクラス設計が不適切って言うなら
複数の商品があって
工場や倉庫があって
社内ルールがあって
流通があって
注文があって
最適な生産計画を立てる
ってシステムのクラス構成を書いてくれ。
生産計画について知らないならググって自分で理解してくれ。
分からないことを調べるのは設計者として当然のこと。
完全な正解なんて求めていないし、要件については一般的と思われるもので
適宜補完してくれていいから。
生産計画なんて調べたくないって言うなら将棋ソフトで考えような。
523:デフォルトの名無しさん
16/05/23 11:37:07.78 qUt6/ya8.net
将棋ソフトのロジックをオブジェクトにしないっていうなら
そういう選択をしてもらってもいいけど、その場合の設計・システム全体の構成は
どうなるのか提示してくれ。
機能的に独立している部分が完全に密結合した設計じゃだめだろ。
オブジェクト指向以前から機能的に独立している部分はモジュールに分離することが推奨されていた。
それと、
思考部分は定跡を考慮したり、
駒の配置を元に点数を評価したり、
詰み専用のルーチンがあったり、
パラメータを調整したり、
評価の際に考慮する要素を変えてみたり、
今は実現してるソフトはないみたいだけどディープラーニングを実装したり
と頻繁に改修されていることも考慮した設計にしてくれ。
これは電王戦も見ていたら開発者が言っていたことなんで事実。
524:デフォルトの名無しさん
16/05/23 11:44:28.52 qUt6/ya8.net
思考ルーチンについては
URLﾘﾝｸ(ja.wikipedia.org)
に説明があったからイメージできない人は読んでみてくれ。
もちろんこれを実装する処理フローなんて不要で、情報とロジック群の構成を
設計として整理してくれれば十分。
525:デフォルトの名無しさん
16/05/23 11:50:00.86 qUt6/ya8.net
思考ロジックをオブジェクトにしないならしないでいいけど
それならオブジェクトを使わない思考ロジックを設計を書いてくれ。
オブジェクト指向設計じゃなくても「思考ロジックがあります。以上」なんてあり得ないから。
昨日から言ってるんだけど「思考ロジックはオブジェクトじゃない」
って言ってる奴がいるので分かりやすくもう一度。
526:デフォルトの名無しさん
16/05/23 11:53:16.96 DQBja8MH.net
こいつ議論する気ないだろ
宿題でもやってもらおうと思ってんのか？
527:デフォルトの名無しさん
16/05/23 11:55:13.23 qUt6/ya8.net
>>518
設計できない、興味ないならやらないでいいんだよ。
お互い関わりたくないからわざわざ来んなよ。うっぜー。
528:デフォルトの名無しさん
16/05/23 12:04:07.88 wJJwI8Yd.net
そしたら将棋ソフトの設計というスレタイで作り直しなよ
それだったら俺も最初から見に来なかったわ
529:デフォルトの名無しさん
16/05/23 12:14:49.83 RiQgyPKS.net
設計してやってもいいが金は誰が出すんだ？
530:デフォルトの名無しさん
16/05/23 12:34:01.34 qUt6/ya8.net
>>520
オブジェクト指向設計についての話題なら大歓迎だぜ。
指針とか経験とかいい本とか。
ドキュメントは不要、設計プロセスは不要、とかスレと関係ない書き込みをしつこく
する奴がいて役立つ情報がまったく得られないから設計スキルが低いだけの奴との無駄なやり取りを
避けるためにこうした経緯。
531:デフォルトの名無しさん
16/05/23 12:35:12.57 qUt6/ya8.net
>>521
興味がある人だけやってくれ。
532:デフォルトの名無しさん
16/05/23 15:48:51.47 0LMZvZN5.net
>>509
ゲーム開発こそOOP無いと死んでしまいます。
継承も移譲も必要
533:デフォルトの名無しさん
16/05/23 15:53:56.75 KJgou+2q.net
(継承すると仮想関数テーブル使って遅いから)死ぬ
静的ディスパッチ使えみたいな人かも知れん
534:デフォルトの名無しさん
16/05/23 18:09:38.65 8ShGEso2.net
>>522
まるで自分はスキル高いみたいな言い方だね
535:デフォルトの名無しさん
16/05/23 18:30:21.54 bDXz1lkX.net
将棋AIに興味があるんだけど
金は誰が出してくれるんだ？
536:デフォルトの名無しさん
16/05/23 19:35:13.90 qUt6/ya8.net
>>526
「俺のほうがすごいー！」みたいなくだらない言い争いをする気はないから
設計に自信あるならきれいなクラス構成を作って見せて。
537:デフォルトの名無しさん
16/05/23 19:36:48.86 qUt6/ya8.net
>>527
上位入賞すればニコニコから賞金もらえるぞ。
興味あるなら設計を考えるところからスタートだ。
538:デフォルトの名無しさん
16/05/23 21:08:34.53 tNl+V9er.net
>>517
> 思考ロジックをオブジェクトにしないならしないでいいけど
> それならオブジェクトを使わない思考ロジックを設計を書いてくれ。
> オブジェクト指向設計じゃなくても「思考ロジックがあります。以上」なんてあり得ないから。
じゃあ模範例を言ってくれ。
俺からすれば、思考ロジックの設計？何いってんの？状態なんだよ。
聞いているのがアルゴリズムなら意味はわかる。だが設計とか意味不明。
将棋の思考ロジックは再帰の連続だろうから、近しい例で再帰を使った二分探索とかどうだ？
二分探索の設計とやらをお前が言ってくれ。ついでにオブジェクト指向で設計してもいいぞ。
そうすればお前が何を求めているかがわかる。
539:デフォルトの名無しさん
16/05/23 22:12:51.54 xFXxeOBl.net
自分は何も出さずに人には出せと言う
出せばここダメあれダメと得意気にダメ出し
もっと建設的なお話しはできないのかね
540:デフォルトの名無しさん
16/05/23 22:25:01.38 k9BlaHRb.net
なんか複雑なクラス構成じゃなきゃいかんという思い込みが強いのだと思う
541:デフォルトの名無しさん
16/05/23 23:23:30.08 MlMGnhEf.net
>>531
無理ですよ
発言内容を見れば素人とわかります
542:デフォルトの名無しさん
16/05/24 00:02:49.39 6RFz1ZJQ.net
>>533
くそみたいな設計しか提示できない素人が偉そうにｗ
543:デフォルトの名無しさん
16/05/24 00:11:33.80 6RFz1ZJQ.net
>>531
クラスが不要だと思うならクラスを使わない設計をしてくれって何回言えば分かるんだ？
>>530
>思考ロジックの設計？何いってんの？状態なんだよ。
将棋ソフトの設計はあなたに任された。
構築は数人のチームでやる。（数人いらないってなら1人でもいいけどとにかく別の人。）
ってケースで想定してくれ。
設計したらお客さんに見せて確認して、構築チームに回す訳だ。
その設計書に将棋ソフトを構成する機能を書いて、
主要なクラスないしモジュールを書くのは常識。
まさかすべてのコードを1つの巨大ファイルに押し込むつもりじゃないだろ？
544:デフォルトの名無しさん
16/05/24 00:12:58.09 6RFz1ZJQ.net
>>531じゃなくて>>532だった。
545:デフォルトの名無しさん
16/05/24 00:17:34.70 yaJTawf0.net
将棋ソフトなんて難しすぎて無理だよ
もちろん金積めばできるけど
掲示板の書き込みで片手間でできるレベルではない
546:デフォルトの名無しさん
16/05/24 00:19:52.06 6RFz1ZJQ.net
>>530
>>531
模範解答を出せという気持ちは分かるけど
これまで提示された設計じゃレベルが低過ぎて会話しても
何も得るものがないと思う。
実際のプロジェクトで客に設計書を提出した経験がある奴はいないだろ？
自分の設計スキルが最高だとは思ってないから、
俺より設計スキルを持った人が登場してくれてささっと素敵な構成を提示してくれるなり
指針を提示してくれるのを待ちたい。
547:デフォルトの名無しさん
16/05/24 00:28:56.57 6RFz1ZJQ.net
>>537
将棋ソフトから離れて有益な会話が始まるなら理想だし、そうなって欲しいとは思ってるけど
具定例がないと抽象的で無意味な議論に戻る気がするなあ。
有益な会話が始まったら将棋ソフトのことなんて忘れてもらっていいけど。
あと、難しいって言うけどあんまり単純だったらそもそも悩まないじゃん。
将棋ソフトにこだわりはないから他に適切な例があればそっちで考えてもらえばいいと思うけど何かある？
548:デフォルトの名無しさん
16/05/24 00:32:46.56 6RFz1ZJQ.net
いきなり完成するのは難しいならまずはモデルクラスから考えてみるのはどうだろ。
メモリとかパフォーマンスはいったん忘れて設計したらどうなるだろ？
549:デフォルトの名無しさん
16/05/24 00:39:17.52 24rCrc9d.net
>>537
駒は代数的データ型使おう
盤は単純に配列かMapでいいべ
UIはオブジェクト指向が良さそう（適当）
そういえばここで言われてるドキュメントってjavadocみたいなやつ？
ドキュメント要る派VS要らない派(コードが成果物)がどの範囲までをドキュメントと呼んでるのかわからん
>>537
将棋AIは難しいけど逆にAI以外は難しくないから（グラフィック凝らない限り）
いっそオセロとかにするとスゲー簡単になるなー
550:デフォルトの名無しさん
16/05/24 00:49:07.65 iG1UUWT4.net
本気で議論したいなら
まず自分が作ってみて
こんなんなったがどう思うよ
ってやった方がいいんじゃね?
551:デフォルトの名無しさん
16/05/24 00:50:35.99 6RFz1ZJQ.net
>>541
難しい場合は論理的な設計から始めることが一般的に推奨されている。
論理的とは代数的データ型やらMapやらの実装寄りのことは忘れて
システムの構成要素とその関係を考えること。
駒、駒が動けるマス、盤面、盤面ごとの合法手みたいな情報がいろいろあるけど
それらの情報の関係とか何がクラスで何が属性なのかとかをはっきりさせる。
一般的な開発プロセスではMapとかを考え出すのはその後。
（違うプロセスがあるならそれでやってもらって結果を提示してね。）
ドキュメントは基本は文章と図。
実際のプロジェクトならお客さんにヒアリングしながら確認する必要があるから
お客さんも理解できるもの。
コードが完成してない状態でプロジェクトメンバーにも見せるから
コードはその時点ではないし。
552:デフォルトの名無しさん
16/05/24 00:57:32.21 6RFz1ZJQ.net
>>542
まあねえ。
様子見ながら考える。
正直なところ、>>358とか、>>431とかみたいに悩むポイントを提示しつつ
いろんな意見を聞きながら進めたかったんだけど、反応がほとんどなかった一方で
「思考ロジックはクラスじゃない」だの「将棋ソフトはおかしい」だの一部の連中が騒ぐから
だったらお前らの考えを言えよってなったのはある。
>>358とか、>>431とかについて意見交換できるならやりたいぞ。
553:デフォルトの名無しさん
16/05/24 01:00:51.27 6RFz1ZJQ.net
「思考ロジックはクラスじゃない」って考えは否定はせんな。
ただ、それにしたって設計は必要だからどんな設計になるかは考える必要があって
思考ロジックはクラスじゃないから設計いらないみたいな発想はおかしいと思う。
が正確だな。
554:デフォルトの名無しさん
16/05/24 01:04:03.54 KRMd4EzS.net
取り立てて機能のない将棋ソフトに
設計なんか必要だと思うほうが間違ってるよね
こんなのz80でだって動くんやで
豪勢なのは思考ルーチンだとしても将棋ソフト本体への入出力が決まってる以上複雑にはならんね