まつもと ゆきひろです

|大瀬戸です。

|だから、（必要な範囲で）各モジュール群＊全体を見渡して＊、
|何処で何をするかと言う方針の決定はソースコードを書く
|段階では、（天才か超努力家以外の普通の人では）無理
|じゃないかなと思います。
|だから、コーディング以前に設計というステップが必要だと思います。

そこまでは否定しません．私も「外部仕様の決定」や「モジュール
分割」は分離できると述べました．が，普通「設計」というとそれ
より踏み込んだプログラミングの一歩手前まで含みませんか？

そのような(詳細)設計は分離すべきではないというのが，私の主張
です．

妹尾です。

  なんていうか、実感として肌に染み込んでくる意見ですね。

  カタチ(例えば書類)の上で分離する事には、私も意味を感じません。
ただ、実装の都合でいつのまにか設計が変わっている(無視されている)
と言う事はあってはならないので、ココロの持ち方として、この分離は
重要ではないかと。

  一応断っておきますが、実装上問題が出たときに、設計まで振り返って、
設計を変更し、実装するのは否定してません。

  むしろ、カタチの上での分離は、実装→設計へのフィードバックが
しにくくなり、結果として「設計が無視される」と言った事態を起こしやすい
のではないかと思います。ただ、こうした「カタチ」の話は、「設計論」では
なく「プロジェクトマネージメント」の話ではないかとも思います。

  まさしく。

  うーん、微妙なトコロですね。

  とりあえず、正論を吐いておくと、「優れた設計者」と「優れたプロ
グラマ」では、「優れた設計者」の方が優遇されて良いんじゃないで
しょうか。

  ただ、プログラミングは「プログラミング」を知らないと出来ないのに
対して、設計は「設計」をしらなくても「できて」しまいますし、これが
結果として「プログラミングはできないから設計でもする」なんて事態を
招く事もあるかと。

＃ まぁ、「仮定」の話ですから。そういうことで。
--
せのお / se...@xa2.so-net.or.jp
プログラマ魂 http://www02.u-page.so-net.or.jp/xa2/senoh/

大瀬戸です。

In article <lvsoltd9ph.fsf...@picachu.netlab.co.jp>, m...@netlab.co.jp says...

そうやって分離するのが「ウォーターフォール」だと思いますが。
そして、「スパイラル開発」がモジュール内でプログラミングと
設計との間の手戻りをすることではないと思っていたのですが。

認識を変えるべきでしょうか。

閑話休題

確認ですが
In article <lvsoltd9ph.fsf...@picachu.netlab.co.jp>, m...@netlab.co.jp says...

でいう、プログラミングと設計は作業のことで

でいう、設計とプログラミングは担当者のことですよね。
ちょっと混乱してきたもので。

妹尾です。

＃ ポストに失敗したみたいで、もう一度出します。
＃ もし二度見た方がいらっしゃいましたらごめんなさい。

  なんていうか、実感として肌に染み込んでくる意見ですね。

  カタチ(例えば書類)の上で分離する事には、私も意味を感じません。
ただ、実装の都合でいつのまにか設計が変わっている(無視されている)
と言う事はあってはならないので、ココロの持ち方として、この分離は
重要ではないかと。

  一応断っておきますが、実装上問題が出たときに、設計まで振り返って、
設計を変更し、実装するのは否定してません。

  むしろ、カタチの上での分離は、実装→設計へのフィードバックが
しにくくなり、結果として「設計が無視される」と言った事態を起こしやすい
のではないかと思います。ただ、こうした「カタチ」の話は、「設計論」では
なく「プロジェクトマネージメント」の話ではないかとも思います。

  まさしく。

  うーん、微妙なトコロですね。

  とりあえず、正論を吐いておくと、「優れた設計者」と「優れたプロ
グラマ」では、「優れた設計者」の方が優遇されて良いんじゃないで
しょうか。それは一人当たりで見たとき、設計者のほうがプログラマ
よりもシステムへの影響力が大きいからです。

  ただ、プログラミングは「プログラミング」を知らないと出来ないのに
対して、設計は「設計」をしらなくても「できて」しまいますし、これが
結果として「プログラミングはできないから設計でもする」なんて事態を
招く事もあるかと。

＃ まぁ、一応「架空」の話ですから。そういうことで。(^^;)
--
せのお / se...@xa2.so-net.or.jp
プログラマ魂 http://www02.u-page.so-net.or.jp/xa2/senoh/

久野です。

