Index: [Article Count Order] [Thread]

Date:  Tue, 7 Nov 2000 21:01:22 +0900
From:  "Oota" <oota@....jp>
Subject:  [XP-jp:01154] Re: C プログラミング診断室というのがありました
To:  extremeprogramming-jp@....jp (extremeprogramming-jp ML)
Message-Id:  <000001c048b4$0b1df640$010400c8@Ra20>
In-Reply-To:  <20001107192812tsujit@....jp>
Keywords:  XP
Posted:  Tue, 7 Nov 2000 21:12:48 +0900
X-Mail-Count: 01154

 早稲田大学の太田です。

 平鍋さんのgenerative programmingの例題については類似のものをJPLoPの
ほうでもお見かけしましたが、理解しやすさと高速性のトレードオフですね。
この使い方に限っていえば、JPLoPでもお話があったようにソースから自動解
析する二村先生(早稲田大学)の部分計算を使ったほうが良いのではと思います
が、generative programmingの用途がもっと広いものだとしたら話は異なりま
すね。

> でも実際、長すぎる関数はよく見かけますよね。
> 「作っていくうちに長くなって、分割するとデグレードし
> そうでほっておく。」
> ってパターンが。
> こーゆー時にはXP(というかリファクタリング)はホント便利です。
> この部分だけでも取り入れる価値はあると思うんですよね。
> 周りにも、そう言って薦めてますし。

 そうですね。リファクタリングのようにどういう状況でどのように分割すべ
きかの基準があるのは非常によいと思います。また、ペアプログラミングだっ
たらあのような状況(6344行)になる前に手を打つのは確実でしょう(私だった
ら高級言語で25行を越えている時点で考え直せというと思います)。

> ・・・たしかにクセ強すぎですねぇ。
>
> 悪くはないんですが、これだと後で人が見た時に意味の分からない
> ソースになりそうで。
> マクロってそういう危険性が強いと思いませんか?

 テンプレートもそんな感じがします。使う分には非常によいのですけど、書
いたものを解析するのはかなり苦痛です。C MAGAZINEで連載中のStandard
C/C++ではSTLの解説を毎回していますが、正直をいいますとまともに理解でき
たことはほとんどありません。

 また、林晴彦さんについてですが、林晴彦さんのテキストはC言語を勉強す
る初期にお世話になったので余り悪いことは書きたくないのですけど、「my.h
を作れ」などチームで開発を進めるのにはよくないことも結構書いていると思
います。その当時は「おおっ」とか思いましたけど、あくまで個人レベルにお
いて有効なだけでチームレベルとなると?ですね。

>  「ソフトウエア・テストの技法」
>  「珠玉のプログラミング 
> 本質を見抜いたアルゴリズムとデータ構造」(小林健一郎訳)
>   実践的プログラムテスト入門	日経BP出版センター
> の3つ、入手しました。
> さっそく読み進んでいます。ノロイですけど。
> #あと「Code Complete」も並列して。
>
> やっぱ良書はいいですね。

 「実践的プログラムテスト入門」で実践的にテストが書けるようになったら
是非御教授下さい。私は読んでも書けませんでしたので(特にデータフローテ
ストが難しすぎました。実際はCode Completeで書いてあるレベルくらいで十
分であるような気がします)。BinderとMyersとKent Beck & Erich Gammaでよ
うやくまともなテストがちょこっと書けるようになりました。

早稲田大学大学院理工学研究科情報科学専攻M2 太田健一郎
e-mail Address oota@....jp
               oota@....jp