昔fjというインターネットの掲示板みたいなものがあった（今でもあるけど）続きの続き

先日の話の続き。

• 昔fjというインターネットの掲示板みたいなものがあった（今でもあるけど） http://d.hatena.ne.jp/hyoshiok/20140115/p1
• 昔fjというインターネットの掲示板みたいなものがあった（今でもあるけど）続き http://d.hatena.ne.jp/hyoshiok/20140118/p1

さすがに長いけど、fjからのコピペはこれで最後になる。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/_m2HEa5QpGMJ
Hirotaka Yoshioka 	
1998/06/02

"SENOH Yasushi"  writes:
> 妹尾です。
> >いずれにしてもなんとなく
> >私の賛成していない設計とプログラミングの分離を前提にしている
> >ような気がするんですが…．
>   私は設計とプログラミングの分離を前提にしてます。
>   確かに作業の流れの中では分離しにくいこともありますが、設計で
> すべきこととプログラミングですべきことは、まるで違うと思います。
> 
>   設計は、そのアーキテクチャを示すものであり、具体的に実装の
> 内容を指すものではないと思います。だから分離は可能だし、
> 現実的だと思います。
多分妹尾さんのおっしゃっている「設計」が示すものをわたしが理解できていな
いのだと思いますが．．．

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

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

よ

昨日の続きからはじめたいと思う。設計とプログラミングの分離という話題から、そもそも設計ってなんだろうか、その共通の認識が出来ていないみたいだ。どうも設計というのが外部仕様の決定というようなものに近いニュアンスと実装に近いニュアンスがあって、そのなかで揺れている感じがする。

例えばAPIの決定を設計というのか、それともそれの実装方法について決めることを設計というのか。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/rwp4gqUlmuoJ
SENOH Yasushi 	
1998/06/03

OOA is prerequisite to OOP? (Re: ソ フト工学 … )

妹尾です。
Yukihiro Matsumoto wrote in message ...
>|  とりあえず、正論を吐いておくと、「優れた設計者」と「優れたプロ
>|グラマ」では、「優れた設計者」の方が優遇されて良いんじゃないで
>|しょうか。
>
>というものでした．で，この発言のこの文脈での意味をとりかねた
>わけです．で，結局はどういう意味だったのでしょうか？
>もしかして
>
>        優れた人材は設計に回すべきだ
>ということ？ それとも全然違う意味？

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

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

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

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

  私は設計とプログラミングの分離を前提にしてます。
  確かに作業の流れの中では分離しにくいこともありますが、設計で
すべきこととプログラミングですべきことは、まるで違うと思います。
  設計は、そのアーキテクチャを示すものであり、具体的に実装の
内容を指すものではないと思います。だから分離は可能だし、
現実的だと思います。

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

-
せのお / se...@xa2.so-net.or.jp
プログラマ魂 http://www02.u-page.so-net.or.jp/xa2/senoh/

設計とプログラミングの分離を前提にしていて、ウォーターフォールモデルを肯定している場合、設計でこけるのと、プログラミングでこけるのでは、前者がより影響度は大きい。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/EYGa1uZHzhgJ
SENOH Yasushi 	
1998/06/03

OOA is prerequisite to OOP? (Re: ソ フト工学 … )

妹尾です。
Hirotaka Yoshioka wrote in message ...
>"SENOH Yasushi"  writes:

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

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

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

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

  確か 「銀たま」に

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

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

  単に「言葉」の話じゃないとおもいますよ。


-
せのお / se...@xa2.so-net.or.jp
プログラマ魂 http://www02.u-page.so-net.or.jp/xa2/senoh/

縦書きにすると言う要求に対しての外部仕様を< SPAN DIR=TTB >とするというのは設計ではないという風にとらえている。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/Gasd9L_uub8J

Oseto Futoshi 	
1998/06/03

OOA is prerequisite to OOP? (Re: ソ フト工学… )

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

In article , hyos...@us.oracle.com says...
>でもって，設計(未定義語)とプログラミングをわけるメリットってなんなんでしょ
>うね．よくわからないっす．

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

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

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

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

>Yukihiro Matsumoto  writes:
>> るか，「分離するかしないかは担当者が『好きにして』」と考える
>> かの違いでしょう．
>
>素人にプログラミングさせれば，そりゃだめでしょう．どんなことやったって，
>とか思っちゃいます．
素人がプログラミングしちゃうわけです。最初は。(;_;)

>ど，大学の教育とか企業の研修がプロのプログラマを育成するのに，どれだけや
>くだっているかというと，ほとんど，なんの貢献もしていないのじゃないかと思っ
>てます．あ，これは余談か．
ははは。（笑）

>シュリンクラップなソフトウェアの開発現場ではプログラマがエディタであれや
（中略）
>ある意味でハッカーがコードをハックしながらプロダクトを作っていく．そーゆー
>イメージです．カオスといってもいいかもしれません．でも，モノは作られてい
>ます．すごいスピードで．
僕（や多分妹尾さんも）が設計とプログラミングを分離するという
意味は、この、「カオスといってもいいかもしれ」ない、
「コードをハックしながら」のプログラミングを、ハッカーでない
普通のプログラマがやったら危険だと言っているわけです。
別に、「詳細な設計仕様書」を書けって言っているわけじゃ
全然無いです。
＃あったら、後の世代にとっては嬉しいですけどね。
考え方として、「今は設計をやっているからこれこれは
考察対象から省く。今は、プログラミングをやっているから云々」
という仕事をしないと危険じゃないか。と言っているわけです。
＃そこをやらないと、「エディタに向かって考え込む」訳です。
＃シュリンクラップのソフトウェア開発現場が、非常な開発競争を
＃やっているのは端から見ても判ります。
＃でも、だからと言って高機能ワープロが途中でハングアップするのは
＃我慢が出来ないです。:-)

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

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

ここでハッカーと言う言葉が出てくる。素人にやらせないという立場に対して、素人がプログラミングしちゃうわけです。最初は。となる。前提が違うと言うところがあきらかになる。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/hlbHuAeLwRgJ