os...@cs.ricoh.co.jpさん:

  もちろん設計は必要ですね。

  それで、そのような並行システムの設計ってOOA/OODでやられてます?
それでどのくらい有効なんでしょう。

                その辺も懐疑的なんで :-)                  久野

まつもと ゆきひろです

|大瀬戸です。

|>分離すべきは，前段階の「外部仕様の決定」「モジュール間のイン
|>ターフェースの決定」レベルか，後段階の「テスト」などでしょう．
|>前段階は手戻りが頻繁に発生しちゃいかんはずなんで，分離に問題
|>ないですし，後段階は分離しないと先入観から問題を見逃しちゃう
|>恐れがありますよね．
|
|そうやって分離するのが「ウォーターフォール」だと思いますが。

えーと，ということは，大瀬戸さんは「分離はすべからくウォーター
フォールである，存在してはいかん」と思っていらっしゃるという
ことでしょうか？ しかし，それでは大瀬戸さんの他の発言とは矛
盾するのできっと違うでしょうね．

前の発言で私が述べたのは

  外部仕様やモジュール間のインターフェースは頻繁に変更しては
  いけない(場合が多い)ので，分離による問題が生じにくいし，変
  更の頻度を下げる外部要因とするために分離した方が良い(場合
  が多い)

という意味で「手戻りが発生しない」とか「してはいけない」とか
いうような意図はありませんので，直接にウォーターフォールモデ
ルにつながるという認識はなかったのですが，いかがでしょう？

ついでにいえば，上記の「良い」は主にコストの問題ですので，コ
ストを度外視している場合には，良いも悪いもありません．

そして，私は「このような方法は『スパイラル開発』である」とは
ひとことも申しておりませんので，

|そして、「スパイラル開発」がモジュール内でプログラミングと
|設計との間の手戻りをすることではないと思っていたのですが。

については，若干当惑しております．

# 個人的な考えでは「フィードバックが行われれば粒度はともかく
# スパイラル開発である」と思ってますが．

|確認ですが
|In article <lvsoltd9ph.fsf...@picachu.netlab.co.jp>, m...@netlab.co.jp says...
|>なったようですが，その場合実装やさまざまな事情によって，プロ
|>グラミングと設計の間の手戻りがかなり発生するはずですよね．そ
|
|でいう、プログラミングと設計は作業のことで
|
|>の場合，設計とプログラミングを分離することはたんにコミュニケー
|>ションコストを増大させるだけだと思います．
|
|でいう、設計とプログラミングは担当者のことですよね。

そうであった方が「被害」が大きいですが，どちらも作業と考えて
いただいても議論の本質は変りません．

                                まつもと ゆきひろ /:|)

まつもと ゆきひろです

|妹尾です。

|  カタチ(例えば書類)の上で分離する事には、私も意味を感じません。
|ただ、実装の都合でいつのまにか設計が変わっている(無視されている)
|と言う事はあってはならないので、ココロの持ち方として、この分離は
|重要ではないかと。

えーと，この場合の前提は

  実装の都合でいつのまにか設計が変わっている(無視されている)
  と言う事はあってはならない

ですよね．この議論では設計という用語がいろいろの領域(粒度)で
使われているので難しいのですが，私の考えは

  この設計変更が閉じたモジュールの範囲内で行われるなら問題なし

と思ってます．ですから，前提を共有してないんですね．もちろん，
他人との関わりのある部分を勝手に変更してはいけないので，大き
なレベルでの設計については同意しますが．

ですから，わたしはこの件に関して妹尾さんの意見を全否定してい
るのではなくて，成立しない場合がありますよ，と述べているまで
です．

|  とりあえず、正論を吐いておくと、「優れた設計者」と「優れたプロ
|グラマ」では、「優れた設計者」の方が優遇されて良いんじゃないで
|しょうか。

ふむ，つまり「優れた設計者」であるが「プログラマとしては優秀
でない」人や「優れたプログラマ」であるが「ろくな設計が出来な
い」人が存在すると考えておられるんですね．

企業における「コーダー」という職種の存在を見ているとそういう
人がいそうな気になってもしょうがないと思いますが，私の経験で
はそういう人は見たことないですし，存在しないんじゃないかとも
思っています．

もしかすると「プログラマ」という単語が指しているものが食い違っ
ているのかも知れませんが．

                                まつもと ゆきひろ /:|)

大瀬戸です。

In article <lv1ztcvab0.fsf...@picachu.netlab.co.jp>, m...@netlab.co.jp says...

