- - PR -
if文のコメントを、どのようにつけますか?
«前のページへ
1|2|3
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-05-10 08:24
あれれ?当たり前ですか^^; 私は「慣例化されている」とは思いますが、「当たり前」であってはならないと思います。仕様書があって、それを目標に作り、また仕様書を元にテスト計画を立てるのであって、仕様変更があれば、常に同期を取らなければならない、と思います。 #スレッド趣旨と外れてきていますが、突っ走ります
確かにそうなのですが、それを「仕方ないじゃん」と放ったらかしにしていてはいけない、と思うのです。放っているから、よけいに混乱が生じると。 ですから、プログラムを元に仕様書を修正するのではなく、仕様変更があったり、仕様書に足りないところがあれば、まずは仕様書を修正し、テストパターンを作り直し、そしてプログラムの修正、ではないかと思います。 | ||||||||||||
|
投稿日時: 2004-05-11 14:09
では、ちょとだけお付き合いを(ちょびっと遅レスですが・笑)。 仕様書とソースの同期、たしかに取れていない現場が多いですね…混乱することしばしばです。 (私が知る限りの、あちこちの現場を転々とした感想ですけど…) そういうときは、ソースを信じるしかないのですが。(^^; ただ、Jitta さんのおっしゃることは ”真” だと思います。 キングファイル数十冊分の 「ゴミの山」 なんかも見たことがありますが(…)、そういうプロジェクトはたいてい火を噴いていました。 じゃぁ仕様書がないところならいいのか?といえば、それはそれで引き継いだ人間が苦労すると、末路がたいてい決まっています。 ロクな仕事してないな〜と我ながら思ったりもしますが(苦笑)、「参加してよかった!」 「このプロジェクトは大成功!」 という現場に参加したこともあるんですよ♪ そういうところは、決まって仕様書があり、メンテされ続け、またテストが確立されていました。 (プログラマのお仕事は、仕様書どおりのモノを作るだけじゃないんだわ〜と、それらの現場で学びました) 仕様書といっても、先の例のような山ほどの資料ではありません。「どこまでを仕様書とするか」 も、重要なポイントになっていました。 1人でプログラムを作っているのでない限り、プロジェクトとしての ”レベル” を維持する努力は必要です。 それはそのまま、システムの ”レベル” にも通じてくると思います。 「紙は紙、コードはコード」 とお考えの方がいらっしゃいましたら、是非見直してみてください。 そして、ステキな現場に出会えるのを楽しみにしております。 (転々としてるといっても、最初から携われたプロジェクトはないな〜…。そうなると、なかなかこういうことも言い出せなかったりするんです。涙) | ||||||||||||
|
投稿日時: 2004-05-11 15:46
//判断内容
if(A){ //Aの場合 XXX } else{ //A以外の場合 XXX } こう書きます。 | ||||||||||||
|
投稿日時: 2004-05-11 16:06
おじゃまします。脱線ついでに・・・・
みんな「あちゃ〜!!じいじが来た!」と思うだろうな。Cafeだからいいでしょ!
私は昔いたずらでこんなことをしたことがあります。 とてつもなく時間が不足しているところへ、横から2週間でできないか?とちっぽけな依頼がありました。みんなで休息がてら先方の話を聞くと、 2〜3日で作れそうだが、マニュアルの作成や先方への説明をするとなると、そんな人員は「ない!」 で、私が言っちゃった。「2週間後に納品しますから、これから1週間かけて手書きでいいから、そちらでそちらにとってわかりやすいマニュアルを作ってこちらへ持ってきてください。画面の設計もしてよ。etc」 で、3日でテストも完了。ただ納品しただけ。 マニュアルは作成しなくていいし、説明もいらないし、使い勝手の悪いところがあったら、それはそちらがちゃんとしなかったからですよ。と・・・・ 究極の(?)自己防衛では? こういうことは1回だけでしたけど。当時の仲間と会うと、必ずこの話が出ます。 | ||||||||||||
|
投稿日時: 2004-05-11 20:05
Knuth 先生の「文芸的プログラミング」をやれば、ドキュメントと
ソースコードの整合性が保たれるはずですよ。 # ひとつのソースから、文書とプログラムの双方が生成される仕組み。 すごく手間がかかるという話ですが... # 私はやったことありません。 |
«前のページへ
1|2|3