- 1 名前：デフォルトの名無しさん [2016/05/19(木) 22:07:47.87 ID:9fCVrsOw.net]
- 手順とかノウハウとか語りたい
- 267 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 01:55:46.57 ID: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 名前：デフォルトの名無しさん [2016/05/22(日) 01:58:22.26 ID:sxeEi6BC.net]
- >>264
漢字オブジェクト名ｗｗｗ
- 269 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 01:58:50.19 ID:mLM/Nu20.net]
- >>263
ドキュメント文化をやめてほしい
少なくとも疑問を持ってほしいだけだよ
もし業界全体で馬鹿馬鹿しいドキュメント文化から解脱できたなら
それはいったいどれだけの国益になるか
そこを考えてほしいんだ
- 270 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 01:59:51.63 ID:mLM/Nu20.net]
- >>265
もしかしておじいちゃん？
- 271 名前：デフォルトの名無しさん [2016/05/22(日) 02:02:04.15 ID:sxeEi6BC.net]
-
- 272 名前：="../test/read.cgi/tech/1463663267/266" rel="noopener noreferrer" target="_blank">>>266
楽しませてもらってるけどスレと関係ない目的だから別のスレ立ててやってもらえるかな。 []- [ここ壊れてます]
- 273 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 02:03:26.44 ID:mLM/Nu20.net]
- >>268
関係はあるだろう
さっきも言ったがOOPの真髄はドキュメント不要論にリンクするんだからさ
- 274 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 02:03:45.85 ID:WwOYSBmy.net]
- 客がドキュメントを読むんだよ。
知らないのか？
客がドキュメントを読むんだよ。
- 275 名前：デフォルトの名無しさん [2016/05/22(日) 02:05:22.19 ID:sxeEi6BC.net]
- >>269
頼むからそんなとんでも理論で絡んで来ないで。
お前は自分のスレを立てるに足る逸材だから。
- 276 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 02:15:56.49 ID:mLM/Nu20.net]
- >>270
客がドキュメント読みたきゃ読めばいい
客が客の時間使ってドキュメントを読もうがサボって漫画を読もうがそれは客の勝手だ
だけどこっちの開発はそれじゃ進まねえんだよ
- 277 名前：デフォルトの名無しさん [2016/05/22(日) 02:20:15.89 ID:sxeEi6BC.net]
- >>272
客の期待通りの設計になっているかを確認するためにもドキュメントを作成する。
なんとそのドキュメントがメンバー間で理解を共有するための役にも立ってしまう。
すごいじゃん。
- 278 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 02:25:01.82 ID:WwOYSBmy.net]
- ドキュメントを読む時間 × メンバーの数 = コスト
- 279 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 02:29:51.66 ID:mLM/Nu20.net]
- >>273
ドキュメントを正確に書ける保証はない
客がドキュメントを正確に読める保証はない
保証はないと言ったが実際には正確でないほうが多い
本当の意味で客が期待する設計はドキュメントからは生まれない
お互いが認識するモデルをすり合わせるために対話の時間をいかに多くとるかで決まる
- 280 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 02:33:12.47 ID:mLM/Nu20.net]
- ましてや開発メンバー全員が同じ文章から同じ意図を読み取るなど夢のまた夢
- 281 名前：デフォルトの名無しさん [2016/05/22(日) 02:37:48.99 ID:sxeEi6BC.net]
- >>275
口頭じゃ後から確認できないんだから文書として残す必要があるよね。
ってことなんだけど、こいつはそんなちゃちな世界には生きてないんだろうな。
もう頼むからこのスレから巣立って。
- 282 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 02:43:09.84 ID:WENufHUB.net]
- >>259
本当馬鹿馬鹿しいな
おまえの会社はソース読めるエンジニア上がりの営業かもしれんが
他行ったらそんな俺ルール通用しないからな
>>266
個人的希望をばら撒くスレじゃねーから
>>274
口伝のほうがコストかかるだろ
そもそもユニットテスト推奨してるやつが
口伝推奨するとか矛盾もいいとこ
- 283 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 05:16:18.29 ID:PykTFw3U.net]
- 口伝する人がいない。いなくなってしまった。
- 284 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 05:17:10.39 ID:WwOYSBmy.net]
- 結局ソースコードを読むのが
一番コストがかからない
- 285 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 06:36:24.05 ID:OmI05SCB.net]
- なんでおまえらってオブジェクト指向が理解できないとOOPは甘えとか言って投げ出すの？マジで馬鹿なの？マジでﾀﾋぬしかないの？
- 286 名前：デフォルトの名無しさん [2016/05/22(日) 10:29:24.79 ID:sxeEi6BC.net]
- 何をコーディングするか設計するのが設計なのにコードを読めってアホ過ぎる…。
うざいから素人は書き込むなよ。
- 287 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 10:41:33.67 ID:vKoFE7Z9.net]
- 死守すべき拠点・砦・戦線に当たる部分はドキュメントすべき
それ以上細かいのはいらない
- 288 名前：デフォルトの名無しさん [2016/05/22(日) 10:48:03.65 ID:sxeEi6BC.net]
- ドキュメントの範囲は好きにしていいから、どうやって設計するか語ろうぜ。
設計プロセスについて語れる奴はいないの？
- 289 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 11:42:56.90 ID:0426LZJd.net]
- 設計もTDDさえしてればなんとかなるんだよなあ
- 290 名前：デフォルトの名無しさん [2016/05/22(日) 11:47:16.20 ID:sxeEi6BC.net]
- 具体的な話なしに略語しか書けない奴って経験があるように感じさせないんだよなあ。
- 291 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 11:50:37.50 ID:0426LZJd.net]
- TDDをご存じない？
- 292 名前：デフォルトの名無しさん [2016/05/22(日) 11:51:57.78 ID:sxeEi6BC.net]
- 経験ないと具体的な話はできないからなあ。
- 293 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 11:54:53.76 ID:EaQ4G/f7.net]
- >>282
俺もそう思う
何を何のために設計してるのかと
それを知りたければソースコードを読めって破綻してる
じゃソースコードは何を実現するためのソースなのかと?
不具合もソースがそうだからそれが正しいとか言っちゃうのか?
- 294 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 11:56:01.52 ID:EaQ4G/f7.net]
- 設計書書かない奴は書き込み禁止
だって設計してないじゃん
- 295 名前：デフォルトの名無しさん [2016/05/22(日) 12:35:41.84 ID:sxeEi6BC.net]
- >>290
ほんとな。
オブジェクト指向設計について語ろうってスレにわざわざ書き込む意味が分からん。
興味がない、語る内容がないなら書き込む必要ないのに。
- 296 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 12:39:57.00 ID:WwOYSBmy.net]
- >>289
> 何を何のために設計してるのかと
> それを知りたければソースコードを読めって破綻してる
概要をつかむためだよ。
だから設計書には概要しか書かれない。
実際の詳細はソースコードを読めになるのは当たり前。
- 297 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 12:42:21.47 ID:WwOYSBmy.net]
- 設計書は概要をつかむためで概要しかかかれないのだから
当然、設計書に書かれたものから、ソースコードを生成できるわけじゃない。
設計書は方針、こんな感じにしてくださいねっていうもの。
設計書を見て書くというのは、設計書に反しないように作るってことであって
設計書をソースコードに翻訳する作業じゃない。
そして往々にして、実際にソースコードを書いてると、
設計に問題が出てくる。
この時設計書も直さないといけない。
- 298 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 12:59:08.54 ID:vqfBgWhe.net]
- >>277
何度言えばわかるのかなぁ
事後ならコードというその時点で最も信頼できる読みやすいドキュメントがあるだろう
>>278
文章のほうが遥かに高くつく
あんたもプロになればわかるけど設計書なんて１回書いたきりで終わりになんかならねえのよ
口頭ならミーティング１セッションで終わるやりとりがドキュメントだと何回ものファイル更新・交換になってしまう
あぁいちおうお前もバカそうだから念押しするがこれ設計～製造の話な
後に残す文章はコードがあるからまた別の話だ
- 299 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 13:02:48.15 ID:JErM/sdi.net]
- 日本語で書かれた設計書で概要をつかんで、ソースコードを書くフェーズは、”詳細設計”なんです。
単に、日本語で書かれた設計書をソースコードに単純翻訳しているのではありません。
「ソースコードを書く」＝「詳細設計」なんです。
だから、実際にソースコードを書いていると、詳細設計的に問題が発生して書き直しとなるし、場合によっては一つ前の日本語で書かれた設計書まで戻って直す必要も出てきます。
- 300 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 13:03:07.84 ID:vqfBgWhe.net]
- >>280
正解
加えて言えば読めるコード書けないバカが日本語なら書けると勘違いしてドキュメントという幻想にすがりつく
馬鹿馬鹿しいよ
あいつらの書いたドキュメントなんてテストしてないスクリプトへのリプレースみたいなもんだ
読みやすくなるどころか開発言語より読みにくくなってる
読みにくいだけならまだしも開発言語で書いたコードと平気で剥離する
- 301 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 13:05:39.79 ID:vqfBgWhe.net]
- >>282
>>289
設計するためにコードを読むんじゃない
設計するためにモデリングするんだよ
そしてモデリングの過程でコードを書くんだ
順番を間違えるな
- 302 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 13:13:22.82 ID:WENufHUB.net]
- >>294
君が作ったソースの中身を説明するためにミーティング開催するの？
ドキュメント書かないわ、人件費の意識ないわ、終わってるな
- 303 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 13:28:40.61 ID:k1JTbXad.net]
- じゃあ製造に失敗しないパーフェクトな設計書って具体的に何が書いてあるの？
- 304 名前：デフォルトの名無しさん [2016/05/22(日) 13:44:35.01 ID:sxeEi6BC.net]
- >>297
そんな言い合いしてても無意味だから設計のプロセスについて語ろうぜ。
どんな手順でやってて、それぞれのステップの成果物は？
- 305 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 13:51:29.86 ID:WwOYSBmy.net]
- >>300
成果物なんて後から出てくるもの。
まずはステップの目的を考えなさい。
- 306 名前：デフォルトの名無しさん [2016/05/22(日) 13:56:34.04 ID:sxeEi6BC.net]
- >>301
ステップのゴールを決めるのがプロセスなんだけど…。
めんどくさいから素人は書き込むなよ。
- 307 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 14:02:56.02 ID:6l64NX2q.net]
- コード＝ドキュメントってのは理想ではあるんだが
コードってのはこう動くってことしか書いてなくて、しかも実装者以外の人間が欲しい情報よりも粒度が細かい。
あと、その裏にある開発者の意図やシステム特有の事情とかは書かれないしコメントで補完するにも限界がある。
一方でドキュメントを手で作成しても改訂のたびに修正する労力と修正後にソースと同期をとる労力がバカにならないし
大量にドキュメントを書いてもそんなの見ない、見ようと思っても索引や検索が不十分で探し廻らなきゃならないで
結局知ってそうな人に聞くのが早い、ドキュメントの利点なんて新しく加入した人への説明を（形式上）省けるくらいの利点しかない、
てなことになる。
なので現実的な最適解としては、できるだけコードからリバースして「必要な情報だけ」を自動的に抽出する、
そのためのツールを用意し、また抽出しやすいようなコードを書く、それでは作成できないけど本当に必要なものは手で作成する、
て辺りになるんじゃないかと思う。
で必要な情報てのは、画面とか機能とかサブシステムとかの一覧とそれらの間のI/F詳細くらいで、
それ以上はソース読めでいいように思う。
- 308 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 14:07:39.59 ID:WwOYSBmy.net]
- >>302
ステップの目的を成果物生成にしてはいけない。
そんなことをやると理由はないけど作りました。
作って終わり、使われないものが出来上がるだけ。
- 309 名前：デフォルトの名無しさん [2016/05/22(日) 14:13:48.86 ID:sxeEi6BC.net]
- >>304
開発プロセスの本くらい読みなよ。
まともな開発プロセスならステップと成果物が決まってるから。
そんなことすら知らない素人のくせに知ったかぶりすんなよ。
ちょっと勉強したらどんだけ恥ずかしい書き込みしてるか分かるから。
- 310 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 14:14:28.75 ID:WENufHUB.net]
- >>304
成果物なしでどうやってプロセスの完了を判断する？
ソースコードも成果物だし、
成果物のチェックはどんなプロセスでも必要だよ
- 311 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 14:19:58.15 ID:vKoFE7Z9.net]
- これだけ延々と中身の無いレスを垂れ流す奴が書くドキュメントを読まされるという苦行
- 312 名前：デフォルトの名無しさん [2016/05/22(日) 14:29:28.77 ID:sxeEi6BC.net]
- コードだけでいいって言ってる奴がしつこく書き込む矛盾なｗ
ドキュメントの範囲は好きにしていいからプロセスについて語ってくれって言ってんだけどなあ。
- 313 名前：4qmWB+Wj mailto:sage [2016/05/22(日) 14:34:56.12 ID:Pvh7yqZB.net]
- (..´・ω・).oO(今日も伸びてんなぁ
- 314 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 14:37:04.55 ID:WwOYSBmy.net]
- >>305
> まともな開発プロセスならステップと成果物が決まってるから。
それはまともじゃない開発プロセスか、
お前が読み間違ってるだけだな。
読むといいよｗ
www.jaspic.org/event/2005/SepgJapan/presentations/5A1.pdf
俺がいいたいことが書いてあった。
d.hatena.ne.jp/Mic_K/20100516
CMMIの教本（PDFが配布されてますね）には、いろいろと”典型的な作業成果物”や”サブプラクティス”なんていろいろ書いてます。
が、そんなことはどうでもいい。参考にもなりません。
そんなことよりも、
そのプロセスエリアが「本質的に」何をすべきと主張しているかをじっくりと「考える」ことが大事。
そして、自分たちの組織文化的にどういうことがそれに当てはまるか「解釈」することがもっと大事。
バカなCMMI推進者たちは、すぐに文字通りにやろうとします。考えもせず。
これこそ、「形骸化のはじまり！」
「制度化」というCMMIでよく出てくる言葉の意味を理解してません。
逆説的ですが、「CMMIをやろうとすればするほど、CMMIを実装できない」
というジレンマに陥ります。
なぜか？
かんたん。「CMMIの本質を理解してないから？」
そもそも、組織のみんなは日々の業務を一生懸命こなしてます。日々、大小さまざまな改善を積み重ねてませんか？
なのに、CMMIでプロセス改善しよう、って言ったって、「いや、今だって改善してるけど？」的な議論になります。
つまり、CMMIなんて所詮枝葉、形つまり、方法論にすぎないのに、方法論の実装を目的にしちゃうCMMI推進者が「ガン」なわけですね。
- 315 名前：デフォルトの名無しさん [2016/05/22(日) 14:40:22.53 ID:sxeEi6BC.net]
- >>310
いろんなメンバーがかかわるプロジェクトでプロセスがないってねえ…。
ま、>>291だな。
不要って思うなら使わなきゃいいじゃん。
- 316 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 14:42:17.90 ID:6l64NX2q.net]
- 他人の作業を自動化・効率化するプログラムを作っているはずなのに
自分の作業の自動化・効率化を（自分の頭で）考えないで人力でなんとかする（しろ）
って人が結構いるよなぁ
- 317 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 14:47:32.63 ID:EaQ4G/f7.net]
- >>308
でも彼の理論で言うと
もういきなりソースコード組むしかないよね
ファイルフォーマットも通信プロトコルもDBのテーブルも後から付いてくる心配するな!
突っ切れ!
筋肉でプログラミングするタイプかな?
- 318 名前：デフォルトの名無しさん [2016/05/22(日) 14:50:18.38 ID:sxeEi6BC.net]
- >>313
プロセスのステップが明らかになればそこもはっきりすると思ってさ。
お互いの頭の中にぼんやりとしたイメージしかない状態で設計から構築に進むって
プロセスがまったく想像できないから詳しく語って欲しいじゃん？
- 319 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 15:09:12.83 ID:EaQ4G/f7.net]
- >>314
多分こちらが疑問に思ってるようなことは
彼にとっては「そんなのキーボードに手を置けばゴーストが囁くだろ常考」の一言なんだよ
そして粘土をこねるように彫刻を刻むように手を入れてって納期が来たらそこで完成
恐らくそんな開発を言ってる
受け取った客が検収すると不具合ばっかりで使い物にならないケース
- 320 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 15:11:50.07 ID:SSySxKMQ.net]
- プロセスでふと思ったけど
まあ前提として要件がそこそこ決まってるとして
オブジェクトの洗い出しみたいなことするよね
でまあデザインパターンあたりかじってりゃ
たとえばここはテンプレートメソッドでがちがちにしちゃろーとか
ストラテジーにしてゆるーくしちゃろーとか
なんだけど
その判断のプロセスは自分でもわからんな
言語化できてねえ
- 321 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 15:13:18.77 ID:SSySxKMQ.net]
- っつーか言語化できたら本書いて一儲けできそうだなｗｗｗ
- 322 名前：デフォルトの名無しさん [2016/05/22(日) 15:17:51.26 ID:sxeEi6BC.net]
- >>316
オブジェクトの洗い出しって具体的にどんな感じでやってる？
特に機能的なオブジェクトの洗い出しはアバウトにやってて、もうちょっと何かないかなあって感じてて。
- 323 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 15:24:46.95 ID:SSySxKMQ.net]
- >>318
俺もその辺が明確にできればなーって期待してこのスレみてる
アプローチ方法的にはなんかER図作るときみたいになっちゃってるかもしんない
最初にエンティティ出してそれに振る舞いついたらオブジェクトみたいな
うん、うまく言語化できんやっぱり
上級者に期待だわ
- 324 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 15:27:46.05 ID:k1JTbXad.net]
- 設計書厨はまず設計書に書く内容をここで言ってみな
話はそれからだろう
- 325 名前：デフォルトの名無しさん [2016/05/22(日) 15:32:18.74 ID:sxeEi6BC.net]
- >>319
俺もER図書いてエンティティを洗い出すな。
そこからクラス図を書く感じ。
エンティティ的なクラスを決める基準はかなり明確なんだけど機能的なクラスは難しいよな。
デザインパターンを考えながらなんとなく決めてるけど、判断に悩むことが多い。
要件定義から設計へ移行する辺りの明快な指針があんまりないんだよなあ。
- 326 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 15:32:30.31 ID:WwOYSBmy.net]
- > うん、うまく言語化できんやっぱり
そういや中二病っぽく「言語化」とか言ってる
アニメか漫画があったよな。
それのパクリかｗ
- 327 名前：デフォルトの名無しさん [2016/05/22(日) 15:33:49.99 ID:sxeEi6BC.net]
- 要件定義から設計ってより構築の手前の具体的な設計の辺りかな。
- 328 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 15:34:57.20 ID:WwOYSBmy.net]
- >>321
> 俺もER図書いてエンティティを洗い出すな。
俺は、rails generateでモデルを作るな。
そのコード上の定義からER図は rails-erdでモデルを
変更するたびに自動的に生成される。
見方を変えれば、コードを使ってER図を書いているだけ。
やってることは、あんたと一緒でそれがより効率的になっただけだね。
マウスでポチポチやらないで、コードを書くだけだから楽だよ。
修正履歴もわかるしね。
- 329 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 15:35:56.44 ID:WwOYSBmy.net]
- ちなみに、モデルっていうのはクラスだから
Rubyコードを使ってER図を書くと同時にクラスも作れる。
- 330 名前：デフォルトの名無しさん [2016/05/22(日) 15:38:48.31 ID:sxeEi6BC.net]
- >>324
そこは好きなツールを使えばいいと思う。
それより設計指針的な話で、どういう基準でクラスを選択するかを聞きたい。
- 331 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 15:39:06.09 ID:WwOYSBmy.net]
- rails-erdの動画があったよｗ
Create an ERD in Rails in under 30 seconds.
https://www.youtube.com/watch?v=SETJf4cB_NU
- 332 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 15:43:24.37 ID:WwOYSBmy.net]
- >>326
大概はモデルクラスだろ？
画面があれば、コントローラクラスが必要になる。
機能はメソッドだから機能ごとにクラスは作らない。
やることってその程度じゃね？
- 333 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 15:44:05.88 ID:JaLdteXY.net]
- >>321
悩んでる時点でもうアウトだ�
- 334 名前：�
幾ら悩んでも明確な答えは出てこない
そんなフワッとした状態で設計書という名の便所の落書きを幾らかいてもなにも進展しない
結果はコードを書くしかないんだよ
コードを実際に書けば次にどうするかの指針が見えてくる
基本中の基本だわな [] - [ここ壊れてます]
- 335 名前：デフォルトの名無しさん [2016/05/22(日) 15:49:05.35 ID:sxeEi6BC.net]
- >>328
業務的の機能のきれいな構成だな。
- 336 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 15:50:23.31 ID:SSySxKMQ.net]
- >>321
機能的なクラスって少し掘り下げて教えて欲しい
～Utilityとか～Helperとかの名前で実装する類のもの?
だとすると設計段階では洗い出さないかな……
- 337 名前：デフォルトの名無しさん [2016/05/22(日) 15:51:55.61 ID:sxeEi6BC.net]
- >>329
設計が決まってないのにどんなコードを書くのかな？
おおまなか設計がなくちゃコード書けない。
- 338 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 15:53:09.10 ID:WwOYSBmy.net]
- > デザインパターンを考えながらなんとなく決めてるけど、判断に悩むことが多い。
デザインパターンを考えながら決めるのレベルで
まだ初心者なんだよな。
俺がデザインパターンを知ったのはもう15年ぐらい前になるけど、
その時の感想は、みんな（本の作者）も同じこと考えてるなぁ～。
俺が考えた「アレ」をこんなに体系的にまとめてくれて嬉しいわ。だった。
幾つか自分で同じようなものを実装したこともあったしね。
デザインパターンの解説にも書いてあるけど、
新しい何かではなくて、過去の人が考えていたことに名前をつけてまとめただけ。
だから俺の場合、作るときにああすれば良いんじゃね？って思いついて、
その後にデザインパターン本みて抜けや考慮漏れなどを補強する感じ。
- 339 名前：デフォルトの名無しさん [2016/05/22(日) 15:54:42.20 ID:sxeEi6BC.net]
- >>331
だいたいデザインパターンが扱ってるレベルのクラスと想定して欲しい。
業務ルールをチェックする機能をどうするかとか。
- 340 名前：デフォルトの名無しさん [2016/05/22(日) 15:56:32.49 ID:sxeEi6BC.net]
- >>333
デザインパターンのそんな当たり前の説明をドヤ顔でされても…。
- 341 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 15:58:10.11 ID:WwOYSBmy.net]
- >>334
> 業務ルールをチェックする機能をどうするかとか。
Railsだとバリデーションを使う。
基本的なのはあるが、特殊な業務ルールであれば
カスタムバリデータを自作すればいい。
railsguides.jp/active_record_validations.html
標準のやり方がってそれに従えばクラスが出来上がるので
クラスをどうするか？とかを意識することは少ない。
- 342 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 15:58:39.18 ID:WwOYSBmy.net]
- >>335
当たり前の説明をしただけだけど、
何か気に触ったの？ｗ
- 343 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 16:01:24.72 ID:SSySxKMQ.net]
- >>334
難しい例だね……ちょっと実装よりというか
たいがいフレームワークで作られちゃってるというか
例に出してくれたバリデーションまわりって設計段階ではやっぱり洗い出さないなあ
要件みてこんなバリデーションいるよねー、程度
で、たいがいフレームワークにバリデーションの仕組みあるから
やっぱり自力で洗い出さない……
複雑なバリデーション作るにしてもフレームワークの流儀に沿うだけだしね
派生してちょろちょろ処理書いて決められたreturnするってだけの
- 344 名前：デフォルトの名無しさん [2016/05/22(日) 16:03:43.19 ID:sxeEi6BC.net]
- >>336
クラス内で完結しないチェックもできんの？
複数のクラスを参照することが必要な場合はどうするのかとか？
- 345 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 16:06:23.48 ID:JaLdteXY.net]
- >>332
理解力ねえなあ
コード書きながら考えるんだよ
具体的なコードがあるから
この方向性はダメだなとか
これは行けそうだとか
これがありならこっちはどうだとか
思考が展開していく
簡単な話だろ
設計書屋さんって1手目から最後まで読み切ってから1手目を打とうとしてるんだよね
そんなんでうまくいくわけないでしょ
- 346 名前：デフォルトの名無しさん [2016/05/22(日) 16:09:12.64 ID:sxeEi6BC.net]
- >>338
税制の変更やら社内ルールの変更やらは想定される訳で
その場合の変更に対応できるきれいなデザインって何だろうっていつも悩む。
モデルとか画面の設計はわりと簡単で、業務ロジックの設計・構築がメインじゃない。
設計段階で洗い出さないならいつ設計するんだ？
設計と構築の区切りをどこまで明確にしてるか分からないけど、コーディングの前に
設計する必要はあるじゃん。
- 347 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 16:16:53.72 ID:JaLdteXY.net]
- >>339
このレベルで偉そうにしてたのか
- 348 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 16:18:54.34 ID:WwOYSBmy.net]
- >>339
複数のクラスを参照することが必要ならば、
参照すればいいだけだろう？参照するしかないし。
そんなのデザインパターンがでるまでもない。
- 349 名前：デフォルトの名無しさん [2016/05/22(日) 16:20:48.62 ID:sxeEi6BC.net]
- >>343
- 350 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 16:23:08.82 ID:WwOYSBmy.net]
- >>344
それって、ぐうの音も出ないって意味？
- 351 名前：デフォルトの名無しさん [2016/05/22(日) 16:27:04.89 ID:sxeEi6BC.net]
- ちょうど今電王戦見てるから将棋ソフトで考えてみるとさ。
駒クラスがあって王・飛車とかは駒のサブクラスにしようかって感じだろ。
盤面情報と思考ロジックはどんな感じのクラスにするのがいいだろう？
- 352 名前：デフォルトの名無しさん [2016/05/22(日) 16:28:08.95 ID:sxeEi6BC.net]
- >>345
失礼。クリックミス。
- 353 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 16:28:29.75 ID:JaLdteXY.net]
- >>345
このid sexさんはちょっと昔ながらの人なんだろうね
基本的なフレームワークの扱いもロクに知らんって露呈してしまった
おそらく設計書(笑)ばっかり書いてて最近の開発現場の常識知らないんだろうな
おそらくもうすぐ定年だろう
かわいそうだからあんまりいじめてやらんといて
- 354 名前：デフォルトの名無しさん [2016/05/22(日) 16:29:56.23 ID:sxeEi6BC.net]
- >>345
失礼。クリックミス。
- 355 名前：デフォルトの名無しさん [2016/05/22(日) 16:30:23.58 ID:sxeEi6BC.net]
- >>348
具体例を出したからお前の実力を見せ付けて欲しいな。
- 356 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 16:37:00.58 ID:WwOYSBmy.net]
- フレームワーク＝設計だと考えればいいよ。
デザインパターンっていうのは設計するときに必要なものだけど、
フレームワーク作っている側がデザインパターンを使って設計してる。
こっちは、足りない部分を埋めるだけ。
もちろん、基礎知識としてデザインパターンは必要。
フレームワークに足りない部分を拡張するときには必要になる。
だけど定型的なそんな処理で設計なんて考える必要はない。
フレームワークを導入した時点でほとんどが終わっている。
- 357 名前：デフォルトの名無しさん [2016/05/22(日) 16:40:12.95 ID:MeU4g4+w.net]
- sexじゃなくてsxeやん
- 358 名前：デフォルトの名無しさん [2016/05/22(日) 16:41:15.97 ID:sxeEi6BC.net]
- >>351
ややこしい業務ロジックが色々あるときはどうしてる？
- 359 名前：デフォルトの名無しさん [2016/05/22(日) 16:44:19.40 ID:sxeEi6BC.net]
- >>351
具体例があったほうが分かりやすいから将棋ソフトの例で考えてみてよ。
思考ルーチンは定跡＋何らかのロジックがあるし、思考ルーチンのどんどん改修されるとして。
ロジックの細かい部分は俺も知らないし、大まかな構成で十分。
- 360 名前：デフォルトの名無しさん [2016/05/22(日) 16:47:39.90 ID:WF/9GeMl.net]
- まあそんな熱くなるなってｗ
- 361 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 16:51:47.45 ID:EaQ4G/f7.net]
- 俺は要件定義で
対象のシステムの構成図
ユースケース図
機能一覧
画面一覧
説明書
まで書く
設計書は頭に構成図貼り付けて
機能一覧に基づいて機能毎に
概要、機能詳細、画面詳細、データフロー、シーケンス図、ログ、メッセージ、ファイルフォーマット、テーブルetc
を書く
基本的にはログやメッセージみたいな共通部分以外で
機能より細分化したクラスは作らない
- 362 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 16:53:43.65 ID:WwOYSBmy.net]
- >>353
> ややこしい業務ロジックが色々あるときはどうしてる？
ややこしい業務ロジックなどない。っていうのが答え。
処理が多くて面倒くさいだけだろう？
もしくは設計が必要な部分（フレームワーク）と
設計が必要ないような些細な部分が、ごちゃまぜになってる。
フレームワークを使ってなさそうだし、綺麗に分離できてないんだろう。
ちなみに「設計が必要ないような些細な部分」といったが
この部分が重要ではないという意味じゃないぞ。
むしろ顧客にとっては（当然だが汎用的なフレームワークより）
この部分の方にこそ価値があって重要な部分。
重要だからこそ、出来る限り汎用的な部分をそぎ落として
改修が入るコードのみにする。そこまで削ぎ落とすから設計なんぞ不要。
フレームワークを使うことで設計はどこかの誰かがやってくれるから
通常の開発で設計なんぞ、終わってることだから、やらない。
あんたは、この改修が入る部分と設計が必要な部分をあわせたままやってるから、
ロジックの改修時に設計をどうするかって話がでてくる。
- 363 名前：デフォルトの名無しさん [2016/05/22(日) 16:54:30.16 ID:sxeEi6BC.net]
- 具体例を出したら途端に書き込みが減ったけど考えてくれてるかな？
盤面をクラスとして作るべきか、思考ルーチンの中で使われる情報に過ぎないのか？
って疑問がまず出てくるけどどう判断する？
- 364 名前：デフォルトの名無しさん [2016/05/22(日) 16:56:03.51 ID:sxeEi6BC.net]
- >>357
将棋ソフトの例で一緒に考えよう。
実際にきれいな考え方を示してくれたら素直に認めるから。
- 365 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 16:59:15.28 ID:WwOYSBmy.net]
- >>354
> 具体例があったほうが分かりやすいから将棋ソフトの例で考えてみてよ。
将棋ソフトで設計が必要なのは、まずインターフェース部分。
コマの配置データから、盤面の画像を配置すればいいだけ。
ここは思考ルーチンの改修とは全く別の話だから、
思考ルーチンの改修時に触らなくていいように分離する。
ということで、インターフェース部分の設計は終わり。
思考ルーチンの改修時に考えなくていい。
他に何を設計するんだ？
あとは単なるアルゴリズムだけだろう。
やるとしてもデータを所持して、思考ルーチンを呼び出すだけの
単純なインターフェースを考えればおしまい。
- 366 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 16:59:59.08 ID:WENufHUB.net]
- rails含めてMVCフレームワークで事足りる案件なら
すでに構成が確定してるから
クラス設計とかクラス図とか全く必要ないよな
俺は未だにクラス図が必要になるケースがわからん
科学計算とか人工知能とかそちら方面かな？
- 367 名前：デフォルトの名無しさん mailto:sage [2016/05/22(日) 17:02:51.37 ID:WENufHUB.net]
- プロセスの成果物については考え方違うが>>351は同意だわ
|
 |
