良いドキュメント・マニュアル・仕様書を書くスレat TECH
良いドキュメント・マニュアル・仕様書を書くスレ - 暇つぶし2ch262:名無しさん@そうだ選挙に行こう
05/09/11 04:01:28
でも、ホント、Word の売りってなんなんだろうな?

パワポは俺も最近までは全然評価してなかったんだけど、会議で使う資料をパワポで作ったら、
いつもテキストファイルで書いてる内容と変わらんのに、妙に内容の評価がよくてワラタ。
やっぱり人は体裁で騙されるもんだなwww  ・・・それからはパワポに一目置いている俺ガイル。

263:名無しさん@そうだ選挙に行こう
05/09/11 11:27:31
>>262
発表において、体裁ってもんがどれほど重要か。
どんな小手先の技でもいいから、人の気を引くというのは大切よ。

Word の利点、ぱっと思いついたのだと、
- 修正履歴を残せる → 学生の論文チェックとかかなり楽
- コメントを付けれる → これも校正に凄く便利
- スペルチェック → 英文はとりあえず最初 Word で書いとけみたいな
- 一応、段落ごとにスタイル定義しておいて、スタイルの書式変更したら同じスタイル一斉に変更される

264:名無しさん@そうだ選挙に行こう
05/09/11 13:27:47
Wordで20ページ↑の仕様書を書いてみればわかるよ
スタイルとかクロスリファレンスつけておくとマジ便利
目次や索引も自動で作れるし。
これでもう少し図形描画の機能が充実してればなぁ・・・
ま、そっちはVisio使ってるからいいんだけど。

#でも、個人的にはLaTexを吐いてくれるエディタが欲しいところ

265:名無しさん@そうだ選挙に行こう
05/09/11 13:29:26
利点
- 目次作成 + 自動更新
- 図表番号の自動更新

266:名無しさん@そうだ選挙に行こう
05/09/11 17:20:24
>>263-265

どれも俺からすると些末な機能なんだけど。

XSLTが大好きな俺的にはXML形式に対応してるところなんかが蝶最高なんだけど、
これはExcelやパワポでもできることだしな。

267:名無しさん@そうだ選挙に行こう
05/09/11 17:33:54
Wordの最大のウリは
多数派であるということ

268:名無しさん@そうだ選挙に行こう
05/09/11 17:50:31
>>264
最近のはマシなんか?
Wordでページ数多い文書作ると重いわすぐ落ちるわで……
いい印象無かったんだが

269:名無しさん@そうだ選挙に行こう
05/09/11 18:28:11
>>264-265
この辺のテンプレート集とかスクリプト集ってある?
折角の利点も簡便で分かり易くないと説得が難しい。
偉いさんてのはプライドを刺激されると意固地になるからな。彼らは難しいとか
理解できないを決して口にせず、それらを必要がないの一言で片付けてしまう。

270:名無しさん@そうだ選挙に行こう
05/09/11 18:32:51
>>267
Excelの方が多数派だよ?
総務などの非生産部門には必ずと言っていいほどExcelが導入されてるから

271:名無しさん@そうだ選挙に行こう
05/09/11 18:33:14
>>269
目次だのなんだのって、単なるWordの基本機能だから、スクリプトは不要だよ。
ちゃんとスタイル使って(「見出し1」とか「見出し2」とか)文書を
書けば、章番号を自動で振ってくれるし、後でそれをもとに自動で目次が作れる。

272:名無しさん@そうだ選挙に行こう
05/09/11 18:34:18
>>270
ExcelとWordでは用途が違うというだけの話だ。
適材適所で使い分けるのが賢いやり方。

273:名無しさん@そうだ選挙に行こう
05/09/11 18:51:04
>>271
ありゃ?そうなのか、て言うか基本機能なのかよ!
俺自身が実際に触って、基本機能くらいは理解しないと話にもならんな_| ̄|○|||
それが何とも億劫と言えば億劫なんだが……
俺も偉いさんの事をとやかくは言えんな……

