- - PR -
ソフト開発を成功させる1つの方法の感想
| 投稿者 | 投稿内容 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2001-10-21 21:58
ソフト開発を成功させる1つの方法という記事が載りましたが、この記事に関しては、「ああ、いろんな反論が来るな」ということが始めから分かっていました。
というのは、明らかにこの記事で書かれた内容は理屈が通らないからです。(おお、書いた本人がそこまで言うかって  )
でも、意外と反論は来ませんね。 と思ったら、 http://slashdot.jp/article.pl?sid=01/10/21/0838203&mode=thread&threshold= がありました。 突っ込みどころが多い記事を書いたんだから突っ込んで遊んでくれるのは構いません。 でもこれだけ? 意見のある人は、いませんか? このスレで、できる範囲で答えます。 ただし、質問者が納得できる答えができるとは限りません。経験則は、誰もを納得できるように説明できない場合もあります。 [ メッセージ編集済み 編集者: autumn 編集日時 2001-10-21 22:44 ] [ メッセージ編集済み 編集者: autumn 編集日時 2001-10-21 22:51 ] | ||||||||||||||||||||
|
投稿日時: 2001-10-22 11:24
本人ですが質問します。
やっぱり、変だと思います。 たとえば、可読性を落として変なテクニックを使いまくって短くしたプログラ ムを正しいと見なすのは常識的にも経験則的にもおかしいと思います。 _________________ | ||||||||||||||||||||
|
投稿日時: 2001-10-22 11:33
では御希望にお答えして  、ひとつ反論。
OOPまわりのお話について。 再利用性を追求するのは、「自分が後で再利用するため」ではなくて、「他人が今/後で再利用するため」でしょう。本来労働集約的産業ではないプログラミングという作業を、既存の企業が従来のやりかた(集約)で効率化するためには、作業の重複をふせぐための手法やフレームワークが重要になってきます。 # あ、もうひとつ、責任の所在の明確化:) たとえば、Java に HashMap や Vector がなかったらどうでしょう。私はいつも Java でプログラムしているのですが、たまに C でパッチなんかを作る時に毎回リストを作ったりしちゃって効率が悪いですね。 「短い方がいい」というのは、プログラミングの枠組にすでに汎用的で直観的な道具が準備してあり、かつ他人がそれを使い回すことがないという条件のもとでは、ある程度は正しいでしょう。しかし、そのような道具を必要に応じて作る場合には、プログラムの簡潔さよりもAPIの統一性、簡便性、利用する上での安全性を優先しておかなければ利用に不安が生じ、結局はみんなが車輪の再発明をしてしまうでしょう。 # あ〜、「ライブラリ化すべきモノ、すべきでないモノ」とか # 「再利用してもらえる API の作り方」とかあったらおもしろそう… | ||||||||||||||||||||
|
投稿日時: 2001-10-22 11:36
うーん、そうなんだよね。 しょうがないので、知恵を絞ってみました。 まず、「短いプログラムは無条件で正しい」という曖昧な日本語を明確に定義したいと思います。 短いプログラムと言っても、ソースコードから無くても困らない空白や改行を取り去っても、それでプログラムが改善されるわけではありません。それに実行ファイルのサイズに変化は起きないはずです。 ここでは、短いプログラムを以下のように考えてみましょう。 ・ プログラムに持たせたい能力を「機能」と呼ぶ ・ 宣言、ステートメント、演算子などを「要素」と呼ぶ ・ 各種テストをパスし、実用上問題ない状態を「バグがない」と呼ぶ ・ 上記条件をクリアしない状態を「バグがある」と呼ぶ ・ 「機能」を実現し、「バグがなく」、「要素」の個数ができるだけ少ないプログラムを「期待されるプログラム」と呼ぶ もし、可読性が低いプログラムで条件を満たすことができれば、「短いプログラムは無条件で正しい」は、到底正しいとは認められないわけです。 おそらく、そのようなプログラムは作成可能なので、それを誰かが作った時点で、証明終了となるでしょう。 しかし、そのようなプログラムは、普段お目に掛かりません。証明のために作ることはできるけれど、可読性を犠牲にしたソースが「期待されるプログラム」であることは滅多にありません。 実際に可読性の低いソースを記述することを考えてみましょう。 まず、可読性の低いソースを書き始めると、事前に周到な用意をしていない限り、書いているプログラマ自身が混乱させられてしまいます。その結果、このようなソースは容易に以下のような状況に陥ります。 ・ 機能がすべて実現されていない ・ 要素の数が最小ではない(無駄な要素が混入している) ・ バグが入り込んでいる つまり、可読性を低下させると「期待されるプログラム」という状態に迫るどころか、むしろ遠ざかってしまうケースが多いと思われます。 事前に周到な用意をすれば、可読性の低い「期待されるプログラム」は作成できると思いますが、事前に周到な用意ができるほどの知恵があれば、わざわざ可読性の低いソースなど書かないでしょう。 すると最善の「期待されるプログラム」とは、現実的には、可読性を維持した範囲内にしか出現しないことになります。 この最善というのは、理論的な最善ではないかも知れません。理論的にはもっと短いプログラムが作成可能かも知れませんが、現実的にそのようなプログラムが作成され、「期待されるプログラム」の条件を満たす可能性は薄いと考えられます。ですので、最上級の結果ではなく、比較級の結果が得られるだけと考えられます。しかし、最初の命題は「短いプログラムは無条件で正しい」であって、「最も短い……」ではないので、十分に短いプログラムが得られれば、それが最短でなくても良しとします。 以上から言えることは、厳密な論証として、「短いプログラムは無条件で正しい」という命題が可読性の低いプログラムを「正しい」と評価する可能性はあり、常識的な経験則と矛盾します。しかし、可読性の低いプログラムが「期待されたプログラム」の条件を満たす可能性は低く、体感的な経験則として見た場合、「期待されるプログラム」が可読性の高いソースを持っている可能性は高い、と言えるかも知れません。 意見? 反論? _________________ 川俣晶 [ メッセージ編集済み 編集者: autumn 編集日時 2001-10-22 11:37 ] | ||||||||||||||||||||
|
投稿日時: 2001-10-22 11:40
本人だけど、ここなんだよ、ここ。
「短いプログラムは無条件で正しい」って、無条件と言ってるんだから、機能の実現だとか、バグがないとか、そんな条件付けるのはアンフェアってものじゃない? _________________ | ||||||||||||||||||||
|
投稿日時: 2001-10-22 11:50
また自分が困るような突っ込みを思いついてしまった 
うーん、悩ましいけれど、必要な機能が不足したり、バグがあったりするソフトを、短いからと言って正当化したところで、そのことには何の意味もありませんよね? 極論すれば、機能を1つも実装してないプログラムや、実行させた瞬間に例外を吐いて落ちて、後は何もしないプログラムが、良いプログラムという結論になってしまいます。 「短いプログラムは無条件で正しい」というのは、(正しいかどうかは別として)、ソフトウェアを評価する手段の1つですから、評価される側もそれなりの完成度を持ったプログラムでなければ、適用する意味がないでしょう。つまり、ある機能を、十分な完成度で、どの程度の長さで実現するかを問うているのであると解釈しないと、(正しいかどうかは別として)、命題そのものが自己矛盾を起こして崩壊します。 _________________ 川俣晶 [ メッセージ編集済み 編集者: autumn 編集日時 2001-10-22 12:47 ] [ メッセージ編集済み 編集者: autumn 編集日時 2001-10-22 12:48 ] | ||||||||||||||||||||
|
投稿日時: 2001-10-22 11:56
A: 可読性の高いプログラムは正しい
B: 可読性の高いプログラムは短い よって、短いプログラムは正しい?
ちょっと変かな。 A: 可読性が高い B: 正しい C: 短い 元記事とひとりぼけつっこみ(失礼!)は 「A=B かつ A=C、よって B=C」に見えますが、 ほんとは「A->B かつ A->C」 つまり B->C が常に正しいとはいえない:) | ||||||||||||||||||||
|
投稿日時: 2001-10-22 12:30
ありがとうございます。
実は昨日、経験則的にやっている方法論が、リファクタリングという名前で確立されていることを教えて貰いました。知ったばかりの言葉を偉そうに使うのは本意ではないのですが、問題はコーディング時に再利用を意識するか、それとも、再利用する時にリファクタリングするかの問題と言えるかも知れません。 たとえば、アプリAをコーディング中に、まだ仕様の決まっていないアプリXで再利用することを想定して、アプリAでは使わない機能も組み込んで汎用性を高めておくのが前者。逆に、アプリXの仕様が決まっていない段階で悩んでも無駄と考えて、アプリXのことは、アプリX開発時に考えようと言うのが後者だと思います。(が、何せ、昨日知ったばかりの付け焼き刃のキーワードなので、間違っていたらごめんなさい) 私は前者の方法論を採用して泥沼にはまって後者に転向しました。
残念ながらJava2ベースで開発したことがほとんどないので、HashtableとVectorになっちゃいますが、これはもう手放せません。Javaで書いていて何が気持ちいいって、標準ライブラリのクラスの選び方がセンスが良くて、少ないのに役に立つ感じです。 ↓この程度なら資料見なくても書けるぐらい、身体に染みついてます。 Hashtable h = new Hashtable(); h.put("hello","world"); System.out.println( h.get("hello") ); (もし、ミスがあったらごめんなさい コンパイラに確認してもらわないと自信が持てないもので )
という訳で標準ライブラリを知り使いこなすのは、私は常識だと思います。というか、それすらやらないでプログラムを短く出来るわけがありません。せっかく膨大な人間が利用して信頼性も確立しているライブラリがあるのなら、それと同じ機能を自分で書くなど無駄の極みです。 標準でないライブラリも問題なければ、どんどん使うべきだと思います。もっとも、コストやライセンスの問題から、使いたいのに使えないケースというのもあるので、ちょっと痛いところですが。あと、WindowsではDLL Hellというやっかいな問題のために利用を見送ったことも多々あります。
道具や枠組みを作るという話になると、これは別の話題になって、今回の話題のスコープから外れた話題になるような気がします。 ソフト開発と、道具や枠組みの開発が相互補完的に同時進行するようになると、別の方法論があってしかるべきだと思います。 つまり、今回のタイトルである、「ソフト開発を成功させる1つの方法」と書かれたとおり、これは1つの方法であって全ての方法ではないし、全ての領域で成功する方法論であるとも言えないと思いますので。
ぜひ、この掲示板に新しいスレを立ててください
_________________ | ||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。