TLのDCIとかMVCに違和感があった
-
- いいね！1
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
最近はFat Modelのなにがわるいのかわからなくなっているレベル。ゆえにTLのMVCとかDCIとかDDDとかついていけない。実務で自分が書けているかどうこうという話は抜きにして。
2012-12-26 10:58:05
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
「modelかなり太っていてわかりにくいじゃないですか」っていって「これはxxxにおいて、yyyはもっとスリムにするぜ」ってやっても、顧客の業務モデルをリファクタリングしなきゃそれはたんなるプログラマーの都合で、むしろ変更のリスクが高くなるんじゃないかなって思ってる。
2012-12-26 11:02:50
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
だから、プログラマーの都合で書きやすくしていい部分と、そうじゃない部分っていうのは考えなきゃいけなくって、あくまで印象の話だと、TLのMVCの話は「プログラマーがプログラミングしやすいコードを書くための話」なのかなって思った。
2012-12-26 11:04:09
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
僕は難しいことはよくわからないけれど、DCIの素晴しいところは、「顧客がもつメンタルモデルは別個にしてあげるほうがコードと対応がはかりやすいよね」っていう着眼点だと思っていて、それがどのモデリングパターンのどれと似ているという話とはちょっと感覚があわなかった。
2012-12-26 11:05:29
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
僕がこんなことを思うのは、TLの優秀なプログラマーさんたちみたいに日々研鑽して苦労していろんなコードを書くということをしていないからだろうなっておもってしまいました。自分はその程度の実力なんだと思う。
2012-12-26 11:06:45
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
なんかうまく表現できなくってごめんなさい。でも今の僕の実力だと、TLのMVCとかDDDとかDCIの議論はほとんど肌に合わないなって思ったので、ちょっと書いてみました。
2012-12-26 11:09:06
Naoto Takai
@takai
@kyon_mm そうですね、DCIはOO分析とならべて考える水準のものなので、リファクタリングみたいな話とはちょっと水準が違うとおもっています
2012-12-26 11:07:58
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@takai あー。そうですそうです。その感覚が非常に近いです。ソフトウェア開発対象物への観点(切り口)をユーザーにより近付けようとして素晴しい試みだなっておもいました。
2012-12-26 11:14:43
猫のお腹に顔をうずめて深呼吸
@crimsonwoods
本質的にプログラマの都合で書きやすく（実際には書きやすさより読みやすさだと思うけど）しちゃいけない部分って無いと思っていて、やれる/やれないは単純に払えるコストの問題かなと思っている。
2012-12-26 11:17:10
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@crimsonwoods はい。僕もそうおもいます。そこいかにちかづけるかが、プログラマーたちが言語やDSLやツールをつくるとこだろうと。
2012-12-26 11:28:32
なぎせ ゆうき
@nagise
@kyon_mm フレームワーク的なモノを書くことによって、特定の制限のもとでは生産性が向上し、逆にその制限から外れる場合は生産性が下がるわけで、設計というのは常にメリットとデメリットが存在して、顧客の要件に合わせてメリットが活きデメリットが出てこない選択をすることになる
2012-12-26 11:12:44
なぎせ ゆうき
@nagise
@kyon_mm 僕らが共通化とかなんとか言ってフレームワーク的なモノを作るとき、暗黙にここは不変な要件、ここは可変な要件ってのを考えてるハズ。それを外すと大改修になるんで、設計時には要件を満たすことに加え、変更リスクも織り込んで考えないとトータルのコストを減らせない
2012-12-26 11:20:07
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@nagise あー。なるほどなるほど。その要件を考えるときにどういった視点であるかが重要なのですかね。
2012-12-26 11:30:24
なぎせ ゆうき
@nagise
@kyon_mm なので、顧客の要件を見誤ってプログラマ都合で設計方法を選ぶと顧客の仕様変更に追従できなくなったりするというのはその通りで、どの部分が可変でどこを不変と見ていいかを間違えればそれはアーキテクチャ選定ミスと言われて仕方がないと思う
2012-12-26 11:14:26
なぎせ ゆうき
@nagise
@kyon_mm お客さんの中であやふやな部分や、お客さんの業務モデル的に将来変更が見込まれるモノってのは修正しやすいように設計するべきだし、そのへんを汲まずに現在のビジネスモデルのスナップショットだけを元にシステムを設計したらそりゃあダメでしょ
2012-12-26 11:34:38
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@nagise 僕は「現在のスナップショット」が正しいって思ってしまっていました。たしかにそれではいけないですね。なるほどー。そういう意味だと、「ここは基盤となるモデル」「ここはふわふわしたモデル」というように明に分けるパターン名をつけてあげるとよいのかもなって今思いつきました。
2012-12-26 11:39:17
なぎせ ゆうき
@nagise
@kyon_mm そうですね。要件の確度みたいなのを多分みんな感覚で考慮してると思うけど、明確に名付けるとかしてお客さんにも意識してもらうと良いのかもしれない
2012-12-26 11:41:56
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
DDDを勉強したときに思いましたけど、ユーザーのメンタルモデルとかビジネスモデルを理解するって本当にたいせつだなぁ。
2012-12-26 11:42:46
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@nagise あー。たしかに。僕が覚えている中だと「優先順位をどうつけるか」はいろんなものがある気がするんですけど、「一緒にアーキテクチャとかモデルをくんでいく」っていう意味ではユビキタス言語くらいで、「確度」のようなものを明にした手法ってなさそうです。そういうの考えてみたい!
2012-12-26 11:45:37
なぎせ ゆうき
@nagise
@kyon_mm 確度といえば、単体独立のコードなんてのは後で書き換えても影響は殆ど出ないんで危険視してないけど、このデータモデル変えることになったら大変！みたいなところは注意して設計する、みたいな力配分ってのも経験に基いて無意識化でやってるリスクコントロールなんだと思う
2012-12-26 11:49:39
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@nagise あー。ありますね。あとクライアントコードがおおくなってきて、あくまで一例ですけどDI的なものとかCallbackがどうとか考えてきたりとか。それ単体をどう設計するかは書かれることがあっても、ビジネスモデル？のなかでどう対応させるかとかっていう話を聞いてみたいですね
2012-12-26 11:55:16