Hiro Yoshioka 	
1998/06/03

OOA is prerequisite to OOP? (Re: ソ フト工学 … )

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

SENOH Yasushi  wrote in article
<6l23ko$hn8$1...@news01ca.so-net.or.jp>...
> 妹尾です。
> >別に言葉は，どーでもいいっちゃいいのですが，プログラミングと分離した，設
> >計というのは，どーゆーナニなのでしょうか？抽象的は話だと，わたしは多分理
> >解できないので，たとえば，モジラに縦書きを追加するという要求があったとし
> >て，外部仕様で，< SPAN DIR=TTB >というタグがあったときに縦書きにする，となっ
> >ていた場合の「設計」ってなんでしょうか？
>   具体的といわれても モジラの設計を知らないので、それは無理です。
モジラの実装を知らないと設計できないわけですよね．
じゃあ，設計できるようになるためには，何をしなくちゃ
いかんかというと，実装を理解しなければならないわけですよね．

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

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

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

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

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

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

よ

設計と実装が不可分だという立場からどちらが重要とか先だと言うことではなく、わけるメリットはないと強調している。

Hiro Yoshioka 	
1998/06/03

OOA is prerequisite to OOP? (Re: $B%=(J $B%U%H9)3X!D(J )

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

Oseto Futoshi  wrote in article
<6l2850$h...@ohmori.ohmori.ricoh.co.jp>...
> 大瀬戸です。
> >Yukihiro Matsumoto  writes:
> >> るか，「分離するかしないかは担当者が『好きにして』」と考える
> >> かの違いでしょう．
    

        > >素人にプログラミングさせれば，そりゃだめでしょう．どんなことやったって，
> >とか思っちゃいます．
> 
> 素人がプログラミングしちゃうわけです。最初は。(;_;)
> 
> >シュリンクラップなソフトウェアの開発現場ではプログラマがエディタであれや
> （中略）
>
>ある意味でハッカーがコードをハックしながらプロダクトを作っていく．そーゆー
> >イメージです．カオスといってもいいかもしれません．でも，モノは作られてい
> >ます．すごいスピードで．
> 
> 僕（や多分妹尾さんも）が設計とプログラミングを分離するという
> 意味は、この、「カオスといってもいいかもしれ」ない、
> 「コードをハックしながら」のプログラミングを、ハッカーでない
> 普通のプログラマがやったら危険だと言っているわけです。
ここは同意します．

だから

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

なんです．

> そうなんですよ。プロには勝てないです。ハイ。
> でも、そのプロってなかなか社員にならないんですよね。
> ＃流しのプロっていればよいのかな。:p
雇用されているのプロのプログラマーっていっぱい
いますよ．むしろそっちのほうが多数でフリーランス
のほうが少ないような気がする．プロのプログラマが
日本に少ないとしたらなんでだろうか？

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

よ

    
日本におけるハッカーという言葉のニュアンスが孤高のプログラマと言うか気難しい一匹狼のプログラマというイメージがあって、例えばリチャードストールマンのような社会性（？）に乏しい人で、会社員でプロフェッショナルなプログラマというのが想像できなかったのかもしれない。マイクロソフトとかソフトウェア製品を作っている会社にはプロフェッショナルなプログラマはいくらでもいたのになあーと思う。

一方日本においてはソフトウェア工場という名の下に標準化されたプロセスのもとにバグ密度の低いプログラムを作っていくのがプログラマというイメージがあった。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/ANvfM6FF2LYJ

Yukihiro Matsumoto 	
1998/06/03

OOA is prerequisite to OOP? (Re: ソ フト工学 … )

"SENOH Yasushi"  writes:

    

    
妹尾です。
    
    

    
  非常にベタな書き方をしてしまえば、設計でこけるのと、
    
    

    
プログラミングでこけるのはどちらが影響力がでかいかと
    
    

    
いえば、設計のほうだろう。だから設計はプログラミングより
    
    

    
も注意してやる必要がある。だから優れた(こけない)設計者
    
    

    
は、とても重要だという事です。
    
    

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

よしおかさんの

   (https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/cVhZ_RzipakJ)

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

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

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

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

ですから，


    

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

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


    

    
  逆に言えば、プログラミングから分離されていない「設計」って設計
    
    

    
じゃなくてプログラミングだと思うんですけど。具体的にどう実装しよう
    
    

    
かと考える行為は設計ではなく、プログラミングだと思います。
    
それならそれで結構です．ちゃんとしたものが出来れば．

                                まつもと ゆきひろ /:|)
p.s.
妹尾さんの反論としては「なぜいつも設計とプログラミングは分離
していなければならないか」という点に関して行われることを期待
します．
ほぼ、双方の主張の相違点が出そろった。
一方は設計とプログラミングの分離を前提とし、設計はプログラミングより重要だという立場をとる。一方はそうでない世界があるという立場をとる。

妹尾さんの立場は前者、まつもとさんの立場は後者。前者の人に、後者の立場もありうるんだよということを理解してもらいたいというのがまつもとさんの主張である。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/uSDOq0yDHIkJ

Oseto Futoshi 	
1998/06/03

OOA is prerequisite to OOP? (Re: ソ フト工学 … )


大瀬戸です。
In article <01bd8e9f$5f5fcca0$91ab...@yoshioka.vip.best.com>, yosh...@best.com says...
>お，なんか意見の一致をみそうな気配が．．．

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

>> 僕（や多分妹尾さんも）が設計とプログラミングを分離するという
>> 意味は、この、「カオスといってもいいかもしれ」ない、
>> 「コードをハックしながら」のプログラミングを、ハッカーでない
>> 普通のプログラマがやったら危険だと言っているわけです。
>
>ここは同意します．
>
>だから
>
>> >素人にプログラムを書かせない．素人に設計をさせない．素人を何人あつめても
>> >プロには勝てないっすよ．
>
>なんです．
そこのスタンスが、置かれた環境によるんでしょうね。

