オブジェクト指向は戦場では必要無し その３
■ このスレッドは過去ログ倉庫に格納されています
0001うつつつつ
NGNG引き続きＯＯ厨とアンチＯＯ厨の血で知を笑う戦いきぼ。
その１ http://pc.2ch.net/test/read.cgi/tech/1011997945/
その２ http://pc.2ch.net/test/read.cgi/tech/1013266554/
0256John ◆0z.4Is5E
NGNGPerlで数千行・・・悪夢
0257デフォルトの名無しさん
NGNG話がかみ合わなくて当たり前。
2chでよく見る光景。
0258デフォルトの名無しさん
NGNGまずは構造化プログラミングから学習してください。
0259John ◆0z.4Is5E
NGNGちょっと２４に意見を書いてみる。
ちなみに、リンク先のコードは読んでいません。
最近、３つのサーバーが相互作用するプログラムを設計しました。
（まだコーディングは終わってません）
驚いたことに、OOのメリットはほとんど出てきませんでした。
サーバーを３つに分けてること自体がOODという見方もできるかもしれませんが、
個人的にはカプセル化とポリモーフィズムこそがOOだと思っています。
そして、カプセル化とポリモーフィズムを基盤とした設計こそがOODだと思っています。
だから、サーバーを３つに分けたのは単なるモジュール化ですね。
話しがそれましたが、プログラム（のコンセプト）によってはOOのメリットが見えずらい物が
あるようです。
>ただ、元のギコBASICはこれを継承してテキストスクリプトでグラフィック描画>が出来る
>コンポーネントになっていました。
この発言はOOを勘違いしているように思えるのですが、
完成したプログラムはコンポーネントに必ず成ると思います。
OOで設計されたプログラムは、簡単にキーワード（予約語（intとかの事))を追加して
機能拡張できるといった具合になってるはずです。
最初から仕様がしっかり決まっていて、
アルゴリズムを変更する可能性が０で・・・
といった単純なプログラムであれば、どんなに大きくても
OOのメリットはあまりないですね。
でも、そんなプログラム書いてる人って
いわゆるコーダーなんですかね。
0260デフォルトの名無しさん
NGNG全部手書きすれば、予想外の分量になる事もあるかもね...
んでも、既存のクラス・ライブラリやフレームワーク探さずに
手書きしてたら、「勉強中の人」か「DIY趣味の人」て感じかな。
0261デフォルトの名無しさん
NGNG> アルゴリズムを変更する可能性が０で・・・
それは、PMやSEが余程有能ならそういうプロジェクトもあるかもしれんが、
現実にあんのか？
> でも、そんなプログラム書いてる人って
> いわゆるコーダーなんですかね。
わけわからん。
「そんな」って、上に挙げたのはプログラムの質ではなく、
プロジェクトの質では？
0262デフォルトの名無しさん
NGNGへいへい、自分のスレにお帰り
0263John ◆0z.4Is5E
NGNG程度の問題ね。
端的な表現で悪かった。
でもさ、なんでもプロジェクトで考えるのはよくないよ。
プログラムといえば、使い捨てスクリプトから複雑怪奇な人工知能とかまであるわけでしね。
0264デフォルトの名無しさん
NGNGならなんで
> いわゆるコーダーなんですかね。
こんな台詞が出てくるのか？
0265デフォルトの名無しさん
NGNG> OOのメリットはあまりないですね。
> 驚いたことに、OOのメリットはほとんど出てきませんでした。
つまり、今のあなたは単純なプログラムを書いている
> いわゆるコーダーなんですかね。
0266デフォルトの名無しさん
NGNGJohn と書いてなければ、もう少しまっとうな回答も期待できたものを…（ｗ
0267デフォルトの名無しさん
NGNG>設計書相当のものがなくて、どうして試験仕様が作れるのかという点と、
>品質の確保をどのように行っていくのかがわかりません。
UnitTest使えば簡単。
だけど品質管理部門が許可してくれないかもしれないという罠。
設計書なんぞ飾りです。
偉い人にはそれが解らんのです。
0268デフォルトの名無しさん
NGNGちょっとしたコントロールは >>24の２ を基準にすればいいだろう
これらをまともに仕事で使えるようにしたら少なくとも倍にはなると思うぞ
それにヘタにOO設計でもすれば1桁サイズが大きくなると思うが
そうじゃないというなら書いてみたらどうだ？
0269デフォルトの名無しさん
NGNGヘッダファイルが仕様書になるように作るという事でしょう
＞機能追加を後日行わなければならなくなった時でも
RADツールでの開発品だと、プロパティやイベントが解読の手助けになる事が多いですね
0270デフォルトの名無しさん
NGNG> それにヘタにOO設計でもすれば1桁サイズが大きくなると思うが
ならんて。
OO だと、確かに手続き型に比べてサイズが大きくなる傾向はある。特に C++
だとコンパイル時の依存関係を減らすために pimpl イディオムを使っったり、
メッセージの転送を行うだけのメソッドを書くことが多いから。
それでも一桁も差は出ないよ。
> そうじゃないというなら書いてみたらどうだ？
さすがに同一仕様のスクリプトを OO, 非OO で書いたことはないけど、これまで
Perl, C, C++ あたりでスクリプトを作った経験から。
一番短かったのは Perl でした。字句解析は、組み込みの正規表現パターンマッ
チングと hash で済ませて、構文解析は内部で Perl スクリプトを作って eval() で
済ませた（ｗ
0271デフォルトの名無しさん
NGNG複数のサーバがやりとりするような場合はオブジェクトより
もっとデータ中心で考えないといけないからね
「データ指向」とか呼んでる人もいるから検索して読んでみたらどう？
0272デフォルトの名無しさん
NGNGたぶんそのコードをこのスレでさらしたら「それはオブジェクト指向じゃない」
といわれるだろうな
0273デフォルトの名無しさん
NGNG0274デフォルトの名無しさん
NGNG勝手にやらせたら１０倍どころじゃない事に・・
0276デフォルトの名無しさん
NGNG│＼
┌───┘ ＼
│ ＞
└───┐ ／
│／ こんな矢印
ﾜﾗﾀ
0277デフォルトの名無しさん
NGNG0278デフォルトの名無しさん
NGNG0279デフォルトの名無しさん
NGNG> さすがに同一仕様のスクリプトを OO, 非OO で書いたことはないけど、これまで
> Perl, C, C++ あたりでスクリプトを作った経験から。
桁が増えるかどうかはライブラリやコンポーネントが充実しているかどうかで決まらないか？
例えば、C++でC言語の標準関数並のライブラリだけでOOしたら簡単に1桁は突破しそう
0280とあるダメ社員
NGNGみなさんの話題は、コーディングや実装と、モジュールレベルの単体試験と
いった工程に話を限っているのですね、きっと。
だから、私は、みなさんの話に付いていけずに、？？？となるのでしょう。
｜267 ：デフォルトの名無しさん ：02/03/01 12:35
｜>>255
｜>設計書相当のものがなくて、どうして試験仕様が作れるのかという点と、
｜>品質の確保をどのように行っていくのかがわかりません。
｜UnitTest使えば簡単。
｜設計書なんぞ飾りです。
できあがったクラスの試験では、それで十分なのかもしれませんね。
でも、クラス自身の設計が適正であるか、全体の動作が正しいか、異常ケース
検証は出来ないですよね。
そのへんが知りたいです。
｜269 ：デフォルトの名無しさん ：02/03/01 14:23
｜>>255
｜ ヘッダファイルが仕様書になるように作るという事でしょう
それは、理解しています。
ですが、「わかる」「やさしい」という定性的な表現は、なかなか難しい
ですし、クラスの動作自体がわかったところで「なぜそれをするのか」が
わからなければ、結局「わかった」とは言えないのは誰でも理解できると
ころですよね。
まして、ここで話題になっているのは万単位のステップ数にもなる大きな
プログラムです。
数千、数万もの手順を踏まなければ機能しないプログラムで、個別の動作
を知るだけでは、理解できたとはなかなか言えないのではないでしょうか。
クラスの設計そのものがまだよくわかっていませんので、ヘッダファイル
にすべてが記載されていないＯＯのプログラムは、論外の品質である、と
いうようなものであるならば、また話は別になると思いますが。
0281デフォルトの名無しさん
NGNG>>280
> まして、ここで話題になっているのは万単位のステップ数にもなる大きな
> プログラムです。
> 数千、数万もの手順を踏まなければ機能しないプログラムで、個別の動作
> を知るだけでは、理解できたとはなかなか言えないのではないでしょうか。
それがカプセル化の一部であってOOの利点の一つだと思う。
すべてを理解出来なくても(知らなくても)コーディングが出来ると。
で、
> できあがったクラスの試験では、それで十分なのかもしれませんね。
> でも、クラス自身の設計が適正であるか、全体の動作が正しいか、異常ケース
> 検証は出来ないですよね。
> そのへんが知りたいです。
設計はさておき（ｗ、XPの概念的には実装されたコード(クラス)はUnitTestによって
すべてが正しいことが保証される。
バグのないクラスをいくら組み合わせてもバグは発生しないっつー考え方だと思うが。
だからといって総合テストでバグが出ないわけではないが（ｗ
0282デフォルトの名無しさん
NGNG> まして、ここで話題になっているのは万単位のステップ数にもなる大きな
> プログラムです。
いや、数万ステップ程度だと「大きなプログラム」とは言わないんだけど。
ただ、数万程度でも「ヘッダに書いてあるでしょ」で理解できる規模は超えてる
けど。
0283デフォルトの名無しさん
NGNG追記
ソフト全体を見渡したとき、API的な関数すべてが並列に存在してるものを理解するよりも
オブジェクト単位で考えたほうが見通しはいいと思うんだが。
非OOでもソースの見通しをよくするためにファイル分割するんでしょ？
0284デフォルトの名無しさん
NGNG会話が成り立たないからな。
0285デフォルトの名無しさん
NGNGttp://members.tripod.co.jp/aspara_2000/
一緒の会社にならない事を祈るばかり.(藁
0286267
NGNG>みなさんの話題は、コーディングや実装と、モジュールレベルの単体試験と
>いった工程に話を限っているのですね、きっと。
>
>でも、クラス自身の設計が適正であるか、全体の動作が正しいか、異常ケース
>検証は出来ないですよね。
もしかしてUnitTestの事を"単体テスト"と直訳したのかな。
xUnitとかTesting Frameworkって書けば良かったか。
とにかく、OOやってるならXPの事もちょっとは知っておいた方が良いよ。
0287デフォルトの名無しさん
NGNG構造化手法原理主義というよりはソフト工学絶対主義という感じね。
それにしてもこれだけ偏った思考をする人もめずらしい。
0288とあるダメ社員
NGNGどうもありがとうございます。
｜> 数千、数万もの手順を踏まなければ機能しないプログラムで、個別の動作
｜> を知るだけでは、理解できたとはなかなか言えないのではないでしょうか。
｜それがカプセル化の一部であってOOの利点の一つだと思う。
｜すべてを理解出来なくても(知らなくても)コーディングが出来ると。
カプセル化の利点は仰るとおりですね。
しかし、利用しようとするクラス・関数の目的と適用範囲を知らないと
いけないですよね。メーカ配布のクラスライブラリ（ＭＦＣ等でもいい）
を使用する場合は、それでも構わないと思いますが、社内の別プロジェ
クトで制作したようなものの場合は、やはり「設計書」が必要なのでは
ないでしょうか。
すべてを理解する必要はなくとも、使うに当たって必要な動作確認はし
なければならないわけですし。
｜設計はさておき（ｗ、XPの概念的には実装されたコード(クラス)はUnitTestによって
｜すべてが正しいことが保証される。
｜バグのないクラスをいくら組み合わせてもバグは発生しないっつー考え方だと思うが。
｜だからといって総合テストでバグが出ないわけではないが（ｗ
ご自分で書かれている通り、バグを含まないモジュールを組み合わせても、不具合は出ますよね。
だから、わからないな、と思っているのです。
また、一万ステップが大きい・小さいというのは感性評価なので、どちらでも結構ですが、いず
れにせよ、隅から隅まで覚えていられる分量は超えていますよね。
0289デフォルトの名無しさん
NGNG｜設計はさておき（ｗ、XPの概念的には実装されたコード(クラス)はUnitTestによって
｜すべてが正しいことが保証される。
すべてのテストコードを書くの難しいんだよね。
みんなちゃんと書いてる？
0290デフォルトの名無しさん
NGNGなぜメーカ配布のクラスライブラリは設計書は無くても構わなくて、
社内だと設計書が必要なの？
まさか結合テストでホワイトボックステストをやろうとしているのか？
0291とあるダメ社員
NGNG｜もしかしてUnitTestの事を"単体テスト"と直訳したのかな。
｜xUnitとかTesting Frameworkって書けば良かったか。
｜とにかく、OOやってるならXPの事もちょっとは知っておいた方が良いよ。
一応、直訳したわけではありません。恥ずかしながら、不勉強でちゃんと
理解したとはとても言えませんが、エクストリームプログラミングは講習
を一度受けた程度で、なかなか興味深い開発手法ですが、開発体制を根本
から変えなければならないため、思案しているに留まっています。
0292とあるダメ社員
NGNG｜なぜメーカ配布のクラスライブラリは設計書は無くても構わなくて、
｜社内だと設計書が必要なの？
｜まさか結合テストでホワイトボックステストをやろうとしているのか？
うーん、文章力がなくてすみません。
ブラックボックステストをやろうとすると、設計書が必要ではないですか
といいたい訳です。
中身の詳細はともかく、このクラス・関数群は何をするものなのか、いち
いちソースを読まなければならないのであれば、非常に効率が悪いのでは
ありませんか？ という疑問です。
メーカの配布のライブラリを使用するのに制約をつけないのは、一つ
目には、設計書相当の文書・市販の解説書が存在するからです。
必要があれば、講習会を受講する、サポート契約を結ぶなどなど理解
するための補助手段も豊富に存在します。
また、マイクロソフトほど大きな会社では、すぐに対応してくれると
は思えませんが、基本的には市販品を購入した場合には、バグがあれ
ば、メーカに対応してもらえることも、理由となります。あんまり関
係ありませんが。
0293デフォルトの名無しさん
NGNG>>24 の１，２のコードは千行前後あるけど 読める人は苦も無く読んでるでしょ？
あのコードはコメント多くとは言えないし、親切なコードでもない。
でも、Delphi知らない人でも平気で読んでるわけで、 それはどうしてだと思う？
0294デフォルトの名無しさん
NGNG> でも、Delphi知らない人でも平気で読んでるわけで、 それはどうしてだと思う？
俺に限って言えば、過去に同じようなプログラムを作ったことがあるから。コンパ
イラ／インタプリタを一回作ったことがあれば、コードを読むポイントはC だろうが
Delphi だろうが、あまり変わらん（と思う）。
0295281
NGNG>>288
> ご自分で書かれている通り、バグを含まないモジュールを組み合わせても、不具合は出ますよね。
> だから、わからないな、と思っているのです。
それはソースの実装が悪いのではなくて、設計がわるいからでわ？
それがOOの欠点なんだろうが、設計が完璧であれば(たぶん)そういう問題は発生しないと思われ。
完璧な設計でバグのないクラスを実装させるわけだから。
このへんが「XPってあくまで理想論なんでしょ」って煽られるとこだと思うが。
>>289
UnitTestはやったことない（ｗ が、 似たようなことならみんな我流でやってるよね？
Cとかなら#indef DEBUGにテストコード書いたりとか。
XPはそれの拡大解釈くらいで考えてる。
0296デフォルトの名無しさん
NGNG設計書と仕様書を混同していないか？
> ブラックボックステストをやろうとすると、設計書が必要ではないですか
> といいたい訳です。
仕様書があればブラックボックステストはできるはずです。
また、マイクロソフトではMSDNなどのメソッドの解説は仕様レベルであり、
設計まで公開したものは見たことありません。
# 仕様から設計が推測できるのはいくつかあるが
0297デフォルトの名無しさん
NGNG> UnitTestはやったことない（ｗ が、 似たようなことならみんな我流でやってるよね？
達人プログラマの「容赦ないテスト」とかね
0298とあるダメ社員
NGNG理解力がなくてすみませんが、文脈上、あなたが何を仰りたいのかわかりません。
設計書とか仕様書という単語は、その方の属している文化による方言があるの
で、この場では私は区別して使っていません。
強いて言えば、プログラムそのものではなく、その機能の説明・目的などが書
かれた文書、プログラム群全体の目的や機能が書かれた文書といった程度にな
ります。
このスレでは、「数千〜万程度のプログラムであれば、設計書はなくても作れ
る。ソースだけ。」といった趣旨の事が書かれています。
従って、ソースしかない、ソースで十分だよという前提の議論だと思っていて
それに対して設計書相当のモノが必要なのではないでしょうか？というのが書
いている趣旨だったのです。
ここでなぜ、設計書・仕様書の区別が問題となるか、わかりません。
296 ：デフォルトの名無しさん ：02/03/01 21:39
設計書と仕様書を混同していないか？
> ブラックボックステストをやろうとすると、設計書が必要ではないですか
> といいたい訳です。
仕様書があればブラックボックステストはできるはずです。
また、マイクロソフトではMSDNなどのメソッドの解説は仕様レベルであり、
設計まで公開したものは見たことありません。
# 仕様から設計が推測できるのはいくつかあるが
0299293
NGNG設計図なしに作れる秘密はそこにあるのにね
0300デフォルトの名無しさん
NGNG> このスレでは、「数千〜万程度のプログラムであれば、設計書はなくても作れ
> る。ソースだけ。」といった趣旨の事が書かれています。
はて？このことか
｜俺、数千行どころか数万行でも最初に設計なしに作れるよ。 と言ったらどうする？
｜もちろんユーザから必要な帳簿のイメージのFAXは貰うけどさ
> 従って、ソースしかない、ソースで十分だよという前提の議論だと思っていて
> それに対して設計書相当のモノが必要なのではないでしょうか？というのが書
> いている趣旨だったのです。
この発言ならば、「設計なしに」とは書いてあるが、「設計書なしに」とは
書かれていないし、「必要な帳簿のイメージのFAXは貰う」と言っている
# なお、この発言をしたのは私ではない。
この場合、「必要な帳簿のイメージのFAX」が
「その機能の説明・目的などが書かれた文書」に当たると思うが？
0301とあるダメ社員
NGNG｜293 名前：デフォルトの名無しさん ：02/03/01 21:22
｜とあるダメ社員さんye
｜>>24 の１，２のコードは千行前後あるけど 読める人は苦も無く読んでるでしょ？
｜あのコードはコメント多くとは言えないし、親切なコードでもない。
｜でも、Delphi知らない人でも平気で読んでるわけで、 それはどうしてだと思う？
今、２４のリンク先を見てきましたが、うーん、私のスキルが足りないのでよくわかり
ませんでした。でも、仰る通り、読める人は読んで、短時間の内に改造まで加えられる
ようですね。単純に自分のスキル不足を恥じるばかりです。
>>295
｜295 名前：281 ：02/03/01 21:38
｜現場を見据えつつ書いたつもりなんだが
｜>>288
｜> ご自分で書かれている通り、バグを含まないモジュールを組み合わせても、不具合は出ますよね。
｜> だから、わからないな、と思っているのです。
｜それはソースの実装が悪いのではなくて、設計がわるいからでわ？
そのあたりが、わたしがよく理解できていない部分なんです。
クラスの実装とは、設計そのものに匹敵するような、構造を規定する部分ですよね。
従って、設計が悪いというのは程度問題ではあるのですが、実装が悪いのか設計が検討不足なのか
わかりづらい部分です。
0302デフォルトの名無しさん
NGNGMFC のクラス階層図は、あきらかに「設計」の範疇だと思うが。個々のメソッドの
リファレンス以外に、暮らすライブラリのフレームワークの概要を記述した文書も
MSDN Library には入ってるぞ。
（MFC の出来／不出来はともかく）
0303とあるダメ社員
NGNG為にする議論は、あまり好きではありません。
｜300 名前：デフォルトの名無しさん ：02/03/01 22:32
＜略＞
｜俺、数千行どころか数万行でも最初に設計なしに作れるよ。 と言ったらどうする？
｜もちろんユーザから必要な帳簿のイメージのFAXは貰うけどさ
｜> 従って、ソースしかない、ソースで十分だよという前提の議論だと思っていて
｜> それに対して設計書相当のモノが必要なのではないでしょうか？というのが書
｜> いている趣旨だったのです。
｜この発言ならば、「設計なしに」とは書いてあるが、「設計書なしに」とは
設計せずに設計書が出来るわけはないのは、自明ですよね。
あまりといえばあまりな発言だと、わたしは思います。
｜書かれていないし、「必要な帳簿のイメージのFAXは貰う」と言っている
｜# なお、この発言をしたのは私ではない。
｜この場合、「必要な帳簿のイメージのFAX」が
｜「その機能の説明・目的などが書かれた文書」に当たると思うが？
仰る通り、設計書の一部にはなりますね。客先からの要求仕様とでも呼ぶモノの一
部ではあると思います。しかし、アウトプットのイメージだけ見せられても、客先の要
望がすべてわかるはずもないと思っていますが違いますでしょうか。
0304293
NGNGそういう事。 単純にスキル不足つまり経験の差。
設計図が無ければクラスライブラリも使えないなんて甘えた事じゃホントの経験は身につかないさ
0305デフォルトの名無しさん
NGNGまさか。
クラス階層図ぐらいはないと話にならんし、template method を使ってるような
場合 (MFC でも PreTranslate ウンチャラとかで使ってる) には
- そのメソッドがフレームワークから呼ばれるタイミング
- 呼ばれるメソッド中でやって良い事 (pre-condition, post-condition)
なんかは明確にドキュメント化してないと、危なくて使えないでしょう。MFC だと
最悪「ソースを読め」なんだが、ソースコードがないライブラリも存在するわけで。
0306John ◆0z.4Is5E
NGNGあとでじっくり読んでみようかな。
>>271
データ指向調べてみます。
>>285
なんかすごそう。
あれで２年生ってすごいな。
掲示板に書き込みたいんだけど、どうやって書き込むんだ？
ここ見てたら教えてくれ。
それと、一回会ってみたいな。
学校どこだろ。
0307John ◆0z.4Is5E
NGNG0308デフォルトの名無しさん
NGNGそれはどこで定説になったんだ? まさか2ちゃんではあるまいな?
0309デフォルトの名無しさん
NGNG0310デフォルトの名無しさん
NGNGせめて
(M)マクドナルド
にしてくだちい。
0311305
NGNG0312デフォルトの名無しさん
NGNG２週間まって書き込もう。
0313デフォルトの名無しさん
NGNG0314281
NGNG> そのあたりが、わたしがよく理解できていない部分なんです。
> クラスの実装とは、設計そのものに匹敵するような、構造を規定する部分ですよね。
> 従って、設計が悪いというのは程度問題ではあるのですが、実装が悪いのか設計が検討不足なのか
> わかりづらい部分です。
あくまで個人的な考えだが、OOPLで考えた場合、仕事のレベル的に
クラスなどの設計：プログラマーの仕事
クラスメソッドとかの実装：コーダーの仕事
ぐらいで考えてる。
実際JavaとUML使えばコーディングするのはメソッドの内容とかの
(純粋な意味での)コード実装部だけでしょ？
OO + XP的な考え方だと(要求仕様を満たすという点で)実装が悪いつーのはあり得ない。
要求仕様を満たせるようなソフト設計をしていることがあくまでも前提だと思うんだが｡
「とりあえず動けば」的な実装だとちゃぶ台返しの危険性があるから
そのリスクを回避するためのリファクタリング＆短期リリースなんじゃない？
0315246
NGNG>>248
>「数千から、MAX 1万行ぐらいのモジュール」の外向けのインタフェースと、
>それをどう組み合わせるかについては、さすがに文書化するけどさ。
「外向けのインタフェース」に関しては文書化すると書いている。
モジュールの「仕様」ってのは、外から見える部分のことでしょう。
で、外向けの仕様がちゃんと定義されていれば、ブラックボックス
テストはできる。だから、「仕様書」は書くよ。
でも、「設計書」と言ったら、そのプログラムの内部の設計のドキュメントの
ことを指すでしょう。こんなもんなくても数千行ぐらいヘッダファイル見ながら
書けるのが普通。
OOに限らず、手続き指向でもモジュールの内部的な実装は隠蔽するはずだから、
「仕様書」と「設計書」は明らかに別物でしょ。「設計書」がないとテスト
できないようでは、実装筒抜けのタコモジュールだということ。
# もっとも、ややこしい呼び方をしたときの挙動などが実装に依存してしまう
# ことはないわけではないが (藁
だいたい、元の発言が、
>まじめなお話で数千行（数万って…凄いなぁ）もあるプログラムを設計書も作成しな
>いで、作れるというのは信じ難いです。
こうなんだから、「できるよ」と答えたまで。
保守まで考えると設計書も必要なこともある。そういう場合、たいていは
コーディングの後で書く (^^;
0316246
NGNG「大規模」だと思っているフシがあるのがどうも…
1万なら小規模、数万〜十万ぐらいで中規模、大規模といったら…
もう果て無し、ってとこかなあ。WordやExcelだって、百万単位でしょ。
# だから、アンチMS連中が少々粋がったって、なかなかアレには
# 追いつけない...
で、世間で業務に使われているプログラムには、WordやExcelなんぞとは
比べ物にならないほど巨大なものもあるわけで。もちろん、そのソースには
思いっきりﾄﾞｷｭｿなものも含まれているけど(鬱
「数千」なんて、どう考えたって「ゴミ」。プログラマは現在、そういう世界に
住んでいる。
0317デフォルトの名無しさん
NGNG>>285 オブジェクト指向にこだわらず、
オートマトンとかペトリネットとかやればよいのでは...
状態をオブジェクトにせず、特定のオブジェクトが状態遷移するよーな
モデルを考えると、確かにはまるみたいですね.
アナパタ本解説ページの多重分類と動的分類の説明読んで、
「そこまでやらんとモデリングできないのぉー」と、
ちょっと面倒な感じがしましたです.
0318デフォルトの名無しさん
NGNG>UnitTestはやったことない（ｗ が、 似たようなことならみんな我流でやってるよね？
>Cとかなら#indef DEBUGにテストコード書いたりとか。
>XPはそれの拡大解釈くらいで考えてる。
全然解ってないのね。
XPについて語るならとりあえずxUnit使ってからにしてよ。
0319デフォルトの名無しさん
NGNG＞設計はさておき（ｗ、XPの概念的には実装されたコード(クラス)はUnitTestによって
＞すべてが正しいことが保証される。
要求仕様的に正しいかどうかはともかく、
単体で（そして統合しても）書いた人が意図したように動くことが保証される。
TestCase をきちんと書いてる限り、
どれだけコードを追加、修正しても保証されるのがポイント。
はっきりいってデバグがすげー楽。
0320とあるダメ社員
NGNGわたしの以前の意見を少し訂正します。
>>24の１行目のテキストをオフラインでちょっと見てみました。
ダイアルアップなので、オンラインだとお金が気になってしまいます。
｜>>293
｜293 名前：デフォルトの名無しさん ：02/03/01 21:22
｜とあるダメ社員さんye
｜>>24 の１，２のコードは千行前後あるけど 読める人は苦も無く読んでるでしょ？
｜あのコードはコメント多くとは言えないし、親切なコードでもない。
｜でも、Delphi知らない人でも平気で読んでるわけで、 それはどうしてだと思う？
＜略＞
回答として、私自身のスキルが足りない、と書きました。
｜304 ：293 ：02/03/01 23:14
｜とあるダメ社員さんye
｜ そういう事。 単純にスキル不足つまり経験の差。
｜ 設計図が無ければクラスライブラリも使えないなんて甘えた事じゃホントの経験は身につかないさ
読んでみましたが、まだまだ改造できるほど理解できている訳ではありません。デルファイ自体知らないこともあり、スキルが足りないことを改めて自覚しました。
しかし、２４の目的とする事は比較的明確ですね。読まなければ目的がわからないプログラムではない。
単にBASICを２ｃｈで使われているような言葉に置き換えて動作する言語を作ろう、という事だと思います。
つまり、ほぼ業務知識が必要のないプログラムでは、プログラムを読めばわかるというのは当然のことであるように思います。
言ってみれば、ユーザが開発者を兼ねるようなケースですね。
プログラムの動作はわかる。しかし、意味がわからないという点が設計書（仕様書でも良いです）の必要性を端的に示す点だと思っています。
それが不要である例を使われてしまうと、議論が迷走してしてしまうように思うのですが、どうでしょうか。
0321デフォルトの名無しさん
NGNG・言語への知識
・クラスライブラリの対象ドメインへの知識
・クラスライブラリそのものへの知識
Java を知って、XML と DOM/SAX を知って、Xerces の使い方を知れば
Xerces が使えると。
>>298
＞このスレでは、「数千〜万程度のプログラムであれば、設計書はなくても作れ
＞る。ソースだけ。」といった趣旨の事が書かれています。
＞従って、ソースしかない、ソースで十分だよという前提の議論だと思っていて
＞それに対して設計書相当のモノが必要なのではないでしょうか？というのが書
＞いている趣旨だったのです。
一人で書くなら10万行でも設計書は要らない（納品に必要なけりゃ）。
何故ならそのプログラムを熟知してるから。
まあ、忘れっぽいので記憶の助けのためにメモ書きくらいはするかもしれん。
10人で作るとして、きちんとした形式の設計書は要らない。
何故なら設計は日々変わるし、結局コードを読まなきゃいけないので。
図や説明を手書きで書いて、質問されたらその都度答える。
形式にこだわった文書は取りこぼしが多い。
0322デフォルトの名無しさん
NGNGことないですか？ここで馬鹿されてるようなアンチOOにサーバー
はくられたとかそんなことあるんでしょうか？
0323デフォルトの名無しさん
NGNG＞それが不要である例を使われてしまうと、議論が迷走してしてしまうように思うのですが、どうでしょうか。
それが必要である例だけ使っても、議論にならなと思うのですが、どうでしょうか？
つか、設計書と仕様書の違いがわかっているように見えないので、なにを議論したいのか不明です。
0324281
NGNG> 全然解ってないのね。
> XPについて語るならとりあえずxUnit使ってからにしてよ。
XP使ってないとそれについて意見したりしちゃいけないの？
概念的にわかりやすいから例として挙げただけだが。
おれの場合は個人で概念だけを導入するくらいまでしかいってないんだが、
実働プロジェクトでXP導入してるとこってまだまだ少ないと思うんだが気のせい？
0325281
NGNG仕様書：ソフトウェアに要求される機能などを定義する(SEの仕事)
設計書：そのソフトウェアを実装するためのソフトウェア設計を文書化したもの(プログラマの仕事)
くらいだから、設計書がなくてもなんとかなるわな。
実際戦場だと設計書が実装のあとになることが多いし（ｗ
0326デフォルトの名無しさん
NGNG辻褄合わせの作業がいかにおおいことか。。
0327293
NGNG＞ほぼ業務知識が必要のないプログラムでは、プログラムを読めばわかるというのは当然のこと
それはどうかな？
basicという用語を知ってたからコメントやソースを見て判ったのでは？
つまりそれを見る為の知識の一部があったからでしょ？
それとも使われてる再帰下降法から判ったの？
「プログラムの動作はわかる。しかし、意味がわからない」のはやっぱり経験不足・勉強不足だよ。
社会常識や技術の常識は勉強しておくのは普通でしょ？
途中で欲しい出力のイメージさえ判れば入力画面もコードもデータベースも判るという話が出てた
けど、それが普通であって、 分析とか設計とか必要なのがプログラマとしては異常な事だと思うよ
もちろん会社全体としては経験不足の要員でも仕事が出来るよう色んな対策をしなければならな
い訳で、しかし開発要員が全員それじゃダメでしょ？
0328293
NGNG会社として 分析とか設計とかの工程を入れて、ドキュメントを残す事は必要な事だから
会社員なら それは無視してはいけないよ。
会社員の優先順位の一は会社の為に働く事だからね。
0329デフォルトの名無しさん
NGNG0330デフォルトの名無しさん
NGNGだってOOPLは有効だけど OO つまりOO設計や分析は必要無しが主題でしょ
0331デフォルトの名無しさん
NGNG分析設計工程が打ち合わせ中に終ってしまうんだよね
何年も同じ仕事してたらそういうふうになるのは当然では？
0332305
NGNGシステムの使われ方に関してユーザ（クライアント）よりも詳しくなってれば、「分析
は打ち合わせ中に終わってる」っつーのも有り得る話だな。ただ、普通はそんなこ
とはない。
金融でも医療でも教育でも、専門家はクライアントでこちらは素人、というケース
が圧倒的に多いもの。その場合には相手が物事をどう捉えているのか、クライア
ントがシステムに何を期待しているのか、そういったことを（断続的にで良いけど）
ある程度の時間をかけて話をして、お互いの理解を深める必要がある。それが分
析。
（専門家なしでやってる作業は「分析」ではなくて「分析まがい」でしかないよ）
0333318
NGNG>XP使ってないとそれについて意見したりしちゃいけないの？
>概念的にわかりやすいから例として挙げただけだが。
使ってくれと言ったのは"XPそのもの"じゃなくてxUnitだよ。
混同してる時点で理解度がかなり低いというのは判る？
>概念を導入
って言ってもどうやってイテレーションするの？
リファクタリングするフレームワークが無くちゃ3回目ぐらいのイテレーションで
設計変更に耐えられなくなるよ。
それにね、xUnit自体はXPを前提としなくても十分有効なツールだよ。
0334デフォルトの名無しさん
NGNG「戦場では」を前提にするのは虚しいような気がしてきた（W
だって、戦場になってからOO使うかどうか決めるわけじゃないでしょ。
「戦場にしないためにはオブジェクト指向は必要か？」のほうが
多少は意味がありそうな気がする。
ま、２ｃｈに意味を求めるのも何だかなーだが。
0335281
NGNG理解度が低いのはそのとーりだが
> って言ってもどうやってイテレーションするの？
> リファクタリングするフレームワークが無くちゃ3回目ぐらいのイテレーションで
導入してると言ったのは"XPそのもの"じゃなくてXPの概念だよ。
混同してる時点で理解度がかなり低いというのは判る？
と煽ってみるてすｔ
0336デフォルトの名無しさん
NGNG多分ね、xUnitと #indef DEBUG を同等と考えてるから、XPの概念が
導入できてないって思われてると思う。
0337デフォルトの名無しさん
NGNG> 「戦場にしないためにはオブジェクト指向は必要か？」のほうが
> 多少は意味がありそうな気がする。
多くの戦場ではオブジェクト指向は有効であろう。
でもオブジェクト指向は常に有効ではないし、必要でもない。
0338デフォルトの名無しさん
NGNGスレ違い、XP信者はXPスレにお帰り。
0339デフォルトの名無しさん
NGNG> 「プログラムの動作はわかる。しかし、意味がわからない」のはやっぱり経験不足・
> 勉強不足だよ。
世の中、そんな簡単なプログラムばかりじゃないぞ。
DNA 解析のプログラムなんか、動作は分かるが意味がわからなかったりする
し。（聞いたら分子生物学の厚い本と論文渡された…。数学の話は専門だった
から分かるんだが、生物系の話は進展が早くてついていけん）
0340デフォルトの名無しさん
NGNGこの一文が見えてないのか？
｜ 何年も同じ仕事してたらそういうふうになるのは当然では？
> ある程度の時間をかけて話をして、お互いの理解を深める必要がある。
> それが分析。
何年も同じ仕事をしているならば、お互いの理解が深まっている為、
分析の工程を短縮、または省略しても良いとは考えないのか？
（考えなしでやってる工程管理は「工程管理」ではなくて「工程管理ごっこ」でしかないよ）
0341デフォルトの名無しさん
NGNG確かにそういうのはあるよね。 でもそういうのとは別の話のような気もするし
というか、そういうのいくら文章残したって結局 何やってるかの説明は”論文読め”になるような気もするし
0342デフォルトの名無しさん
NGNG見えてるけど、実際に「分析なし」で済んだ経験がないもの。
何年も同じクライアント相手に仕事をしてても、その間にクライアントが手がける
ビジネスやら環境だって変化していくから、常に勉強の連続だよ。変化がない場
合にはそもそもシステムに手を入れる必要はないから、保守要員で対応できる。
0343デフォルトの名無しさん
NGNGDNA 解析みたいな学術的な話に限らず、たとえば在庫管理システムなんかの
データベース設計にしても、業界ごとの支払いの慣習やら何やらが設計に反映
してこないか？ それってコードやスキーマを見ても分からないから、文書化し
てないと後任が困るでしょ。
（実際の企業でも、支払い関係は○○さんに聞け、で他は誰も理解してない場
合もあるけど）
0344デフォルトの名無しさん
NGNG> ｜ 何年も同じ仕事してたらそういうふうになるのは当然では？
これは危険は思い込み。
顧客が「今」システムを必要としている理由は、
その顧客しか知りえない。
そして顧客はその理由を知っているか又は断片を知っているが、
それを適切に記述できるとは限らない。
その「理由またはその断片」と「記述」を結びつけるのが分析。
0345とあるダメ社員
NGNG>>327
｜327 ：293 ：02/03/02 08:56
｜>>320
｜＞ほぼ業務知識が必要のないプログラムでは、プログラムを読めばわかるというのは当然のこと
｜それはどうかな？
｜basicという用語を知ってたからコメントやソースを見て判ったのでは？
｜つまりそれを見る為の知識の一部があったからでしょ？
｜それとも使われてる再帰下降法から判ったの？
名称と書かれた内容からです。また、わたし自身も未熟なプログラマではあるからです。
知識がある、といってもプログラマなんですから高級言語を使わない人はいないと思います。
プログラマならばほとんど誰でもある程度理解している分野と言って良いのではないでしょうか。
｜「プログラムの動作はわかる。しかし、意味がわからない」のはやっぱり経験不足・勉強不足だよ。
｜社会常識や技術の常識は勉強しておくのは普通でしょ？
ここはすでに339さんが言及していますが、常識や技術の常識と「業務スキル」はまったく別だと
思います。歴史的な経緯で特別な処理を行わなければならない例は沢山ありますし、業界のルール
のようなものであれば、まったく聞かなければわからないものも沢山あります。
339さんが仰っているような、学術機関での難しい例もありますし。
｜途中で欲しい出力のイメージさえ判れば入力画面もコードもデータベースも判るという話が出てた
｜けど、それが普通であって、 分析とか設計とか必要なのがプログラマとしては異常な事だと思うよ
それについては、わたしは否定的な見解を述べています。
アウトプットだけをもらったところで、客先の要求仕様の一部にはなりえても、全部がわかるわけ
ではない、ということです。
0348デフォルトの名無しさん
NGNGないとは言わん。特にシステムはほとんど変わらず、帳票の形式だけ改修して
くれみたいな仕事だと、ほんとに出力見本だけで終わりだし。
0350とあるダメ社員
NGNGもちろん、そういう例もあるとは思います。
でも、そういう例ばかりではないことも、おわかりですよね。
さらに言うと、出力例だけ要求定義が十分であるような案件で、１００００行もの手続きを経なければならないようなプログラムがはたして本当に存在するのでしょうか？
0351デフォルトの名無しさん
NGNG0352デフォルトの名無しさん
NGNG財務分析用のアプリケーションを組むときに、最後にこんな感じのグラフと表を、
と言われて要件定義できるか？
0354とあるダメ社員
NGNG｜323 ：デフォルトの名無しさん ：02/03/02 06:39
｜つか、設計書と仕様書の違いがわかっているように見えないので、なにを議論したいのか不明です。
設計書・仕様書の呼び方は、その方の所属する文化に応じて変わるので、この場では特に使い分けし
ていません。という事をすでに書いていますが、仕様書として統一した方が良さそうですね。
今後は仕様書として記載します。
0355デフォルトの名無しさん
NGNG> アウトプットだけをもらったところで、客先の要求仕様の一部にはなりえても、
> 全部がわかるわけではない、ということです。
「多くの」プロジェクトでは上記の通り。
しかし「全ての」プロジェクトではないことは同意してもらえるかな？
「多くの」場合、定石通りに物事を進めていれば無難に物事を進められるだろう
しかし、「ある場合」には定石を無視することも必要である。
------- 以降独り言 ツッコミ禁止 -------
# だが、これをやって失敗すると次から店員にマークされるという危険も伴う、諸刃の剣。
# 素人にはお薦め出来ない。
# まあお前らド素人は、定石を確実にこなせるようになりなさいってこった。
■ このスレッドは過去ログ倉庫に格納されています