>>272
問題は、決して賢くないという点だ!Σ(´Д` )

274:名無しさん@そうだ選挙に行こう
05/09/11 19:02:01
>>273
URLリンク(www.amazon.co.jp)
この本がおすすめ。

アウトラインモードで取り敢えず書くのが
自然に思えてきたら結構使ってる人なんじゃないでしょか。

275:名無しさん@そうだ選挙に行こう
05/09/11 21:47:06
>>273
俺、元々LaTeX派だったけど、3日でWordに転向しちゃったよ。
割とすぐ覚えれる。

276:名無しさん@そうだ選挙に行こう
05/09/11 21:50:52
>>274

この本、自分も人から薦められて買ったけど、かなりいい本ですね。
職場に一冊常備すべし。


277:名無しさん@そうだ選挙に行こう
05/09/11 22:54:18
Win板かソフ板の話題が続いている件について

278:デフォルトの名無しさん
05/09/12 00:35:07
>>274-276
ホントかよ?ジエリじゃねぇだろうなw
とりあえず明日本屋行ってくるよ。初心者向けではないみたいだから
一緒に入門書も買ってくる。

279:デフォルトの名無しさん
05/09/12 00:59:59
>>278
じえんじゃないよ。
まあじえんだとしてもいいじゃん
本屋で立ち読みしてみて決めてちょー。

カラーページがないところとかが硬派で
それだけで好感が持てますだ。

DTPのマナーみたいな話も、システム文書には
必要ないけど、面白かったな。


280:デフォルトの名無しさん
05/09/16 00:55:41
Wordのスタイル機能は書式をいぢりづらいのがネック。
特にスタイル使わずに書かれた文章にスタイルを導入しようとすると死ねる。

281:デフォルトの名無しさん
05/09/16 10:45:36
>>280
あとからは相当骨でしょそりゃー。

282:デフォルトの名無しさん
05/09/23 00:26:28
なんかMSワードって何処でも決まって悪者にされる傾向があるけどなんでだろうね。
俺はかなり良いソフトだと思うんだけど。いやマジで。

今までアドビのフレームメーカーとかロータスのワードプロも触ってきてるけど
ワードのUIはそれらより飛びぬけて直観的だし、機能も多い。

ワード使い難いって奴はフレームメーカー使ってみるといいかも。
フレームメーカーの糞UIはマジで殺したくなるよ。それでいてワードより高かったりしたから恐れ入る。

まあでも時々挙動不審だったりするし、段落番号の設定みたいに異常にわかり難い
UIがあったりする欠点は確かにあるな。

それにしても、ワード貶してる奴らに関しては、ワードの問題というより
そいつらの能力の問題じゃないかと思うが。

283:デフォルトの名無しさん
05/09/23 01:07:59
デフォルト設定のせい
UNIXが使いにくいのとおなじ

284:デフォルトの名無しさん
05/09/23 11:01:41
それにしても、UNIX貶してる奴らに関しては、UNIXの問題というより
そいつらの能力の問題じゃないかと思うが。

285:デフォルトの名無しさん
05/09/23 14:04:57
じゃあWordに文句を言うやつも無能だな。

286:デフォルトの名無しさん
05/10/10 16:31:55
>>285
そりゃ無能だろ

287:デフォルトの名無しさん
05/10/10 17:27:01
あーでもWordの使いにくさとUNIXの使いにくさは別だな。
UNIXはどうしようもないからな。

288:デフォルトの名無しさん
05/10/10 17:33:25
doxygen 1.4.5 age

289:デフォルトの名無しさん
05/10/10 17:34:07
なんで並列に語ってるのか知らないけど あえてノルなら
Wordの使いにくさは 袋小路 であり、UNIXの使いにくさは 迷路 だ。

Wordでやりたいことをやるとき、正式な方法が無いことはよくあり
正式じゃない方法で突破することが多い
UNIXでやりたいことをやるとき、正式な方法がそもそも難解で
そのことを訴えると「道があるんだからいいだろ」と突っぱねる

290:デフォルトの名無しさん
05/10/10 18:29:51
Linuxの場合、とっつきやすさや使いやすさを最初から目指していないのだから使いにくくて当然な気がする。
Wordはなー。MSってUIにけっこう力入れてるはずなのになんであんなことになるのか。

291:デフォルトの名無しさん
05/10/10 19:38:35
英文だと一般の評判多少マシなのか?

292:デフォルトの名無しさん
05/10/11 11:07:21
ドキュメンテーションを書くときは常に例を書き込むとかなりグー。
PHPのドキュメンテーションなんていい例じゃないかな。
使い方系のドキュメンテーションはシナリオ書いとく。

ところで、結局Wiki立てても書くのは結局一人だけだよなぁ。
でもみんなで書くという機能よりも手軽にどこからでも書けるというのが気に入ってる。
使いこなすとかなり快適。あとはVISIOでちょっと図を描いて終了。


293:デフォルトの名無しさん
05/10/27 03:40:16
確かにリファレンスとかは、
動作例ある方が読みやすいもんな。

つーか動作例無いと、リファレンスに見えないというか。

294:デフォルトの名無しさん
05/11/01 01:47:40
ドキュメントなんか書いてる暇があったらソースを書け。

295:デフォルトの名無しさん
05/11/06 15:48:48
概要仕様はワープロソフトできっちり作るな。納品しやすいし。
細かい仕様はソースにコメント埋めまくり。

ワードとかUNIX使いこなせない香具師はスキル低いだけ。

何か一つだけしか覚えられない香具師がエクセル使っている感が有るな。
自由紙、原稿用紙、レポート用紙、方眼用紙っていろいろあるけど、どれか一つ選べって状態で方眼紙選んじゃってるだけだ。
レポート用紙にグラフも書けるのにさ。

296:デフォルトの名無しさん
05/11/11 16:36:53
どのソフトを使うかなんか関係ないって。中身ですよ中身。
つーか、こんだけソフト開発が行われてるんだから、もちっとドキュメント作成技術も洗練されていてくると思うんだけどな~。
どこのプロジェクト行っても、読まれない&読んでも意味ないドキュメントばっか。
新規で起こす時も役にたたねぇだろうなーと思いつつ作ってるし。

それともオレが知らないだけで、既に良いツールor作成理論とかあったりするの?
もしあったら教えてエロイひと

297:デフォルトの名無しさん
05/11/11 22:53:22
>>296
コツを教えてあげるよ

自分が欲しいと思えるドキュメントを作ればいいよ
役に立つように作るべし
役に立たないと思った個所はどんどん削除

298:デフォルトの名無しさん
05/11/11 22:55:25
あと、起承転結では読みづらいので 起結承転 を心がけること

299:デフォルトの名無しさん
05/11/11 23:11:01
正直「転」はいらん。

300:デフォルトの名無しさん
05/11/11 23:23:41
統合設計書作成アプリケーション作って。
普通のアプリでWikiっぽい機能+Wordの章番管理+Excelみたいな表が
自由に作れる幹事で

301:デフォルトの名無しさん
05/11/12 08:19:16
転ってアレか。

この関数は○○の機能を持つ <- 起結
ただし、××の副作用を持つ <- 承転

302:デフォルトの名無しさん
05/11/12 17:11:51
さすがにtxtを推奨する奴はいないようだ。

303:296
05/11/14 09:43:53
いや、ドキュメント書けないわけじゃないないけどね。
この業界、結局ウォーターフォール型がほとんどじゃない?
だったら 要求>仕様>設計>試験 ぐらいのテンプレートとか支援ツールあってもいいんじゃねーかなと思って。
それに有名な規格ができたら、顧客の理解度、満足度ももっと高くならないかなぁ。とか
(Rational Rose とかは勘弁な。”UML図”だけじゃレビュー通らないし)

あと変に思うのは設計書。実装イメージをそのまま文書にしたのをよく見かけるけど、設計書は利用者ガイドであるべきだと思うんだ。
あの高いソフト買うと付いてくる大量のマニュアル郡みたいに、コンセプト、概要、実装サンプル、注意点、とか。
設計者が変わりに文書で実装しても意味ないっしょ。

あ~ぐだぐだと駄文書いてスマヌ

304:デフォルトの名無しさん
05/11/14 10:41:15
俺もそう思う。
納品物としての仕様書なんかいらん。読んでくれないし。
きっちり書いたユーザーマニュアル納品すれば一番ブレがない。
要求は全てそこに落とせばいいんじゃないかなあと。
だからマニュアルといっても画面の説明だけじゃなくて
半分業務マニュアルって感じ。

所謂仕様書らしい仕様書は、
お客さんにガッチガチの情シスがあって
そこが出せっていうんだったら書くよ、って感じで
いいんじゃないでしょうか。

なんか仕様書とあまり変わらないか。
でも言葉とかフォーマットとか、もっとお客さんに優しい感じ。

305:デフォルトの名無しさん
05/11/14 13:50:36
納品物としての仕様書は、
質重視ではなく量重視だな。

306:デフォルトの名無しさん
05/11/14 15:40:39
すると普通の仕様書より表現が冗長になりそうな
マニュアルでの納品がやっぱいいな
スクリーンショットわんさかで

307:デフォルトの名無しさん
05/11/14 21:10:06
>>301
そんな感じ
注意事項

308:デフォルトの名無しさん
05/11/15 01:24:59
>>306
マニュアル + クラス仕様書(自動生成したもの) が最強。
そして両面印刷なんてもってのほか。

309:デフォルトの名無しさん
05/11/29 03:00:58
>>254
亀レスすまそ。

よくExcelのセルを方眼紙みたい(正方形)にする人がいるんだけど、
あれって何が便利であんなセルにしちゃうわけ?
レイアウトしやすいってだけ?

310:デフォルトの名無しさん
05/11/29 10:04:30
本当に方眼紙に仕様書を書いてた名残らしい。
あと、インデントしやすいからといってた。

311:309
05/11/30 18:12:53
>>310
方眼紙ってそのまんまかいなw

312:デフォルトの名無しさん
05/12/31 19:33:11
doxygen 1.4.6 age

313:デフォルトの名無しさん
05/12/31 20:00:13
wiki風の装飾付きtxtを書いて、自前ツール通してhtmlにしてるな。
リンクやレイアウトが簡単だし、ブラウザは誰でも入ってるから。

314:デフォルトの名無しさん
06/01/25 17:59:27
doxygenのマニュアル読んでも、「使わねー」とか「ソース汚なくなるだけー」
みたいなコマンド(キーワードや記法)が多いと思ったんだけど、どう?
おまいらのdoxygenボキャブラリーはどんなもんよ?


315:デフォルトの名無しさん
06/01/25 22:45:51
file brief author
pre post param return retval
後メンバグループにname { }

316:デフォルトの名無しさん
06/01/27 09:26:58
>>315
それだけあれば、ひととおりの仕様は説明できそうだよね。
「意見」なんかを入れはじめるとややこしくなるんだよね。

317:デフォルトの名無しさん
06/02/25 02:38:32
ドキュメントが書けないやつは自分の頭でわかってないからだ。
自分ではわかってるけど説明するのが下手というやつは、自分でも
わかってない。それは直感と連想能力とヒントでピントでプログラミング
してるだけだ。

318:デフォルトの名無しさん
06/02/25 11:59:02
16分割の最初の2枚ぐらいでわかっちゃうようなやつには
ドキュメント作成なんてまだるっこしくってやってられんのだろうな。
馬鹿の気持ちが分からないから、標準からはずれたのを作成してしまう。

医者なんかでもそうだけど、臨床とかエンドユーザーが絡む作業は
あんまり頭が切れるヤツは向いてなくて、
ちょっと馬鹿だけどそれを自覚して慎重・着実に作業する
ヤツの方が向いてる。

319:デフォルトの名無しさん
06/03/04 02:25:09
ソフトウェア開発の世界標準フォーマットみたいなもの無いかな
各工程で何の文書が必要で、どのような項目を記載するものだ、みたいな

320:デフォルトの名無しさん
06/03/32 17:58:17
UMLって客に見せても実際は理解してもらえない。
客側に上級シスアドみたいなのがいれば話は別だが、現在ではそんな状況はあまりない。
結局UMLで書くってのは設計者のオナニーなんだなと思う。
なにしろUML試験なんかあるくらいだから、コンピュータど素人のお客にわかりやすいわけがない。

ところでXP開発におけるドキュメントの生成の仕方ってどうしてる?
うちは要件定義書が文章じゃなくて業務フローのの図だけなんだが。
そんなのが入力では詳細設計書なんて書けないぜ。


321:デフォルトの名無しさん
06/03/32 18:31:53
UMLは客に理解してもらうためのもの、
なんて言ってる人はあなた以外に見たことありませんけどw

自分が勝手に銀の弾丸を求めてるだけでしょ?
銀の弾丸がきっとあるに違いないと無意識に思ってるから
ネジ廻しがネジを締めることにしか使えないことに苛立つんだよ。

322:デフォルトの名無しさん
06/03/32 18:57:02
>UMLは客に理解してもらうためのもの、
>なんて言ってる人はあなた以外に見たことありませんけどw

見聞が狭いんだね。俺は何人か知ってるよ。
見たこともない、とは重傷だな。


323:デフォルトの名無しさん
06/03/32 20:35:16
ダメなドキュメントってあるよね。当たり前のことしか書いてなくて、
ポイントが抑えられてないような。
UMLだろうがワードだろうが、同じ人間が書く限りダメなドキュメントなのは変わらないのが現実

324:デフォルトの名無しさん
06/03/32 23:02:48
ドキュンメント

325:デフォルトの名無しさん
06/04/09 00:06:13
みんなはdoxygenでコメント書くとき
Qtスタイルにしてます?JavaDocスタイルにしてます?

326:デフォルトの名無しさん
06/04/09 17:17:32
JavaDoc スタイル。
Qt ってマイナーだし Qt にするメリットってあるの?

327:デフォルトの名無しさん
06/04/09 20:37:45
>>320
むつかしく書きすぎ、細かく書きすぎ
なんじゃないの?

328:デフォルトの名無しさん
06/04/09 21:42:04
言われてみればそうだよな…・。
伝えるだけなら、
紙に手書きしてコピったりスキャナで取り込むなりの方が遥かに敏速。

329:デフォルトの名無しさん
06/04/10 03:00:04
>>319
それこそ本屋にいけば山ほどその手の本があるやん。
成果物が一番はっきり明示されているのはラショナル統一プロセス
じゃないの。ISO9001なんかを取得している会社なら社内標準で
成果物が設定されているでしょ。

>>320
オブジェクト指向言語で開発しているなら、それとの親和性の
高さという点から、内部設計はUMLでするのはいい。けど、
要求仕様をユースケースなんかで顧客に見せるやつの気が知れない。
というかそういうやついるのか?俺はずっと前からアンチユース
ケース派でそういうことばっかり言っているけど。

330:329
06/04/10 03:02:49
>>319
それと追記するけど、どんな職場や環境、メンバーのスキルに
合致した魔法の世界標準フォーマットは存在するわけがない。

それぞれに合致したものはそれぞれが苦労して考えるしかない。
参考にするのはいいけど、巷に出回っている開発プロセスを
そのままやろうとすると失敗するよ。


331:デフォルトの名無しさん
06/04/18 15:12:14
質問。

仕様書だけ書いて、それを
ベクターみたいに、アップロードして
みんなに見せるサイトって、どこかある?

332:デフォルトの名無しさん
06/04/18 15:15:33
参考。仕様書相互リンク

良いドキュメント・マニュアル・仕様書を書くスレ
スレリンク(tech板)

小規模開発では仕様書は作るだけ無駄
スレリンク(prog板)

AJAX時代の仕様書とは
スレリンク(tech板)

営業が作った仕様書に
スレリンク(prog板)

良い仕様書、悪い仕様書、普通の仕様書
スレリンク(prog板)

プログラマ経験がないのに仕様書を作成
スレリンク(prog板)

仕様書の量でしか成果を決められない客
スレリンク(prog板)

Excelで仕様書を作る会社の奴の数→
スレリンク(prog板)

333:デフォルトの名無しさん
06/04/19 02:18:12
Doxygenの質問はここでいいのかな…?

HIDE_UNDOC系のタグをYESにしててドキュメント付けした要素だけ
書き出してるんだけど(もちろんEXTRACT_ALLはNO)
\fnとか一行コメントとか付けてない関数を強制的にドキュメントに含めてよ!
って指示するコマンドありますか?

今は全角空白の一行コメント付けて無理やり出してるんだけど
リスト表示のとこで無駄に下に空白ができちゃってみづらいんです
(同じページに列挙したいけどわざわざコメント付けしたくない関数ってのがいっぱいある)

334:sage
06/04/28 11:10:03
コーディングは製造であって、
その前に設計仕様書があるべきだと思うんですが、
DoxygenやJavaDocで出したものを、仕様書にするってことは
それ以前にモジュール設計仕様書とか無いままコーディング
してるんでしょうか?


335:デフォルトの名無しさん
06/04/28 12:19:21
中身ダミーで関数名と Doxygen 形式の仕様コメントだけ入れた骨組みをもって設計仕様ではダメなの?

336:デフォルトの名無しさん
06/04/28 13:07:44
で、実際んな事やってんの?って話だろ

337:sage
06/04/28 13:21:18
>>336
そりゃ、設計代もらってるんだからやりますよ
フリーソフトウェアの開発者とかなら話は別ですが…


338:デフォルトの名無しさん
06/04/28 13:55:57 BE:162918959-
鉄面皮で四角四面のウォーターフォール うぜぇ

339:デフォルトの名無しさん
06/04/28 17:09:48
>>334
>コーディングは製造であって、

違います。
- コーディングは設計作業です
- ソースコードは設計成果物です
- コンパイル・リンクなどが製造工程になります

340:デフォルトの名無しさん
06/04/28 17:25:01
不正確でつまんない比喩なんてどうでもいいよ。


341:デフォルトの名無しさん
06/04/28 21:56:05
>>339
幸せだなぁ…
そう思ってるうちはコーダーから卒業できんよ

342:デフォルトの名無しさん
06/04/28 22:45:00
東芝とか日立とかの大手が集まって仕様書の標準作るらしいね。
2007年をめどに完成予定とか。
どうなるのかな?

343:デフォルトの名無しさん
06/04/29 04:30:26
実行されたプログラムの動作こそが製造だ。
コーディングは、ラインの設計だ。

344:デフォルトの名無しさん
06/04/29 10:24:49
不正確でつまんない比喩なんてどうでもいいよ。


345:デフォルトの名無しさん
06/04/29 21:31:40
コードコンプリートの
メタファの章はよくまとまってるよ

346:デフォルトの名無しさん
06/05/01 20:45:13
Doxygenを実際使ってるプロジェクトってある?
俺は個人的にちまちまいじってるぐらいです。

みんなに使ってもらうにはやはり雛形を作成するしかないけど
どんなのがいいのか思案中。

なにかサンプルと成るものってあります?

347:デフォルトの名無しさん
06/05/01 20:49:42
>>346
Doxygen 自体
libstdc++
Subversion

いっぱいあるよ。
っていうか、雛形なんか要らないと思うけど。

348:デフォルトの名無しさん
06/05/01 20:54:11
Doxygenで悩むのがテンプレート定義しかないヘッダファイルへのコメント
そりゃヘッダに実装も書いてあるんだからそこにコメント付けるのが自然かもしれんが
各テンプレートの間にミッチりコメントが詰まってソースコードとして読みづらくなる(困

こういうときってコメントだけの空cppファイルとか作るんですかね?

349:デフォルトの名無しさん
06/05/01 20:58:42
>>348
Doxygen とか関係なしに、コメント書きすぎなんじゃね?
もしくはコメント書かざるをえない設計とか?

350:デフォルトの名無しさん
06/05/01 22:23:54
>>349
書きすぎってのはあるかも試練…
対象ユーザーのC++理解度が低い前提で書いてるんで
どう使ったらいいかのコード例みたいのもコメントに含んでるんだけど
やりすぎかね

@defgroup してモジュールの説明とか書き始めるともうコメントだらけですよ

351:デフォルトの名無しさん
06/05/02 16:26:03
サンプルみたいなものが書いてあるならそれはコメントとは呼ばないよ

352:デフォルトの名無しさん
06/05/05 14:12:41
doxygenだと__declspec(property)とかがメソッドとして認識されちまう。
なんかうまい方法ある?
っつーかこんなん使うなって話になりそうな気もするけど

353:デフォルトの名無しさん
06/05/06 13:39:38
>>352
プリプロセッサで消せば?
こんな感じで。
#ifndef __MSC_VER
 #define __declspec(arg) /* ignore */
#endif

354:デフォルトの名無しさん
06/05/11 01:18:44
おぉ?
URLリンク(www.doxygen.jp)

355:デフォルトの名無しさん
06/06/11 22:16:55
Doxygen 1.4.7 age

356:デフォルトの名無しさん
06/06/14 14:33:53
ちょっと見やすくなったね>1.4.7

357:デフォルトの名無しさん
06/06/22 09:09:28
1.4.7 で dot を使おうとすると FreeSans.ttf が見つからんエラーになるなorz
まあ、すでに bugzilla に報告済みだから次のバージョンでは何らかの対策がされることを
期待するが。

358:デフォルトの名無しさん
06/06/22 10:13:30
【佐賀】サムスンSDS開発のシステム不具合で市が課税ミス 昨年度はSEがデータだけ修正して誤魔化した?
スレリンク(newsplus板)l50

佐賀市は19日、市税や住民票などを管理する市独自の基幹システムでプログラムエラーが
あり、国民健康保険税に課税ミスがあったと発表した。

この基幹システムは、旧市が韓国IT大手の「サムスンSDS」と約8億7千万円で共同開発し、
05年4月から運用を始めた。開始直後は約50人の同社員がエラーをチェックしていた。

市情報政策課は「昨年度もエラーはあったはずだが、データを手直ししただけで、プログラム
自体を修正しなかった可能性が高い」と話している。

359:デフォルトの名無しさん
06/06/29 23:09:03
URLリンク(www.atmarkit.co.jp)

360:デフォルトの名無しさん
06/07/16 19:06:32
doxygenで

/// @file test.hpp
/// @brief doxygenテスト

/// 加算
int add(int a, int b);

/// 加算
加算double add(double a, double b);

をドキュメント化すると最初のint add(int a, int b)しか載りません。
クラスのメンバ関数はオーバーロードしたものもドキュメントに載るのに。
何か方法はないでしょうか?

361:デフォルトの名無しさん
06/07/16 19:15:50
>>360
その 加算double ってのは何だ?

362:デフォルトの名無しさん
06/07/16 19:23:54
タイプミスです。すみません。

/// @file test.hpp
/// @brief doxygenテスト

/// 加算
int add(int a, int b);

/// 加算
double add(double a, double b);

363:デフォルトの名無しさん
06/07/24 11:03:53
.bat, .vbs, .rb等々どんなソースにも仕込める
簡単な書式のヘルプ作成ツールみたいなのないですか?

例えば.batなら

@echo off && goto enddoc
<title>mytool</title>
<description>なんか役に立つツール</description>
<parameters>
-h: このヘルプを表示
-v: verbose
</parameters>
:enddoc
...
メインの処理

とかやっといてフィルタかますとmytool.htmが生成されるとかそんな感じのもの

364:デフォルトの名無しさん
06/07/24 18:39:30
>>363
その程度だったら、
自分でRubyかPerlあたりでフィルタ作ればいいんじゃない?

上の例を借りると、

@echo off && goto enddoc
REM @XX_BRIEF <title>mytool</title>
REM @XX_BRIEF <description>なんか役に立つツール</description>
REM @XX_BRIEF <parameters>
REM @XX_BRIEF -h: このヘルプを表示
REM @XX_BRIEF -v: verbose
REM @XX_BRIEF </parameters>
:enddoc

とでもしておいて、
行中に@XX_BRIEF等の特定のキーワードが含まれるかチェック
→ キーワードの後ろから行末までの文字列を抽出
→ 必要に応じて文字列を整形し、特定のフォーマットに変換
→ ファイルに出力

という感じで。
ソースコード内の変数名やメソッド名を参照するようなことはできないけどね。

365:デフォルトの名無しさん
06/07/26 04:08:38
>>360, 362
1.4.7 で問題なく出力できた。

366:デフォルトの名無しさん
06/07/28 01:57:06
DQNメント

367:デフォルトの名無しさん
06/10/18 11:22:21
Doxygen 1.5.0 age

368:デフォルトの名無しさん
06/10/30 01:23:57
doxygen 使ってますが、
> Generating caller graph for function foo
という行で止まってしまいます。

いつも同じ関数の処理をしている時に止まるようです。
止まってしまう関数の処理を中断して先に進ませる方法はないでしょうか?



369:デフォルトの名無しさん
06/10/30 11:19:27
Doxygen 1.5.1 age

370:デフォルトの名無しさん
06/10/31 00:35:52
doxygenだと改行が無視されて
せっかく綺麗に作ったコメントがぐちゃぐちゃになるんだけど
なにか対策ある?

371:デフォルトの名無しさん
06/10/31 00:43:23
>>370
<pre></pre> でどう?
場合によっては何かもっと適切な対策があるかもしれないけど。

372:デフォルトの名無しさん
06/11/01 00:55:01
\n書くとか。
漏れはもう改行を気にするのはやめたけど。

373:デフォルトの名無しさん
06/11/01 13:48:26
>>370
doxygenの整形に任せるのが正解。
改行が必要なほど複雑な説明を長々とコメントに書いてはいけない。
補足説明とか引数別の説明とか例外のリストとかそういうのは
それようのタグがあるのでそれを使ってdoxygenに整形させる。

374:デフォルトの名無しさん
06/11/11 11:36:25
楽にドキュメントを書ける(・∀・)イイ!ツールすらないことがよくわかった。
おまいら今なら作れば売れるぞw

375:デフォルトの名無しさん
06/11/11 12:00:06
脳味噌にUSBケーブル接続して脳内仕様をダイレクトに出力できるデバイスが
発明されない限り、ドキュメント作成ツールのメガヒットはありえない。

376:デフォルトの名無しさん
06/11/11 13:26:33
えーそんなの出来たら
おっぱいとか満載になっちゃって大変そう。
雑念払う練習しないと。

377:デフォルトの名無しさん
07/01/08 23:42:18
ソースがドキュメントとか逝ってる人、勘弁してよ。
ちょっと不思議な動きしてるんですけど、
ソースのバグなんだか、仕様なんだか、わからないよ!

と、10年以上前に誰かが作ったソースをメンテさせられることになって
鬱状態の僕は思いました。5万行もあるよ。。

みんな、doxygen使ってるか!
ちゃんと、その関数が何やりたいのとかきちんと書いてな!
あとsunのJavadocみたいに、スレッドセーフかどうかとかも書いてあるとうれしいよ!

パッケージとかモジュールとか、ソースより大きい単位でも
doxygenってドキュメント書けるの?

>>374
買うから作って。

あけましておめでとう。

378:デフォルトの名無しさん
07/03/10 16:46:51
"要求定義"
"要件定義"

同じものを違う呼び方してるだけ?

379:デフォルトの名無しさん
07/03/10 17:25:20
>>378
レイヤーが違う
上位が要件、下位が要求

380:デフォルトの名無しさん
07/03/10 17:53:37
なるほど。
これらを区別していない書籍も多いと思ったのですが、
そんなことないでしょうか?

381:デフォルトの名無しさん
07/03/10 17:55:28
多いか少ないかなんて問題なのか?

382:デフォルトの名無しさん
07/03/10 18:40:21
学習者にとっては問題です。

それぞれ英語では何という語句にあたりますか?


383:デフォルトの名無しさん
07/03/10 20:30:09
>>382
要件はマターとかファクター
要求はリクエスト

384:デフォルトの名無しさん
07/03/10 20:52:38
requirement...

385:デフォルトの名無しさん
07/03/10 21:02:38
>>384
requestもrequireも語源は同じですよ

re(再び) + quaerere(ラテン語で求める)
再び求める ⇒ 要求、お願い

requireよりrequestの方が若干丁寧です

386:デフォルトの名無しさん
07/03/10 21:49:15
>>378
海外では"requirements definition"。
日本の計算機屋の言語感覚が鈍かったから、「要求」と「要件」がごっちゃになってる。
「要求」の方だけ覚えときな。

387:デフォルトの名無しさん
07/03/10 23:01:13
"要求"・・大学・研究機関で使われる
"要件"・・企業で使われる

だろ?

388:デフォルトの名無しさん
07/03/10 23:27:23
"要件"・・営業が使う

389:デフォルトの名無しさん
07/03/12 01:50:03
うーん。 難しいんですね。

レイヤーが違うというなら、
比喩的に、ボールペンの
要求定義、要件定義はどのようになるんでしょうか。

390:デフォルトの名無しさん
07/03/12 21:24:59
>>389

[要求]
先端は鋼などの硬球
運筆に応じて回転、軸内のインクが滲出


391:デフォルトの名無しさん
07/03/12 22:01:44
それは仕様じゃないの

392:こんなもんかな
07/03/13 10:29:20
仕様
速記に適し、それなりの耐久性を有すること。
ある程度の耐候性があればインクの種類は問わないが、掠れ難いこと。

393:デフォルトの名無しさん
07/03/13 10:52:47
[要求]
字が書けること

394:デフォルトの名無しさん
07/03/13 23:51:25
>>392
そっちのが要求じゃないの

あっこれマジレスってやつかっ?

395:デフォルトの名無しさん
07/03/14 00:16:56
「要件」は何?

396:デフォルトの名無しさん
07/03/14 00:48:48
要件定義書 ver0.00

- 普通紙に字が書けること
- インクの補充が容易であること
- 出来うる限りメンテナンスフリーであること

以上の要求を実現する筆記用具を開発することにより、ユーザーの利便性を高め
生産性の向上に(以下省略


>以上の要求を実現する筆記用具を開発することにより、ユーザーの利便性を高め
>生産性の向上に(以下省略
↑この辺が要件。

397:デフォルトの名無しさん
07/03/14 01:06:54
URLリンク(www.atmarkit.co.jp)

少なくとも日本IBMでは区別してるようだな。
IEEEでは単にSoftware/System Requirements Speciticationであって、
区別してないようだな。

398:デフォルトの名無しさん
07/03/14 01:19:00
俺もIだけど、要求しか使わないよ。
上の例で挙げられているような仕様書は、
今どきコボラーくらいしか書かないんじゃないかな。

399:デフォルトの名無しさん
07/03/14 04:30:05
要望と要求と要件は微妙に違うという意見もある

要望は客が単に思ってること
要求はシステム上不可欠なこと
要件は実装するシステム機能

ま、いちいち分類したところで、結局ドキュメントを書かないもれには関係ない話だw

400:デフォルトの名無しさん
07/03/15 00:34:54
要件とは顧客の要望や要求を日本語に文章化したものではないかと思います。。。

その意味じゃ>>396の言ってる事がしっくりくるw

401:デフォルトの名無しさん
07/03/15 17:05:37
management textでいうプロジェクトリーダーの理解=要件
ってこと?

402:デフォルトの名無しさん
07/03/18 15:15:13
プログラム単体レベルで考えると、破綻する。
システム全体を見据え、ドキュメントを体系化すべし。
富士通だと、SDAS
URLリンク(img.jp.fujitsu.com)

NEC、日立も似たようなもん持ってる。(どれが良いとかはシラン)
孫会社、下請けは知らないかもしれないが、本尊の動きくらい知っときなょ。

403:デフォルトの名無しさん
07/03/18 21:26:20
俺の考えは、

マニュアル → 専門のテクニカルライターを使う
設計書   → システム全体が見渡せるもの/外部仕様はしっかり書く。
        内部仕様はほどほど。(結局ソースが正になるから)

ドキュメントが無いソフトは糞とかいうけど、
ドキュメントが無いと保守できないソフトこそ糞だと思う今日この頃だよ。


404:デフォルトの名無しさん
07/03/18 23:12:23
全体の概要とか外部仕様、内部仕様を区別せず、
一口にドキュメントの是非を問うから議論が分かれる気が。

>>403 が言うとおり、
システム全体像・外部仕様はしっかり、
内部仕様はソースが正、doxygen とかで自動生成
って言えば、あんまり反対する人いないと思うんだけど。

405:デフォルトの名無しさん
07/03/18 23:15:45
マーケティング部門向けの仕様書って
開発用と別に書いて渡してますか?

406:デフォルトの名無しさん
07/03/19 00:49:55
>>404
内部仕様書でも、分業単位の分まではきっしり作っておこう

407:デフォルトの名無しさん
07/03/19 04:40:13
>>403
上場企業だと、内部統制の関係で全てキッチリ必要

408:デフォルトの名無しさん
07/03/27 23:59:41
unmanagedとmanagedのコードが混在したアセンブリのドキュメントってdoxygenで出力できますか?
CVSに入ってるdoxygenだとCPP_CLI_SUPPORTという設定が使えるみたいなんだけど

409:デフォルトの名無しさん
07/03/28 09:19:09
>>407
上場企業というより、メーカー系の企業だな。
やつらは工場で作るものとソフトウェアを同じ体系にまとめようとするからムリがある。
上場企業でもソフトハウス系はそんなことない。

410:デフォルトの名無しさん
07/03/28 12:50:41
>>409
でも、工場で作るものと同じ仕様で仕様書を作っておくと
何年後でも開発者が死んだあとでもメンテが出来たりするので
あなどれないんだよな

411:デフォルトの名無しさん
07/03/28 18:55:58
小さな会社が手がけるレベルの開発じゃそこまでライフサイクル長くない…

412:デフォルトの名無しさん
07/03/29 09:16:07
あって役にたつのは、外部仕様書と内部実装の理解を助けるための簡単なドキュメントだな。
それ以上細かい内部仕様書は糞。
思うに、本当の内部仕様書ってのはソースコード自身だと思う。

413:デフォルトの名無しさん
07/03/29 11:35:18
>>412
それじゃ バグがあっても仕様通り ぢゃあないか

414:デフォルトの名無しさん
07/03/29 11:50:55
そうそう、大抵納品後数年経ってから発覚するような(必ずしもバグでない)不具合があったときに
一番役立つのがソースコードとソース内にきちんと書かれたコメントなんだよね。
尤も、それらがきちんと書かれていないコードに限って後から不具合が露見するんだが。
で、ついでに言えばそういうプロジェクトは大抵仕様書に仕様変更がきちんと反映されていないから仕様書は手掛かりにしからない罠。

415:デフォルトの名無しさん
07/03/29 12:14:21
勝手に転載

979 名前: デフォルトの名無しさん [sage] 投稿日: 2007/03/29(木) 10:14:13
処理Aの仕様書
・・・Aを実行する。

1行きたー。どうしよう。

416:デフォルトの名無しさん
07/03/29 23:41:27
良いDQNなんていません

417:デフォルトの名無しさん
07/04/05 13:28:09
Doxygen 1.5.2 age

UTF-8 キタ

418:デフォルトの名無しさん
07/04/14 22:07:50
要件定義書とか設計書とかのフォーマットはダウンロードできるとこありますか?
書籍でも良いです

419:デフォルトの名無しさん
07/04/14 22:33:19
RFP本とUML設計本くらいしか知らない。

実務資料はふつープロジェクト外秘や社外秘だから
必要なら会社で見せてもらえ


420:デフォルトの名無しさん
07/04/14 22:35:59
ためしに 設計書 フォーマット でググったら、
見覚えあるプロジェクトの公開資料が出てきてびっくらこいたw

421:デフォルトの名無しさん
07/05/16 01:23:38
スレ違いかもしれませんがdoxygen使いの方が
多そうでしたので質問させてください。

WinXPProSP1 VB6.0で開発を行っており、
このVBのソースをdoxygenに出力させたいのですが、
どなたか方法をご存知の方はいらっしゃらないでしょうか?

ネットを漁りvbfilterを使用し、tee.exe/gawk.exe/sh.exeも必要との事でインストールし、
input-filterに 「C:\vbfiltervbfilter.bat C:vbfilter\tools」と入力し
なんとか変数一覧やメソッド一覧等が出力されるようになったのですが、
コメント部分の文字が化けてしまいます。

VBのソースがshift-jisで書かれておりdoxygenのinput-encodingが
UTF-8になっておりましたので、nfk.exeもインストールしdoxygenのinput-filterに
「C:\vbfiltervbfilter.bat C:vbfilter\tools|"nfk -w"」
としてみたのですがうまく変換されません。
(nfk単体で確認した所うまくshift-jis→utf-8変換処理は動作しておりました。)
恐らくdoxygenのinput-filter辺りでうまくパイプ処理が使えていないのが
原因だと思います。
4~5時間ほど試してみたのですが自分の力では解決できず
書き込みに至った次第です。

説明不足も多々有ると思いますがどなたか
方法をご存知の方がいらっしゃいましたらご教授のほどよろしくお願い致します。

422:デフォルトの名無しさん
07/05/16 06:57:14
>>421
ソースが shift-jis だってんなら INPUT_ENCODING=Shift_JIS だろ。

423:デフォルトの名無しさん
07/05/16 10:48:18
手元のDoxyfileにはinput-encodingなんてないのだが。
で、input_filter="iconv -f eucjp -t cp932"、use_windows_encodig=yes、output_language=japaneseで使ってるが。
#doxygenはcygwinので、バージョンは1.5.1。

424:デフォルトの名無しさん
07/05/16 11:15:06
INPUT_ENCODING は 1.5.2 で追加されてる。
VB 使いが言う shif-jis は cp932 が正解だろうな。

425:423
07/05/16 11:21:47
>>424
情報THX。ちょっとリビジョン上げてくるわ。

426:423
07/05/16 11:50:37
がーん、未だcygwin版がリリースされてなかったw
#RedHatNetworkは1.3.9.1のままだし。

今回(1.5.2)の変更点はUTF-8対応のほか、C++/CLI対応だとか随分Win使い寄りのような。
件のinput_encodigやdoxyfile_encodingが追加されたと同時にuse_windows_encodingが無くなったようなので、
私のところでは進行中のプロジェクトのDoxyfileをいくつか修正する必要がありそうです。
#逆に、rtfとtexのencodingをわざわざ変えなくて済むようになるなら嬉しいけれど。

427:デフォルトの名無しさん
07/05/16 23:22:19
1.5.1 と 1.5.2 の間で互換性を失ってるのは甚だ遺憾。

428:421
07/05/17 02:03:27
会社から書き込めないので遅くなりましたが、
>>422様の仰るとおり
INPUT_ENCODING=Shift_JIS
input-encoding=C:\vbfiltervbfilter.bat C:vbfilter\tools
にして見た所VBのソースが文字化けせず正常に出力される事が確認できました。
ありがとうございました。

と言うかこんな事に気付かない俺ってダメすぎですorz
的確な突っ込みありがとうございました。

429:デフォルトの名無しさん
07/05/17 10:27:21
つーか、それでも書き間違える(写し間違える)辺りがなんとも。

430:デフォルトの名無しさん
07/06/21 11:08:45
今まで特にコメントのスタイルとか自分では決めず
コメントを書いてきたんだけど、やっぱりそれじゃ
後から見てばらばらで気持ち悪いので、何らかの
ドキュメント自動生成ツールに従った形で書こうと思っています。
doxygen / javadoc / phpdocumentor などのツールが
あるようですが、書式はそれぞれ異なるんですよね?

スレタイに doxygen / javadoc / phpdocumentor とかの文字列が
なかったから検索に手間取っちゃったよ・・・

431:デフォルトの名無しさん
07/06/25 10:46:20
DoxygenにはJavadoc互換モードがあるからどっちかにあわせておけばいいんじゃない?
#phpのは知らない。

432:デフォルトの名無しさん
07/06/25 12:22:53
>>430
その3つなら、PHPとJava使うときはそれぞれの、他はDoxygenでいいんじゃね。

433:デフォルトの名無しさん
07/06/25 20:30:05
sandcastleでC++用のものも作れるんでしょうか?

434:デフォルトの名無しさん
07/07/06 01:22:50
doxygen(Ver1.5.2)とHTML Help Workshopを使って、
Windowsヘルプを 作成しているのですが、索引が
どうしても文字化けしてしまいます。
INPUT_ENCODING = Shift-JIS
DOXYFILE_ENCODING =UTF-8
と設定し、ページに関しては文字化けは解消された
のですが… 何か解決策があれば教えてください

435:デフォルトの名無しさん
07/07/28 08:38:52
doxygen 1.5.3 age

436:デフォルトの名無しさん
07/08/12 01:05:32
>>430
doxygen ではよくこの書き方が紹介されているが、個人的にあまりおすすめしない。
/*!
@brief メソッドの説明
@param p 引数の説明
@return 戻り値の説明
*/
・複数行コメントは一括コメントアウトの邪魔になるから
・実コードで引数が変更になると Doxygen の内容も変更しなくちゃいけなくなるから
 (つまりコードと Doxygen の2重管理になる)

437:436
07/08/12 01:08:05
じゃあどうやるかというと

//! @brief メソッドの説明
//! @return 戻り値の説明
void hoge(
p //!< p の説明
)
{ ... }

438:デフォルトの名無しさん
07/08/12 01:46:25
Doxygenは警告吐くんだからちゃんとチェックすりゃいいやん。
>437のやり方だってコードとコメント両方メンテすんのはかわらん。多少近くなるが。
あと長い説明を入れにくくなるな。

439:437
07/08/12 01:55:50
>>438
> あと長い説明を入れにくくなるな。
う゛、鋭いな。

440:439
07/08/12 01:56:36
重ね重ねすまん、間違えて age てしまった

441:デフォルトの名無しさん
07/08/12 02:30:53
おれが昔立てたスレが上がってるな。

おまえら、ドキュメントなんて書きたくなきゃ書かんでいいぞ。
例えばWindowsにはヘルプがあるだろう。
けど、WindowsのGUIは洗練されてるから、あんなの読まなくても判るよな。
判らん奴もいるが、どうせそいつらはヘルプの読み方すら判らんアホだし、
付き合うだけ無駄だろう、と。こういった無茶な主張も今や世間が味方だ。
つまりウィンドウの操作なんて、もはや一般常識なのだ。凄い時代になった。
この概念を突き進めていけば、ユーザーはプログラムの画面を見れば、
何をすべきなのか判るという事だ。洗練されたGUIによって、プログラムと、
ドキュメントは融合を果たしたわけだ。
画面見て使い方が判らないプログラムはゴミと同じ。(これはGNU製に多い)
いや、むしろ今の時代は判らないとのたまう人間の方が、立場は下なのだ。
「ドキュメント見なくても判ります」
おまえら、この言葉を吐く自信はあるか?

442:デフォルトの名無しさん
07/08/12 02:56:38
>>441
GNU の作った GUI 製品って、何かあったっけ?

443:デフォルトの名無しさん
07/08/12 04:59:50
>>441
> WindowsのGUIは洗練されてるから

笑うところですか?

444:デフォルトの名無しさん
07/08/12 05:11:08
いちいち人に聞かないと笑うところも判らない、と。

445:デフォルトの名無しさん
07/08/12 13:51:49
>>437
void hoge( //! @return 戻り値の説明
ついでにここまでやろう

446:デフォルトの名無しさん
07/08/12 13:53:32
>>441
どこ立て読み?

447:デフォルトの名無しさん
07/08/12 16:57:19
>>442
GTK+

448:デフォルトの名無しさん
07/08/12 17:46:54
>>447
それは GUI 製品とは言わんだろ。

画面見ただけで GTK+ の使い方がわかったら神だな。

449:デフォルトの名無しさん
07/08/12 21:34:45
Glade
Sylpheed

450:デフォルトの名無しさん
07/08/12 22:09:55
>>449
そいつらは GPL でライセンスされてるだけで GNU 製とは言わんのじゃないか?

もしかして >>1>>441 の言ってる GNU 製ってのは GPL でライセンスされてる
製品ってこと?それなら作者もバラバラなはずだから、ただの偏見だね。

451:デフォルトの名無しさん
07/08/12 22:44:33
>>441
見ただけで処理がわかるとか
どんだけ紙プログラマなのw
ユーザがそんなに凄けりゃ俺たち要らない子だよね(・ω・

452:デフォルトの名無しさん
07/08/12 22:49:21
GNU製ってったらGIMPは?
あれはフォトショのコピーUIな気もするが。


453:デフォルトの名無しさん
07/08/12 23:10:29
つってもGIMPがもとでGTKが生まれたわけだが
今更Cでオブジェクト指向ゴッコかよ
と思わないでもない

454:デフォルトの名無しさん
07/08/12 23:44:15
仮にライブラリのインターフェースをC++にしたとして、
使う人間の方にしわ寄せがくる。DLLにしたくてもABIの問題もあるし。
COMやQTは難解すぎる。
C++はプログラマのフロントエンドとしてのみ使うべきだろう。


455:デフォルトの名無しさん
07/08/12 23:49:25
GNUか忘れたけど、OpenGLなUNIXのライブラリで、
失敗すると勝手にexitやabortするアホなのがあった。
勝手に終わらすなや。straceなかったら死んでた。

456:デフォルトの名無しさん
07/08/13 01:11:07
wxD

457:デフォルトの名無しさん
07/08/13 12:02:32
話を戻そう。

>>436
>・複数行コメントは一括コメントアウトの邪魔になるから
一括コメントアウトってなに?

ソース管理の原則からは、不使用コードは#ifで囲ってしまうべきであり/* */や//は使うべきではない。
まして、基本的にリリース時には残さないべきなので、複数行コメントを忌避する理由はないと思う。

458:デフォルトの名無しさん
07/08/13 22:07:06
ソース「管理」の原則からは、ね。

でも実際に集中して作業してるときって /* */ 使わないか?
#if #endif より入力しやすいと思うんだが。
ついでに、古いコーディング規約が改定されずに使われる場合、
「VSS でチェックインするソースには原則として /**/ を含まないこと」
みたいな決まりが未だにまかり通る現場もあるんでは?(←ウチだけか?)

>> // は使うべきではない。
おまえんとこは1行コメントも #if なの?

459:デフォルトの名無しさん
07/08/13 22:11:15
>>458
/**/を使ってはならないという規則で/**/でコメントアウトするのは
ナンセンスな気がするが……
もっと言うと、/**/でコメントアウトするときに障害になるから
/**/を使うなということか

あまりにナンセンスすぎて意味がよくわからないな

460:デフォルトの名無しさん
07/08/13 22:24:42
>>459
こんな些細なネタで話を伸ばしたくないんだが。

/**/ は作業中のみ一時的な目的に使うべし、
チームメンバーに公開するソースからは /**/ 無くすべし、
当然使わないコードは消すべし、
一時的に残すなら #if ~ #endif を使うべし。
ということでまぁ折り合いがついてる。

それより、
>> // は使うべきではない。
> おまえんとこは1行コメントも #if なの?
についての解答が欲しい。あんまりコメント書かない習慣ってことか?

461:459
07/08/13 22:34:47
>>460
俺は上の人とは違う(はじめて書き込んだ)ので、上での話を
俺に聞かれても知らん。
俺のことを言えば、//を禁じるのも/**/を禁じるのもナンセンスにしか
思えない。

462:デフォルトの名無しさん
07/08/13 22:42:06
>>461
人違いスマソ
大人しく 457 からの回答を待つよ

463:デフォルトの名無しさん
07/08/14 00:37:35
457ではないけど、コードの無効化に//を使うなって事じゃない?
//f(a, // aのコメント
//b, // bのコメント
//c) {// cのコメント
//}

/*
f(a, // aのコメント
b, // bのコメント
c) {// cのコメント
}
*/
↑つまりこんなことするなって?(こんなことするか?)

#if 0
f(a,b,c) {
}
#endif

>>458
/* */て右手だけでシフト押したりするから入力しづらくね?
手前のキー使うから爪切ってないと辛い
#if 0
#endifのが気持ち早い


464:458
07/08/14 00:58:23
>>463
が紹介したような使い方は稀だけど、無効化した理由を添えることはあるだろう。

// int i = func();
int i = func2();
// ↑×××により○○○に変更。

/* */ の入力にシフトは使わん。テンキーについてるやつを使う。

465:デフォルトの名無しさん
07/08/14 02:00:54
#if で無効化しておいて理由をコメントで添えずにコミットすることを禁止すべきだろう。

466:458
07/08/14 10:24:32
㌧ なるほど

467:457
07/08/14 11:04:13
>ソース管理の原則からは、不使用コードは#ifで囲ってしまうべきであり/* */や//は使うべきではない。
読み難かったかな。
不使用コードをコメントアウトする目的で、/* */や//は使うべきではないということね。
その目的で//を使うと、例えばリリース前に消したくても通常のコメントと区別がつきにくいので消し損ねかねない。
#ifならgrepでの検出も簡単だろう。

って、>465が書いているね。更には、リビジョン管理しているなら残すべき理由もないはずだが。

468:デフォルトの名無しさん
07/08/14 22:41:53
a = b;
/*
c = d;
*/
e = f;

↑こうなってるときに

/*
a = b;
/*
c = d;
*/
e = f;
*/

↑あとからこんなことする馬鹿がいるからじゃね?

469:デフォルトの名無しさん
07/08/15 03:51:34
>>468
誰に向けて書いたのか知らないがそれはコンパイルエラーだから論外

470:デフォルトの名無しさん
07/08/18 03:26:18
>>468程度でも見難いと思う程度の脳味噌ですが…

471:デフォルトの名無しさん
07/08/22 00:13:17
/* */ とか #if #endif でコメントアウトされてると、grepでコードを引っかけたときに、
それが使われているコードなのかコメント化されているコードなのかがgrepの結果からだけでは分からない。
てなわけでうちでは // だけ使うことになってる。

472:デフォルトの名無しさん
07/08/22 11:30:55
>>471
だからこそ、リリース版のソースにコメントアウトされたコードを残してはいけないのです。

473:デフォルトの名無しさん
07/08/23 01:19:20
当社では、コードを修正する際に修正前のコードをコメントアウトしてソースに残しておくことが
規則で定められてるんだけど、もしかしてレア?

474:デフォルトの名無しさん
07/08/23 01:22:00
SVNとかCVSとかは?

475:デフォルトの名無しさん
07/08/23 01:50:24
>>473
いや。よくある糞規則。

476:デフォルトの名無しさん
07/08/23 05:59:57
最悪だな

477:デフォルトの名無しさん
07/08/24 01:10:24
>>473ごく普通のことです…orzキタネー

478:デフォルトの名無しさん
07/08/24 10:56:27
まさか、コメントアウトされた行も含めて行数で金取ってたりしないよな。

479:デフォルトの名無しさん
07/08/24 11:33:09
行数で計算して金をとってる所なんてあるの?見たこと無い。COBOLとか?

480:デフォルトの名無しさん
07/08/24 11:46:27
>>479
Cでも未だあるらしいよ。

481:デフォルトの名無しさん
07/08/24 22:18:51
目安としてステップ数はなくても、n万行のコードって今でも言うでしょ。

482:デフォルトの名無しさん
07/08/24 22:45:51
言わない

483:デフォルトの名無しさん
07/08/25 14:35:46
某上場企業のシステムのリメイクを請け負ったけど
元のがループ使わずコピペでシコシコ行数稼いでいるプログラムがあった
マジで



484:デフォルトの名無しさん
07/09/03 22:19:04
>>479
F痛

485:デフォルトの名無しさん
07/09/04 07:28:56
テンプレートとかgenericsは敵だな。型の分だけ、コード増やせない。

486:デフォルトの名無しさん
07/10/27 18:26:59
Doxygen 1.5.4 age

487:デフォルトの名無しさん
07/10/28 13:23:14
よく、日本人は罫線をやたらと使いたがるって話があって、
たしかに、excelで、罫線使いまくったドキュメントって書くのが面倒なんだけど、
かといって、日本式のそういうドキュメントしか見たことないから、罫線なしで
かっこいいドキュメントというのが想像できません。

外国で使われてるドキュメントのサンプルみたいのを見れるところってありませんかね。

488:デフォルトの名無しさん
07/10/28 20:18:16
>>487
米のミドルウェアをいくつも使ったけど、そのへんのオープンソースのよりもショボい感じ。
オープンソースのをいくつも見ればいいと思うよ。

489:デフォルトの名無しさん
07/10/29 01:30:01
HTMLヘルプで十分て気がする
表示ソフトいらないし、ファイル1個で済むし
*NIXで見れない?
知 る か

490:デフォルトの名無しさん
07/10/29 02:08:39
>489
URLリンク(xchm.sourceforge.net)

491:デフォルトの名無しさん
07/10/29 12:29:28
>>487
罫線を使わないこととExcelを使わないことはイコールではないよ。
喩えて言えば、○×をやるのに周りを囲むか(囲こんな形)か、囲まないか(井こんな形)の違い。

492:デフォルトの名無しさん
07/12/08 03:09:44
doxygenで更新履歴をいじった関数に書いて、
todoリストみたいにまとめたいなと思って調べたら、
\xrefitemを使えばオリジナルの\todoができることは、わかったのですが、
関連ページ追加される項目を日付ごとにまとめて並べること方法ないでしょうか?

493:492
07/12/10 02:14:40
以下のようにしてみました。

ALIASES += "history{1}=\xrefitem histories\1 \"更新履歴(\1)\" \"更新履歴(\1)\""

日付でソートできていないし、日付ごとに別ファイルになってしまいます。orz
もっとよい方法は無いでしょうか?

494:デフォルトの名無しさん
07/12/30 02:14:53
ドキュメント管理が破たんしてる業務システムの保守をやってるんだが、

・機能ごとに、仕様書があったりなかったり
・管理がずさんで、どのファイルが本物の仕様書かわからなかったり
・仕様書が現状の実装と同期がとれてなさそうだったり

てな具合。
で、どうにかせにゃアカンってことで、取り急ぎコード修正・保守作業に
最低限必要なドキュメントだけ、リバースエンジニアリングして書き起こしてる
とこなんだが、作った後の維持管理って、みんなどんな感じでやってる?

495:デフォルトの名無しさん
07/12/30 11:15:07
ソースと同じくCVS管理

496:デフォルトの名無しさん
07/12/30 17:27:36
市役所の情報システム部門に勤務している人って居る?

497:デフォルトの名無しさん
08/01/02 20:27:53
市役所のシステム部門つっても、市職員がいる「○○市情報××課」みたいな
市役所ネイティブの部署と、運用を委託されてる会社の人が常駐している実務
部隊の2通り取り方があるわけだがどっち?


498:デフォルトの名無しさん
08/01/09 12:59:45
DOXYGENだが、1.5.2以降、内部ユニコード処理になって、入力ファイルと
出力ファイルのエンコード指定ができるようになっているのはいいんだ
けど、言語とエンコードの指定に関係なく生成されたHTMLのヘッダ部分
は、「charset=UTF-8"」なんだが、ガイシュツ?

ブラウザ側のエンコード自動識別のおかげでHTMLドキュメントはうまく
表示できるが、HTML Help CompilerでHTML Helpファイルに変換すると、
インデックス部分の日本語が化ける。


499:デフォルトの名無しさん
08/01/09 16:53:47
生成されたindex.hhcのエンコーディングをUTF-8からCP932(ShiftJIS)に変換して、
hhc.exe index.hhpでおk

500:498
08/01/09 19:45:11
>>499
それじゃあ、ツールを使って自動化する意味ないじゃん。

他にも、index.hhpでのフォント指定やら変で、特に1.5.x以降を使う
メリットが見当たらないので、結局1.4.7に戻した。1.4.7は、Japanese
選択しとくと、「charset="SHIFT_JIS"」になる。

HTML Help をコンパイルする前にフォントを変更しても、Doxygenで生成
されるソースコードのページのフォントが変なんだよね。どうもアルファ
ベット部分だけ、無条件にArialになってるっぽい。

501:499
08/01/10 02:54:40
自分はHTMLとPDFを生成できるようにnmake用のMakefile作って自動化してるんだが。
ツール側の対応に頼るのもいいけどさ。

502:デフォルトの名無しさん
08/01/10 06:10:22
すいません、あるWindowsアプリ(制御系)のドキュメントを
作成するよう指示がありました。
ちなみに開発環境はTurboC++。
C++の知識レベルは、入門書1冊読んだ程度。(アプリ開発経験なし)
Doxygen使ってみたのですが、Doxygen対応コメントで作成されてないので
クラス階層とか関数呼出などの図ではイメージできるのですが、
コメントがないので、やってることがさっぱりわかりません。
そういう場合は、やはり、ソース解読しながら、
Doxygen対応コメントをひたすら打ち込むことから始めるべき
なのでしょうか?


503:デフォルトの名無しさん
08/01/10 07:58:38
アプリのなんだからDoxygen関係ないじゃん


504:デフォルトの名無しさん
08/01/11 14:48:40
Doxygen用のコメントを作るには、ある程度解析が必要だから方針としては悪くないと思うよ。
でも、そこで要求されている「アプリのドキュメント」はDoxygenの出力でいいの?
通常はその括りだと基本仕様か機能仕様に類する資料が必要になってくると思うのだけど。

505:デフォルトの名無しさん
08/02/10 21:43:34
Doxygen 1.5.5 release age

506:デフォルトの名無しさん
08/02/11 11:45:18
Doxygen 1.5.6 release age

507:デフォルトの名無しさん
08/02/11 12:09:51
ちょっとまて
ここはDoxygenスレじゃないんだぜ

508:デフォルトの名無しさん
08/02/12 14:02:50
だからといってDoxygen等の各ツール専用スレを建てると
このスレもそのスレも今まで以上に過疎るからやめてほしいぜ

509:デフォルトの名無しさん
08/02/12 14:42:19
いや個々のツールの使い方はかなり無関係だろこのスレ

510:デフォルトの名無しさん
08/02/12 14:47:10
保守代わりってことでいいと思う

511:デフォルトの名無しさん
08/02/12 15:06:37
一ヶ月も放置されてたスレに、自分の意にそぐわないレスが二つ付いただけで
噛み付く奴って何なの?

512:デフォルトの名無しさん
08/02/12 15:33:25
問題は時系列ではなく内容である
「1ヶ月ぶりのレスだから何書いても許す」というほうが不条理

513:デフォルトの名無しさん
08/02/12 15:35:41
不条理もへったくれもないだろ。スレ違いと言うほど外れた内容じゃないんだから。
敢えて>509の言うように「個々のツールの使い方」は無関係だとしても、「個々のツールの情報」は無関係じゃないだろ。

514:デフォルトの名無しさん
08/02/12 15:46:47
>>512
何書いても許すなんて言ってないだろ、ボケ
「お前の意に沿わないレス」で噛み付くなって言ってんだ

515:デフォルトの名無しさん
08/02/12 16:05:15
お前の意に沿わない「お前の意に沿わないレス」へのレスに
噛み付くなともいへり。

516:デフォルトの名無しさん
08/02/12 16:06:10
すまん、あまり面白くなかった。

517:デフォルトの名無しさん
08/02/12 16:15:09
よし、いいぞもっとやれ、もっと罵りあえ!



いいですか、↑これがどうしようもないレスという物の見本です

518:デフォルトの名無しさん
08/02/12 16:17:58
まあ久しぶりににぎわってよかった。

↑これはどうかな。優等生過ぎてどうしようもない?

519:デフォルトの名無しさん
08/02/12 22:50:57
ドキュメント書くのメンドクセェ・・・
そもそも何を書いていいのか分からんのだよ

520:デフォルトの名無しさん
08/02/12 23:44:47
>>519
大丈夫だ。どうせ誰も見ない。

ぐらいの気持ちで書いてまつ。
本当に皆が必要な内容ならそんな悩まなくても書けるよ。

521:デフォルトの名無しさん
08/02/13 01:27:10
「~したら期待したとおりにうごかねーぞゴルァ」ときた時に
「ドキュメントは読みましたか?フフン」とするために書く。

522:デフォルトの名無しさん
08/02/13 23:08:46
ソースコードにドキュメント付けするときには、
とりあえず日付を真っ先に書くようにしている。

ほかの文章は後からでも書けるけど、
こればっかりは後から思い出そうとしても思い出せない。

523:デフォルトの名無しさん
08/02/15 15:13:16
書いてすぐコミットしようよ・・・

524:デフォルトの名無しさん
08/02/16 12:59:06
>>522
ついでに天気とその日の主な事件も書いとけ

525:デフォルトの名無しさん
08/02/26 20:56:32
source code に含まれないドキュメントに数学記号使った数式を
書いたら怒られたんだが, なぜ?


526:デフォルトの名無しさん
08/02/26 23:47:14
>>525
理由も聞かなかったのか?馬鹿

527:デフォルトの名無しさん
08/02/27 00:17:20
>>526 意味がわからんとゆわれた


528:デフォルトの名無しさん
08/02/27 00:26:10
プログラマなら常識ですと言ってやりたいなwwww

529:デフォルトの名無しさん
08/02/27 00:26:46
>>527の意味もわからんわ馬鹿

530:デフォルトの名無しさん
08/02/27 15:40:49
>>437
俺も重複を避ける為にそう思った。
が、この文法では、@param属性(入力,出力、入出力)が付けられない。これは痛い。
従って、@paramを使わざるをえなかった。

//445
ダメだよ、それじゃ。パッと見でもおかしいし、実際 変な表示になるよ。

531:デフォルトの名無しさん
08/03/05 23:50:08
マニュアル・手順書を作るのに、使うのはWord?Excel?

俺はExcel派。
Word使うヤツの気が知れない。

要するに、あとで文章直すときに改行がExcelだと
大変だってだけの話でしょ?

レイアウトは断然Excel優位だよね。


532:デフォルトの名無しさん
08/03/05 23:52:51
まだEXCEL使い奴いるんだな

533:デフォルトの名無しさん
08/03/06 09:04:30
つられませんから。

でもスタイル指定しないWordはひょっとしたら
確かにExcelよりクソかもしれない。

534:デフォルトの名無しさん
08/03/06 16:21:43
まあ、Excelの方が向いてるドキュメントはあるわな。

535:デフォルトの名無しさん
08/03/07 01:26:50
>>531
> マニュアル・手順書
にかぎるんだったら, エディタで書いた平テキスト
エンドユーザー向けのマニュアルは別部門が作る
図面ほしいって言われたら、CAD 図面

# 新規ハード使う組み込み系の仕事がほとんどだが


536:デフォルトの名無しさん
08/03/12 18:34:18
ここはdoxygenスレじゃない事は分かっているのですが・・・ちょっと質問。

関数仕様書を作るのにdoxygenを使おうとしています。 ver1.5.5を使っている
のですが、HTML出力は上手くいくものの、rtf出力になるとUTF-8でエンコード
されていて、テキストエディタでは日本語が読めるのですが、Wordやワードパッド
では文字化けして読めません。これではRTF出力する意味がありません。

DoxyWizardでは出力、入力ともShift-JISに設定しているのですが・・・(当然、
ソースのコメントはShift-JISです)

一体何がいけないのでしょうか?




537:デフォルトの名無しさん
08/03/12 21:54:59
SHIFT-JIS

SHIFT_JIS


538:536
08/03/13 09:27:00
SHIFT_JISにはなっていました。エンコード設定の所にカーソル合わせると
「gnuのlibiconv使ってるからそこのページ見ろや」みたいな表示が出るので
そこを見てコピペしたからだと思います。

HTMLはちゃんと表示出来るのにRTFがダメなのが良く分かりません。

539:デフォルトの名無しさん
08/03/13 13:50:29
CP932は試した?

540:536
08/03/14 18:08:47
CP932でもダメのようです。
どうも、エンコード方式を指定するバージョンでは全てダメのようで。
具体的には1.5.2からはダメ。

仕方ないので1.5.1以前を使おうかと思います。ソースいじってなんとかする
スキルはないし。

あと、ついでにもう気づいた事。@paramコマンドで[in][out]表示が出来ますが、
HTMLでは問題ないものの、RTFでは何故か表示できません。

なぜRTFにこだわるかと言うと、提出物としてはHTMLよりもWord文書の方が良い
のではないかという事です。RTFならそのままwordで読めるし、DOCに直すにしても
ほとんど手直しの必要がないですからね。

まぁ、Word出力するなら商用ツール使えって事なのかなぁ・・・でも、ウチの会社
そんなに余裕ないし。



541:デフォルトの名無しさん
08/03/14 20:30:26
defaultcharsetと合ってないor設定されていないんじゃないかな

542:デフォルトの名無しさん
08/03/24 11:25:04
>>536
うちじゃどうしても日本語が必要なときはTeXで出して、pdfに落として提出した。
そうでないときは、全部英語にしておいた。
そうか、1.5.1ならRTFに日本語を出せたのか……

543:デフォルトの名無しさん
08/04/07 23:38:23
ソースにdoxygenのコメントのテンプレートを挿入してくれるツールって無いですか?
たとえば

int f(int x)
{

}

というソースがあったら


/*!
*
* @param x
* @return
*/
int func(int x)
{

}

のような感じでコメントを挿入してくれるとありがたいです。


544:デフォルトの名無しさん
08/04/12 21:56:16
>>543
よし、売ろう

545:デフォルトの名無しさん
08/04/13 16:41:20
>>543
Visual Studioでの開発ならマクロ組めば出来るんじゃないかな

546:デフォルトの名無しさん
08/04/28 19:31:50
ネットワークプロトコル説明するのに、状態遷移図書いて提出したら
「意味がわからん!!! 書き直してこい!!!」
と言われてしまったんだが、おまえらどうやって説明してますか?

# 一応、説明文は遷移図一枚につき5ページくらいは書いたんだが…


547:デフォルトの名無しさん
08/04/28 19:34:27
>>546
># 一応、説明文は遷移図一枚につき5ページくらいは書いたんだが…
説明文をだらだらと長く書きすぎたんじゃない?

548:デフォルトの名無しさん
08/04/28 19:42:13
だったら図だけで分かってほしかったよorz

これじゃわからんって言うから、書き足していったらこうなった

どう説明すりゃいいんだ?
縦線ひいて斜め矢印か?
例外だらけになるやないか!!!


549:デフォルトの名無しさん
08/04/28 19:46:17
>>548
怒られたのに何がダメだったのか聞いてはないの?

550:デフォルトの名無しさん
08/04/28 19:50:19
>>548
箇条書きにした?

551:デフォルトの名無しさん
08/04/28 19:51:26
>>549
もっと詳しく書けっていったから詳しく書いたんだが、ついでに数式まで交えて…
「例をだせや!!!」っても、「はじめてなんでありません」と…


552:デフォルトの名無しさん
08/04/28 19:52:27
>>545
そういえば、VSってソース解析する上にマクロからアクセスできるんだったな。
ドキュメント自動生成マクロなんかあってもよさそうなのにな。
何とか工房がそうなのか?

553:デフォルトの名無しさん
08/04/28 20:10:39
>>551
相手が理解できない点を、推測じゃなくて、ちゃんとヒアリングするのは無理なのか?
あと、説明するときは、いきなり本物じゃなくて、ミニマムセットで理解できるかどうか確認するとか。
そこらへんにギャップがあると、「それじゃわからん」vs「ではどう書けと」の対決になるような希ガス。

554:デフォルトの名無しさん
08/04/28 21:32:33
プロトコルなんだから、シーケンス図?(自分対相手でメッセージを線で表現した奴)も
必要なんじゃない?

555:デフォルトの名無しさん
08/04/28 22:06:01
自分<-- メッセージ -->相手

こうかw

556:デフォルトの名無しさん
08/04/28 23:24:10
通信プロトコルならシーケンス図がいいんじゃないか?
状態遷移図と突き合わせできるように書けばOK

557:デフォルトの名無しさん
08/04/28 23:33:37
>>556
しかし、シーケンス図だと条件分岐がすごく書きにくくない?

558:デフォルトの名無しさん
08/04/29 01:20:36
パターン別に何種類か書いたらよかろうが

559:デフォルトの名無しさん
08/04/29 01:28:42
組み合わせ爆発しなきゃそれでいいかもしれんが……。


560:デフォルトの名無しさん
08/04/29 12:28:52
プロトコルってのは「やりとりの規約」だかんな
やりとりに出てくるもの全てを図に入れて,なおかつどんなやり取りが行われるのかを書かないといけないんでないかい?
でもヒアリング一発ですみそう

561:デフォルトの名無しさん
08/04/29 12:46:13
rfcでも参考にして書けばいいんでない?

562:546
08/04/29 14:38:51
>>561
RFC を参考にしてではなく RFC 提出できるくらいまじめに書いた

だけど、定義してるのはプロトコルなんで
「実装する奴が理解でない!!!」

結局, フローチャート書きまくりだとか数式無しだとかじゃないと
駄目らしい

だけどさ、状態遷移図をコーディングレベルに落すのは
「あんたらの仕事じゃねぇの???」 >>25才位のクライアントの担当者

# つか、ステートマシンとか習わかったのか?


563:デフォルトの名無しさん
08/04/29 14:57:59
>>562
もしかして日本語がやばいんじゃないか?

564:546
08/04/29 15:12:04
>>563
おぉ、そうかもしれん >俺の日本語 Www
だれどさ、院出てから、10年以上この業界に巣食ってるけど、
いままでお目にかかったことがない >こんなクライアント


565:デフォルトの名無しさん
08/04/29 15:23:28
クライアントは何屋さん?

566:546
08/04/29 15:44:01
>>565
今まで、地方自治体外郭団体向けに事務処理ソフト作って{る|た}会社
>>564 書く直前に
「理工系の知り合いに聞いたら、うちが悪かった」
って,電話入ってきた。
まぁ、>>564 ただの愚痴だし、確に、俺も悪かった思うが………
こんなに、言語の差があるもんなのか?


567:デフォルトの名無しさん
08/04/29 16:41:31
とりあえず日本語でおk

568:デフォルトの名無しさん
08/04/29 16:46:09
まぁ、独自プロトコルを定義した仕様書を今まで見たことないんだろうね。
いつまでも自分流儀でやって、愚痴たれながしとけばいいよ。

569:デフォルトの名無しさん
08/04/30 00:07:17
事務処理オンリーだった会社じゃ通じなくても不思議はない。
不思議はないが不甲斐ないな、そこ。

570:デフォルトの名無しさん
08/04/30 02:15:31
>>543
VS2005ならDoxyCommentがいいんじゃね
書式もカスタマイズできるし

571:デフォルトの名無しさん
08/04/30 02:52:52
正直、ドキュメントが読めない
DBの構成とか設計書とか。
「読んだら分かる」っていつも言われるんだけど、
どうしたらいいかな。

572:デフォルトの名無しさん
08/04/30 03:18:04
>>571
落ち着いてジックリ読んでみな。

573:デフォルトの名無しさん
08/04/30 10:43:42
>>566
そう言う所は、得てして「うちはどこそこの仕事をしているんだ」って妙な自負があるから
こっちが何を書いてもクレームつけるよ。謝罪の電話があっただけでもましな方かも。
# うっかりしていると、同じドキュメントを「概要」と「詳細」と「解説」の3バージョン作る羽目になったり。

574:デフォルトの名無しさん
08/04/30 13:11:38
これはいい勉強になるスレ

575:デフォルトの名無しさん
08/05/01 21:02:41
>>571
ドキュメントは読めるようになったほうがいいよ。人に
頼ることなく進む力がぐんと増える。(ドキュメントに
頼る時点で、というのは無しで)

どうしたらいいかと言われると解答に困るんだけど、
日頃から疑問に思ったことがあれば、まずドキュメントに
目を通すという習慣をつけてみたらどうだろう。

java でプログラミングしてて分からないことがあったら
まず javadoc を当たってみて、それでも分からなければ
ぐぐってみたりとか。
ツールのインストールの時も、まずは付属ドキュメント
(README, INSTALL みたいなやつ) に目を通すとか。

576:デフォルトの名無しさん
08/05/02 10:31:47
それ、「~ほうがいいよ」ってレベルじゃなくて、「~できなきゃダメ」のレベルだと思う。

577:デフォルトの名無しさん
08/05/03 13:36:57
>>546
遷移図は全体を出さずに、

 ほげをするとBになります
 A→B

 ここでげほをするとCになります
 A→B→C

 ここでほれをするとAになり、やりなおしできます
 A→B→C┐
  ←─┘

まあなんだ、たぶん図は崩れたと思うけど、インクリメンタルに
説明と共に図を成長させると理解してもらいやすい。

パワポのアニメで説明するとわかったきになるのに、
紙に出した同じ資料がわかりにくいのも同じ理由だと思う。



578:デフォルトの名無しさん
08/05/06 04:58:29
>>572
>>575

遅くなったけど、ありがとう。
疑問を持ったら人に聞くクセをなくすように
がんばります。

579:デフォルトの名無しさん
08/05/08 17:47:02
今度開発の仕事やらせてもらう事になりました。
その前に勉強として、仕様書作ってプログラム作れって上司から
言われました。
プログラムは作ったことあるんですが、仕様書なんて作ったことありません。
常識的に考えたら、基本設計書、概要設計書、コード設計書とか全部作るべきでしょうか?

580:デフォルトの名無しさん
08/05/08 20:27:21
上 司 に 聞 け

581:579
08/05/08 23:52:12
>>580
言葉足らずですみません。
仕様書って何の事か聞いたんですが、自由に作っていいって言われたんです。
自由に作れと言われたら基本的な概要、機能とか画面構成など書けば仕様書としては
成り立つんだと思うんですが、いかんせん初めての経験なのでどのように書いたらいいか
わからないんですよね。
社会人の常識として設計書の本読んで基本設計書、概要設計書
など全ての設計書を作るのが妥当なのかという質問です。

582:デフォルトの名無しさん
08/05/09 00:08:07
単なる練習プログラムなんだから概要からでいいんじゃね

583:デフォルトの名無しさん
08/05/09 03:44:01
上司乙w

584:デフォルトの名無しさん
08/05/09 08:08:02
>>581
疲れたので途中で止めとくけど、こんな感じで読める読み物を作ればおけ。

ゴールの定義
・どういう背景があり(どういう歴史があり何で困っていたのか)
・何を実現したいと考えています(作ったものを使うことで得られると期待される効果のこと)
・このために何々をするものを作ることにしました

全体構造
・大きな制約条件として~がある中で(納期、コスト、現状からくる技術�%A

585:デフォルトの名無しさん
08/05/09 08:09:41
あれ?途中で切れてしまった・・・
書き直すもの疲れたので諦めるすまん>>581


586:デフォルトの名無しさん
08/05/09 09:40:43
骨組みでこの程度がわかれば良い。
・なんで作ったのか
・それを使ってどういう効果が期待できるか
・必要とする環境
・入力は何か
・出力は何か

競合するプログラムが既にある場合を除いて、
最初はどういう機能がとか、画面が云々とかは不要。
必要だといわれたら付け足していけば良いはず。
読む側にとってどうでもよさそうな事は極力避ける事。
つーか多分作ったのを後で添削するのが
意図なわけだから、あまり時間掛けると嫌われるぞ。

587:581
08/05/09 16:21:25
>>586
入力、出力ってどういう意味ですか?
A4用紙一枚にまとめるのは変でしょうか?

588:デフォルトの名無しさん
08/05/09 16:40:36
>>587
入力も出力もないプログラムは役に立たないだろう
記述が必要十分なら一文字にまとまっていても構わないぞ

589:581
08/05/09 17:00:35
>>588
もしデータベースを扱うプログラムだったら、
どのようなデータを登録して(入力)、どのような形で表示するか(出力)
簡単に言えばこのような事でしょうか?

590:デフォルトの名無しさん
08/05/09 20:04:08
電卓のイメージなら簡単だろ?
ユーザーが入力して、プログラムがそれを計算する。(出力)

591:デフォルトの名無しさん
08/05/10 01:11:34
上司から言われたことの真の目的を明確にして、その目的を達成するためのプロセスや成果物を決めたらどうだろうか?
社会人の常識とかじゃなくて、目的から考えた方がよいのでは

592:デフォルトの名無しさん
08/05/10 10:46:22
クラスの仕様の概要って、どこまでが概要ですか?

593:デフォルトの名無しさん
08/05/10 10:52:50
>>592
クラス仕様の詳細じゃない部分

594:デフォルトの名無しさん
08/05/10 11:23:40
>>592
・そのクラスの責任範囲と全体の中での役割
・超簡単なサンプル使用例
・データの流れと関与する主要APIを図示したもの(ポイントとなるクラスの場合)

これが1ページで欲しい所。

595:デフォルトの名無しさん
08/05/26 16:40:33
doxygenについて質問したいのですが、専用スレが無いようなのでこちらでさせてください。
PC:Windows XP
コンパイル方法:Visual Studio 2005のコマンドプロンプト上で、下記の命令をする
 make msvc
C:\doxygen1.5.5 に doxygen1.5.5.src.tar.gz を解凍した中身を置きました。
C:\doxygen1.5.5\src のソースをいじって、コンパイルしましたがエラーが出てしまいます。
エラー内容
----
 link /NOLOGO /LIBPATH:..\lib /SUBSYSTEM:console /OUT:..\bin\doxygen.exe
 @C:\DOCUME~1\AA\LOCALS~1\Temp\nm2E.tmp
 ~
 doxycfg.lib(portable.obj) : error LNK2019: 未解決の外部シンボル __imp__libiconv_open が関数 "void * __cdecl portable_iconv_open(char const *,char const *)" (?portable_iconv_open@@YAPAXPBD0@Z) で参照されました。
 ~
 ..\bin\doxygen.exe : fatal error LNK1120: 外部参照 5 が未解決です。
 NMAKE : fatal error U1077: 'link' : リターン コード '0x460'
----
doxygenのソースのコンパイルは、下記以外に必要なものはありますか?
・Active perl
・GnuWin32のFlex
・Qt
・VC2005
・Microsoft Platform SDK

596:デフォルトの名無しさん
08/05/26 17:33:49
libiconvって書いてあるじゃん。
エラーメッセージぐらい読めるようになったら?

597:595
08/05/26 18:28:33
>>596
ありがとうございます。
iconv.lib,iconv.hがdoxygenのソース内に入っていたのでこれで良いのかと思っていました。
Libiconvをコンパイルしたものと差し替えたら、コンパイルが通過して下記ファイルが出来ました。
 doxygen.exe
 doxytag.exe

598:ura2ch.czsoftbank219174032071.bbtec.neta.net
08/05/26 18:33:08
guest/guest

599:デフォルトの名無しさん
08/05/28 23:41:27
開発の人間なら仕様書を云々言う前に
ソース内のコメントをちゃんと書け!

と思う、インフラ屋は俺だけではないはず。

特にリリース後の修正箇所に対して正確な
コメントが書かれているソースが本当に少ない。

頼むから引数のコメントくらい、まともに書いてくれ・・・・

600:デフォルトの名無しさん
08/05/30 04:18:14
変数名自体を説明にするしかない

601:デフォルトの名無しさん
08/05/30 13:08:41
システムハンガリアンを止めて、アプリケーションハンガリアンにする。

602:デフォルトの名無しさん
08/05/31 00:23:06
>>599
> 特にリリース後の修正箇所に対して正確な
> コメントが書かれているソースが本当に少ない。

これはコミットログやChangeLogの役目だろう

603:デフォルトの名無しさん
08/05/31 13:13:14
> これはコミットログやChangeLogの役目だろう
ソース内のロジックとコメントは分業してるってこと?

ロジックとそのコメント内容が一致してないから
障害対応してるときに頭からソースを読まなければ
ならないってこと。
そして、修正したPGはすでにいないことが多い・・・・

604:デフォルトの名無しさん
08/05/31 17:32:04
コメントとソースを同じくらい価値があるものだと考えるのはいいが
コメントとソースを同じように扱ってはいけないだろ

605:デフォルトの名無しさん
08/05/31 18:51:02
そこまでコメントに期待してないよ。
ただ最初にも書いたけど、表題部の
プログラム名や用途、引数説明すら
まともに書いてないソースが多すぎる
からカキコしただけだ

606:デフォルトの名無しさん
08/05/31 19:19:50
doxyの1.5.6でツリーが文字化けするのって俺だけ?
1.5.5平気なんだけど

607:デフォルトの名無しさん
08/05/31 21:19:45
4コマ漫画で800ページの取扱い説明書


608:デフォルトの名無しさん
08/05/31 22:24:13
>>603
> 特にリリース後の修正箇所に対して正確な
> コメントが書かれているソースが本当に少ない。

これは 「こう修正しました」 っていうコメントのことでしょ?
それはまさにコミットログ等の役割
コードからは読み取れない 「こういう処理です」 っていうのがコメントの役割だと思う

609:デフォルトの名無しさん
08/06/01 01:34:08
>>608
"「こう修正しました」"は
ソース内の修正(変更)履歴のことを言ってる。

610:デフォルトの名無しさん
08/06/01 01:53:13
>>609
そりゃあSCMがない時代の苦肉の策でしょ

611:デフォルトの名無しさん
08/06/01 09:06:34
>>609
バージョン管理使おうぜ

612:デフォルトの名無しさん
08/06/01 11:47:08
>610,611
今、休出でVSS見てるけど、コミットログやChangeLogは存在しない。
各ソースのチェックインコメントは全部一緒で"○○○○更改に対する修正"・・・・
ほかに見るとこあれば教えてくれ。

(インフラ側で作ってる基盤モジュールのアップデート履歴のほうが
詳細に記載している。)

613:デフォルトの名無しさん
08/06/01 17:35:45
>>612
履歴を残そうという意識が作業者に無ければコミットログにも残るわけ無いだろ。
お前んとこのローカルな事情だな、それは。

で、一般的に履歴を残すんならどっちかというとコミットログのほうが適切という話。

614:デフォルトの名無しさん
08/06/01 17:43:21
>>612
コミットログはチェックインコメントと同じ意味
ツールが違うと用語が違う
チェックインコメントが全部一緒だと無意味だと感じませんか?
チェックインコメントは修正内容を記録するのにうってつけだと思いませんか?

615:デフォルトの名無しさん
08/06/01 17:49:07
ソースに履歴コメントされても探すのが大変だし。同時に変更したファイルの関連や前後関係も把握するのも正確に記載するのも困難。
コミットログならすぐ探し出せる。コメント漏れがあっても差分を見つけられる。
コミットログに情報がないというのは、結局コメントの入れ方、運用の問題でしょ。

616:デフォルトの名無しさん
08/06/01 19:27:14
ソースが動かないというのは、結局プログラムの書き方、プログラミングの問題でしょ
みたいな感じに見えた

617:デフォルトの名無しさん
08/06/02 15:25:20
【コメント】doxygen【コンソメ】
スレリンク(tech板)

618:デフォルトの名無しさん
08/07/27 04:43:22
doxygenの話題は禁止

619:デフォルトの名無しさん
08/08/23 14:10:15
URLリンク(www.hotdocument.net)
じゃだめかな。


620:デフォルトの名無しさん
08/08/23 18:05:57
これはひどい

621:デフォルトの名無しさん
08/11/17 15:02:59
doxygen,hotdocument,visio

どれがいいだろうか・・・
C++Builder2007なんだけど。どれ対応してるかもまだ調べてないんだ。

とりあえず・・・探すか。


最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch