- - PR -
募）モデリングについて意識するタイミングは？
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2003-05-16 20:08
>それを「モデリング不在」と呼ぶ場合、アナタの「モデリング」という言葉の定義を
>はっきりさせてからにしてください。 多分，何にも考えてないのだと思いますよ． モデリング中心主義者というものは，ほとんど裸の王様． 「バカには理解できないモデリング」といわれれば， 「もちろん私にはモデリングの素晴らしさが理解できる」と 言ってしまうわけですね． 「モデリングのどこが良いか分からない」と言う人に対しては， 「このモデリングの素晴らしさが分からないなんてなんてバカな奴」 と答えると． とにかくUMLやDOM，モデル駆動型プログラミングなどの世界で使われる， いわゆる「モデリング」ってのは，非常に胡散臭い代物で定義はなきに 等しいと考えてます．何しろまともな根拠を示していることは皆無なので． ちなみに私の場合はJavaVMの実行モデルやメモリモデル，或いは有名な 「リレーショナルモデル」などではモデルも利用していますが，いわゆる UMLなどのモデリングは役に立たないのでほとんど利用しません． 設計はしますけどね． 他者とのコミュニケーションに関しては，ドキュメントも必要だと思います． そのごく一部にUMLライクな記述やデータベース設計のER図は使うでしょう． でもドキュメントの大半はそれら以外の部分が占めます． ＃コミュニケーションに関しては，やはりソースコードに勝るものは ＃ありません．汚いソースコードに膨大なドキュメントをつけるなら， ＃綺麗なソースコードとユニットテストの方が数段優れている． | ||||
|
投稿日時: 2003-05-19 10:39
あんまり相手にしたくないんですが。
＞３００ｋのソースコード これは外部との接続プログラムだったんですけど、 データのインタフェースも画面のインタフェースも概要設計も フレームワークまで提供されているうえで、ある意味設計は終わっているんです。 しかし、ソースコードを各時点でJavaでどう実装すればいいかを考えたときに まず、自分なりに理解したモデルを定義するでしょう？ ３００ｋのフローなのは仕方ないのですが、それをそのままベタで書くのは常識がない。 まあ、モデリング以前という話もあるんですが、 ここの板はJavaSolutionなんですからJava言語でインプリするときに モデルをきちんと定義しろってことです。 設計段階の各所でモデル定義されているにもかかわらず、 そのモデルを無視して全くモデルのないJavaコードを書かれるとトサカにきますよ。 モデルを無視してプログラムしやすい形でモデリングするならまだしもです。 きちんとコード段階でモデリングしてたら３００ｋのメソッドなんてありえないでしょ？？ | ||||
|
投稿日時: 2003-05-19 10:42
その通りです、 綺麗なソースコード＝モデリングが考慮されたソースコード というと言い過ぎかもしれませんが・・ ＃メソッドにJavaDocコメントくらいはつけてくださいね。 | ||||
|
投稿日時: 2003-05-19 10:47
私はモデリングがすばらしいとは一言もいってない（はず）です。 勘違いした上にいちゃもんつけてくる人とは話したくないのですが・・ 一番すばらしいのはJavaなんて書かないことです。 プログラムを書かずに、最適なパフォーマンスの最適なソリューションが たった一人で構築できるならそれに越したことはありません。 モデリングはチーム開発の最低条件でしかありません。 その上でやるべきことは沢山あります。 | ||||
|
投稿日時: 2003-05-19 12:27
ども、ほむらです。
---------------- KO-JIさんへ なんか。。。すべてを引用したくなるような貴重なご意見ありがとうございます＾＾ (長くなってしまうので引用は割愛させていただきますが^^;;;;) 僕は日ごろからIN/OUTのはっきりしないプログラムに価値は無いと思っています。 そういう考え方からいっても。 要求から分析して(IN/OUTをはっきりさせて) そこから設計という形にもっていくと自然な工程として進めていくことが出来そうです。 要求モデルの作成が検討段階で行われるというのは 最初驚きましたがよくよく考えてみるとこれもまた自然なんですね＾＾；；； (うーん、奥が深い) システム化の検討段階から行われるということは その後の影響力もかなり強そうです。。。 もれたりしたら、悲惨そう(笑) あと、大切なことは設計をただ設計だけでおわらせるのではなく。 作った後でレビュー(たぶん、検証とかウォークスルーのことですよね？)することも 大切ということですね(今まではまともにレビューをしたことが無いかもしれません) 積極的に使用していって自分のこれからの開発に 役立てていきたいと思います。 | ||||
|
投稿日時: 2003-05-19 14:09
ほむらです。
また、勘違いをしているかもしれませんが・・・・ --------------
僕的に、綺麗な=読みやすいとするならば モデリングや設計と読みやすいソースコードは 別次元の話だと思います。 読みやすいソースコードは １．整形されたソースコード ２．処理概要などこまめに書かれたコメント ３．データ IN/OUTに関するコメント が重要だと思っています。(基本的ではありますが^^;;;) 一言で言うならばJAVA言語を知らない人でも 他の言語を知っていれば ある程度の処理内容はわかること ・トレースできることでしょうか・・・ たしかに、設計やモデリングによって練りこまれたソースは 機能分割などが出来ていて、見た目にもわかり易く さっぱりしているのも事実ですが ソースコードを書く上で速度ばかりを重視してへんな圧縮をしたり 不用意に変数を多数宣言または逆に使いまわしてしまっては 決して綺麗なソースコードにはならないかと・・・ 場所によっては速度を気にする場面もあるかと思いますが 全体の処理の中で１０%にも満たない部分を高速にしても意味の無いことですし そう考えれば、速度重視のモジュール(メソッド?)なんて 片手あれば足りるくらいの数ではないでしょうか | ||||
|
投稿日時: 2003-05-19 16:10
>僕的に、綺麗な=読みやすいとするならば
>モデリングや設計と読みやすいソースコードは >別次元の話だと思います。 ですね．むしろリファクタリングの世界だと思う． これについては本一冊書かれてますので，詳細は そちらを参照してください． | ||||
|
投稿日時: 2003-05-19 16:21
基本的すぎる・・・と思いました。 いまどきソースコードの整形は良くも悪くもIDEがやってくれますし、 JavaDocのないソースは納品物として認めてくれませんし・・認めません。 IPOに関心されているようですが、 制御指向（フロー指向）のモデリングでは一般的な考え方で、 COBOLの時代からあるかなり古いものです。 IPOを書くということはフロー指向でモデリングすることを意味します。 何指向でも私はかまいませんが、モデリングをしっかりすることは大事ということで 理解してもらえましたでしょうか。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。