ここへの回答をする前に、

について確認ですが、ここでおっしゃられている「設計の分離」は
工程の分離のことですよね。担当者の分離のことなんかじゃないですよね。

以後、「工程の分離」だと解釈して話を進めます。

で、僕からの回答をします。
ここでお互いの認識がずれている可能性のあるのが、
「モジュールの大きさ」についての様な感じがします。
僕の認識では、モジュールは、
・手続き型言語の場合は、プロシージャや関数のこと
・オブジェクト指向言語の場合は、クラスのこと
です。
その上で、そのモジュールの構成はコーディング以前に設計というステップで
詰めておく必要があると考えてます。
＃モジュール内部のメカニズムは、場合によりその時にある程度規定する
＃かもしれません（疑似言語という形で。）が、
＃基本的には“好きにして”ってスタンスです。

分析・設計という概念を知る以前は、僕の場合、モジュールの決定は
結構いいかげんでした。
＃その時代はＣ言語でしたから、モジュール＝関数 です。
つまり、最初に“まぁこんなもんだろう”と大まかな決定をして
詳細を詰めていき、大きさが80x25のスクリーンで手に負えなく
なってくると、その都度、意味の上でまとまった単位で
細かい関数に分ける、ということの繰り返しでした。
お陰で、出来上がったソースは、1度しか使われないモジュールや
良く似たモジュールが沢山ありました。

手続き型言語の場合は、そういうことがおきても多少の無駄
（呼び出し時間とスタックの消費量）だけで済み、ちゃんと
動くわけです。
＃しかも、1度しか使われないモジュールであっても
＃「手続きの隠蔽」という見方をすると、
＃全く無駄なわけじゃないですけど。

ところが、オブジェクト指向型言語の場合、オブジェクトに
よって、「手続きの隠蔽」に加え「データ（構造）の隠蔽」が
加わります。その場合、矛盾したオブジェクト構造はそのまま
矛盾したデータを含むことが起きてしまうと思います。
だから、思い付きでオブジェクトを作り出す訳には
いかないと思います。

だから、オブジェクト単位の大きさまで踏み込んだ設計
が必要になるのではないかと思っています。

＃もっとも、Shlaer-Mellor 法から OO に入ったから
＃こんな考えを持つのかもしれませんが。
＃しかも、SM法なんてOOじゃないという人もいるかもしれない。:p

まつもと ゆきひろです

|大瀬戸です。

|ここへの回答をする前に、
|
|>そのような(詳細)設計は分離すべきではないというのが，私の主張
|>です．
|
|について確認ですが、ここでおっしゃられている「設計の分離」は
|工程の分離のことですよね。担当者の分離のことなんかじゃないですよね。

実は担当者の分離を念頭において話していたのですが…．工程の分
離でも議論の本質は変らないとは思いますが，「分離」という用語
の使い方によっては違いが出てくるかも知れません．

|ここでお互いの認識がずれている可能性のあるのが、
|「モジュールの大きさ」についての様な感じがします。
|僕の認識では、モジュールは、
|・手続き型言語の場合は、プロシージャや関数のこと
|・オブジェクト指向言語の場合は、クラスのこと
|です。

あ，そうなんですか．うーん．

私が(多分よしおかさんも)考えているモジュールはもっと大きな単
位です．そして，そのレベルで

|＃モジュール内部のメカニズムは、場合によりその時にある程度規定する
|＃かもしれません（疑似言語という形で。）が、
|＃基本的には“好きにして”ってスタンスです。

が成立すると考えています．

|ところが、オブジェクト指向型言語の場合、オブジェクトに
|よって、「手続きの隠蔽」に加え「データ（構造）の隠蔽」が
|加わります。その場合、矛盾したオブジェクト構造はそのまま
|矛盾したデータを含むことが起きてしまうと思います。
|だから、思い付きでオブジェクトを作り出す訳には
|いかないと思います。

それについては否定しませんが，なにか私が設計が要らないとか，
思い付きでオブジェクトを定義すれば良いと主張しているかのよう
に読めるのですが，気のせいでしょうか？

私が主張しているのは，ある一定の粒度以下では設計という工程と
プログラミングという工程を分離する必要はない，ということで，
分析や設計が不要だとか，いい加減なプログラムを書けば良いとか
いうようなことは主張してません．

                                まつもと ゆきひろ /:|)

妹尾です。

  これは実装レベルの話だから問題ないと思います。
  逆に言えば、こういうレベルの事は設計で話すようなコトではないと