>雇用されているのプロのプログラマーっていっぱい
>いますよ．むしろそっちのほうが多数でフリーランス
>のほうが少ないような気がする．プロのプログラマが
>日本に少ないとしたらなんでだろうか？
全部のプログラマの数を数えたわけじゃないですけど、
僕の知り得る範囲では、素人からプログラムをはじめた
人がほとんどです。
＃それこそ、流しのプログラマなんてお目にかかったことが無い。

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

っていうか、ソフトウエアに要求されている＊質＊が
違うのかもしれませんね。
＃WindowsNTで制御されている、BowingNTなんて飛行機が
＃飛んでいたら、乗りたいと思います？:p
プロフェッショナルになるには素人（アマチュア）からはじめるのは当然で生まれた瞬間からプロフェッショナルということはあり得ない。不断の訓練が必要なのはアスリートの世界と一緒である。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/2zOH0_c8PV8J
SENOH Yasushi 	
1998/06/03

OOA is prerequisite to OOP? (Re: ソ フト工学 … )

妹尾です。
Hiro Yoshioka wrote in message
<01bd8e9d$39bc66e0$91ab...@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/
どーでもいいけど、人月の神話のことを「銀たま」というのか、初めて知った。そーいえば、コードコンプリートって読んだことがない。不勉強を深く恥じ入る。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/cpvzdjn36m4J
SENOH Yasushi 	
1998/06/03

設計とプログラミング(Re: Re:: OO A is prerequisite to OOP?)

妹尾です。
＃ OO から離れたのでサブジェクト変えました。

Yukihiro Matsumoto wrote in message
...

>
>妹尾さんの反論としては「なぜいつも設計とプログラミングは分離
>していなければならないか」という点に関して行われることを期待
>します．
  だから 設計とプログラミングはやる事が全然違うからです。

  とりあえず、「銀たま」か「コードコンプリート」でも読まれては
いかがですか。少なくとも私は「分離しないほうがいい」という
話は聞いた事がないです。


-
せのお / se...@xa2.so-net.or.jp
プログラマ魂 http://www02.u-page.so-net.or.jp/xa2/senoh/
設計とプログラミングは分離しない方がいいではなく、むしろ分離できない渾然一体なものであると言う方が近いかもしれない。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/L7ya2yI89qMJ

Hirotaka Yoshioka 	
1998/06/03

OOA is prerequisite to OOP? (Re: ソ フト工学 … )

よしおかです．
やっぱり宗教が違うみたいですね．しくしく．
あいかわらづ，おやぢのヨタ話かましてますので，お急ぎの方，どーぞとばしちゃっ
てください．

"SENOH Yasushi"  writes:
> 妹尾です。
> >>   具体的といわれても モジラの設計を知らないので、それは無理です。
> >モジラの実装を知らないと設計できないわけですよね．
>   いいえ、「設計」を知らないと「設計を拡張」することもできないとしか
> 言ってないつもりですが。
そりゃそーですよね．

> >じゃあ，設計できるようになるためには，何をしなくちゃ
> >いかんかというと，実装を理解しなければならないわけですよね．
>   いいえ。現実問題として、そういう事は多々ありますけど。それは
> ドキュメントの不備か、まともな設計がされていないかだと思います。
がびーん．コードを読めばわかることをなぜわざわざ別の形式にしなければいけ
ないのだろうか？コードを読むとっかかりとしての簡単なメモとかアーキテクチャー
のドキュメントはあったとしても，詳細設計(？)のドキュメントを作るなんて時
間のムダだと思ってしまうなあ．なにをもって，「ドキュメントの不備」という
のか，「まともな設計」というのかをわたしが理解していないからだとは思うの
ですけどね．

ドキュメントを作るのが目的ではなくて，ソフトウェアプロダクトを作るのが目
的なんですよね(確認)．でもって，ソフトウェアを作るとき，「まともな設計」
だと，バグが修正しやすいとか，拡張しやすいとか，性能がよいだとか，いろい
ろな属性をかねそなえていると．

事例研究として，
http://www.mozilla.org/
にいって，モジラが「まともな設計」でないというのを指摘いただけるとうれし
いんですけど．あるいはドキュメントが不備で，設計ができないという指摘をい
ただけたら．具体的な話じゃないと，どーも理解ができないんですよ，わたしは．

でも，僭越ながら妹尾さんのお話をうかがっていると，なんか評論家のお話を聞
いているような感じがします．いやーごもっともごもっともみたいな．プログラ
マーつーのはプログラムを書いて金もらってんだから，ドキュメントがあろうが
なかろうが，設計がタコだろうがなんだろうが，プログラムを作った方がエライ
つーか．でもそれって人それぞれですから，別にいいんですけど．

>  ただ、ドキュメントを整備しつづけるのは困難なので、プログラムと
> ドキュメントを一体化することはあると思います。でも、そのドキュメント
> を読むのと「実装を理解する」事は別物だと思います。
そうですか．現実問題として，一つのものを表現するのに複数の実体があるのは，
一貫性を維持するのが困難なんで推奨されていないし，教条的に「ドキュメント
を整備しろ」というのは簡単だけど，危険な発想だとわたしは思います．外部仕
様を用意するのは，あたりまえなんだけど，詳細設計のドキュメントもメンテナ
ンスしないといかんですか．言葉がよくわかっていないけど．

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

ちょっとほっとしてます．

> >設計工程と実装工程を分けるメリットってなんでしょうか？
>   逆に混ぜてしまうメリットは？

開発のスピードが早い速い．

> >いい設計にはよりよい実装の理解が必要だと
> >思っちゃったりするんです．わたしは．
>   「銀たま」や「コード コンプリート」なんかを読まれてもそう思う
> のでしたら、何も言いません。
>   「銀たま」こと「人月の神話」アジソン ウェスレイ パブリシャーズ ジャパン
>       2900円 ISBN4-7952-9675-8
人月の神話は，初版も第2版も読みました．何回も読みました．

http://www.best.com/~yoshioka/d/98/i980227.html

に感想文のせてます．

コードコンプリートは読んでいないです．すいません．

