オブジェクト指向は戦場では必要無し その３
■ このスレッドは過去ログ倉庫に格納されています
0001うつつつつ
NGNG引き続きＯＯ厨とアンチＯＯ厨の血で知を笑う戦いきぼ。
その１ http://pc.2ch.net/test/read.cgi/tech/1011997945/
その２ http://pc.2ch.net/test/read.cgi/tech/1013266554/
0233旅の始まりの人
NGNGインピーダンスミスマッチの吸収には、どうしても多量の
同じようなコード（あるいはパラメータ）が必要なんですよ…
RDBMSを扱うのは、もういやになりますねー。
0234デフォルトの名無しさん
NGNG俺もTemplateやら継承やら独自言語作ろうとして失敗した。
まあコードジェネレータ作るのが一番。
0235とあるダメ社員
NGNGそれは、基本的に同じだけど違う部分を手直しする、という意味ですよね、きっと。
Ｃでやっても同じ事ですから、その部分についてはわかります。
でも、なぜそんなに大量に同じようでちょっと違うものを作り込まなければならな
いのかわからないのです。
0236旅の始まりの人
NGNGRDBMSをなるべく使わない、というのを最近考えるんですけどね。
OODBとか、キー値でハッシュテーブルにしたXMLテキストで永続化とか。
暇な時にトライ中です。
0238デフォルトの名無しさん
NGNGモデル記述の言語からすべて生成されるような仕組みにするのが、
よく使う逃げですね。
プログラマーの持つ最大にして唯一の能力は機械に仕事をやらせることで
す。
医者の不養生といいますが、プログラマーは、お客サンのためだけでなく、
自分のためにもめんどくさがりや精神をもっと発揮すべきなんですよね。
美学からいくと、生成したものは、Artではない気がする。そこの
プログラマーの心理的な抵抗がある気がする。
きっと、生成すらしなくてよいようなフレームワークがあるんだろうな。
なんだろう？
0239
NGNG（済まないと予想される）
例えば、同じアイテムなのに、
ある画面では「氏名」
ある画面では「あなたの名前」
ある画面では「姓」「名」だったり・・・。
0240デフォルトの名無しさん
NGNG0241旅の始まりの人
NGNG高速に動作する複雑な構造化問い合わせの機能が必要なければ、
RDBMSを使用しないというのは、かなり良い解決策だと思うん
ですよ。
検索のパターンだけ洗い出しておいて、RDBMSのスキーマ定義を
単純化して(可変長バイナリのカラムを用意する)、問い合わせ結果
をプログラム側で動的に解析するというのも、メモリとCPUパワー
に余裕があるなら、いける、かな？どうでしょう？
0242デフォルトの名無しさん
NGNG0243デフォルトの名無しさん
NGNGオブジェクトのストアとしてRDBMSを使っちゃえ、ということでせうか。
>>239
失礼しました。ほんとに使いごごちの良いアプリってモデル記述
言語をがんばってもそれが複雑になる一方というか、、、
モデルとビューとコントローラーは果たして分離できるのか。
それすら怪しい。。「オブジェクト」指向じゃだめなんでしょう。
なんかこう、多態で、可変で、そんな生き物みたいなもの、、
幽玄指向でいきましょう。
0244デフォルトの名無しさん
NGNG> 医者の不養生といいますが、プログラマーは、お客サンのためだけでなく、
> 自分のためにもめんどくさがりや精神をもっと発揮すべきなんですよね。
優れたプログラマは皆面倒くさがり屋である。
面倒くさがり屋であるが故に何でも自動化しようとし、プログラム技術が上達する。
しかし、面倒くさがり屋なので脳内設計が多く、上に立つ人間には向かない;->
0245デフォルトの名無しさん
NGNG↓ここのうけうりです。
See -> http://www.pragmaticprogrammer.com
邦訳は達人プログラマーね。
0246デフォルトの名無しさん
NGNG>まじめなお話で数千行（数万って…凄いなぁ）もあるプログラムを
>設計書も作成しないで、作れるというのは信じ難いです。
>ま、白髪三千丈の類の冗談なんでしょうけど。
俺、212じゃないけど、数千行程度なら「設計書」なんぞ書かなくても
楽勝で書けるよ。これぐらいなら当たり前じゃなかろうか。
別にコピペの塊じゃない。
C/C++なら、ヘッダファイルが十分「設計書」の役割を果たすと思う。
数千行程度のゴミプログラムで、それもひとりで書いてるんならね。
1関数で数千行書く奴もちょくちょくいるが(鬱 そういう話をしている
のでもない。
0247デフォルトの名無しさん
NGNGマジメに聞いてるようなんで マジメに答えましょう
好きな道具はDelphiです。
DelphiはOOPLですが設計にクラスわけなんてオブジェクト指向してる訳じゃないんで
別に最初に考えたりしません。 クラスは再利用したりしません。ただコンポーネントは
再利用出来ますが。
まあ具体的な話の方がいいでしょう
慣れれば、会計処理なんて定型ですから必要な印刷物が判れば必要な入力画面もわかります
仕事貰ったら、印刷イメージ見ながら、どんどん入力画面作ります。画面作りながら SQLのCREATE文
書いてゆきます。 画面できたら客に使わせて入力させてゆきます。
それから印刷にかかりますが、印刷はお客さんにはコダワリが必ずあるので、貰ったイメージ通りに
作ればOKとはゆきません。
簡単なテキストスクリプトを作って現場で微調整できるように用意しておきます。
入力画面の要望聞きながら１ヶ月後には印刷部も出来上がります。
それで印刷させては客先で調整します。
だいたいこれでコードは数千行です。
その後、色々細細と客の注文を聞いて便利機能を付け足します。
便利機能は手間がかかりますから、最初の状態から、だいたい２〜５倍のコードになります。
それは客の予算によってという事です
予算があれば最終的に数万行になるというだけです
0248246
NGNG(このモジュールはクラスではない。Javaならpackage相当)、
それを組み合わせて全体のプログラムを作るって感じかな。
「数千から、MAX 1万行ぐらいのモジュール」の外向けのインタフェースと、
それをどう組み合わせるかについては、さすがに文書化するけどさ。
0249デフォルトの名無しさん
NGNG映画ではヒーローだけど
戦場ではちょと迷惑ね
0250デフォルトの名無しさん
NGNG数千行程度ならあたり前のゴミプログラムとか言ってるお前、
プログラム下手すぎだな。（ﾜﾗ
上手いコードほどコード量は少なくなるはずなんだが。
0251デフォルトの名無しさん
NGNGちょっとしたスクリプト作れば簡単に数千行いくだろ
そうじゃないというなら見せて貰いたいもんだ。どうせ見せられないだろうがな（ﾜﾗ
0252デフォルトの名無しさん
NGNG0253デフォルトの名無しさん
NGNGhttp://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/lounge/file/1004530597_1/MyDraw.pas
このコードすごいな・・・コードものすごいというかさっぱり判らんけど走らせたら・・・
0254デフォルトの名無しさん
NGNGそもそも何行かかるかなんて言語にもよるってのは置いといて、
そのちょっとしたスクリプトだかコントロールだかで
数千行かかってしまったという痴態をここで晒してみそ？
0255とあるダメ社員
NGNGどうもありがとうございます。
会計処理や事務処理分野は、私はよくわかっていませんので「定型的」と
言われてしまうと「そうなんですか」としか答えられませんが、「C/C++
なら、ヘッダファイルが十分「設計書」の役割を果たすと思う。」という
ような事が、本当にあり得るのか、わかりません。
２４６さんや２４７さんのやられている分野でも、試験の工程は必ず存在
しますよね。
設計書相当のものがなくて、どうして試験仕様が作れるのかという点と、
品質の確保をどのように行っていくのかがわかりません。
また、無理に再利用をしなくても良いとは思いますが、なんらかの修正
・機能追加を後日行わなければならなくなった時に、頼りになるのがソ
ースだけというのは、非常に効率が悪いと思いますが、ＯＯの開発環境
では１万行にも及ぶプログラムでも大丈夫なのでしょうか？
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システムの使われ方に関してユーザ（クライアント）よりも詳しくなってれば、「分析
は打ち合わせ中に終わってる」っつーのも有り得る話だな。ただ、普通はそんなこ
とはない。
金融でも医療でも教育でも、専門家はクライアントでこちらは素人、というケース
が圧倒的に多いもの。その場合には相手が物事をどう捉えているのか、クライア
ントがシステムに何を期待しているのか、そういったことを（断続的にで良いけど）
ある程度の時間をかけて話をして、お互いの理解を深める必要がある。それが分
析。
（専門家なしでやってる作業は「分析」ではなくて「分析まがい」でしかないよ）
■ このスレッドは過去ログ倉庫に格納されています