思ってます。良い設計とはシステムなりを実現するにあたって必要な
ことがすべて記述されていて、なおかつ実装の自由があるものだと
思います。実装の自由の範囲内では何をしようとも、それは設計を
かえる必要はありません。

  という事で、良いんじゃないでしょうか。どのレベルまでを設計と
呼ぶかという差はあれど、実態は変わらないと思います。

  少なくとも、そういう意味ではありません。

  このあたりは単に言葉の問題で、「プログラマ」ってのは「プログ
ラムを書く人」であり、「設計者」は「設計をする人」だという事です。
「プログラムも書けるけど、設計している人」は設計者です。

＃ こういう表現ってへんですか？

  私も見た事無いです。でも、存在しないと主張する気もありません。
もっとも、存在するにせよ、しないにせよ、私の書いた事には関係
ありません。
--
せのお / se...@xa2.so-net.or.jp
プログラマ魂 http://www02.u-page.so-net.or.jp/xa2/senoh/

大瀬戸です。
＃沢山あってフォローが大変です。(^^;)ゞ

In article <lv67il8qrn.fsf...@picachu.netlab.co.jp>, m...@netlab.co.jp says...

私が(多分妹尾さんも)考えているモジュールはもっと小さな単
位です．:-)

＃モジュールという言葉をつかったのが駄目だったのですね。
＃済みません。

In article <lv67il8qrn.fsf...@picachu.netlab.co.jp>, m...@netlab.co.jp says...

担当者間のコミュニケーションコストと、
一人の担当者の頭の中でのコミュニケーションコストとを、
比較すると、議論の本質はかわらないといえないのでは
ないでしょうか。

つまり、モジュール一つの捉え方（たとえば大きさ）から
異なってくると思うわけです。

もし、ここでのモジュールが関数単位、オブジェクト単位
であるのならば、担当者（あえてそう呼びます）が
エディタに向かって、キーボードを叩きながら考えても
そんなにおかしなことにはならないでしょう。

しかし、ここでのモジュールがもっと大きな単位
＃たぶん、担当者に任せられる仕事の大きさの単位
であるのならば、担当者が直接エディタに向かって、
キーボードを叩きながら考えてると、おかしなことに
なるのではないでしょうか。
“好きにして”っていう、スタンスは取れないと思います。

前者は、まつもと さんの

という発言と（粒度の面でも）同じだと思いますが
如何でしょう。

そして、後者において、もし、“好きにして”っていう
スタンスを取るとすると、

という発言と矛盾してしまうので、この意見にも同意頂けると
思います。

つまり、モジュールの粒度の面を共通に認識すると
お互い同意見になるのではないかと思いますが、
如何でしょうか。

決してそのような意図はありません。
しかし、モジュールの大きさの解釈で食い違いがあって
そのため誤解を生じた可能性は否定できないと思います。
申し訳ありません。m(_ _)m

まつもと ゆきひろです

|妹尾です。

|>ふむ，つまり「優れた設計者」であるが「プログラマとしては優秀
|>でない」人や「優れたプログラマ」であるが「ろくな設計が出来な
|>い」人が存在すると考えておられるんですね．
|
|  少なくとも、そういう意味ではありません。

そうなんですね．それは曲解のしすぎだったかもしれません．謝罪
します．

|＃ こういう表現ってへんですか？

表現は変じゃないです．ただ，元の表現は

|  とりあえず、正論を吐いておくと、「優れた設計者」と「優れたプロ
|グラマ」では、「優れた設計者」の方が優遇されて良いんじゃないで
|しょうか。

というものでした．で，この発言のこの文脈での意味をとりかねた
わけです．で，結局はどういう意味だったのでしょうか？
もしかして

               優れた人材は設計に回すべきだ

ということ？ それとも全然違う意味？ いずれにしてもなんとなく
私の賛成していない設計とプログラミングの分離を前提にしている
ような気がするんですが…．

                                まつもと ゆきひろ /:|)

まつもと ゆきひろです

|大瀬戸です。

|>私が(多分よしおかさんも)考えているモジュールはもっと大きな単
|>位です．
|
|私が(多分妹尾さんも)考えているモジュールはもっと小さな単
|位です．:-)
|
|＃モジュールという言葉をつかったのが駄目だったのですね。
|＃済みません。

じゃあ，私はサブシステムという言葉を使いましょう．