ここでわたしの対象としているソフトウェアはいわゆるシュリンクラップみたい
なやつで，原子力発電所の制御とか，航空機のなにとか，そーゆーものではない
です．そこそこの品質の製品をどーつくるかの話ですね．

よ
Hiro Yoshioka
yosh...@best.com (home)
hyos...@jp.oracle.com (office)
http://www.best.com/~yoshioka/diary.html
What is Oracle 8?
It's The Database for Network Computing.
http://www.oracle.co.jp/books/o8/003/top.html
かなり立場が違っている。設計とプログラミングは分離すべきだという立場の人が、ドキュメントが不備だから実装が理解できないという主張に対し、実装のドキュメントを作ることは無駄だと言い切っている。プログラマはプログラムを作ることに価値があってドキュメントを作ることではないという極論を展開している。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/qWh48cSeB9kJ

Shinji Kono 	
1998/06/03

 OOA is prerequisite to OOP? (Re: ソフト工学… )


河野 真治@琉球大情報工学です。
In article  , 
        Hirotaka Yoshioka  writes 

>がびーん．コードを読めばわかることをなぜわざわざ別の形式にしなければいけ
>ないのだろうか？コードを読むとっかかりとしての簡単なメモとかアーキテクチャー
>のドキュメントはあったとしても，詳細設計(？)のドキュメントを作るなんて時
>間のムダだと思ってしまうなあ．なにをもって，「ドキュメントの不備」という
>のか，「まともな設計」というのかをわたしが理解していないからだとは思うの
>ですけどね．
もし、一人で作っているのだったら、そんなドキュメントはいらない
んですよね。でも、例えば、学生に「こういうものを作る」と説明
する時とか、あるいは「一体全体、何を作ったんだ?」とか、「何を
作るつもりだったんだ?」とかいう答に対して、

    「がびーん．コードを読めばわかる」

とはいえないでしょう? そういう時に、どういうものを答えれば良いか
ということに関しては、OOA/OODは正しい答を与えていると思います。

それとも、何人かでプロジェクトをすすめる時に、テレパシーかなんか
を使うんでしょうか...

あと、3000行ぐらいのプログラムでも読めない奴っていますよね。
僕でも3000行を一日で読めっていわれると、げー、と思う。
そういう奴にも、それなりに構造を納得してほしかったり、
一部でもいいから改良してほしかったりしますよね。その時に、
コードでなくて何を見せるのか? ってことだと思うんだ。




-

Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科
「がびーん、コード読めばわかる。」なかなかインパクトがある言葉だな。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/wiS8Kxz3d-4J

Hirotaka Yoshioka 	
1998/06/03

 OOA is prerequisite to OOP? (Re:ソ フト工学… )


よしおかです．
どもども，多分ドキュメントをどの程度の細かさで記すかという粒度の問題だと
は思うのですけど，わたし自身は，設計の概要とか，モジュールの構成とか，そー
ゆー安定している部分のドキュメントが不要だとかいっているわけではなくて，
それは必要だとは思うけど，詳細(？)なものは不要だと言っているわけです．

ko...@ie.u-ryukyu.ac.jp (Shinji Kono) writes:
> 河野 真治@琉球大情報工学です。
> In article  , 
>         Hirotaka Yoshioka  writes 
> >がびーん．コードを読めばわかることをなぜわざわざ別の形式にしなければいけ
> >ないのだろうか？コードを読むとっかかりとしての簡単なメモとかアーキテクチャー
> >のドキュメントはあったとしても，詳細設計(？)のドキュメントを作るなんて時
> >間のムダだと思ってしまうなあ．なにをもって，「ドキュメントの不備」という
> >のか，「まともな設計」というのかをわたしが理解していないからだとは思うの
> >ですけどね．
> もし、一人で作っているのだったら、そんなドキュメントはいらない
> んですよね。でも、例えば、学生に「こういうものを作る」と説明
> する時とか、あるいは「一体全体、何を作ったんだ?」とか、「何を
> 作るつもりだったんだ?」とかいう答に対して、
>     「がびーん．コードを読めばわかる」
> とはいえないでしょう? そういう時に、どういうものを答えれば良いか
> ということに関しては、OOA/OODは正しい答を与えていると思います。
河野さんのおっしゃっているのは「何を」というドキュメントで，その必要性を
否定したつもりはないのですけど．わたしが問題としているのは，いかにという
のを記したドキュメントで，その詳細を記したドキュメントの必要性に疑義をは
さんでいると．

> それとも、何人かでプロジェクトをすすめる時に、テレパシーかなんか
> を使うんでしょうか...

がはは．

> あと、3000行ぐらいのプログラムでも読めない奴っていますよね。

読めない奴もいれば，読める奴もいる．
でも，読めない奴は，いーの，相手にしないから．

> 僕でも3000行を一日で読めっていわれると、げー、と思う。
> そういう奴にも、それなりに構造を納得してほしかったり、
> 一部でもいいから改良してほしかったりしますよね。その時に、
> コードでなくて何を見せるのか? ってことだと思うんだ。
仮にその何かというのがあって，その使えないやつを使うはめになって，どーに
かしてほしい場合どうするかという問題だと勝手に解釈します．その何かという
を読む時間，理解する時間は，コードを読んで理解する時間より短いと．そして，
その結果，コードを変更できると．うーむ，そーゆー便利なものがあれば，ぜひ，
見たいです．

ちょっと，話をかえますけど，忙しくて，ねこの手もかりたい状況つーのはあり
ます．もちろん，しょっちゅうです．その時，いろいろな作戦がありますけど，
一番最悪なのは，素人をそのプロジェクトにつっこむこと．つまり，3000行のプ
ログラムを一人で，どーにかできない連中をつっこむことですね．ブルックス先
生も言っていましたよね．状況悪化しちゃいますよね．そーゆー時の次善の策は，
スケジュールを延すか，実装する機能をおとすか，それだけだと思うのです．実
装レベルの詳細を記述したドキュメントを整備することが，その問題を解決する
とは思っていないです．
もちろんこれは，わたしのスタイルというか，ここらへんの会社がやっているス
タイルですから，どんなソフトウェアにも適用可能だとか，有効だとか言うつも
りはモートーないです．

