- PR -

ソフト開発を成功させる1つの方法の感想

«前のページへ 1|2|3|4|5|6 次のページへ»
投稿者投稿内容
biac
大ベテラン
会議室デビュー日: 2001/10/22
投稿数: 106
投稿日時: 2001-10-22 22:26
引用:

autumnさんの書き込み (2001-10-22 14:10) より:
　たぶん、「短いプログラムは無条件で正しい」というのは、エクストリームプログラミングの同類ではなく、マーフィーの法則の同類です。


「マーフィーの法則の同類」と言われてしまうと、納得してしまうではないですか。


「短い」ではなくて「シンプル」だったら、より真実に近いのでは、と思うものの、こんどは、「シンプルなプログラム」の判定方法が問題になります。

XP が出てきたところで、Kent Beck の「シンプルな設計」の条件、
引用:

1. すべてのテストが通る。
2. 重複したロジックがない。
3. プログラマにとって重要な意図がすべて述べられている。
4. (1.〜3. を満たした上で) クラスの数とメソッドの数が最低限になっている。

というのはどうでしょう?

もっとも、OOP が前提になっているので、そういう環境で仕事をしていない人からは、そっぽをむかれるでしょうね。


--------------------------------
biac#Cでgotoを使う男

[ メッセージ編集済み 編集者: biac 編集日時 2001-10-22 22:28 ]
autumn
大ベテラン
会議室デビュー日: 2001/07/27
投稿数: 215
投稿日時: 2001-10-22 22:49
引用:

えー、昔プログラマの経験則から申しますと、長かろうが短かろうがプログラムには間違いに入る余地はあります。

　その通りです。ですが、長くても短くても同じではありません。
　もし、for文の終了判定を100回に1回間違って書くプログラマが居た場合、for文が10回含まれるプログラムでは、10プログラムに1回程度の割合でバグを作り込むことになります。しかし、for文が100回含まれるプログラムでは、1プログラムに1回程度の割合でバグを作り込むことになります。仮に同じ機能を実現するプログラムだとすれば、余計な機能を取り去って、より少ないfor文で実現する方がバグに巻き込まれる確率が少ないことになります。

　それはさておき。
引用:

例えば、整数値N1からN2までの総和を求めるプログラム(N1<N2)。
コード:
int i,S ;
S = 0 ;
for (i=N1 ; i<=N2 ; i++) S += i ;

非常に短いプログラムですが、3行目を
コード:
for (i=N1 ; i<N2 ; i++) S += i ;

としてしまう間違いです。コンパイルしてもエラーは出ませんし、コードだけを一見してもすぐには発見しづらいでしょう。

　これは容易に防止できるバグです。
　ループの終了値が1個ずれるのは、定番のバグです。これは終了値とループする回数の関係を正確に把握していない、あるいは、正確にソースコード上に表現されていないことから入り込むバグだと思います。
　よく使われるパターンの
for( i=A; i<B; i++ )
　は、B-A回まわります。
　それに対して、
for( i=A; i<=B; i++ )
　はB-A+1回まわります。
　まわる回数が1回違うにも関わらず、両者は非常に紛らわしい見かけになります。
　ですので、紛らわしい使い方は使わないように習慣づける、というのがバグから逃れる方法の1つです。
　つまり、
for( i=A; i<=B; i++ )
　を書きたいときは、
for( i=A; i<B+1; i++ )
　と書くように習慣づけると言うことです。これにより、B-A+1回の+1がソースコード上にも明示的に見えるようになるので、何回まわりたいのかがソースを見る者に分かりやすく伝わります 。

_________________
autumn
大ベテラン
会議室デビュー日: 2001/07/27
投稿数: 215
投稿日時: 2001-10-22 22:59
引用:

「短い」ではなくて「シンプル」だったら、より真実に近いのでは、と思うものの、こんどは、「シンプルなプログラム」の判定方法が問題になります。

　うぉっと!
　なんか妙な気分になって来ました。
　以下の2つを見てください。
　まず私が今日書いた「短いプログラム」のより明示的な定義。
引用:

・　プログラムに持たせたい能力を「機能」と呼ぶ
・　宣言、ステートメント、演算子などを「要素」と呼ぶ
・　各種テストをパスし、実用上問題ない状態を「バグがない」と呼ぶ
・　上記条件をクリアしない状態を「バグがある」と呼ぶ
・　「機能」を実現し、「バグがなく」、「要素」の個数ができるだけ少ないプログラムを「期待されるプログラム」と呼ぶ

　そして、XPのシンプルの定義。
引用:

1. すべてのテストが通る。
2. 重複したロジックがない。
3. プログラマにとって重要な意図がすべて述べられている。
4. (1.〜3. を満たした上で) クラスの数とメソッドの数が最低限になっている。

　なんだか、同じことを言ってるような気がして来ませんか?

_________________
しょむ
ぬし
会議室デビュー日: 2001/09/06
投稿数: 430
投稿日時: 2001-10-23 03:37
いやぁ、DOS いいっすよ。DOS6 以降。タスクスイッチあるし。

世の中の PC で行なわれてる仕事の 80% は、メニューから数字でやりたいことを選んでカーソルでポチポチ移動でできますよ？ 汎用アプリも Just Window とやらぐらいでできますよ？ ちうか、むしろ、改行で fold したり、「4倍角はどうするんだ？」っていう人はたくさんいますよ？

# 川俣さん壊れてきた？(笑)
しょむ
ぬし
会議室デビュー日: 2001/09/06
投稿数: 430
投稿日時: 2001-10-23 04:11
引用:
なんだか、同じことを言ってるような気がして来ませんか?

どちらにせよ、「機能」「要素」「ロジック」をどの程度の大きさにとるか明確じゃないですね。先の汎用化にしても、結局この部分をどの程度にとるかによっていろんなことが変わってきます。

XP もマーフィーだってことで:P

デザインパターンも XP も、職人の暗黙知を形式知にしてみた、ってだけな気がしてなりません。職人は「そうそうそうなんだよ、俺がいいたかったのはこれなんだよ。よくいってくれた」とうなずき、普通の人は「ふーん、そうなんだー、うまくいくんだー」と思い、管理者は「よくわからんけど常識らしい。キミら勉強しとき」と言える。すばらしい:P

--
あ〜、シンプルさと言えば認知科学とか使うと面白そうですねぇ。人が認識しうる「シンプルさ」とか「抽象性」とか「構成物の数」とか:-)
マジックナンバーで「クラスの継承関係は、7個でひとつの機能的グループができるようにしましょう」とか
H2
ぬし
会議室デビュー日: 2001/09/06
投稿数: 586
お住まい・勤務地: 港
投稿日時: 2001-10-23 08:06
途中からおじゃまします。

大学1年生達の書いたプログラムをテストするというのを何度かやったのでその時の経験談です。

まず、AutoMarkというプログラムで皆さんのプログラムを自動テストします。いろいろな条件でテストして、パスすれば点がもらえるという方式です。そのあと、私みたいな3年生や4年生達が一つ一つソースコードをみて、スタイルを見ていきます。

気づいたこと
  • すべてのテストにパスするプログラムはだいたい読みやすい。
  • 読みやすいプログラムはだいたい短い。


読みやすいというのは、コメントが多すぎずそれでいて説明が十分なことです。
コード:
i++  //iに１を足す
なんて書かれてもしょうがないわけです。（へ〜、i++ってそういう意味だったんだ・・・と一人突っ込みますが）

逆にCで
コード:
(p != NULL) && (*p = 0);　//pがnullポインタでなければ0に初期化する（*1）
っていうのは一見コードは読みにくいですが、何をやってるかはわかるわけです。

で大体思うのは、読みやすいソースは短いんです。一度、横534桁の行が（かなり長い時間スクロールしないと読めない）あってのけぞりました。案の定、自動テストの点はほとど０に近い点数でした。

