- - PR -
ソフト開発を成功させる1つの方法の感想
投稿者 | 投稿内容 | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2001-10-23 14:57
歓迎します 。
貴重な体験談をありがとうございます。
そうですね。「短いプログラムは読みやすい」は成立しないと思いますが、短いプログラムを目指すことは有益のように感じられます。
やっぱり整理が上手い人は、短く分かりやすいプログラムを書けるのでしょうか? _________________ | ||||||||||||||||
|
投稿日時: 2001-10-23 15:03
上記の文章には私も同意します。 短いプログラムを指向すると、本質的に類似の処理を1つにまとめて扱うことになります。こうすれば、万一バグが出ても、1箇所直せば全てのケースで直したことになるし、仕様変更も1箇所直すだけで済むので、直し忘れが出たりはしません。 _________________ | ||||||||||||||||
|
投稿日時: 2001-10-23 15:19
どうも思い違いをしていたようです。
話を少し整理したいと思います。 「短いプログラムは正しい」と言うと、「シンプルなプログラムは正しいなら納得できるが、短いでは納得できない」という人が結構出てきます。そして、「可読性を高めるためにプログラムが長くなっても良い」と言う人も多いわけです。 この話を整理すると、2つの思想が対立していることになります。 ・ 量を問題にして質には言及しない (量的要素の重視) ・ 長さは問題にせず質(シンプル)を重視する (質的要素の重視) 私の経験則は、質的要素を重視するよりも、量的要素を重視した方が、プログラミングが成功する確率が高いということでした。それが「短いプログラムは正しい」という命題が正しいように思ってしまった理由です。 ところが、XPにおけるシンプルという言葉の意味が「クラスの数とメソッドの数が最低限になっている」という条件を含んでいるということは、実はXPでも量的要素に意味があると見なしていることになります。 ということは、実は「プログラムはシンプルであるべきだ」と主張する人間は2種類に分かれることになります。 量的な問題に着目してシンプルであるべきだと主張する人と、質的な問題に着目してシンプルであるべきだと主張する人です。 うっかり私は「シンプル」を口にする人は、みんな後者だと思っていましたが、間違いだったようです。 ですので、細かい条件に食い違いはあるにせよ、プログラムの善し悪しに関して量的な問題に着目している人は、私と近い世界を見ている人だと思います。 _________________ | ||||||||||||||||
|
投稿日時: 2001-10-23 16:45
一人漫才でーす。
Q: これぞ最高の短いプログラムってのを教えてください。 A: 個人的に一番スゴイのは、やっぱりこれかな。 もう記憶があやふやなので、間違ってたらごめん。
これは、SHARP MZ-80Kシリーズにおいて、直前にカセットテープからロードしたプログラムの複製をカセットテープに保存するプログラムです。モニタSP-1002上で画面クリア後、上記文字列を入力してから、行を変えてGOTO$D000リターンで実行します。 可読性は最低です。何書いてあるのかさっぱり分かりません。でも、これだけ短いと、プログラムを人間の脳みそに格納するのも容易です。デパートのパソコン売り場で面白いプログラムを見かけて「え、これ君が作ったの? もらっていい?」と言って慌ててカセットテープをその場で買ってコピーをもらうには最適。(もちろん、不正コピーのために使っちゃだめだぞ) これさえあれば、そんな事態に備えて毎日プログラムの入ったカセットテープを持ち歩く必要もありません。 プログラムの短さが行き着くところまで行くと、可読性の悪さすら無視できるほどの価値が生まれるということですね。 Q: じゃ、僕もそういうの作って公開してヒーローになろうかな? A: これだけ通信環境が整備された今、脳みそに記憶できるなんてメリットでは誰も使ってくれないでしょう。脳みそなんか使わないで、ちょいとネットから落としてくればいいんだから。 _________________ | ||||||||||||||||
|
投稿日時: 2001-10-23 22:40
短いプログラムというのは、例外的状況への対応をサボっている疑いがある。
セキュリティ上の問題を引き起こす可能性大。
動けばいいという発想はそろそろ死滅して欲しい。 私の個人情報が漏洩するのは嫌だから。 | ||||||||||||||||
|
投稿日時: 2001-10-24 01:36
「短いプログラムは無条件で正しい。なぜなら、短いプログラムは短いというだけで実行速度も速く、理解も容易であるからだ」
何が間違ってるの? 可読性がどうとかこうとか、そんな事書いてないじゃん。 上を言ったのは、アメリカ人でしょ? 日本人は大好きだね〜、そんなのにすぐに突っ込んで。 そりゃそうだって何で返せないのかな〜? なんで、可読性がとか・・・ああ。 1万行あるコードとたった3行のコードが全く同じ結果を返します。 エラーが発生する確率も同じで、ああ、アホらしくなってきた。 やめます。 | ||||||||||||||||
|
投稿日時: 2001-10-24 03:33
ちょっと違うかも。 「行数がすくない」は単なる量的なお話ですが、「クラス数・メソッド数がすくない」は単にコード量がすくないというのではなく、機能と API の重複を減らせ(or なくせ)という質的なものも含む感じがします。 # あー、極論思いついた… クラスひとつ、main() ひとつのアプリ、とか(笑) # そんなこたー XP が言ってることではない:)
「すべてのテスト」にセキュリティーテストが含まれていれば問題なしでは。 すべてあげられるかは別として。 ------------------ ともあれ、実は「ふつうのプログラマは冗長な(重複のある)プログラムを書きやすい」とか「アプリケーションが大規模になってくると冗長性が高くなる」とかいう前提のもとに、「いまふつうに書いているものをベースとして、短くしましょう/クラス数やメソッド数が減らせないか考えましょう」あたりが落としどころかなぁと思ったり。 | ||||||||||||||||
|
投稿日時: 2001-10-24 14:02
一人漫才でーす。
Q: ソートとか、いちばん短いプログラムが最善とは限らないのでは? 短い方を選ぶと、とんでもなく遅いぞ〜。 A: プログラムに要求される機能として、速度に関する要素が含まれないのなら、短い方が作るのは楽ですぜ。データ量が十分に小さいケースでは、速度は重視されないこともあるでしょう。逆に、データ量が多ければ、性能面での要求が必ずあるので、それを満たす範囲で最も短いプログラムを探ることになりますから、計算量が爆発的に増えるアルゴリズムは候補外でしょうな。 もっとも、ソートぐらいなら標準ライブラリに最初から入ってるようなものなので、ライブラリ呼び出し一発でおしまい、というのが最も短い選択かも。 _________________ |