ドキュメントの整備はコーディングより重要である
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2005/06/04(土) 17:34:55プログラマならソース読んで理解しろなどと言うやつは
ドキュメントを書く能力がないだけ。
ドキュメントの作成はコーディングより重要なのである。
0002デフォルトの名無しさん
2005/06/04(土) 17:36:390003デフォルトの名無しさん
2005/06/04(土) 17:40:280004デフォルトの名無しさん
2005/06/04(土) 18:48:500005デフォルトの名無しさん
2005/06/04(土) 18:55:460006デフォルトの名無しさん
2005/06/04(土) 19:07:40そんなものは状況により。
盲目的に何々より重要であると書く人間は、バランス感覚が失調している。
偏った考えを断定して主張しようとする場合、
大概は心を病んでいるので、これ以上悪化する前にカウンセリングを受けた方がよい。
0007デフォルトの名無しさん
2005/06/04(土) 20:03:14> ドキュメントを書くのもプログラマの能力のうち。
まあこれはプログラマに限らず、共同作業する際に問われる基本能力だわな。
ていうか、自然言語で適切にドキュメンテーションできない奴が
プログラミング言語で正確な表現が出来ているわけが無い。
0008デフォルトの名無しさん
2005/06/04(土) 20:05:55重要性については同意。
しかし、中途半端なドキュメントでは、結局コードを見る羽目になる。
0009デフォルトの名無しさん
2005/06/04(土) 20:10:390010デフォルトの名無しさん
2005/06/04(土) 20:17:25> しかし、中途半端なドキュメントでは、結局コードを見る羽目になる。
「結局コードを見る羽目になる」かどうかが判断でき、
ドキュメントが中途半端であれば、コードも信頼するに値しないであろうことが
ドキュメントを少し読んだだけで容易に判断できるようになる。
>>9
> 松本さんを全否定していますね。ヘラヘラ。
ドキュメントを書く能力がない奴⇒プログラマならソース読んで理解しろなどと言うやつ
は真である、というだけ。
>>1の言う
プログラマならソース読んで理解しろなどと言うやつ⇒ドキュメントを書く能力がない奴
の真偽については言及していない。
0011デフォルトの名無しさん
2005/06/04(土) 20:21:45第三者が確認する術がドキュメント以外にあるのであれば、
わざわざドキュメンテーションするのは冗長な作業になりますね。
0012デフォルトの名無しさん
2005/06/04(土) 20:30:57口頭とか？ でも口頭だと特定の第三者であって、任意の第三者では無いな。
まぁドキュメントがあっても特定の人しか読めないなら似たようなもんか。
0013デフォルトの名無しさん
2005/06/04(土) 20:39:34それ以外は全部枝葉。トヨタ生産方式って知ってるか?
0014デフォルトの名無しさん
2005/06/04(土) 21:00:05今はちゃんと動いていたとしても
将来拡張したり他の言語や環境に移植したりする可能性を考えると
やっぱりドキュメントがあった方が良い。
0015デフォルトの名無しさん
2005/06/04(土) 21:52:060016デフォルトの名無しさん
2005/06/04(土) 21:54:33本当にコードを読むことで検証可能なものであれば、
コードだけでも良いのだと思います。
ただし実装者だけでその判断を行うことは不可能です。
だれが確認できれば良いか、というと、プロジェクトに従事する人
(将来的に従事することになる人も含む)が理解できれば最低限の事は足り、
例えばユーザレベルの人まで理解させなければならないドキュメントを書くべきかどうかは
コストも考慮した上で判断すべきでしょう。
そういう意味では、「特定の人しか理解できなくても良い」というのは誤りではないと思います。
あとは、例えばテストコードなども有用であると思います。
テストファーストにはこういった思想も含まれていると認識しています。
>>13
検証できなければちゃんと動くのかどうかすら分かりません。
ちゃんと動いているように見えているだけかもしれません。
容易な検証を可能にすることは、トヨタ生産方式の「自働化」において
メリットがあると思われますが。
0017デフォルトの名無しさん
2005/06/04(土) 22:48:25システム構築ほど変化が激しくないでしょ。ライン設計に
外注何十人投入とか聞いた事ないし。変更のための
コミュニケーションも少なくてすむ。
物理的でシーケンシャルな生産ラインと、システム構築を
同列にして語るのはいかがなモノか。
0018デフォルトの名無しさん
2005/06/04(土) 23:12:56全てを同列にして語れるものでないというのは当然だが
共有できる知識が全く無いわけではない。
とりあえず
>>13あるいは>>17みたいに考えているは、
一度トヨタ生産方式について書かれた本をちゃんと読んでみては如何か。
トヨタ生産方式 日本生産管理学会【編】
http://bookweb.kinokuniya.co.jp/guest/cgi-bin/wshosea.cgi?W-NIPS=9960915875
リーンソフトウエア開発
http://bpstore.nikkeibp.co.jp/item/contents/m_4822281930.html
0019デフォルトの名無しさん
2005/06/04(土) 23:28:51誰が見ても理解できるソースコードを書く方が
効率的だし健全だ罠
0020デフォルトの名無しさん
2005/06/04(土) 23:36:35>>7
0021デフォルトの名無しさん
2005/06/04(土) 23:42:05ドキュメントなんて冗長な作業は不要。寧ろ丸投げしておいてユーザからの
クレームを後日FAQとして纏めた方が時間的に楽だ。ドキュメントの内容はユーザに書かせる。
0022デフォルトの名無しさん
2005/06/04(土) 23:52:05日本語でなくプログラミング言語で思考するような状況になれば、
胸を張って
「ドキュメントなんてのは冗長な作業」
と言えるのではないか、と私も思います。
0023デフォルトの名無しさん
2005/06/04(土) 23:55:54「この＊あいえすれでぃ＊っていう関数は何するの？」
って聞かれたときは、コードが自明でもだめなのかもしれないと思った。
ほどなく、そいつがバカなんだと気付いたけど。
0024うう
2005/06/04(土) 23:58:300025うう
2005/06/05(日) 00:00:370026デフォルトの名無しさん
2005/06/05(日) 00:07:230027デフォルトの名無しさん
2005/06/05(日) 00:09:090028デフォルトの名無しさん
2005/06/05(日) 00:16:22owl.hがないところで。
0030デフォルトの名無しさん
2005/06/05(日) 00:51:390031デフォルトの名無しさん
2005/06/05(日) 00:58:36前提が間違ってる。
0032デフォルトの名無しさん
2005/06/05(日) 01:20:03「コードなんか読めるか、ドキュメント書け」とかいっているやつの関数名や変数名は,
昔のベーシッくんやアセンブラの名残か、大文字6文字以内でなんだかわかんないのが多い
。
0034デフォルトの名無しさん
2005/06/05(日) 01:24:05はぁ？
0035デフォルトの名無しさん
2005/06/05(日) 01:32:50http://pc8.2ch.net/test/read.cgi/tech/1065364445/
0036デフォルトの名無しさん
2005/06/05(日) 01:38:160037デフォルトの名無しさん
2005/06/05(日) 01:52:14従って極端な部分はとりあえず流しとけ。
議論すべきなのは方向性だ。
このスレにおいては
「現状、ドキュメントが軽視されすぎではなかろうか」
ということが相当する。
>>6
世の中の殆ど全てのことが状況に依るが、
そんなものを正しいといったところで何も進展はしない。
0038デフォルトの名無しさん
2005/06/05(日) 01:54:500039デフォルトの名無しさん
2005/06/05(日) 01:54:56ライブラリって、たぶん「図書館」って意味で言ってるんだと思うよ。
（わざと）
図書館には文書が必須だよね、って洒落でいってんでしょ。
気づこうよ、それくらい。
0040デフォルトの名無しさん
2005/06/05(日) 02:01:190041デフォルトの名無しさん
2005/06/05(日) 02:12:41それでも俺らは特に気にしない
つまり誰も読まなきゃあっても意味が無い
0042デフォルトの名無しさん
2005/06/05(日) 02:14:19>>1
ところでドキュメントの整備がコーディングより重要だったら、どうしたいの？
強制的にドキュメントを読ませる方法でも教えてくれるのか？
0043デフォルトの名無しさん
2005/06/05(日) 02:14:51Windows はユーザー向けのヘルプもあって、
開発向けにはMSDNにドキュメントが山ほどあるのに、
「ないよね」ってあんまりだろう。
0044デフォルトの名無しさん
2005/06/05(日) 02:20:21>>22
>>41
msdnとかKnowledge Baseは立派な部類だと思うが。
ていうか読めよ。
ユーザから見たWindowsの事を言っているのであれば、
GUIやらWYSIWYGやらのドキュメントより有効な方法が織り込まれている
(し、ドキュメントが欲しければ購入できる)。
0045デフォルトの名無しさん
2005/06/05(日) 02:21:17○Windowsにはまともに読まれてるドキュメントないよね
0046デフォルトの名無しさん
2005/06/05(日) 02:21:44読まなくて良い文章は書く必要が無いし読む必要も無い。
当然だと思うが？
0047デフォルトの名無しさん
2005/06/05(日) 02:26:130048デフォルトの名無しさん
2005/06/05(日) 02:37:560049デフォルトの名無しさん
2005/06/05(日) 02:40:23Windows上のアプリならUIがある程度補助になってくれるが、
ちょっとでもアウトローに走るとドキュメントか、
それに以上にわかりやすいUIを作る必要がある
0050デフォルトの名無しさん
2005/06/05(日) 02:41:53その最低限のmanさえほとんど用意されてなかったりクソ程にも役に立たないけど
0051デフォルトの名無しさん
2005/06/05(日) 02:44:460052デフォルトの名無しさん
2005/06/05(日) 02:48:59あずいず
0053デフォルトの名無しさん
2005/06/05(日) 02:55:36なんで man だけ知ってるんだろう
0054デフォルトの名無しさん
2005/06/05(日) 02:58:530055デフォルトの名無しさん
2005/06/05(日) 03:05:39ソースコードをわざわざ読むほうが
もっと嫌だ。
0056デフォルトの名無しさん
2005/06/05(日) 04:42:03コードの設計書とかは割りとどうでもいい
どうせツール使って解析するし
0057デフォルトの名無しさん
2005/06/05(日) 05:12:25禿げ上がってしまったが同意
0058デフォルトの名無しさん
2005/06/05(日) 10:20:370059デフォルトの名無しさん
2005/06/05(日) 10:45:200060デフォルトの名無しさん
2005/06/05(日) 11:13:59後々メンテできなくて困るね
理由があって手間をかけた構成にしてあるのに、そこをいじって変なバグを作っちゃうのは
困るから
0061デフォルトの名無しさん
2005/06/05(日) 13:28:06どこまでが仕様でどこからがコードの設計かって
明確に分けられないですよね…
0062デフォルトの名無しさん
2005/06/05(日) 13:38:01設計: どういう風に動かすか
006313
2005/06/05(日) 13:55:45何が重要なのかをつきつめていくと、最後に残るのはちゃんと動くシステムだけだ、とゆーつもりでした。
他は枝葉で、全ては必要性とそれをとりまく判断基準によって作成の可否が決定されるでしょう。(とゆーのがトヨタ生産方式の思想の一つ、と解釈している)
誰もが読む必要があるドキュメントが重要であることも、誰も読まないドキュメントが無駄であることも論をまたないわけで、そーゆー意味では>>6の意見をもって「終了」だったのかもしれづ。
0064デフォルトの名無しさん
2005/06/05(日) 14:13:02> そーゆー意味では>>6の意見をもって「終了」だったのかもしれづ。
| >>37
| >>6
| 世の中の殆ど全てのことが状況に依るが、
| そんなものを正しいといったところで何も進展はしない。
0065デフォルトの名無しさん
2005/06/05(日) 14:18:36全てを一から自分(達)で作り、
暗黙の前提条件や前提知識を許容しないのであれば
全く以ってその通りだと思います。
0067デフォルトの名無しさん
2005/06/05(日) 14:32:17トヨタが言うところの生産とソフトウェア開発との最も顕著な違いのひとつとして
「全体の作業量に対する繰り返し作業を行う割合」があると思います。
この点だけを考えてみても、トヨタ生産方式をそのままソフトウェア開発に
適用できないことは容易に想像がつくでしょう。
極論を言うと、ソフトウェア開発における「トヨタ生産方式」というのは
単なる比喩に過ぎません。
とりあえず、>>18に挙げられているような本を読んでみてください。
0068デフォルトの名無しさん
2005/06/05(日) 14:33:560069デフォルトの名無しさん
2005/06/05(日) 14:37:25「不必要なものは作るな。必要になってから作れ」
これはその通りです。流行しているラピッドデベロップメントでもそういわれていると思います。
しかし、ドキュメントについて考えてみても
必要になってから作ろうと思っても作れないものもある、ということです。
0070デフォルトの名無しさん
2005/06/05(日) 14:41:22> >>65
> 暗黙知を前提にして死亡したプロジェクトって数限りなくあ(ry
それが仕様と設計が明確に分けられない理由です。
>>68
私が2,3行で正しく要約できるようなものであれば、
恐らく、そもそも>>13が誤解するようなこともないでしょう。
007113
2005/06/05(日) 14:55:10比喩、というよりも、アジャイル開発とトヨタ生産方式の類似性に目を付け、アジャイル開発について、経営者や管理職に<del>ハッタリをかます</del>簡単にイメージさせるための道具、と考えています。
リーンソフトウェア開発については、ついこの間買って積ん読状態(ぉ
一応、これらはあくまで指針であって、適用分野に応じてカスタマイズ／最適化されるべきなのはわかってるつもり。(つもりかもしれんけど)
パレートの法則(20:80の法則)(原則?)にのっとり、20%の努力で80%救えればいいと思ってる。
0072デフォルトの名無しさん
2005/06/05(日) 15:03:03逆もしかり
80%使い込んでしまったが20%しか終わってない...orz
0073デフォルトの名無しさん
2005/06/05(日) 15:42:38トヨタ生産方式 ＝ 下請けは首を吊らない程度に絞り上げろ
0074デフォルトの名無しさん
2005/06/05(日) 19:04:36コメントでいいじゃん
>>71
いるよね〜方法論だけの人って。使えないんだよ、はっきり言っちゃうと。
0075デフォルトの名無しさん
2005/06/05(日) 22:49:300076デフォルトの名無しさん
2005/06/06(月) 00:28:100077デフォルトの名無しさん
2005/06/06(月) 00:41:350078デフォルトの名無しさん
2005/06/06(月) 01:56:19あと、コードを書く前にどうしてそういうコードを書こうと思ったのかという
思考過程をなんらかの形で残しておくこと(メモ描きでもいいから)。
0079デフォルトの名無しさん
2005/06/06(月) 02:02:12いやー、それやっても「アルジャーノンに花束を」の状態でなぁ…
我ながら困ったもんだよ。
0080デフォルトの名無しさん
2005/06/06(月) 02:03:39かゆうまレベルはマジでつかえねぇ
0081デフォルトの名無しさん
2005/06/06(月) 02:08:44かゆ…うま…がどれくらい酷いのかよくわからんが、
自分がそうでないことを祈るよ。
0082デフォルトの名無しさん
2005/06/06(月) 02:11:11自分が過去に書いたコードすら読めないなんてのは愚の骨頂だぞ。
これじゃぁドキュメントがないと生産性が上がらないのは仕方ない。
しかし、ドキュメント書くにも手間がかかるわけで、そういう人は
生産性低いよ。コードを読むことが軽視されすぎている。
0083デフォルトの名無しさん
2005/06/06(月) 02:14:350084デフォルトの名無しさん
2005/06/06(月) 02:22:380085デフォルトの名無しさん
2005/06/06(月) 02:24:17>ドキュメントを書く能力がないだけ。
逆に言わせて貰うと、プログラマならドキュメントを書けというやつは
コードの読解能力がないだけ。
0086デフォルトの名無しさん
2005/06/06(月) 02:25:21最近はデバッガが整備されて、ステップ実行なども簡単にできる環境も多いしね。
問題は、どういう意図で書かれたのかだ。
0087デフォルトの名無しさん
2005/06/06(月) 02:26:44視野狭窄なアフォばっかだな
クライアントに対する仕様書やマニュアルは必要だろ
内部構造の設計書が必要かどうかは状況によるけどな
0088デフォルトの名無しさん
2005/06/06(月) 02:28:54もっとも重要なのは、「そのコードで正しいのか」がコードだけでは
わからんのだ。そのプログラムはクラッシュしないかもしれないし
非常に高速に動作するかも知れないが、仕様通りでないのなら意味が無い。
だからドキュメントは必要。
0089デフォルトの名無しさん
2005/06/06(月) 02:28:55設計の根拠について話をしてたんだけど
>自分が過去に書いたコードすら読めないなんてのは愚の骨頂だぞ。
ってなんか関係あるの？
だれも自分のコードが読めないって話をしてるわけではなかったんだが。
0090デフォルトの名無しさん
2005/06/06(月) 02:29:08あなたのその書き込みの意図が判りませんので、ドキュメント化してください。
0091デフォルトの名無しさん
2005/06/06(月) 02:31:44そういう企画の話してんじゃねーだろ。空気嫁アフォ土方野郎。
0092デフォルトの名無しさん
2005/06/06(月) 02:35:50そのコードの意図がわかんねーときたよｗ
ご愁傷様。
0093デフォルトの名無しさん
2005/06/06(月) 02:37:12コードだけじゃ意図がわからんことはあるだろ
エスパーでもない限り
0094デフォルトの名無しさん
2005/06/06(月) 02:37:35企画と仕様書はちげーよ
0095デフォルトの名無しさん
2005/06/06(月) 02:41:29いや、実際のコードを読まないと理解できないような職場は非常に生産性が悪いと思う。
普通は、ドキュメントや議事録を読めば仕様くらいは理解できるように整備するものだ。
0096デフォルトの名無しさん
2005/06/06(月) 03:51:39いや、ドキュメントを読まないとコードの意味が判らないようなコードを書く
書き手の能力不足や、読み手の読解力不足について語っている。
そんな職場は非常に生産性が悪いと思う。
ドキュメントを整理する前に人員を整理したほうがいいだろう。
0097デフォルトの名無しさん
2005/06/06(月) 05:23:57お前、ドキュメントがなにか分かってないだろｗ
0098デフォルトの名無しさん
2005/06/06(月) 11:37:06「地図と現実の地形が異なる場合は、現実の地形を信じろ」
0099デフォルトの名無しさん
2005/06/06(月) 11:46:13例外／反証 を希望
0100デフォルトの名無しさん
2005/06/06(月) 11:50:02ソフト開発においては、わけのわからんプログラムを解析して
作成されたドキュメントのようなものだな。
0101デフォルトの名無しさん
2005/06/06(月) 12:41:29コードを書く能力を獲得する唯一の方法は、
コードを読む能力を獲得する事です。
卵が先か？ 鶏が先か？
0102デフォルトの名無しさん
2005/06/06(月) 12:42:52荒す意図はないんだけど・・・新しい格言をひとつ
「マニュアルと現実の動作が異なる場合は、
マニュアルを信じろ」
0103デフォルトの名無しさん
2005/06/06(月) 12:45:31どーみても各自「ドキュメント」という語でイメージしてるモノが違ってるでしょーがー。
0104デフォルトの名無しさん
2005/06/06(月) 13:04:54サブルーチンで何やってるかとか、
if構文で何をしてるかぐらいがわかればいい
010599
2005/06/06(月) 13:11:52おお。なんか触発されました。（最初はチャカシのように思えたけれど）
他者のコードを一行も読まずにまともなコードを書ける様になった人はいない という事実も併せて考えると・・・
書けるようになったから読めるようになった とか 読めるようになったから書けるようになった
という２パターンしか無いと思います。そこで新見解
「コードを読む能力とコードを書く能力は不可分。硬貨の表裏」
どうでしょうか？
0106デフォルトの名無しさん
2005/06/06(月) 13:16:19正解！
0107デフォルトの名無しさん
2005/06/06(月) 13:20:220108デフォルトの名無しさん
2005/06/06(月) 13:22:52うーん、おもしろくない
0109デフォルトの名無しさん
2005/06/06(月) 13:44:16だからこそ天才なんだよ。
凡人は他人から学ぶのさ。
0110デフォルトの名無しさん
2005/06/06(月) 14:15:46あんた大人だなー
0111デフォルトの名無しさん
2005/06/06(月) 18:17:050112デフォルトの名無しさん
2005/06/06(月) 20:24:32提案書からコード設計まで色々あるしな
上のレスで散々言われてるけど
「システムがどういう動きをするのか(コードはどういう動きをするのか)」
は比較的簡単に解析できる
「システムはどういう動きをすべきなのか(どういう意図でそのコードを書いたのか)」
はドキュメントがしょぼいとどうにもならなくなる
個人的にはコード設計はまぁあんまり重要では無いと思う
頻繁に変更があったりするし、納品しても顧客は見やしないし
ツールでコードから仕様書つくれるしね
0113デフォルトの名無しさん
2005/06/06(月) 20:56:08取説まで含む流れのようだったのだけど
0114デフォルトの名無しさん
2005/06/06(月) 20:59:49ドキュメント生成ツールはいろいろあるわけだし。
コード読めば分かるようなコメントはいらないが、
自明でない個所にはちゃんと説明をつけて欲しい。
0115デフォルトの名無しさん
2005/06/06(月) 21:32:510116デフォルトの名無しさん
2005/06/06(月) 22:30:07ＩＳＯなんかちゃんちゃらおかしいぜ
0117デフォルトの名無しさん
2005/06/07(火) 00:19:040118デフォルトの名無しさん
2005/06/07(火) 00:49:450119デフォルトの名無しさん
2005/06/07(火) 10:30:450120デフォルトの名無しさん
2005/06/08(水) 02:46:11コード設計は顧客はロクに見ないが、次に引き継ぐ人間なら確認するのが前提だろうな。
ドキュメントを読んだ上で、実際のソースを読んだ方が「どう違うのか」が大体把握できる。
逐一、スパゲティコードを読み解いて「どうなっているのか」を解析していくよりは、大まかな全体像が
掴めている分だけ作業的には楽。引き継ぐ人間が以前と同じなら、本当に無用の長物だが。
>>114
その線引きが難しいんだよな…。「誰にとって」自明かどうかは完全に主観だから。
経験則で申し訳ないが、優れたコメントはピンポイントなものが多いのではないかな。
あれば問題なく分かるが、無ければ無駄に悩むことになるような（ある意味でイレギュラーな）箇所に
コメントを付記しておくことは必要だろう。
0121デフォルトの名無しさん
2005/06/08(水) 11:10:590122デフォルトの名無しさん
2005/06/08(水) 23:54:410123デフォルトの名無しさん
2005/06/08(水) 23:57:18いや土方コーダでも他人の仕事を引き継ぐ機会はあるから
ドキュメントの重要性は認識できるはず
要は自分が誰も読みもしないドキュメントを書くのが面倒なだけ
0124デフォルトの名無しさん
2005/06/09(木) 00:02:47自分が読むだろ・・・
0125デフォルトの名無しさん
2005/06/09(木) 00:08:54納めた後は読まない香具師が多いと思う...
0126デフォルトの名無しさん
2005/06/09(木) 00:18:46保守する気無しかよ・・・
0127デフォルトの名無しさん
2005/06/09(木) 00:19:41自分で保守するんなら、大半のドキュメントは必要ないよ...
0128デフォルトの名無しさん
2005/06/09(木) 00:30:03要約すると、後は野となれ山となれっつー姿勢でいる奴は
ドキュメントの重要性を認識していてもドキュメントを書かないって事？
0129デフォルトの名無しさん
2005/06/09(木) 07:17:55ブログなんていうオナニー文章書く暇あるんだったら
ソースコードに感想文を付記しとけ。
0130デフォルトの名無しさん
2005/06/09(木) 07:23:160131デフォルトの名無しさん
2005/06/09(木) 08:52:480132デフォルトの名無しさん
2005/06/09(木) 11:16:35>後は野となれ山となれっつー姿勢でいる奴は
>ドキュメントの重要性を認識していてもドキュメントを書かないって事？
そうゆうやつはドキュメントの重要性を認識していないやつ
ドキュメントなしで痛い目にあったことがない奴
0133デフォルトの名無しさん
2005/06/09(木) 15:31:33昨日の自分は他人
晩飯すら思い出せんorz
0134デフォルトの名無しさん
2005/06/09(木) 16:29:03痛い目にあってないんだったら
それは素晴らしい事です
プロジェクト管理能力や顧客のコントロール力が
ずば抜けてるという事ではないでしょうか
よって、
ドキュメントなしで他の人が痛い目にあって
多大な迷惑をかけた事に気が付いてない人
とかそんな感じじゃないっすか
0135デフォルトの名無しさん
2005/06/09(木) 16:44:49「そこまで金貰ってないし」
「ドキュメント無くても困るの俺じゃないし」
「他人がやってないのに自分だけドキュメント整備したら馬鹿みたい」
とか思ってドキュメント書かない人は多いのでは無いかと予想。
この場合、ドキュメントの重要性を理解しているかは問題ではないのでは？
0136デフォルトの名無しさん
2005/06/09(木) 16:52:05とか
0137デフォルトの名無しさん
2005/06/09(木) 17:02:53早々にドキュメント書くのに飽きて交代してもらうのも諦めそうな予感
0138デフォルトの名無しさん
2005/06/09(木) 17:26:120139デフォルトの名無しさん
2005/06/09(木) 19:12:460140デフォルトの名無しさん
2005/06/09(木) 19:14:430141デフォルトの名無しさん
2005/06/10(金) 00:15:57しっかりしたプログラムも素早く書けるのでは？
0142デフォルトの名無しさん
2005/06/10(金) 00:18:48まあドキュメント屋がソフトに関して完全に素人かといえばそんなことは
まったく無いだろうけどな
日本だとまったくコーディングできないS∃とかいう良くわからん
連中がいるよな
0143デフォルトの名無しさん
2005/06/10(金) 01:09:250144デフォルトの名無しさん
2005/06/10(金) 01:20:28http://www.aerith.net/design/comment-j.html
0145デフォルトの名無しさん
2005/06/10(金) 02:06:59あぁ。ソースをツールでフィルタリングしてコメント部分をドキュメントとしよう という流れなのか。
図式化ツールや静的解析ツールもつかうのかもね・・・
じゃあここでのドキュメントって内部構造／内部設計を記述したものを意味するのか
皆さん苦労しているのね・・・
0146デフォルトの名無しさん
2005/06/10(金) 02:11:02wikiは、専用のフォーマットな上、URLが一般的な名前空間じゃないので、
永続的なドキュメントには向かん。
まだ、素のHTMLの方が良くないか？
0147デフォルトの名無しさん
2005/06/10(金) 02:12:12別にそうとも限らんでしょ
でも、コメント元にツールで出力って一見ラクそうだけど
Java SDKのAPIドキュメントのようにそれなりに「ちゃんとした」文書にしたければ
かなりコメントかかんといかん。
が、ソースに直にそれぐらいの量の麗々しいコメント書いちゃうと、
リファクタリングの妨げになる。
で、結局専用のフェーズ設けて後でコメント入れだけしたり、ドキュメント出力
だけのためのソースを書いたり。
ぜんぜんラクになってねーよな。
0148デフォルトの名無しさん
2005/06/10(金) 02:12:56永続的なのじゃなくて、ちょっとしたメモや知識の共有や議事録とかにさ
0149デフォルトの名無しさん
2005/06/10(金) 02:14:20そういうのは流石にこのスレの趣旨から外れてないか
0150デフォルトの名無しさん
2005/06/10(金) 02:15:02議事録は永続化しないの？
羨ましい...
0151デフォルトの名無しさん
2005/06/10(金) 02:18:48だから必要なもののみをできるだけ短期間で書くのがよいのだが
実際はいらないものを長時間かけて書いている。
0152デフォルトの名無しさん
2005/06/10(金) 02:18:50重要度が1億倍ぐらい違う希ガス
前者はトラブったときの言質などにも利用される
0153デフォルトの名無しさん
2005/06/10(金) 02:20:10そうなんだよな。なんでそうなるんだろうな。
0154デフォルトの名無しさん
2005/06/10(金) 02:22:38・納品物だから
・ISO9000に準拠してるから
・プロセスがそうだから
とかかな。
0155デフォルトの名無しさん
2005/06/10(金) 02:25:37絞り込めてないってこったよな
プロセスがそうだから、はまあ論外だな
0156デフォルトの名無しさん
2005/06/10(金) 03:11:59他人のためのドキュメントはドキュメント屋に任せとけばOK
0157デフォルトの名無しさん
2005/06/10(金) 03:20:49ちっこいプロジェクトとか、
自分にドキュメント屋を付けてくれるような大きなプロジェクトならOK。
0159303
2005/06/11(土) 15:44:51テストコード（テストツール使うとか関係なく自前の単純なテスト用でも）
に、使用方法と、こんな使い方だめですよーとか。
こんな使い方するとあの処理に役立ちますーとか、そういうドキュメントのが
よくないかい？
0160デフォルトの名無しさん
2005/06/11(土) 19:44:07アクター図かイベント・フローぐらい付けて、そのコードの配置位置を示せよ
0161デフォルトの名無しさん
2005/06/16(木) 01:13:44金と引き換えなんだから、いるだろ
0162デフォルトの名無しさん
2005/06/16(木) 23:28:24みんな客が出してくる要件メモ程度の情報でコーディングやったりしてるの？
0163デフォルトの名無しさん
2005/06/16(木) 23:30:15結局客に見せながら作っていった方が早い。
0164デフォルトの名無しさん
2005/06/16(木) 23:42:210165デフォルトの名無しさん
2005/06/16(木) 23:53:15そんなことやっとったら仕様がハート様レベルまで膨れ上がって
金がかかりすぎてしまう
うちはとにかく仕様書を完備して向こうのハンコを押してもらうまで
仕事を始めないよ。
仕様バグの責任をやつらに押し付けるのが主目的。
おかげでここ数年はデスマーチとか無いな。
向こうがデスってヘルプ依頼で特急料金払うから助けてと
言ってくることはあるけど、そのときはもうこっちの言い値だな
0166デフォルトの名無しさん
2005/06/17(金) 00:07:41ただまあ責任を押しつける防衛的な手法は
良いソフトを作る方向とは違う感じだな・・。
0167デフォルトの名無しさん
2005/06/17(金) 00:11:29当社も同様。曖昧な仕様のプログラムなんて誰も組めないし
0168デフォルトの名無しさん
2005/06/17(金) 00:13:38聞く点はあるけど。「良い」って誰にとって？
発注側？受注側？
0169デフォルトの名無しさん
2005/06/17(金) 00:14:35だけど、結果論的になっちゃうけど、仕様を最初に
ガツガツ話し合って詰めた案件の方が
なぁなぁでやってるものよりもバグ総数も少ないし
仕様変更も当然だけどあまりないし、質が高いんだよな
0170デフォルトの名無しさん
2005/06/17(金) 00:17:51つぎはぎになっちゃうんだよな
「時代はXP」とかかっこいいこと言って仕様を次々変えてると
根っ子の変更とか飛び出したりしてますますデス丸。
あと、最後のドキュメント整備の時間が圧倒的に少なく済む。
冗談抜きで当社比100倍くらい、納品準備の手間が軽くなった。
0171デフォルトの名無しさん
2005/06/17(金) 00:26:59いざものができたら「これじゃ使いにくいに決まっているだろ」と言い出す顧客。
まぁ、そんときゃ「機能追加」と抱き合わせで修正掛けるけど。
0172デフォルトの名無しさん
2005/06/17(金) 00:33:04事前に前者という形で詰めることのメリットは、前者は顧客との共同作業であり
後者は往々にして相談なしに突っ走る(結果仕様の食い違いに気付くのが遅れて
コストが増える)でことなのかな。
ならやっぱXPでいうならオンサイト顧客だっけ? 大量の仕様定義を先にやらなくても
作りながら客自身に頻繁に確認とれればいいんだよなあ。
0173デフォルトの名無しさん
2005/06/17(金) 00:42:43> ある程度詳細なレベルの仕様定義はもはやプログラミングそのもの
それ、外部仕様書じゃなくて内部仕様書の話じゃないか？
顧客と取り決める外部仕様書のレヴェルでは、そこまで実装を
考慮する必要は無い、でしょ。
まったく実装を考えなくてもいいかといえば、それはそうじゃないけど、
技術的に可能か不可能か、どんな感じで実現できるか、工数はどれぐらい
かかるか、といったことが見えていればさしあたりは十分。
0174デフォルトの名無しさん
2005/06/17(金) 03:07:09ところが、外部仕様がかっちりきっちりキマると
内部仕様も釣られてきちんとキマってくるんだよ。
まるでふたつのおっぱいのように・・・
内部仕様はその時点で脳内にしか無いとしてもね。
ゴールがはっきり見えれば見えるほど
作業効率も上がるしね
0175デフォルトの名無しさん
2005/06/17(金) 09:44:55真面目な流れを無視するようで悪いがこれだけは言わせてくれ。俺も真面目だ。
> まるでふたつのおっぱいのように・・・
ふたつのおっぱいがきれいに揃っているほうが稀。
0176デフォルトの名無しさん
2005/06/17(金) 15:00:26と当たり前の結論に
0177デフォルトの名無しさん
2005/06/17(金) 17:49:110178デフォルトの名無しさん
2005/06/17(金) 17:51:22ただ大きければいいというものではないな。
0179デフォルトの名無しさん
2005/06/17(金) 19:08:26( ﾟ∀ﾟ)彡 おっぱい!おっぱい!
( ⊂彡
| |
し ⌒Ｊ
0180デフォルトの名無しさん
2005/06/17(金) 23:14:46誤解を招く書き方になってしまった。すまない。
外部仕様とは、ブラジャーなんだよ。
よいブラジャーはよいおっぱいを育てる。
人としてのサガなのか、どうしてもノーブラを求めてしまうが
それではすぐ型崩れを起こし、最後には垂れてしまうのだ。
おっぱいにあわせたよいブラジャーを作ることが、一見遠回りに見えるが
よいおっぱいを作り上げるための最短ルートなんです。
0181デフォルトの名無しさん
2005/06/17(金) 23:19:19もちろん、よいブラジャーに騙されるパターンもあるけど
逆に見た目だけでもおっぱいの価値を高められることの
良い証明になると思う。
あと、さらしやなんかで適当に巻いたおっぱいだけど
実はよいおっぱい というパターンもあるけど、これは
非常にまれで、実際にはよいおっぱいである例は少ない。
0182デフォルトの名無しさん
2005/06/18(土) 00:18:500183デフォルトの名無しさん
2005/06/18(土) 07:07:470184デフォルトの名無しさん
2005/06/18(土) 13:59:51今までの理論からすれば納得できる。
でも、完璧なコードなんて今まで見たこと無いからな・・・
ああ・・最近生でコードそのものを見てないな
生コード見てえなぁ・・・揉みたいなぁ生コード・・・
0185デフォルトの名無しさん
2005/06/18(土) 14:17:41作る時間が無駄だし、第一探す時間はもっと無駄だorz
0186デフォルトの名無しさん
2005/06/18(土) 15:54:09> 「完璧なコード」であれば、外部仕様は不要
そんなわけがあるか
コードが完璧でも客が読めなきゃ意味ねーだろ
0187デフォルトの名無しさん
2005/06/18(土) 16:01:15オレはいやなんだが おまえらはどうよ
0188デフォルトの名無しさん
2005/06/18(土) 16:14:52おっぱいの話はこちらでどうぞ↓
【GPL】ライセンス問題討論すれ4【BDSL】
http://pc8.2ch.net/test/read.cgi/linux/1107439063/l50
0189デフォルトの名無しさん
2005/06/18(土) 17:02:04ソースコードなのかな？
もっと全体→部分でいうところの、全体寄りのものなのでは？
ソースコードって所詮部分のレベルでしかないじゃん
0190デフォルトの名無しさん
2005/06/19(日) 00:17:37女性の全てと捉えるか、ただのパーツとして捉えるか
の違いだな
0191デフォルトの名無しさん
2005/06/21(火) 00:35:46コーディングされていないソフトウェアは使用することができない。
0192デフォルトの名無しさん
2005/06/21(火) 02:53:21OSSは？
×コーディングされていないソフトウェアは使用することができない。
○ソースコードが無いプログラムは保守する事が出来ない
0193デフォルトの名無しさん
2005/06/21(火) 03:03:07ドキュメントが整備されて無いOSSって大抵放置されてないか？
まぁ良く使われるからドキュメントも整備するんだって展開になると鶏と卵だけど。
0194デフォルトの名無しさん
2005/06/22(水) 13:05:10ドキュメント無しのOSSの場合、保守者＝開発者。
0195デフォルトの名無しさん
2005/08/05(金) 00:06:04・ファイルの先頭を「０バイト目」と書いたら「先頭は１バイト目である」と怒られた。
・データの遷移図で元データを右側に書いたら「元データは左側に書くべきである」と怒られた。
修正したがなんか納得できん
0196デフォルトの名無しさん
2005/08/05(金) 00:14:34ファイル先頭を0オリジンとするか1オリジンとするかは文化によって異なる。
ただし、単位が文字や行ならば1オリジンになることが多い。
0197デフォルトの名無しさん
2005/08/05(金) 09:48:18お前はものを数えるときに0から数えるのか？
アプリの内部形式では0から数えるとしても、客も見る設計書に書くの場合は
日常で使う1オリジンを使うべきだと思うが。
0198デフォルトの名無しさん
2005/08/05(金) 12:05:41こんど「下から上」というのを書いてみたら？
0オリジンは「先頭からの変位」を表現しているから、設計書にはそのような記述をすれば良かったと思うよ。
0199デフォルトの名無しさん
2005/08/05(金) 12:50:55だからこそ、左から右に綴るのが一般的なわけで。
逆に綴る言語が幾つかあるが、それらの国でも数値はアラビア数字で左から右に書く。
従って、左から右に図を書く方が理に適っている。
0200デフォルトの名無しさん
2005/08/05(金) 13:11:18違う。左から右へ視線移動するのは言語による。
左から右へ文章が記述されるヘブライ語とか
縦書き日本語とか
0201デフォルトの名無しさん
2005/08/05(金) 14:06:21言語に拠らずに左から右と聞いたのですよ。
目を瞑って歩くと自然と左に曲がっていくことと関連があるとかないとか。
0202デフォルトの名無しさん
2005/08/05(金) 18:29:02上から下と下から上、左から右と右から左、
どちらが書くときに楽かを考えれば答えはおのずと出るだろう。
もちろん右利きなことが前提だが。
ドキュメントをしっかり作るのもそれと同じことだ。
0203デフォルトの名無しさん
2005/08/06(土) 10:01:27とか言ってみたりする
0204デフォルトの名無しさん
2005/08/06(土) 15:21:30利き手も
0205デフォルトの名無しさん
2005/08/06(土) 15:27:57イマジネーションが必要な如意棒は左手で
0206デフォルトの名無しさん
2005/08/06(土) 15:33:130207デフォルトの名無しさん
2005/08/06(土) 18:21:570208195
2005/08/07(日) 01:52:25俺的には最終的に得られるものが何なのかを
真っ先に書いておいたほうが喜ばれると思ってた。
実はこの続きがあって、ＤＢの更新表でも
「カラム：値」と表記していたので、怒られたことを
踏まえて「値：カラム」と書き直したらまた怒られたorz
0209デフォルトの名無しさん
2005/08/07(日) 02:03:590210デフォルトの名無しさん
2005/08/07(日) 11:50:29もしその程度で怒られたのであれば、客がＤＱＮと考えたほうがよいかと。
0211デフォルトの名無しさん
2005/08/07(日) 14:41:590212デフォルトの名無しさん
2005/08/07(日) 16:19:340213デフォルトの名無しさん
2005/08/08(月) 00:19:24何故それを行う必要があるのかは分からない。
後者の部分に関しては、
なんらかの方法で明示されて無いとあとあと困る。
ドキュメント化でもコメント埋め込みでも、手段は問わないが。
でもそれはプログラムレベルの話ではないような気がする。
0214デフォルトの名無しさん
2005/10/30(日) 18:03:29一緒くたに書きながら設計するのが一番いいんでない？
正直ドキュメント読むのもめんどくせーんだが、
書かなきゃ、後半えらい事になる。
0215デフォルトの名無しさん
2005/10/31(月) 15:05:34手渡しで収めても誰が必要としてたのか判明しない
だれも読まないのだから当然だけど
IPAってドキュメント読んだ事あんのかね？ぜってードキュメントの体積しか見てない
誰かまっさらなA4用紙1袋を中に挟んで出してみてよ
0216デフォルトの名無しさん
2005/11/01(火) 00:58:330217デフォルトの名無しさん
2005/11/01(火) 04:22:34「うむ。ちゃんと字と図で埋まってるな。」
「おｋ、おｋ。」
ハンコポン！
・・・と、こんなもんだろな。
0218デフォルトの名無しさん
2005/11/01(火) 10:49:15まあ、１ｃｍで100万円くれるんだから、読んでいようがいまいが気にしない。
0219デフォルトの名無しさん
2005/11/04(金) 01:46:36（1987年度「最悪なスタイル賞」受賞作品 by Spencer Hines）
#include <stdio.h>
#include <malloc.h>
main(togo,toog)
int togo;
char *toog[];
{char *ogto, tgoo[80];FILE *ogot; int oogt=0, ootg, otog=79,
ottg=1;if ( togo== ottg) goto gogo; goto goog; ggot:
if ( fgets( tgoo, otog, ogot)) goto gtgo; goto gott;
gtot: exit(); ogtg: ++oogt; goto ogoo; togg: if ( ootg > 0)
goto oggt; goto ggot; ogog: if ( !ogot) goto gogo;
goto ggto; gtto: printf( "%d goto \'s\n", oogt); goto
gtot; oggt: if ( !memcmp( ogto, "goto", 4)) goto otgg;
goto gooo; gogo: exit( ottg); tggo: ootg= strlen(tgoo);
goto tgog; oogo: --ootg; goto togg; gooo: ++ogto; goto
oogo; gott: fclose( ogot); goto gtto; otgg: ogto= ogto +3;
goto ogtg; tgog: ootg-=4;goto togg; gtgo: ogto= tgoo;
goto tggo; ogoo: ootg-=3;goto gooo; goog: ogot= fopen(
toog[ ottg], "r"); goto ogog; ggto: ogto= tgoo; goto
ggot;}
0220デフォルトの名無しさん
2005/11/04(金) 05:44:44■ このスレッドは過去ログ倉庫に格納されています