|しかし、ここでのモジュールがもっと大きな単位
|＃たぶん、担当者に任せられる仕事の大きさの単位
|であるのならば、担当者が直接エディタに向かって、
|キーボードを叩きながら考えてると、おかしなことに
|なるのではないでしょうか。

# そもそも私が「分離しない」と言ってることは「キーボードを叩
# きながら考える」こととイコールではないのですが…，まあ，い
# いです．

一般論としてそういう「おかしなこと」が発生することが多いこと
には同意します．が，そこで「だから分離せねばならない」と考え
るか，「分離するかしないかは担当者が『好きにして』」と考える
かの違いでしょう．

私の欲しいものはルールではなく，ちゃんとしたサブシステムだけ
ですから．またルールを設定しないとちゃんと分析もしてくれない
技術者より，優れたサブシステムをアウトプットしてくれる技術者
が欲しいです(そうありたいです)．

で，これはシュリンクラップなソフトフェアプロダクトでは普通の
考えだと思います，多分．が，日本の多くの企業では(おそらくは
程度のあまり高くない技術者を大量に抱えていたため)ルールで縛
る性悪説的なやり方が横行している(いた)と考えています．

|つまり、モジュールの粒度の面を共通に認識すると
|お互い同意見になるのではないかと思いますが、
|如何でしょうか。

そうかもしれません．よくわからないけど．

                                まつもと ゆきひろ /:|)

よしおかです．

なかなか琴線にふれるお話なんでリプライしちゃいます．
誰かを説得しよーとか，なにか新しい知見があるとか，
そーゆーことは一切ない，ただのプログラマのヨタ話です．

でもって，設計(未定義語)とプログラミングをわけるメリットってなんなんでしょ
うね．よくわからないっす．

素人にプログラミングさせれば，そりゃだめでしょう．どんなことやったって，
とか思っちゃいます．

そーなんです．素人を救済しよーとするから，話がややこしくなるんです．
プロのプログラマにやらせりゃいいんです．でもって，これって鶏と卵なんだけ
ど，大学の教育とか企業の研修がプロのプログラマを育成するのに，どれだけや
くだっているかというと，ほとんど，なんの貢献もしていないのじゃないかと思っ
てます．あ，これは余談か．

シュリンクラップなソフトウェアの開発現場ではプログラマがエディタであれや
これやしながらもの作っていきます．外部仕様書はあります．でも，デザインの
メモ程度のものはあっても，詳細な設計仕様書みたいな，それだけわたせば，素
人でもコードがかけるようなプログラムの一歩手前みたいなものは，少くともう
ちの会社にはありません．シリコンバレーの多くの現場もそうでしょう．コード
が最終的なよりどころです．外部仕様書を書く人と，コードを書く人が違う場合
もありますけど，それも多くの場合一緒だったりします．外部仕様を複数人で書
いて，複数人でコードを書くというパターンもあります．でも，外部仕様だけを
書く人とか設計だけする人とかプログラムを書くだけの人とかの区別はないです．
設計もすればコードも書く．

ある意味でハッカーがコードをハックしながらプロダクトを作っていく．そーゆー
イメージです．カオスといってもいいかもしれません．でも，モノは作られてい
ます．すごいスピードで．

素人にプログラムを書かせない．素人に設計をさせない．素人を何人あつめても
プロには勝てないっすよ．

あー，物議をかもしだすよーな事いっちゃったなあ．

よ

多分妹尾さんのおっしゃっている「設計」が示すものをわたしが理解できていな
いのだと思いますが．．．

別に言葉は，どーでもいいっちゃいいのですが，プログラミングと分離した，設
計というのは，どーゆーナニなのでしょうか？抽象的は話だと，わたしは多分理
解できないので，たとえば，モジラに縦書きを追加するという要求があったとし
て，外部仕様で，<SPAN DIR=TTB>というタグがあったときに縦書きにする，となっ
ていた場合の「設計」ってなんでしょうか？

よ

妹尾です。

  非常にベタな書き方をしてしまえば、設計でこけるのと、
プログラミングでこけるのはどちらが影響力がでかいかと
いえば、設計のほうだろう。だから設計はプログラミングより
も注意してやる必要がある。だから優れた(こけない)設計者
は、とても重要だという事です。

  設計はプログラミングより重要だと思いますけど、どうですか？

＃ このあたりの主張がどうも読み切れない。

  私は設計とプログラミングの分離を前提にしてます。
  確かに作業の流れの中では分離しにくいこともありますが、設計で