大規模ソフトウェアを作成する時，その詳細ドキュメントを整備するより，リグ
レッションテストとかディリービルドとか，そーゆーインフラの方がはるかに重
要だとは思うのだけど，まあ，ここの文脈では，あんまり関係ないですね．
よ
ドキュメントにもいろいろあって、「何を(what)」を示したものと、「いかに(how)」をしめしたものがあって、前者は必要だが、後者はいかがなものかという立場だ。ふむふむ。

そして、なんらかの事情でコードを変更しなくちゃいけないということがあったとき、そのドキュメントを読めば、コードを読むよりも素早く修正できるようになるというものがあれば、ぜひお目にかかりたい。多分そんなものは存在しないであろうとまでは言っていないけど、行間からはそのようなニュアンスがにじみ出ている（テレパシーで感じ取った）

ウォーターフォールモデルが仮定している、工程の分離、そしてその前提となる文書の整備、それが金科玉条のものであるという立場に対する強烈な批判である。

そして、次の段落が猫の手も借りたい状況の時どうするかという古典的な問題に対する解が明示されている。

ブルックスによれば人員の追加は最悪の手段である。(やってはいけない)
スケジュールを延ばすか
実装の機能をおとすか
↑これは昨今アジャイルソフトウェアの時代になってようやく人々のクチに上るようになってきたメッセージである。遅延するプロジェクトに人員を追加してはならない。素人をチームに途中から突っ込むな。未だにそれを理解していないプロジェクトマネージャーがいると言うことがソフトウェア開発における競争力のなさを物語っている。そんなことは15年前から一部では常識だったのに。

ドキュメントの整備だとか言う前にやることあるでしょう。

そして、それこそが、誰も指摘していなかったけど、大規模ソフトウェアを作成する時，その詳細ドキュメントを整備するより，リグレッションテストとかディリービルドとか，そーゆーインフラの方がはるかに重要ということなのである。

リグレッションテストがあれば、変更が容易になる。素早くできる。それはしょぼいドキュメントより遥かに有効である。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/SnUebcbM464J

Oseto Futoshi 	
1998/06/03

 OOA is prerequisite to OOP? (Re: ソ フト工学… )


大瀬戸です。
＃チャチャです。m(_ _)m
In article , hyos...@us.oracle.com says...
>もちろんこれは，わたしのスタイルというか，ここらへんの会社がやっているス
>タイルですから，どんなソフトウェアにも適用可能だとか，有効だとか言うつも
>りはモートーないです．
そうですよね。シュリンクラップの開発競争ではそうでしょう。
＃特に、競争相手がMSなら。
でも、その思想が他のところに波及しないように願うわけです。
核攻撃とまではいかなくても、サッカーの中継の後半ロスタイムの
終了間際の肝心な時にバグられると、人命には関係なくても
腹が立ちます。
＃べつに、あの事件がソフトウエアのバグによるものだとは決して
＃言っていません。でも、バグの所為だったら、殺されるな担当者は。:p

>大規模ソフトウェアを作成する時，その詳細ドキュメントを整備するより，リグ
>レッションテストとかディリービルドとか，そーゆーインフラの方がはるかに重
>要だとは思うのだけど，
私は、はるかに重要かどうかは、全ての開発ケースを知っている
訳じゃないので言えませんが、開発する対象の置かれた環境に
寄るのじゃないでしょうか。
開発する対象の置かれた環境によると言う指摘はその通りだけど、おそらくそのような環境と言うのはその当時の人々が思っているより遥かに多い。


https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/OWFD3uOFP-MJ

Oseto Futoshi 	
1998/06/03

 OOA is prerequisite to OOP? (Re: ソ フト工学… )


大瀬戸です。
＃チャチャの自己フォローになってしまいます。
＃御恥ずかしい。m(_ _;)m
In article <6l4ldb$6...@ohmori.ohmori.ricoh.co.jp>, os...@cs.ricoh.co.jp says...

>In article , hyos...@us.oracle.com says...
>>もちろんこれは，わたしのスタイルというか，ここらへんの会社がやっているス
>>タイルですから，どんなソフトウェアにも適用可能だとか，有効だとか言うつも
>>りはモートーないです．
これは、シュリンクラップ開発の場合での納期が満たせない時の
対処の仕方でしたね。
バグ云々の話では有りませんでした。

お詫びして訂正します。
バグ云々の場合もディリービルドやリグレッションテストの整備は有効ではある。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/V0Bi9QVblLMJ

SENOH Yasushi 	
1998/06/04

 OOA is prerequisite to OO P? (Re: ソフト工学… )


妹尾です。
Hirotaka Yoshioka wrote in message ...
>やっぱり宗教が違うみたいですね．しくしく．

  それはあるでしょうね。やっぱり。最終的には
「これだけの効果がありました」
なんていう成果の話をせんとイカンのでしょうが、そこまでのバックデータは
ないですし、そもそもどうやってそれを測定するのかという話もあります。

  システムの「複雑さ」やプログラマの「能力」なんかは「測定」しにくい
または不可能ですよね。

>がびーん．コードを読めばわかることをなぜわざわざ別の形式にしなければいけ
>ないのだろうか？

  コードはアーキテクチャの実現例であって、そのものではないからです。
  極論すれば「コードを読めば解るのなら、ソースコードでなくて、アセンブラ
コードでもいいですよね」とも言えるかと。当然、そんな主張はしません。
ソースコードにはアセンブラコードに記述されない、意味が込められています。
おなじく設計にもプログラムコードには記述されない意味が込められて
います。

  つまり「コードを読んでも解らない」からです。

>コードを読むとっかかりとしての簡単なメモとかアーキテクチャー
>のドキュメントはあったとしても，

  簡単かどうかは、その規模によると思いますが、設計としてはそこまでの
話しかしていないつもりです。

>詳細設計(？)のドキュメントを作るなんて時
>間のムダだと思ってしまうなあ．

  あれって、「設計」なんですかね？私も疑問を感じてます。
  私も実装方法を記述したドキュメントなんか要りません。大体ウソしか書いて
