最近のアプリ界隈での「設計」の違和感 - なるようになるかも

2018 - 06 - 14 最近のアプリ界隈での「設計」の違和感 アプリ界隈で「設計」の話をするときに MVC / MVP / MVVM のような「設計パターン」だけが語られるようになった気がする。 往々にして、「アプリの規模によってどれを採択すべきかは変わる」みたいな お茶を濁す ような結論で終わることが多い。 私的な結論 「設計」と、「設計パターン」は別物だと思う。 「設計」のレベルを上げた...

記事へジャンプ

みんなの反応

はてなブックマークでの反応
1ktanaka117@hatena 2018/06/14 11:16
わかる。記事の末尾にも書かれているけど、設計パターンをとりあえず触れていくのはまず必要。設計パターンから大枠を掴んで、じゃあ様々な要件・仕様に合わせた設計をしていくにはどうするか考えていくことが大事。
2mizchi@hatena 2018/06/14 12:09
自分フロントで Backbone から React に移ったときにこのパラダイムの変化を感じていて、Flux は仮想DOM的なアトミック性が保証されるなら「正解」なんだけど、それ以外の環境でできるかというと微妙
3ytRino@hatena 2018/06/14 12:13
なお結局お茶は濁っている
4ragion@hatena 2018/06/14 12:15
ギョエピー
5yokos000@hatena 2018/06/14 13:12
全面的に同意。"ビジネスロジック・ドメイン層と言われる領域を~というところがもっとも肝要で" 特にこれ
6atsuya046@hatena 2018/06/14 13:43
ほんこれ
7peko-the3rd@hatena 2018/06/14 14:32
"DDD はソフトウェア製造全体に対する巨視的な考え方を~"実装レベルじゃなくて大上段的な設計こそが設計が出来る人なんだけど、現場でマウント取るのは前者だから議論が噛み合わないことがしばしばある
8rryu@hatena 2018/06/14 15:10
UIにモデルをくっつけるみたいな思考が失敗の原因なのではないかと思う。画面を見て設計するから自然にそうなってしまうのだと思うが、本来は逆に思考すべき。
9knjname@hatena 2018/06/14 20:17
小難しいことを考えたくない、全部同じで綺麗にすむなら多少無駄を払ってもいい、定番に添いたい、引き継ぎはなるべくしたくない
10turanukimaru@hatena 2018/06/14 23:07
趣旨には賛同するが実際に設計の話をして「あるオブジェクトはnullableかmutableかimmutableかまたその根拠は」なんて話しても誰も反応しないかnull不可でimmutableのほうがバグりにくいよね程度。設計の根拠を知ろうともしない
11a-kuma3@hatena 2018/06/14 23:30
所謂構造化設計が共通処理をくくり出しましょう、から、OMT が名詞をクラスの、動詞をメソッドの候補にしましょう、と具体的な手段を提供してからのOMT信者/あれから設計手法は大きな進化をしてない
12Wacky@hatena 2018/06/14 23:49
“作ったことも触ったこともないものに対して、どれが最適かなどという判断を下すことなど不可能なので。”
13massa142@hatena 2018/06/15 03:30
“ビジネスロジック・ドメイン層と言われる領域をうまく抽象化し、UI や DB などと隔離されたかたちで実装できるか?というところがもっとも肝要で、それこそが本来やるべき「設計」じゃないのかなぁと思っている”
14y_hirano@hatena 2018/06/15 05:52
スマホアプリだとサーバから振ってくるデータを整形して表示することが主でビジネスロジックなどはほぼないケースがほとんどなので、設計そのものはあんまり重視しないなぁ。一貫性の方をよほど重視してます。
15innx_hidenori@hatena 2018/06/15 08:23
この方が言わんとする趣旨には概ね同意だなぁ。でもじゃあ「設計って何」という問いに簡単に答えたり説明できない。それに技術者はやっぱり道具の話ばかりしてしまうもなんだと思ってる。
16ilyaletre@hatena 2018/06/15 10:47
設計パターンよりも純粋にドメインをどうモデル化するか考えている時の方が学習・習熟している感じがして楽しいですよね。
17haruharu1@hatena 2018/06/15 11:14
MVCは層的に限界感じてるので、MSVCって感じで作ってる。VやMで書いてたものを別のファイルで書いてるだけだけど
18hdampty7@hatena 2018/06/15 11:59
小屋を建てるのか住宅を建てるのかビルを建てるのか、何を作るかによって最適解は変わる。スケールや更新頻度、投入可能工数によって最終的に如何にバランスさせるかという、実践的なところが実は一番大事なのでは
19Rei19@hatena 2018/06/15 17:42
"ビジネスロジック・ドメイン層と言われる領域をうまく抽象化し、UI や DB などと隔離されたかたちで実装できるか" これ
20notsunohito@hatena 2018/06/15 21:24
設計の定義とは
21kasei_san@hatena 2018/06/16 12:42
“MVC への批判をするときに、FatVC が持ち出されることが多いのですが、FatVC を実装してしまうのは単に実装者の能力不足だと考えていて、MVVM を採用しても FatVM を作るだけだと思っている。”
22raimon49@hatena 2018/06/16 23:18
言わんとするところは分かる。モバイルアプリは「ストアに早く出してしまって育てる」側面も強いので、最初から頭でっかちに議論しているとチャンスを逃すケースもあって、成長フェーズに応じて改善するのが良さそう
23somemo@hatena 2018/06/19 13:37
“ 「設計」と、「設計パターン」は別物だと思う。 アーキテクチャシンドロームから抜け出して、価値のあるものを作りたい。”
24Muke@hatena 2018/06/26 15:02
“どういう要件があり、どういった機能を実現する必要があるのか?”
25to4iki@hatena 2018/08/13 15:10
"作ったことも触ったこともないものに対して、どれが最適かなどという判断を下すことなど不可能なので。"
コメント内容の著作権は、投稿者に帰属します。
削除依頼、不適切コメントのご連絡はこちらにお願いいたします。
2018-06-14 04:36:02:1528918562:1534418738
comments powered by Disqus
※メールアドレスは公開されません。
人気の反応