- PR -

if文のコメントを、どのようにつけますか?

投稿者投稿内容
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2004-05-10 08:24
引用:

あつしFxさんの書き込み (2004-05-08 22:23) より:
ソースコードと仕様書の同期がとれないのは普通です。


引用:

七味唐辛子さんの書き込み (2004-05-09 00:03) より:
仕様書はあくまでも仕様書であって設計図とは違いますまから
同期がとれないのは当たり前だと思います


 あれれ?当たり前ですか^^; 私は「慣例化されている」とは思いますが、「当たり前」であってはならないと思います。仕様書があって、それを目標に作り、また仕様書を元にテスト計画を立てるのであって、仕様変更があれば、常に同期を取らなければならない、と思います。
#スレッド趣旨と外れてきていますが、突っ走ります


引用:

まず、仕様書だけでちゃんとプログラムか書けるプロジェクトってありますか?
通常は仕様書だけじゃわからないところが出てきて、聞きに行かないといけないの
が多かったりしません?


 確かにそうなのですが、それを「仕方ないじゃん」と放ったらかしにしていてはいけない、と思うのです。放っているから、よけいに混乱が生じると。
 ですから、プログラムを元に仕様書を修正するのではなく、仕様変更があったり、仕様書に足りないところがあれば、まずは仕様書を修正し、テストパターンを作り直し、そしてプログラムの修正、ではないかと思います。
はゆる
ぬし
会議室デビュー日: 2004/02/16
投稿数: 1008
お住まい・勤務地: 首都圏をウロウロと
投稿日時: 2004-05-11 14:09
引用:

Jittaさんの書き込み (2004-05-10 08:24) より:
 あれれ?当たり前ですか^^; 私は「慣例化されている」とは思いますが、「当たり前」であってはならないと思います。仕様書があって、それを目標に作り、また仕様書を元にテスト計画を立てるのであって、仕様変更があれば、常に同期を取らなければならない、と思います。
#スレッド趣旨と外れてきていますが、突っ走ります

 (中略)
 確かにそうなのですが、それを「仕方ないじゃん」と放ったらかしにしていてはいけない、と思うのです。放っているから、よけいに混乱が生じると。
 ですから、プログラムを元に仕様書を修正するのではなく、仕様変更があったり、仕様書に足りないところがあれば、まずは仕様書を修正し、テストパターンを作り直し、そしてプログラムの修正、ではないかと思います。



では、ちょとだけお付き合いを(ちょびっと遅レスですが・笑)。
仕様書とソースの同期、たしかに取れていない現場が多いですね…混乱することしばしばです。
(私が知る限りの、あちこちの現場を転々とした感想ですけど…)
そういうときは、ソースを信じるしかないのですが。(^^;

ただ、Jitta さんのおっしゃることは ”真” だと思います。
キングファイル数十冊分の 「ゴミの山」 なんかも見たことがありますが(…)、そういうプロジェクトはたいてい火を噴いていました。
じゃぁ仕様書がないところならいいのか?といえば、それはそれで引き継いだ人間が苦労すると、末路がたいてい決まっています。
ロクな仕事してないな〜と我ながら思ったりもしますが(苦笑)、「参加してよかった!」 「このプロジェクトは大成功!」 という現場に参加したこともあるんですよ♪
そういうところは、決まって仕様書があり、メンテされ続け、またテストが確立されていました。
(プログラマのお仕事は、仕様書どおりのモノを作るだけじゃないんだわ〜と、それらの現場で学びました)
仕様書といっても、先の例のような山ほどの資料ではありません。「どこまでを仕様書とするか」 も、重要なポイントになっていました。

1人でプログラムを作っているのでない限り、プロジェクトとしての ”レベル” を維持する努力は必要です。
それはそのまま、システムの ”レベル” にも通じてくると思います。
「紙は紙、コードはコード」 とお考えの方がいらっしゃいましたら、是非見直してみてください。
そして、ステキな現場に出会えるのを楽しみにしております。
(転々としてるといっても、最初から携われたプロジェクトはないな〜…。そうなると、なかなかこういうことも言い出せなかったりするんです。涙)
タラン
大ベテラン
会議室デビュー日: 2004/03/17
投稿数: 138
投稿日時: 2004-05-11 15:46
//判断内容
if(A){
//Aの場合
XXX
}
else{
//A以外の場合
XXX
}

こう書きます。
じいじ
大ベテラン
会議室デビュー日: 2003/11/11
投稿数: 223
投稿日時: 2004-05-11 16:06
おじゃまします。脱線ついでに・・・・
みんな「あちゃ〜!!じいじが来た!」と思うだろうな。Cafeだからいいでしょ!

引用:
Jittaさんの書込(2004-05-06 18:03)より

仕様書を書くのは自己防衛の為です。仕様書を書いて、「これでいいですね」と、確認して、見せた/見たという証拠を取ります。そうしておいて、その人の「言うこと」が、「仕様変更」であることを明確にしないと、とんでもないことになります。「なります」というか、とんでもないことを言われたので、証拠を取るようにしました。。。


私は昔いたずらでこんなことをしたことがあります。

とてつもなく時間が不足しているところへ、横から2週間でできないか?とちっぽけな依頼がありました。みんなで休息がてら先方の話を聞くと、
2〜3日で作れそうだが、マニュアルの作成や先方への説明をするとなると、そんな人員は「ない!」
で、私が言っちゃった。「2週間後に納品しますから、これから1週間かけて手書きでいいから、そちらでそちらにとってわかりやすいマニュアルを作ってこちらへ持ってきてください。画面の設計もしてよ。etc」

で、3日でテストも完了。ただ納品しただけ。

マニュアルは作成しなくていいし、説明もいらないし、使い勝手の悪いところがあったら、それはそちらがちゃんとしなかったからですよ。と・・・・
究極の(?)自己防衛では?
こういうことは1回だけでしたけど。当時の仲間と会うと、必ずこの話が出ます。
ぽんす
ぬし
会議室デビュー日: 2003/05/21
投稿数: 1023
投稿日時: 2004-05-11 20:05
Knuth 先生の「文芸的プログラミング」をやれば、ドキュメントと
ソースコードの整合性が保たれるはずですよ。
# ひとつのソースから、文書とプログラムの双方が生成される仕組み。
すごく手間がかかるという話ですが...
# 私はやったことありません。

スキルアップ/キャリアアップ(JOB@IT)