ないし。

＃ なんどだまされた事か。

  ってことは、結局やっている事はおなじなのかな。

>なにをもって，「ドキュメントの不備」という
>のか，「まともな設計」というのかをわたしが理解していないからだとは思うの
>ですけどね．

  ここで「まともま設計がされていない」というのは、そのアークテクチャが
まるで表現できないようなプログラムになっているような場合を想定してい
ただけるとありがたいです。

  プログラムがあるからといって、それに読解可能な「アーキテクチャ」
があるとはかぎらないですよね。


>>  ただ、ドキュメントを整備しつづけるのは困難なので、プログラムと
>> ドキュメントを一体化することはあると思います。でも、そのドキュメント
>> を読むのと「実装を理解する」事は別物だと思います。
>
>そうですか．現実問題として，一つのものを表現するのに複数の実体があるのは，
>一貫性を維持するのが困難なんで推奨されていないし，
  そうです。だから私はソースコード中にコメントとして記述してます。これなら
少しは楽です。具体的には (C++の場合) ヘッダファイルに集中して書きます。
こんなカンジです。

// Class:  CPerson (人間クラス)

// Responsibilities:
//   ・ 一人の人間に対応し、その情報を管理する。
//   ・ 人間に対して「名前」「社員コード」を設定・取得することができる。
//        (SetName, GetName, SetIDNumber, GetIDNumber)
//   ・ 人間は、どの部署にいるのかを返すことができる。(GetDep)
//   ・ 人間は、その上司オブジェクトを返す事ができる。(GetBoss)

//  Collaborators:
//  ・ 人間クラスは部署クラスと N:1 の「所属する」という関係をもつ。
//  ・ 上司オブジェクトは所属している部署クラスに問い合わせる事で得る。

  一応 CRC のつもりです。

  あとは全体の見通しをよくするためのクラス図。全クラスは
描きません。OOA/OODで抽出されたクラスだけです。実は
私もこの程度しかしてません。

  実は昔、私は「複数の実体があるのは，一貫性を維持するのが困難
だから、全て一つだけで記述しなければならない」と考え、設計もコメント
(本当にただの一行のコメントも)書かないで作業していたときもあります。
3年間ぐらい、そんなスタイルでやってました。でも、それはナンカ違うな
と思ったんです。

>人月の神話は，初版も第2版も読みました．何回も読みました．

  そーですか。それでもそう思われるのならば、私の出る幕ではないかと。

>ここでわたしの対象としているソフトウェアはいわゆるシュリンクラップみたい
>なやつで，原子力発電所の制御とか，航空機のなにとか，そーゆーものではない
>です．そこそこの品質の製品をどーつくるかの話ですね．

  わからんでも無いですが、やたらと「攻撃的」な手法である気がします。
  「失敗した時のことは考えるな、成功すればいいんだから」的なです。

せのお / se...@xa2.so-net.or.jp
プログラマ魂 http://www02.u-page.so-net.or.jp/xa2/senoh/
双方の意見の相違があきらかになってきた感じがする。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/iaYHDR9J37AJ

Hiro Yoshioka 	
1998/06/04

 OOA is prerequisite to OOP? (Re: $B%=%U%H9)3X!D(J )


よしおかです．
大体双方の主張がでそろって，なんとなく
見解の相違ですね，とかいう感じで落ち着こうと
している予感がする今日このごろです．

> 妹尾です。
> >がびーん．コードを読めばわかることをなぜわざわざ別の形式にしなければいけ
> >ないのだろうか？
>   コードはアーキテクチャの実現例であって、そのものではないからです。
>   極論すれば「コードを読めば解るのなら、ソースコードでなくて、アセンブラ
> コードでもいいですよね」とも言えるかと。当然、そんな主張はしません。
> ソースコードにはアセンブラコードに記述されない、意味が込められています。
> おなじく設計にもプログラムコードには記述されない意味が込められて
> います。
>   つまり「コードを読んでも解らない」からです。
なぜこういう実装をしたか？という問いにはソースコードは
答えていませんね．確かに．その部分は同意します．

従って，なぜこーゆー実装をしたかという事を
記すというのは重要であるという点においては，
意見の一致を見そうなきがします．

でも，それって，コードにコメントで書くのじゃ
だめなんですか？だめなんでしょうね？

> >詳細設計(？)のドキュメントを作るなんて時
> >間のムダだと思ってしまうなあ．
>   あれって、「設計」なんですかね？私も疑問を感じてます。
>   私も実装方法を記述したドキュメントなんか要りません。大体ウソしか書いて
> ないし。
おお，ここでも意見の一致をみそうですね．

> >なにをもって，「ドキュメントの不備」という
> >のか，「まともな設計」というのかをわたしが理解していないからだとは思うの
> >ですけどね．
>   ここで「まともま設計がされていない」というのは、そのアークテクチャが
> まるで表現できないようなプログラムになっているような場合を想定してい
> ただけるとありがたいです。
これって実装がたこだということを言っていますか？

>   プログラムがあるからといって、それに読解可能な「アーキテクチャ」
> があるとはかぎらないですよね。

「アーキテクチャ」を反映していないプログラムからは
いくらプログラムを読んだところで，「アーキテクチャ」を
読解できない，という事ですか？

そりゃそうでしょうね．それはプログラムが
悪いわけですから．

> >>  ただ、ドキュメントを整備しつづけるのは困難なので、プログラムと
> >> ドキュメントを一体化することはあると思います。でも、そのドキュメント
> >> を読むのと「実装を理解する」事は別物だと思います。
> >そうですか．現実問題として，一つのものを表現するのに複数の実体があるのは，
> >一貫性を維持するのが困難なんで推奨されていないし，
>   そうです。だから私はソースコード中にコメントとして記述してます。これなら
> 少しは楽です。具体的には (C++の場合) ヘッダファイルに集中して書きます。
> こんなカンジです。
ここも意見の一致をみそうですね．
管理すべきはソースコードだけだと．

