- PR -

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

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

ちょっと変かな。
A: 可読性が高い
B: 正しい
C: 短い

元記事とひとりぼけつっこみ(失礼!)は
「A=B かつ A=C、よって B=C」に見えますが、
ほんとは「A->B かつ A->C」
つまり B->C が常に正しいとはいえない:)

　「短いプログラムは無条件で正しい」という言葉の意味から言うと、「短いプログラム」であれば「正しい」、と言うことであって、「正しいプログラム」であれば「短い」という主張ではないと思います。なので、C->Bというのが、この言葉で主張されている内容だと思います。
　この主張を認めた場合でも、B->Cは成立しないと思います。
　あとA=CあるいはA->Cは成立しないと思います。ソースの可読性は、長いプログラムであっても実現可能だと思います。確かに長くなるとそれだけで読みにくくなりますが、長いと無条件で可読性が低いというものでも無いと思います。

_________________
しょむ
ぬし
会議室デビュー日: 2001/09/06
投稿数: 430
投稿日時: 2001-10-22 13:44
引用:
たとえば、アプリAをコーディング中に、まだ仕様の決まっていないアプリXで再利用することを想定して、アプリAでは使わない機能も組み込んで汎用性を高めておくのが前者。逆に、アプリXの仕様が決まっていない段階で悩んでも無駄と考えて、アプリXのことは、アプリX開発時に考えようと言うのが後者だと思います。(が、何せ、昨日知ったばかりの付け焼き刃のキーワードなので、間違っていたらごめんなさい)
　私は前者の方法論を採用して泥沼にはまって後者に転向しました。

ありがちなワナですね:)
ここではまりやすいのは、「汎用化をどれくらい行なえばよいかが青天井」という部分です。要求仕様から汎用性を取り出すのは難しいですからねぇ。
わたしがよくやるのは、後者の方法をまずやって、その時に、少なくとも API とモジュール化だけは汎用的にできそうなものにしておく、です。

引用:
という訳で標準ライブラリを知り使いこなすのは、私は常識だと思います。というか、それすらやらないでプログラムを短く出来るわけがありません。せっかく膨大な人間が利用して信頼性も確立しているライブラリがあるのなら、それと同じ機能を自分で書くなど無駄の極みです。

ではちょっと反論。
Perl で拡張 regexp の機能をフルに使いまくったプログラムの可読性はどうでしょうか。短いです。でも非常に読みにくいです。再利用どころかデバグもしづらいです:)

引用:
道具や枠組みを作るという話になると、これは別の話題になって、今回の話題のスコープから外れた話題になるような気がします。

ですよね。だから、元記事でアクセサメソッドの話が出てきたのは変だなと思ったわけです。アクセサメソッドを使うか否かは、プログラムを短くするとかいう以前に、道具を作るルールのお話ですから。

# あぁ、でも作るのだるい。Ruby みたく楽なシンタックスがほしい…
# ACCESSOR:SET,GET String moge; みたく書ければうれしいのに…

引用:
あとA=CあるいはA->Cは成立しないと思います。ソースの可読性は、長いプログラムであっても実現可能だと思います。確かに長くなるとそれだけで読みにくくなりますが、長いと無条件で可読性が低いというものでも無いと思います。

あぁ、そうですね。
元記事は「C->B」といってるけど、実は「C->A かつ A->B」なのであって、「C->A」がB無条件に真かはちょっと疑問だよね、ですかね。

autumn
大ベテラン
会議室デビュー日: 2001/07/27
投稿数: 215
投稿日時: 2001-10-22 14:10
　もう一人の自分が、肝心なことが誤解されてる恐れがあるんではないか?と言うので書きます。
　「ソフト開発を成功させる1つの方法」はOpinionというコーナーに掲載されています。このOpinionというのは、他の技術解説記事と異なり、著者の意見を述べるコーナーであって、技術的に正しい情報を提供する他のコーナーとは毛色が異なります。
　ですので、このコーナーでは、技術的正しさよりも、著者の意見の方が重視されます。また、技術的正しさを保証することは要求されません。むしろ、読者の目を引くような面白い記事や、辛口の記事が求められます。
　たとえば、他の技術解説記事なら、記述された内容に対して、W3CのXXX Recommendationにこう書いてあった、というような根拠を示すことが出来ます。しかし、この記事には根拠を示すことができません。
　どうも「短いプログラムは無条件で正しい」という主張が正しいかのように思える出来事によくぶち当たるので、もしや、何かの妥当性があるのではないか、と思って書きましたが、100%確信するだけの証明はなされていません。これを世の中に広めようとも思っていません。たぶん、もっとスマートに私が直面している様々な状況を説明する方法論が出てくれば、それに乗り換えるでしょう。

　とはいえ、いろいろな意見を見て考えているうちに、ぼんやりと見えてきたものがあります。
　たぶん、「短いプログラムは無条件で正しい」というのは、エクストリームプログラミングの同類ではなく、マーフィーの法則の同類です。
　「こんな経験ない?」「あるある」「えー、オレは無いぞ」といって盛り上がるべきネタで、厳密な検証をやろうとすると、すぐに反証が出てきて成立しないものだと思います。