すべきこととプログラミングですべきことは、まるで違うと思います。

  設計は、そのアーキテクチャを示すものであり、具体的に実装の
内容を指すものではないと思います。だから分離は可能だし、
現実的だと思います。

  逆に言えば、プログラミングから分離されていない「設計」って設計
じゃなくてプログラミングだと思うんですけど。具体的にどう実装しよう
かと考える行為は設計ではなく、プログラミングだと思います。
--
せのお / se...@xa2.so-net.or.jp
プログラマ魂 http://www02.u-page.so-net.or.jp/xa2/senoh/

妹尾です。

  具体的といわれても モジラの設計を知らないので、それは無理です。

  ただ、最終的には その縦書きの追加によって変化する、各クラスの
「責任」と「協調動作」をまとめればいいんじゃないですか。

  枠組みまでは指定してますが、それを実現する方法に関しては言及
してませんよね。注意して欲しいのですが、ここでの「クラス」は OOD
におけるクラスなので、実装されているクラスと 1:1 では対応しません。
それは設計にはないけど、実装の都合で定義したクラスが存在する
からです。

  確か 「銀たま」に

  「設計者は、具体的な実装方法までは指定しない。しかし、プログラマから
聞かれた場合には少なくとも一つは、その方法を挙げる事ができなければ
ならない。」

といった事が書かれていたと思います。つまり考えた上で、限定しないと。

  単に「言葉」の話じゃないとおもいますよ。
--
せのお / se...@xa2.so-net.or.jp
プログラマ魂 http://www02.u-page.so-net.or.jp/xa2/senoh/

ほし＠えすあーるえーです。

In article <6klj21$...@utogw.gssm.otsuka.tsukuba.ac.jp>
         k...@gssm.otsuka.tsukuba.ac.jp writes:

ごめんなさい。ぼろくそに言う人がいるって噂を聞いたような
気がするだけで、具体的な批判の内容は知りません。

ほし

大瀬戸です。

＃あまりにも投稿記事が多くって困っています。
＃程々の投稿数だから、購読していたのに。（苦笑）

In article <g3b3edna7wm.fsf...@dlsun329.us.oracle.com>, hyosh...@us.oracle.com says...

僕の考える分析・設計・プログラミングの定義はこういうことです。
＃別に、どこかの教科書に載っていた訳ではなく、色々な本を
＃読んだ上で、自分が行き着いた考えです。

分析：作りたいソフトウエアは、何であるかを定式化すること。
設計：その何を、与えられたアーキテクチャで達成するための
      メカニズムを選択（場合によっては発明）すること。
      与えられたアーキテクチャの要件により、
      そこに時間制約やメモリ制約などが課せられる。
プログラミング：設計で選られたメカニズムを、プログラミング
      言語を用いて、コーディングする。

って意味です。
＃考えてみたんですけど、プログラミング言語自体にある程度の
＃メカニズムが入っていますよね。たとえば、x = x + 1;なんての
＃は、実は、メモリｘ番地からアキュムレータにロードして云々
＃なんてことが。
＃そういう小さいレベルで、プログラミングが設計に影響を与えて
＃いることはあるでしょうね。

まぁ、僕が定義する設計って、メカニズムの選択（必要なら発明）です。

素人がプログラミングしちゃうわけです。最初は。(;_;)

ははは。（笑）

僕（や多分妹尾さんも）が設計とプログラミングを分離するという
意味は、この、「カオスといってもいいかもしれ」ない、
「コードをハックしながら」のプログラミングを、ハッカーでない
普通のプログラマがやったら危険だと言っているわけです。
別に、「詳細な設計仕様書」を書けって言っているわけじゃ
全然無いです。
＃あったら、後の世代にとっては嬉しいですけどね。
考え方として、「今は設計をやっているからこれこれは
考察対象から省く。今は、プログラミングをやっているから云々」
という仕事をしないと危険じゃないか。と言っているわけです。
＃そこをやらないと、「エディタに向かって考え込む」訳です。

＃シュリンクラップのソフトウェア開発現場が、非常な開発競争を
＃やっているのは端から見ても判ります。
＃でも、だからと言って高機能ワープロが途中でハングアップするのは
＃我慢が出来ないです。:-)

そうなんですよ。プロには勝てないです。ハイ。
でも、そのプロってなかなか社員にならないんですよね。
＃流しのプロっていればよいのかな。:p

よしおかです．

家からポストしているので，うまくいくかどうか
わからないですが．．．