>   あとは全体の見通しをよくするためのクラス図。全クラスは
> 描きません。OOA/OODで抽出されたクラスだけです。実は
> 私もこの程度しかしてません。
なるほどね．

> >人月の神話は，初版も第2版も読みました．何回も読みました．
>   そーですか。それでもそう思われるのならば、私の出る幕ではないかと。
今，手元に第２版を置いているのですけど，
ドキュメントについては１５章に書いてあると
思うのですが，そこで「フローチャートの呪い」
ということで，その役割を否定しています．
また「自己文書プログラム」ということで
プログラムのコードの中に文書を入れる事を
提案してます．

”プログラム文書は悪名高いほどに貧弱で，
そのメンテナンスはさらにひどい．プログラムの
変更が，すみやかに正確にそしてそのまま
紙の上に記述されることはない．”
．．．
”主要な目的は，文書作成の負担を最小化することだ．”

ということで同じ本を読んでもまるっきり違う
解釈というか，印象というか，アプローチを
読み取るという事例なんでしょうね．

> >ここでわたしの対象としているソフトウェアはいわゆるシュリンクラップみたい
> >なやつで，原子力発電所の制御とか，航空機のなにとか，そーゆーものではない
> >です．そこそこの品質の製品をどーつくるかの話ですね．
>   わからんでも無いですが、やたらと「攻撃的」な手法である気がします。
>   「失敗した時のことは考えるな、成功すればいいんだから」的なです。
ブルックスの第２版では，漸増的構築モデルということで，
マイクロソフトの「毎晩構築」アプローチを紹介してます．
デイリービルドとかナイトリービルドとか呼ばれている
やつですね．これは毎日毎日ビルドを繰り返して，
徐々に機能を洗練しいくアプローチです．

毎日のビルドでは常に動くプロダクトが得られます．
時として機能の後退（リグレッション）が発生しますが，
毎日ビルドしてリグレッションテストを流していますから
すぐに発見できます．いつ失敗してもいいのだけれど
それを発見してすぐに修正するというプロセスが
組み込まれています．

このプロセスのダイナミズムを理解しないと
なかなかシュリンクラップの現場の勢いを
理解できないかなと思います．

一つのプロダクトが出荷されるまでに
ものによっては数百回，あるいはそれ以上
ビルドされて，常に修正されるというイメージです．

よ
おそらく当時の日本にはこのディリービルドやリグレッションテストの重要性を理解していた人はほとんどいなかった。いまでこそ継続的ビルドなど言葉が出て来ているが、当時そのような概念を理解していた人はほとんどみかけなかった。

ソフトウェア製品開発の現場が日本にはほとんど存在しなかったのだからそれも致し方ない。残念ではあるけれど。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/q10grJolKJcJ

Kiyohiko Kajihara 	
1998/06/04

 OOA is prerequisite to OOP? (Re: ソフト工学… )


妹尾さんではなく，梶原＠ＮＴＴソフトウェア研究所ですが．
 >>  設計はプログラミングより重要だと思いますけど、どうですか？

 |はあ，きっと妹尾さんには「設計とプログラミングがそれほど分離
 |していない状況」ってのが想像も出来ないんでしょうね．まあ，育っ
 |た環境とかありますからしょうがないんでしょうけど，ねえ．
設計が「システム全体あるいはサブシステムのレベルでの構造や，制御の基本
方針の決定」と定義するなら，プログラミング「各モジュールの役割を決め，
コードを記述すること」とは別のものであるわけです．あるいは「モジュール
の役割を決め，インタフェースを明確にすること」と設計を定義するなら，
プログラミング「各モジュールのアルゴリズムを決め，コードを記述すること」
も別のものですよね．

つまり，設計とプログラミングはシステムの異なる特性を決定（記述）すること
なわけです．

規模の大きなソフトウェアは複雑なので，決定の対象範囲の分割または決定の
順序を設計→プログラミングと分離する必要があるわけです．後者の場合当然，
スムーズにつながらない場合が多いので調整が必要です．前者の場合には，設
計とプログラミングを同じ人が担当した方が効率的ですが，分割損や分割した
ものどおしの調整が必要です．

結局，開発チームの構成やメンバの能力／経験，プロジェクト管理方法などから
決めることになるのであって，「設計とプログラミングを分離すること」がよい，
悪いということではないでしょ．状況によりどちらがより適しているかです．

 kajihara of NTT Software Labs.
状況によるという主張。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/YYeKLGrczmMJ

SENOH Yasushi 	
1998/06/04

 OOA is prerequisite to OO P? (Re: ソフト工学… )

妹尾です。
Hiro Yoshioka wrote in message
<01bd8f95$7ababf40$91ab...@yoshioka.vip.best.com>...
>でも，それって，コードにコメントで書くのじゃ
>だめなんですか？だめなんでしょうね？

  いいんじゃないですか。
  私はそうしていると書いたつもりですが...。

>>   ここで「まともま設計がされていない」というのは、そのアークテクチャが
>> まるで表現できないようなプログラムになっているような場合を想定してい
>> ただけるとありがたいです。
>
>これって実装がたこだということを言っていますか？

  そうですね。ただ、私の立場ではそんな風に実装がタコになるのは設計が
悪い(またはされていない)からだという事です。この辺は宗教かもしれません。

>今，手元に第２版を置いているのですけど，
>ドキュメントについては１５章に書いてあると
>思うのですが，そこで「フローチャートの呪い」
>ということで，その役割を否定しています．

  これって「詳細設計 or プログラム設計」だと思うので、私も否定している
つもりですが...。

>また「自己文書プログラム」ということで
>プログラムのコードの中に文書を入れる事を
>提案してます．

  これもしていると書いたつもりなんですが。

>”プログラム文書は悪名高いほどに貧弱で，
>そのメンテナンスはさらにひどい．プログラムの
>変更が，すみやかに正確にそしてそのまま
>紙の上に記述されることはない．”
>．．．

  こういうのは必要ないと書いているつもりなんですけど。