　以下余談。
　ただし、マーフィーの法則というのは錯覚ではなく科学的な根拠があることが前に読んだ日経サイエンスに載ってました。
http://www.nikkei.co.jp/pub/science/page/honsi/9707/murphy.html
　そういう意味で、「短いプログラムは無条件で正しい」という命題が成立する確率は、ランダムよりも高いのかもしれません。

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

ありがちなワナですね:)

　そうなんです。純情だった当時の私は、オブジェクト指向が混迷した開発現場を救ってくれると信じて、まっすぐワナに一直線でした 。

引用:

わたしがよくやるのは、後者の方法をまずやって、その時に、少なくとも API とモジュール化だけは汎用的にできそうなものにしておく、です。

　なるほど。完全な汎用モジュールに仕上げようと思うから泥沼になるので、構造と切り口だけにとどめておくわけですね。

引用:

ではちょっと反論。
Perl で拡張 regexp の機能をフルに使いまくったプログラムの可読性はどうでしょうか。短いです。でも非常に読みにくいです。再利用どころかデバグもしづらいです:)

　一般論で言えば、短くても扱いにくいので、良いプログラムとは呼べないでしょう。
　ただ、文字数だけで見ると、確かにregexp使うと短くなりますが、多数の機能を少ない文字で記述しているだけで、コンパイル後のコードの長さ(ってPerlで比較できるのか?)を比較すると、必ずしもregexp使用の方が短いとは限らないと思います。

引用:

ですよね。だから、元記事でアクセサメソッドの話が出てきたのは変だなと思ったわけです。アクセサメソッドを使うか否かは、プログラムを短くするとかいう以前に、道具を作るルールのお話ですから。

　ああ、良く分かりました。私は、アプリの主要なクラスはそのアプリの構造にどっぷり浸っていて、再利用される可能性も低いので、道具ではなく、本体であると見なしていました。

引用:

# あぁ、でも作るのだるい。Ruby みたく楽なシンタックスがほしい…
# ACCESSOR:SET,GET String moge; みたく書ければうれしいのに…

　C#だと、最初に神をも恐れぬpublicな変数を作っておいて……
コード:
class Class
{
	public string msg;
}

　後で何かの理由で単なる読み書きで済まなくなったときに、実装を変数からプロパティに入れ替えちゃう……
コード:
class Class
{
	private string m_msg;
	public string msg
	{
	  get { return m_msg; }
	  set { m_msg = value; }
	}
}

　と言うことができます。それが良いことかどうかは議論が分かれるところだと思いますが。

引用:

あぁ、そうですね。
元記事は「C->B」といってるけど、実は「C->A かつ A->B」なのであって、「C->A」がB無条件に真かはちょっと疑問だよね、ですかね。

　C->Aは成り立たないと思います。短ければ可読性の低いソースでも解読できる(可能性がある)とは言えますが、「短い」と「可読性」は直接結びつきません。

_________________
autumn
大ベテラン
会議室デビュー日: 2001/07/27
投稿数: 215
投稿日時: 2001-10-22 17:21
　一人漫才でーす。

Q:
　goto文があっても短ければ良いように書いてるけど、goto文使いまくって書いて良い?

A:
　駄目だったら駄目だったら駄目なのよ〜〜〜　(by メテオさま)
　goto文はソースの分かりにくさを爆発的に増大させてしまうので、使わないに越したことはありません。goto文を使った分かりにくいソースであっても、短いプログラムなら解読可能(かもしれない)という話は1つの話ですが、何も自分からそんな迷惑ソース書くことはありません。
_________________
autumn
大ベテラン
会議室デビュー日: 2001/07/27
投稿数: 215
投稿日時: 2001-10-22 17:48
引用:

　goto文はソースの分かりにくさを爆発的に増大させてしまうので、使わないに越したことはありません。goto文を使った分かりにくいソースであっても、短いプログラムなら解読可能(かもしれない)という話は1つの話ですが、何も自分からそんな迷惑ソース書くことはありません。

　知り合いから「え〜ん。 C で、多重ループ脱出は、goto でしょ〜? (;;)」と泣きが入ったので、補足。
　希に、gotoを使った方がエレガントに書けるケースがあります。新しい世代の言語がgoto文をサポートしている場合は、たぶんその目的に使うために用意しているだけで、滅多に使うようなものではないでしょう。
　もっとも私の場合、多重ループ脱出はreturnでやれるように構造を工夫しちゃったりしますが
_________________
autumn
大ベテラン
会議室デビュー日: 2001/07/27
投稿数: 215
投稿日時: 2001-10-22 18:51
　一人漫才でーす。

Q:
　どこぞで、これはDOSの方がWindows 95より正しいことだと解釈してたけど、何か反論ある?

A:
　DOSはいいぞ〜〜〜。小さくて軽いし。本体だけならブートは一瞬で終わるし。軽さだけならLinuxも敵じゃない。あるユーザーが期待する機能が全てDOS上にあるなら、Windows 95ではなくDOSを選ぶのは素敵な選択だと思います。(この条件に該当する幸運な人が、この2001年の世界に存在すれば……ですけど )

_________________
ひで
会議室デビュー日: 2001/10/02
投稿数: 15
お住まい・勤務地: 三重県
投稿日時: 2001-10-22 20:49
えー、昔プログラマの経験則から申しますと、長かろうが短かろうがプログラムには間違いに入る余地はあります。
ありがちな例としては、ループの脱出条件のミスです。
例えば、整数値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|2|3|4|5|6 次のページへ»

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