あと、突如現れるマジックナンバー。２ってなんだぁ！なんて叫びたくなります。forやwhileなどを多用しすぎるもプログラムもバグが多いですね。大体こういうのはコードも長いわけです。

ほとんどの場合、正しいプログラムは読みやすく読みやすいプログラムは短いです。だからと言って逆も成り立つかというとそれはどうでしょうね。私個人の意見では、「短いプログラムは正しいプログラムになりうる可能性が高い。よって短くするべきである」ですね。

p.s.　もうひとつ経験ですが、Windowsのデスクトップ上ですか？（もしくはUnix/Linuxのホームディレクトリ上）あの場所にぽこぽこ無駄にファイルを置く人のプログラムはやっぱり長くてバグが多いです。関係あるんでしょうかねぇ？

コード:
(*1)
(p != NULL) && (*p = 0);　は
if (p != NULL) *p = 0;　とまったく同じです。
biac
大ベテラン
会議室デビュー日: 2001/10/22
投稿数: 106
投稿日時: 2001-10-23 13:30
引用:

autumnさんの書き込み (2001-10-22 22:59) より:
　うぉっと!
　なんか妙な気分になって来ました。

んでは、Kent Beck の相棒 Martin Fowler の「リファクタリングを行う理由」から。
(「リファクタリング」ピアソン・エデュケーション; ISBN:4894712288)
引用:

設計のまずいコードは、良いものに比べ、同じ処理をするにも余計にコードを書くことになります。 これは文字どおり同じようなコードがあちこちに散らばっているからです。
(...中略...)
重複部分を排除することで、開発者はコードがただの1回のみ書かれ、そこですべてが処理されることを保証できます。 これは優れた設計のポイントです。



※ 2001-10-22 22:26 に書いた、『Kent Beck の「シンプルな設計」の条件』が出てくる本は、「XPエクストリーム・プログラミング入門」(ピアソン・エデュケーション; ISBN:489471275X) です。
autumn
大ベテラン
会議室デビュー日: 2001/07/27
投稿数: 215
投稿日時: 2001-10-23 14:52
引用:

どちらにせよ、「機能」「要素」「ロジック」をどの程度の大きさにとるか明確じゃないですね。先の汎用化にしても、結局この部分をどの程度にとるかによっていろんなことが変わってきます。

　そういえば、昔読んだ本の中で、戦艦大和を建造した技術者の言葉として、「こんなに大きな戦艦を作ったことが凄いのではない。これだけの機能を、このサイズに納めたことが凄いんだ」というのがありました。普通に作れば、もっと大きくなってしまうものを、このサイズに納めたってことですね。
　大きい、小さいなんていうのは、対象を見る基準や視線によって容易に変わりうるものだと言うことでしょうね。

引用:

XP もマーフィーだってことで:P

　XPが経験則の集大成なら、マーフィーっぽくても当然かも知れませんね。

引用:

あ〜、シンプルさと言えば認知科学とか使うと面白そうですねぇ。人が認識しうる「シンプルさ」とか「抽象性」とか「構成物の数」とか:-)

　人間に理解できる複雑度の範囲、のようなものが明確に分かってくれば、いろいろな問題に取り組みやすくなりますね。
　ただ、人間の理解力というのはそれほど高くないような気がします。
　もしかしたら、理解が得意な人間というのは、実は理解しやすいように整理するのが得意なだけかもしれません。
　もし、うまく整理できれば、整理できていない人よりも、書くプログラムも短くなりますね。

引用:

マジックナンバーで「クラスの継承関係は、7個でひとつの機能的グループができるようにしましょう」とか

　これも難しいところで、誰でも容易に分かるような関係なら多少増えても平気だが、理解しにくい抽象的な関係は少なくても難解、ということがあるかも知れません。ただ、目安としてマジックナンバーを導入するのは良いかも知れませんね。
　1メソッドは100行以内、といったルールを持っている人もいますから、目安としてのマジックナンバーはあっても良いと思います。

_________________
«前のページへ 1|2|3|4|5|6 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）