>”主要な目的は，文書作成の負担を最小化することだ．”
>
>ということで同じ本を読んでもまるっきり違う
>解釈というか，印象というか，アプローチを
>読み取るという事例なんでしょうね．

  どこが違うんでしょう？

  設計と実装は分けましょうとは言ってますが、この手の文書を
作成しようとは言ってないつもりです。つまり設計者がコメントとか
クラス定義を書くんです。そして、プログラマはこれを勝手に変え
てはいけないと。

  設計者とプログラマが同一人物であることはあると思いますが、
ちゃんと、それぞれに立場にそって作業すべきです。この場合も
「プログラマ」が勝手に(コメントやクラス定義で表現されている)設計
を変えちゃだめです。一度「設計者」に戻らないと。さらに場合に
よっては「設計者会議」が必要かと。

>ブルックスの第２版では，漸増的構築モデルということで，
>マイクロソフトの「毎晩構築」アプローチを紹介してます．
>デイリービルドとかナイトリービルドとか呼ばれている
>やつですね．これは毎日毎日ビルドを繰り返して，
>徐々に機能を洗練しいくアプローチです．

  だからといって、プログラマが設計を変えていいわけじゃないです
よね。よしおかさんのやり方は「プログラマが設計を変える」ような方法
だと思ったのですが、違うんでしょうか？

せのお / se...@xa2.so-net.or.jp
プログラマ魂 http://www02.u-page.so-net.or.jp/xa2/senoh/
時にはプログラマが設計を変えるときもある、そしてそのためのデイリービルドというインフラがある。という主張は理解されなかったようだ。

https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/YYeKLGrczmMJ

Yukihiro Matsumoto 	
1998/06/05

 OOA is prerequisite to OOP? (Re: ソフト工学… )


まつもと ゆきひろです
kaji...@ammonite.slab.ntt.co.jp (Kiyohiko Kajihara) writes:



    

    
妹尾さんではなく，梶原＠ＮＴＴソフトウェア研究所ですが．
    


    

    
 
    
はあ，きっと妹尾さんには「設計とプログラミングがそれほど分離
    
    

    
 
    
していない状況」ってのが想像も出来ないんでしょうね．まあ，育っ
    
    

    
 
    
た環境とかありますからしょうがないんでしょうけど，ねえ．
    
    

    
結局，開発チームの構成やメンバの能力／経験，プロジェクト管理方法などから
    


    

    
決めることになるのであって，「設計とプログラミングを分離すること」がよい，
    
    

    
悪いということではないでしょ．状況によりどちらがより適しているかです．
    
もちろんです．私は「そういうやり方が存在している」ことを示し
ているだけで，「そのようなやり方がいつも優れている」とは述べ
ていないつもりです．

# 存在を認めてなければ「どちらがより適しているか」とは言えま
# せんものね．

私には妹尾さんは「そのようなやり方」を認めていらっしゃらない
ように読めました．

というわけで、長々と過去のfjのやり取りを紹介してみた。ここまで読んでいただきありがとうございます。

15年前の話なので若い人にはなじみのないことが多かったかと思う。インターネットで議論するという雰囲気を少しでも感じ取っていただければ幸いである。しかし、まどろっこしいね。正直めんどくさい感じもしないわけでもない。Twitterとかでのやりと比べると明らかにリズムも質も異なる。意見が異なっても徹底的に議論を重ねるというスタイルはちょっと疲れるかもしれないが、時としては実りの多いものになる。

当時のわたしの書き込みを今更読んでみると、なんかルサンチマン満載というか、この人なにかイヤなことでもあったんじゃなかろうかという空気が感じられて痛い。中二病をこじらせている感じである。

ソフトウェア製品の開発をしたければ日本という地域にはその仕事はほとんどなくて、不器用なおじさんがはじき飛ばされて異国の地で枕を濡らしながらコードを書いていたという事情があった。いやソフトウェア開発の現場はあった。それが多重下請け構造と呼ばれるSIでの現場だ。だけど、不特定多数に販売するソフトウェア製品というのは一部のパソコン向け商品や、ハードベンダーが顧客向けに販売するパッケージをのぞけば、ほとんどなかったのが実情だ。ソフトウェア製品開発の現場は米国のシリコンバレーやシアトルにしかなかった。少なくとも自分のなかではそのような認識だった。

ソフトウェア開発は好きだしコードを書くことは楽しい。当時40歳のおじさんが日々コードを書きながら七転八倒しているときにたまたまfjの書き込みを見て、横からクチを出した。それが今回紹介したfjの記事だ。まつもとさん（当時33歳くらい）には面識もなんにもなかったが、面白いことを言う人だな、意見が似ているなあと思いながら書き込みを拝見した。言語おたくでRubyという言語を開発中だということは伝え聞いていた。

設計と実装は不可分だ。無駄なドキュメントは書くな、危険ですらある。無駄なドキュメントを書くヒマがあったらディリービルドやリグレッションテストの環境を整備しろ。という主張はその当時ほとんど受け入れられなかったし、ひょっとしたら今での理解されているとは言いがたい。

スケジュールが遅れたプロジェクトに素人を投入するな。スケジュールが遅れたときは、１）機能を落とすか、２）スケジュールを延期するしかない。これも今でも十分理解されているとは言いがたい。ブルックスは30年以上前に指摘している。

もちろん、原子力発電所の制御システムとか飛行機の運航制御システムとかの設計方法論はまた別にあるだろう。しかし、コンシューマ向けのソフトウェア製品開発においては、ブルックスの指摘は未だに正しい。

XP、アジャイルソフトウェア開発、スクラムなどなどの言葉のなかった時代の話である。

ソフトウェア製品が世の中から消え（消えていないけど）、クラウドの時代になって、その機能の多くがウェブサービスになったときのソフトウェア開発のベストプラクティスと通じる部分もあれば陳腐化した部分もある。

15年前には、日本にはソフトウェア製品開発の場所はなかったけど、15年経ってみるとウェブの世界にそれはあって日本の地でもソフトウェア開発ができるようになった。まだまだ伝えるべきことはいっぱいあるよと15年前のわたしに言いたい。

老害のおじさんの戯言である。