SENOH Yasushi <se...@xa2.so-net.or.jp> wrote in article
<6l23ko$hn...@news01ca.so-net.or.jp>...

DIR=TTB>というタグがあったときに縦書きにする，となっ

モジラの実装を知らないと設計できないわけですよね．
じゃあ，設計できるようになるためには，何をしなくちゃ
いかんかというと，実装を理解しなければならないわけですよね．

それって，なんか魔法のドキュメントが存在するわけではなくて，
コードを読む．それに尽きると思うのです．わたしは．

このプロセスの事を仮にデザインリカバリーと呼ぶとすると，
設計者の頭の中には，デザインリカバリーの後に，なんらかの
モデルができあがって，その後にやっとこさ設計ができると．
先に設計があるんじゃなくて先に実装があって，その後に設計がある．
まあ，渾然一体となって鶏と卵なんですけどね．

最初にスクラッチから作る時はどーするんだつー話は
もちろんありますけどね．

いずれにせよ，そーゆープロセスをまわす時，
設計者と実装者を分けるメリットってなんでしょうか？
設計工程と実装工程を分けるメリットってなんでしょうか？

いい設計にはよりよい実装の理解が必要だと
思っちゃったりするんです．わたしは．

あ，なにからなにまで一人で作れるような
小さいサイズのプログラムだったら，別に
どーでもいいことかもしれないですね．

よ

よしおかです．

お，なんか意見の一致をみそうな気配が．．．

Oseto Futoshi <os...@cs.ricoh.co.jp> wrote in article
<6l2850$...@ohmori.ohmori.ricoh.co.jp>...

ここは同意します．

だから

なんです．

雇用されているのプロのプログラマーっていっぱい
いますよ．むしろそっちのほうが多数でフリーランス
のほうが少ないような気がする．プロのプログラマが
日本に少ないとしたらなんでだろうか？

工場型開発対プログラマ型（？）開発なんなんですかね．

よ

|妹尾です。

|  非常にベタな書き方をしてしまえば、設計でこけるのと、
|プログラミングでこけるのはどちらが影響力がでかいかと
|いえば、設計のほうだろう。だから設計はプログラミングより
|も注意してやる必要がある。だから優れた(こけない)設計者
|は、とても重要だという事です。

|  設計はプログラミングより重要だと思いますけど、どうですか？

はあ，きっと妹尾さんには「設計とプログラミングがそれほど分離
していない状況」ってのが想像も出来ないんでしょうね．まあ，育っ
た環境とかありますからしょうがないんでしょうけど，ねえ．

よしおかさんの

  <g3b3edna7wm.fsf...@dlsun329.us.oracle.com>

とか読まれて，どう感じます．「私とは関係ない世界」と思います？
# それはそれで当然ですが．

私のこのスレッドでの主張は

  設計とプログラミングを分離しない世界もあるんだよ
  そして分離するやり方は多くの場合損している
  (が，分離するやり方が向いてる分野もある)

ってものです．妹尾さんの住んでいる(だろう)世界を全然否定して
いないんですね．が，どうか妹尾さんの住んでいる世界の常識だけ
で全てを決めつけないで欲しいとは思います．

ですから，

|  設計はプログラミングより重要だと思いますけど、どうですか？

という「設計とプログラミングが分離した世界を前提にした質問」
をされても困っちゃいます．そのような世界では私も「設計はプロ
グラミングより重要だ」と思います．しばらく前までそういう世界
に住んでましたから．そういう世界では往々にして下流の方に「使
えない人」を配置するのも当然だと思います．

が，よしおかさんの示されたような「そうでない世界」では，設計
でこけようが，プログラミングでこけようが，こけたことは一緒で
す．で，優秀な人*だけ*を求めるのです．

|  逆に言えば、プログラミングから分離されていない「設計」って設計
|じゃなくてプログラミングだと思うんですけど。具体的にどう実装しよう
|かと考える行為は設計ではなく、プログラミングだと思います。

それならそれで結構です．ちゃんとしたものが出来れば．

                                まつもと ゆきひろ /:|)
p.s.
妹尾さんの反論としては「なぜいつも設計とプログラミングは分離
していなければならないか」という点に関して行われることを期待
します．

大瀬戸です。

In article <01bd8e9f$5f5fcca0$91ab9...@yoshioka.vip.best.com>, yoshi...@best.com says...

って言うか、最初っから意見は一致していたんだけど、
言葉が一致してなかったからそう見えなかっただけのような
気がしてます。(;_;)

そこのスタンスが、置かれた環境によるんでしょうね。

全部のプログラマの数を数えたわけじゃないですけど、
僕の知り得る範囲では、素人からプログラムをはじめた
人がほとんどです。
＃それこそ、流しのプログラマなんてお目にかかったことが無い。

っていうか、ソフトウエアに要求されている＊質＊が
違うのかもしれませんね。
＃WindowsNTで制御されている、BowingNTなんて飛行機が
＃飛んでいたら、乗りたいと思います？:p

上原＠茨城大学.院生です。

NG:fj.news.group.comp,fj.comp.oops
Article:<HOSHI.98Jun3105...@sras49.sra.co.jp>
Mr ho...@sra.co.jp

  >ほし＠えすあーるえーです。
  >In article <6klj21$...@utogw.gssm.otsuka.tsukuba.ac.jp>
  >         k...@gssm.otsuka.tsukuba.ac.jp writes:
  >>   Design Patterns批判ってどんなことが言われているんですか?
  >ごめんなさい。ぼろくそに言う人がいるって噂を聞いたような
  >気がするだけで、具体的な批判の内容は知りません。

ぼろくそとまで行かないと思いますが，オブジェクト指向'97シンポジウムで
「パターンははたして有効か」というパネルセッションがありまして，その中
で現状のデザインパターンの問題点として次の点が指摘されていました。

(オブジェクト指向'97シンポジウム資料集より抜粋)
・利用者の創造性が前提
・自動化，ツールサポート (の点が弱い)
・（一般の開発者にとっては）意図するところを理解するのは容易でない
・（一般の開発者にとっては）実際のプロジェクトにそのまま利用できるわけ
  ではない
・効果的に利用するには比較的長期の訓練が必要

また研究課題として，
・言語設計
・型・プロトコルの理論
・プログラミング環境
・パターン情報の視覚化
・パターンのリポジトリ
などがあげられていました。

以降は私見ですが，会場の雰囲気として「デザインパターンを使えばソフト開
発現場での開発効率が上がるのか？」という雰囲気だった気がします。
それに対して，パネラーの方々は「そうじゃない，必ずしもそうとは言えない，
開発者間での共通語彙になるから，うまく使えば有効だけどね」という答えだっ
たと思います。  

面白かったのは富士通の吉田さんが言われた「(各プロジェクト毎に)自分達で
パターンを作って，洗練して，他の人たちも使えるまでにしよう」という，
PSP(Project Specific Pattern)の考えでした。ガンマ本のような，教科書的
なパターンもそれなりに価値があると思いますが，PSPの方がよっぽど実用的
だよなぁ，と感じました。

私は逆に，「デザインパターンはいいんだ！」という方々にどういう理由でデ
ザインパターンがいいのか，聞いてみたいです。  

それでは失礼します。
+---------------------------------------+
|上原 均 <ueh...@cis.ibaraki.ac.jp>     |
|茨城大学 大学院 情報・システム科学専攻 |
+---------------------------------------+

妹尾です。

<01bd8e9d$39bc66e0$91ab9...@yoshioka.vip.best.com>...

  いいえ、「設計」を知らないと「設計を拡張」することもできないとしか
言ってないつもりですが。

  いいえ。現実問題として、そういう事は多々ありますけど。それは
ドキュメントの不備か、まともな設計がされていないかだと思います。

 ただ、ドキュメントを整備しつづけるのは困難なので、プログラムと
ドキュメントを一体化することはあると思います。でも、そのドキュメント
を読むのと「実装を理解する」事は別物だと思います。

  鶏と卵は別れているとおもいますけど。言葉遊びでなく。
  お互いに影響しているということと、渾然一体になってしまう
ことは別物じゃないですか。

  別に分けなくてもいいですけど。

  逆に混ぜてしまうメリットは？

  「銀たま」や「コード コンプリート」なんかを読まれてもそう思う
のでしたら、何も言いません。

  「銀たま」こと「人月の神話」アジソン ウェスレイ パブリシャーズ ジャパン
      2900円 ISBN4-7952-9675-8

  「コードコンプリート」 アスキー出版 (もとは Microsoft press)
     7000 円ぐらいだったと思う。 ISBN は手元に無いので解りません。

  Toy problem はどーでも良いかと思います。
--
せのお / se...@xa2.so-net.or.jp
プログラマ魂 http://www02.u-page.so-net.or.jp/xa2/senoh/