ドキュメントの整備はコーディングより重要である

ドキュメントを書くのもプログラマの能力のうち。
プログラマならソース読んで理解しろなどと言うやつは
ドキュメントを書く能力がないだけ。
ドキュメントの作成はコーディングより重要なのである。

────────────　ひろゆき

つまりコードが読めないので、わかり易いドキュメントをキボンヌと。

ドキュメントの嘘を嘘と見抜けない人は（ｒｙ

あ（ry

＞ドキュメントの作成はコーディングより重要なのである。
そんなものは状況により。
盲目的に何々より重要であると書く人間は、バランス感覚が失調している。
偏った考えを断定して主張しようとする場合、
大概は心を病んでいるので、これ以上悪化する前にカウンセリングを受けた方がよい。

>>1
> ドキュメントを書くのもプログラマの能力のうち。
まあこれはプログラマに限らず、共同作業する際に問われる基本能力だわな。

ていうか、自然言語で適切にドキュメンテーションできない奴が
プログラミング言語で正確な表現が出来ているわけが無い。

>>1
重要性については同意。
しかし、中途半端なドキュメントでは、結局コードを見る羽目になる。

松本さんを全否定していますね。ヘラヘラ。

>>8
> しかし、中途半端なドキュメントでは、結局コードを見る羽目になる。
「結局コードを見る羽目になる」かどうかが判断でき、
ドキュメントが中途半端であれば、コードも信頼するに値しないであろうことが
ドキュメントを少し読んだだけで容易に判断できるようになる。


>>9
> 松本さんを全否定していますね。ヘラヘラ。

ドキュメントを書く能力がない奴⇒プログラマならソース読んで理解しろなどと言うやつ
は真である、というだけ。
>>1の言う
プログラマならソース読んで理解しろなどと言うやつ⇒ドキュメントを書く能力がない奴
の真偽については言及していない。

仕様(ここでは実装者が意図した動作)とコードとが一致していることを
第三者が確認する術がドキュメント以外にあるのであれば、
わざわざドキュメンテーションするのは冗長な作業になりますね。

> 第三者が確認する術がドキュメント以外にあるのであれば、
口頭とか？ でも口頭だと特定の第三者であって、任意の第三者では無いな。
まぁドキュメントがあっても特定の人しか読めないなら似たようなもんか。

ばーろー、(ちゃんと)動くシステム以上に重要なもんなんざありゃしねぇ。
それ以外は全部枝葉。トヨタ生産方式って知ってるか?

>>13
今はちゃんと動いていたとしても
将来拡張したり他の言語や環境に移植したりする可能性を考えると
やっぱりドキュメントがあった方が良い。

ドキュメントは古参SEの頭の中。

>>12
本当にコードを読むことで検証可能なものであれば、
コードだけでも良いのだと思います。
ただし実装者だけでその判断を行うことは不可能です。

だれが確認できれば良いか、というと、プロジェクトに従事する人
(将来的に従事することになる人も含む)が理解できれば最低限の事は足り、
例えばユーザレベルの人まで理解させなければならないドキュメントを書くべきかどうかは
コストも考慮した上で判断すべきでしょう。
そういう意味では、「特定の人しか理解できなくても良い」というのは誤りではないと思います。

あとは、例えばテストコードなども有用であると思います。
テストファーストにはこういった思想も含まれていると認識しています。

>>13
検証できなければちゃんと動くのかどうかすら分かりません。
ちゃんと動いているように見えているだけかもしれません。
容易な検証を可能にすることは、トヨタ生産方式の「自働化」において
メリットがあると思われますが。

　いかに多品種少量生産の現代といっても生産ラインは
システム構築ほど変化が激しくないでしょ。ライン設計に
外注何十人投入とか聞いた事ないし。変更のための
コミュニケーションも少なくてすむ。
　物理的でシーケンシャルな生産ラインと、システム構築を
同列にして語るのはいかがなモノか。

全てを同列にして語れるものでないというのは当然だが
共有できる知識が全く無いわけではない。

とりあえず
>>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

つぅか分かり易い凝ったドキュメントを書くよりも
誰が見ても理解できるソースコードを書く方が
効率的だし健全だ罠

>>19
>>7

いや、だから今日のプログラミング言語は自然言語に酷似しているので
ドキュメントなんて冗長な作業は不要。寧ろ丸投げしておいてユーザからの
クレームを後日FAQとして纏めた方が時間的に楽だ。ドキュメントの内容はユーザに書かせる。

(少なくとも、日本の技術者の大半が)論理的な物事を考える際に
日本語でなくプログラミング言語で思考するような状況になれば、
胸を張って
「ドキュメントなんてのは冗長な作業」
と言えるのではないか、と私も思います。

target.IsReady() というコードを読んだ奴に、
「この＊あいえすれでぃ＊っていう関数は何するの？」
って聞かれたときは、コードが自明でもだめなのかもしれないと思った。
ほどなく、そいつがバカなんだと気付いたけど。

owl.hがない。だれかくれ〜。あそべない〜。

そうだな〜。＞22賛成

そこでデザパタですよ

どこで？

>>27
owl.hがないところで。

>>18
すまんが俺は経営工学出身だから君が言いたい事は分かる。
そしてトヨタ生産方式とソフトウェア工学との相容れない部分も

ライブラリはドキュメントないとどうしようもない

>>30
前提が間違ってる。

まぁ、インターフェースのドキュメントがありゃいいだろ。

「コードなんか読めるか、ドキュメント書け」とかいっているやつの関数名や変数名は,
昔のベーシッくんやアセンブラの名残か、大文字6文字以内でなんだかわかんないのが多い
。

>>32
>>7

>>33
はぁ？

良いドキュメント・マニュアル・仕様書を書くスレ
http://pc8.2ch.net/test/read.cgi/tech/1065364445/

>>6が一番正しいと思った

現状が悪いと感じた場合、極端に逆の方向を主張したくなるのだろう。
従って極端な部分はとりあえず流しとけ。
議論すべきなのは方向性だ。
このスレにおいては
「現状、ドキュメントが軽視されすぎではなかろうか」
ということが相当する。

>>6
世の中の殆ど全てのことが状況に依るが、
そんなものを正しいといったところで何も進展はしない。

ドキュメントは第三者に公開する時には嫌でも必要になると思うけど

>>31
ライブラリって、たぶん「図書館」って意味で言ってるんだと思うよ。
（わざと）
図書館には文書が必須だよね、って洒落でいってんでしょ。
気づこうよ、それくらい。

あれ？ソースコードってドキュメントと違うの？

Windowsにはまともなドキュメントないよね
それでも俺らは特に気にしない
つまり誰も読まなきゃあっても意味が無い

読まれない文書なんてイランのですよ。

>>1
ところでドキュメントの整備がコーディングより重要だったら、どうしたいの？
強制的にドキュメントを読ませる方法でも教えてくれるのか？

>>41
Windows はユーザー向けのヘルプもあって、
開発向けにはMSDNにドキュメントが山ほどあるのに、
「ないよね」ってあんまりだろう。

>>40
>>22

>>41
msdnとかKnowledge Baseは立派な部類だと思うが。
ていうか読めよ。

ユーザから見たWindowsの事を言っているのであれば、
GUIやらWYSIWYGやらのドキュメントより有効な方法が織り込まれている
(し、ドキュメントが欲しければ購入できる)。

×Windowsにはまともなドキュメントないよね
○Windowsにはまともに読まれてるドキュメントないよね

>>42
読まなくて良い文章は書く必要が無いし読む必要も無い。
当然だと思うが？

読まなければならないのに、読まれない文書...

doc2codeを>>1が未踏で作るんだってさ。がんがれよ。PG/SEの70%を解雇させるキラーアプリになる悪寒。

みんなわざわざドキュメントなんて読みたくないんだよ
Windows上のアプリならUIがある程度補助になってくれるが、
ちょっとでもアウトローに走るとドキュメントか、
それに以上にわかりやすいUIを作る必要がある

その点、UNIX文化はドキュメント、最低でもman必須な時点でクソなんだよね
その最低限のmanさえほとんど用意されてなかったりクソ程にも役に立たないけど

昔のLinuxかしら？

>>50
あずいず

>>50
なんで man だけ知ってるんだろう

hey!man

>>49
ソースコードをわざわざ読むほうが
もっと嫌だ。

重要なのは仕様のドキュメントであって
コードの設計書とかは割りとどうでもいい
どうせツール使って解析するし

>>56
禿げ上がってしまったが同意

なにげに名スレ？

「このボタンをクリックしたら何が起こるか」っていうのが重要だよね。

コードはコードでいいけど、なんでそういうコードを書いたのかはドキュメント化してないと
後々メンテできなくて困るね
理由があって手間をかけた構成にしてあるのに、そこをいじって変なバグを作っちゃうのは
困るから

>>56
どこまでが仕様でどこからがコードの設計かって
明確に分けられないですよね…

仕様: どういう風に動いて欲しいか
設計: どういう風に動かすか

>>14>>18
何が重要なのかをつきつめていくと、最後に残るのはちゃんと動くシステムだけだ、とゆーつもりでした。
他は枝葉で、全ては必要性とそれをとりまく判断基準によって作成の可否が決定されるでしょう。(とゆーのがトヨタ生産方式の思想の一つ、と解釈している)
誰もが読む必要があるドキュメントが重要であることも、誰も読まないドキュメントが無駄であることも論をまたないわけで、そーゆー意味では>>6の意見をもって「終了」だったのかもしれづ。

>>63
> そーゆー意味では>>6の意見をもって「終了」だったのかもしれづ。

| >>37
| >>6
| 世の中の殆ど全てのことが状況に依るが、
| そんなものを正しいといったところで何も進展はしない。

>>62
全てを一から自分(達)で作り、
暗黙の前提条件や前提知識を許容しないのであれば
全く以ってその通りだと思います。

>>64
つまり、このスレ自体が無(ry
>>65
暗黙知を前提にして死亡したプロジェクトって数限りなくあ(ry

>>63
トヨタが言うところの生産とソフトウェア開発との最も顕著な違いのひとつとして
「全体の作業量に対する繰り返し作業を行う割合」があると思います。
この点だけを考えてみても、トヨタ生産方式をそのままソフトウェア開発に
適用できないことは容易に想像がつくでしょう。

極論を言うと、ソフトウェア開発における「トヨタ生産方式」というのは
単なる比喩に過ぎません。
とりあえず、>>18に挙げられているような本を読んでみてください。

おまえがトヨタ生産方式とやらを２、３行で要約すれば済む話だお

>>63
「不必要なものは作るな。必要になってから作れ」
これはその通りです。流行しているラピッドデベロップメントでもそういわれていると思います。
しかし、ドキュメントについて考えてみても
必要になってから作ろうと思っても作れないものもある、ということです。

>>66
> >>65
> 暗黙知を前提にして死亡したプロジェクトって数限りなくあ(ry
それが仕様と設計が明確に分けられない理由です。

>>68
私が2,3行で正しく要約できるようなものであれば、
恐らく、そもそも>>13が誤解するようなこともないでしょう。

>>67
比喩、というよりも、アジャイル開発とトヨタ生産方式の類似性に目を付け、アジャイル開発について、経営者や管理職に<del>ハッタリをかます</del>簡単にイメージさせるための道具、と考えています。
リーンソフトウェア開発については、ついこの間買って積ん読状態(ぉ
一応、これらはあくまで指針であって、適用分野に応じてカスタマイズ／最適化されるべきなのはわかってるつもり。(つもりかもしれんけど)
パレートの法則(20:80の法則)(原則?)にのっとり、20%の努力で80%救えればいいと思ってる。

>パレートの法則
逆もしかり
80%使い込んでしまったが20%しか終わってない...orz

>>68
トヨタ生産方式 ＝ 下請けは首を吊らない程度に絞り上げろ

>>60
コメントでいいじゃん

>>71
いるよね〜方法論だけの人って。使えないんだよ、はっきり言っちゃうと。

age

コメントがドキュメンテーションに含まれないなんて誰も言っとら〜〜〜ん！

ちょっとしたコメントだけだと構造までは見通せないしね

設計に使ったノートのコピー残しておくだけでも全然違うんだけどな。
あと、コードを書く前にどうしてそういうコードを書こうと思ったのかという
思考過程をなんらかの形で残しておくこと(メモ描きでもいいから)。

>>78
いやー、それやっても「アルジャーノンに花束を」の状態でなぁ…
我ながら困ったもんだよ。

アルジャーノンレベルならまだいい方
かゆうまレベルはマジでつかえねぇ

かゆうまって貴方w

かゆ…うま…がどれくらい酷いのかよくわからんが、
自分がそうでないことを祈るよ。

コードを読む訓練がされていない人間が多すぎ。
自分が過去に書いたコードすら読めないなんてのは愚の骨頂だぞ。
これじゃぁドキュメントがないと生産性が上がらないのは仕方ない。
しかし、ドキュメント書くにも手間がかかるわけで、そういう人は
生産性低いよ。コードを読むことが軽視されすぎている。

コードが読めない人が多いというのはどっからきたんだ？

なんとなく

> プログラマならソース読んで理解しろなどと言うやつは
>ドキュメントを書く能力がないだけ。

逆に言わせて貰うと、プログラマならドキュメントを書けというやつは
コードの読解能力がないだけ。

どういう動作をするのかはコードを読めば誰でもわかる。
最近はデバッガが整備されて、ステップ実行なども簡単にできる環境も多いしね。
問題は、どういう意図で書かれたのかだ。

なんか土方コーダの視点でのみドキュメントについて語ってる
視野狭窄なアフォばっかだな
クライアントに対する仕様書やマニュアルは必要だろ

内部構造の設計書が必要かどうかは状況によるけどな

意図とか経緯とかはコードだけじゃわからんよな。
もっとも重要なのは、「そのコードで正しいのか」がコードだけでは
わからんのだ。そのプログラムはクラッシュしないかもしれないし
非常に高速に動作するかも知れないが、仕様通りでないのなら意味が無い。

だからドキュメントは必要。

>>82
設計の根拠について話をしてたんだけど

>自分が過去に書いたコードすら読めないなんてのは愚の骨頂だぞ。

ってなんか関係あるの？
だれも自分のコードが読めないって話をしてるわけではなかったんだが。

>>86
あなたのその書き込みの意図が判りませんので、ドキュメント化してください。

>>87
そういう企画の話してんじゃねーだろ。空気嫁アフォ土方野郎。

底辺PGばっか揃っている会社は大変だねｗ
そのコードの意図がわかんねーときたよｗ
ご愁傷様。

>>92
コードだけじゃ意図がわからんことはあるだろ
エスパーでもない限り

>>91
企画と仕様書はちげーよ

>>82
いや、実際のコードを読まないと理解できないような職場は非常に生産性が悪いと思う。
普通は、ドキュメントや議事録を読めば仕様くらいは理解できるように整備するものだ。

>>95
いや、ドキュメントを読まないとコードの意味が判らないようなコードを書く
書き手の能力不足や、読み手の読解力不足について語っている。
そんな職場は非常に生産性が悪いと思う。
ドキュメントを整理する前に人員を整理したほうがいいだろう。

>>96
お前、ドキュメントがなにか分かってないだろｗ

荒す意図はないんだけど・・・古い格言をひとつ
「地図と現実の地形が異なる場合は、現実の地形を信じろ」

コードを読む能力を獲得する唯一の方法は、コードを書く能力を獲得する事です。

例外／反証　を希望

地図は、実際の地形を調べて作成したもの。
ソフト開発においては、わけのわからんプログラムを解析して
作成されたドキュメントのようなものだな。

>>99
コードを書く能力を獲得する唯一の方法は、
コードを読む能力を獲得する事です。

卵が先か？ 鶏が先か？

>>98
荒す意図はないんだけど・・・新しい格言をひとつ
「マニュアルと現実の動作が異なる場合は、
マニュアルを信じろ」

だー、前提も何も定義せずに何かゆーても意味ねー。
どーみても各自「ドキュメント」という語でイメージしてるモノが違ってるでしょーがー。

ソースコードを書き換えて遊ぶんだが、
サブルーチンで何やってるかとか、
if構文で何をしてるかぐらいがわかればいい

>>101
おお。なんか触発されました。（最初はチャカシのように思えたけれど）
他者のコードを一行も読まずにまともなコードを書ける様になった人はいない　という事実も併せて考えると・・・
書けるようになったから読めるようになった　とか　読めるようになったから書けるようになった
という２パターンしか無いと思います。そこで新見解
「コードを読む能力とコードを書く能力は不可分。硬貨の表裏」
どうでしょうか？

>>105
正解！

世界で一番はじめにコードを書いた人は他人のコードなんて読んでないよ

>>107
うーん、おもしろくない

>>107
だからこそ天才なんだよ。
凡人は他人から学ぶのさ。

>>109
あんた大人だなー

おそらく最初のユーザーである言語設計者は全員が天才なのか？

ドキュメントって言っても
提案書からコード設計まで色々あるしな

上のレスで散々言われてるけど
「システムがどういう動きをするのか(コードはどういう動きをするのか)」
は比較的簡単に解析できる
「システムはどういう動きをすべきなのか(どういう意図でそのコードを書いたのか)」
はドキュメントがしょぼいとどうにもならなくなる

個人的にはコード設計はまぁあんまり重要では無いと思う
頻繁に変更があったりするし、納品しても顧客は見やしないし
ツールでコードから仕様書つくれるしね

>>113
取説まで含む流れのようだったのだけど

コード設計はある程度は良質なコメントがあればかわりが効くよな。
ドキュメント生成ツールはいろいろあるわけだし。
コード読めば分かるようなコメントはいらないが、
自明でない個所にはちゃんと説明をつけて欲しい。

自動生成されたドキュメントは、納品物の量を稼ぐため以上の役には立たないしな。

どうせ誰も読まないし・・・が積み重なって今の状況があるわけだ。
ＩＳＯなんかちゃんちゃらおかしいぜ

doxygen 使っとけ

doxygenでも、コメントは入れんと要かんわな。

117、地味なマルチポストだなあ

>>112
コード設計は顧客はロクに見ないが、次に引き継ぐ人間なら確認するのが前提だろうな。
ドキュメントを読んだ上で、実際のソースを読んだ方が「どう違うのか」が大体把握できる。
逐一、スパゲティコードを読み解いて「どうなっているのか」を解析していくよりは、大まかな全体像が
掴めている分だけ作業的には楽。引き継ぐ人間が以前と同じなら、本当に無用の長物だが。

>>114
その線引きが難しいんだよな…。「誰にとって」自明かどうかは完全に主観だから。
経験則で申し訳ないが、優れたコメントはピンポイントなものが多いのではないかな。
あれば問題なく分かるが、無ければ無駄に悩むことになるような（ある意味でイレギュラーな）箇所に
コメントを付記しておくことは必要だろう。

三ヵ月前の自分は他人

まあ結局コーダにはドキュメントの重要性はわからんのだろうな。

>>122
いや土方コーダでも他人の仕事を引き継ぐ機会はあるから
ドキュメントの重要性は認識できるはず

要は自分が誰も読みもしないドキュメントを書くのが面倒なだけ

>>123
自分が読むだろ・・・

>>124
納めた後は読まない香具師が多いと思う...

>>125
保守する気無しかよ・・・

>>126
自分で保守するんなら、大半のドキュメントは必要ないよ...

>>123
要約すると、後は野となれ山となれっつー姿勢でいる奴は
ドキュメントの重要性を認識していてもドキュメントを書かないって事？

コメントは日記なんだよ。
ブログなんていうオナニー文章書く暇あるんだったら
ソースコードに感想文を付記しとけ。

三ヵ月前の他人は自分

あ〜、君はコーディングの方はもういいからドキュメントの方やっといて。

>>128
>後は野となれ山となれっつー姿勢でいる奴は
>ドキュメントの重要性を認識していてもドキュメントを書かないって事？
そうゆうやつはドキュメントの重要性を認識していないやつ
ドキュメントなしで痛い目にあったことがない奴

>>130
昨日の自分は他人

晩飯すら思い出せんorz

>>132
痛い目にあってないんだったら
それは素晴らしい事です
プロジェクト管理能力や顧客のコントロール力が
ずば抜けてるという事ではないでしょうか

よって、
ドキュメントなしで他の人が痛い目にあって
多大な迷惑をかけた事に気が付いてない人
とかそんな感じじゃないっすか

>>134
「そこまで金貰ってないし」
「ドキュメント無くても困るの俺じゃないし」
「他人がやってないのに自分だけドキュメント整備したら馬鹿みたい」
とか思ってドキュメント書かない人は多いのでは無いかと予想。

この場合、ドキュメントの重要性を理解しているかは問題ではないのでは？

もう飽きたから交代してもらうためにドキュメントを書く
とか

>>136
早々にドキュメント書くのに飽きて交代してもらうのも諦めそうな予感

ドキュメント書きを交代してもらおう

プログラムは組めないけど、ドキュメントは書けます

しっかりしたドキュメントを素早く書けるなら専門職としてもやっていけるだろう。

しっかりしたドキュメントを素早く書けるなら、
しっかりしたプログラムも素早く書けるのでは？

MSみたいなデカいとこだとドキュメント屋がいるだろ
まあドキュメント屋がソフトに関して完全に素人かといえばそんなことは
まったく無いだろうけどな

日本だとまったくコーディングできないS∃とかいう良くわからん
連中がいるよな

wikiつかおうよ

技術者の評価を下げる「悪い」コメントに注意しよう
http://www.aerith.net/design/comment-j.html

なんでコメントの話がこんなに・・・
あぁ。ソースをツールでフィルタリングしてコメント部分をドキュメントとしよう　という流れなのか。
図式化ツールや静的解析ツールもつかうのかもね・・・
じゃあここでのドキュメントって内部構造／内部設計を記述したものを意味するのか
皆さん苦労しているのね・・・

>>143
wikiは、専用のフォーマットな上、URLが一般的な名前空間じゃないので、
永続的なドキュメントには向かん。

まだ、素のHTMLの方が良くないか？

> じゃあここでのドキュメントって内部構造／内部設計を記述したものを意味するのか
別にそうとも限らんでしょ

でも、コメント元にツールで出力って一見ラクそうだけど
Java SDKのAPIドキュメントのようにそれなりに「ちゃんとした」文書にしたければ
かなりコメントかかんといかん。
が、ソースに直にそれぐらいの量の麗々しいコメント書いちゃうと、
リファクタリングの妨げになる。
で、結局専用のフェーズ設けて後でコメント入れだけしたり、ドキュメント出力
だけのためのソースを書いたり。
ぜんぜんラクになってねーよな。

>>146
永続的なのじゃなくて、ちょっとしたメモや知識の共有や議事録とかにさ

>>148
そういうのは流石にこのスレの趣旨から外れてないか

>>148
議事録は永続化しないの？
羨ましい...

ドキュメントは本質的にオーバーヘッド。
だから必要なもののみをできるだけ短期間で書くのがよいのだが
実際はいらないものを長時間かけて書いている。

顧客打ち合わせの議事録と内部ミーティングの議事録では
重要度が1億倍ぐらい違う希ガス

前者はトラブったときの言質などにも利用される

>>151
そうなんだよな。なんでそうなるんだろうな。

さぁ

・納品物だから
・ISO9000に準拠してるから
・プロセスがそうだから
とかかな。

納品物だからってのは、結局契約時に本当に必要なものなのか、が
絞り込めてないってこったよな

プロセスがそうだから、はまあ論外だな

自分のために書くものだろ
他人のためのドキュメントはドキュメント屋に任せとけばOK

>>156
ちっこいプロジェクトとか、
自分にドキュメント屋を付けてくれるような大きなプロジェクトならOK。

>>151
>>11

ソースのドキュメントってそんなに入らない気がする。
テストコード（テストツール使うとか関係なく自前の単純なテスト用でも）
に、使用方法と、こんな使い方だめですよーとか。
こんな使い方するとあの処理に役立ちますーとか、そういうドキュメントのが
よくないかい？

そんなんじゃ、なんでそのコードが必要なのか、わかんねぇだろ
アクター図かイベント・フローぐらい付けて、そのコードの配置位置を示せよ

>実際はいらないもの
金と引き換えなんだから、いるだろ

このスレではスレタイと正反対の意見が主流みたいだけど、
みんな客が出してくる要件メモ程度の情報でコーディングやったりしてるの？

どうせすぐに仕様変わってしまうんだから
結局客に見せながら作っていった方が早い。

そして、仕様が膨れ上がるんだ。

>>162
そんなことやっとったら仕様がハート様レベルまで膨れ上がって
金がかかりすぎてしまう

うちはとにかく仕様書を完備して向こうのハンコを押してもらうまで
仕事を始めないよ。
仕様バグの責任をやつらに押し付けるのが主目的。

おかげでここ数年はデスマーチとか無いな。
向こうがデスってヘルプ依頼で特急料金払うから助けてと
言ってくることはあるけど、そのときはもうこっちの言い値だな

>>165
ただまあ責任を押しつける防衛的な手法は
良いソフトを作る方向とは違う感じだな・・。

>>165
当社も同様。曖昧な仕様のプログラムなんて誰も組めないし

>>166
聞く点はあるけど。「良い」って誰にとって？
発注側？受注側？

>>166
だけど、結果論的になっちゃうけど、仕様を最初に
ガツガツ話し合って詰めた案件の方が
なぁなぁでやってるものよりもバグ総数も少ないし
仕様変更も当然だけどあまりないし、質が高いんだよな

仕様変更だらけだと、時間に追われやすいこともあって
つぎはぎになっちゃうんだよな
「時代はXP」とかかっこいいこと言って仕様を次々変えてると
根っ子の変更とか飛び出したりしてますますデス丸。

あと、最後のドキュメント整備の時間が圧倒的に少なく済む。
冗談抜きで当社比100倍くらい、納品準備の手間が軽くなった。

処が、仕様策定段階ではものがないからそのまま通す癖に、
いざものができたら「これじゃ使いにくいに決まっているだろ」と言い出す顧客。
まぁ、そんときゃ「機能追加」と抱き合わせで修正掛けるけど。

ある程度詳細なレベルの仕様定義はもはやプログラミングそのものだよな
事前に前者という形で詰めることのメリットは、前者は顧客との共同作業であり
後者は往々にして相談なしに突っ走る(結果仕様の食い違いに気付くのが遅れて
コストが増える)でことなのかな。

ならやっぱXPでいうならオンサイト顧客だっけ? 大量の仕様定義を先にやらなくても
作りながら客自身に頻繁に確認とれればいいんだよなあ。

>>172
> ある程度詳細なレベルの仕様定義はもはやプログラミングそのもの

それ、外部仕様書じゃなくて内部仕様書の話じゃないか？
顧客と取り決める外部仕様書のレヴェルでは、そこまで実装を
考慮する必要は無い、でしょ。
まったく実装を考えなくてもいいかといえば、それはそうじゃないけど、
技術的に可能か不可能か、どんな感じで実現できるか、工数はどれぐらい
かかるか、といったことが見えていればさしあたりは十分。

>>173
ところが、外部仕様がかっちりきっちりキマると
内部仕様も釣られてきちんとキマってくるんだよ。
まるでふたつのおっぱいのように・・・
内部仕様はその時点で脳内にしか無いとしてもね。

ゴールがはっきり見えれば見えるほど
作業効率も上がるしね

>>174
真面目な流れを無視するようで悪いがこれだけは言わせてくれ。俺も真面目だ。

> まるでふたつのおっぱいのように・・・
ふたつのおっぱいがきれいに揃っているほうが稀。

つまり顧客とのマメなコミュニケーションが大事ですよ
と当たり前の結論に

綺麗なおっぱいは貴重ですよ。と当たり前の結論に。

うむ、こじんまりとしたおっぱいは貴重だ。
ただ大きければいいというものではないな。

　　　 _ 　∩
　　(　ﾟ∀ﾟ)彡　おっぱい!おっぱい!
　　(　 ⊂彡
　 　|　　　|　
　 　し ⌒Ｊ

>>175
誤解を招く書き方になってしまった。すまない。

外部仕様とは、ブラジャーなんだよ。

よいブラジャーはよいおっぱいを育てる。
人としてのサガなのか、どうしてもノーブラを求めてしまうが
それではすぐ型崩れを起こし、最後には垂れてしまうのだ。
おっぱいにあわせたよいブラジャーを作ることが、一見遠回りに見えるが
よいおっぱいを作り上げるための最短ルートなんです。

補足：
もちろん、よいブラジャーに騙されるパターンもあるけど
逆に見た目だけでもおっぱいの価値を高められることの
良い証明になると思う。
あと、さらしやなんかで適当に巻いたおっぱいだけど
実はよいおっぱい というパターンもあるけど、これは
非常にまれで、実際にはよいおっぱいである例は少ない。

外形／外観より性能　ｗ

やはり、コンパクトなのが一番だな。

「完璧なコード」であれば、外部仕様は不要 というのは
今までの理論からすれば納得できる。
でも、完璧なコードなんて今まで見たこと無いからな・・・

ああ・・最近生でコードそのものを見てないな
生コード見てえなぁ・・・揉みたいなぁ生コード・・・

少なくともメンテすりゃいいドキュメントをバージョンごとに新規で作るのは止めてほしい・・・。
作る時間が無駄だし、第一探す時間はもっと無駄だorz

>>184

> 「完璧なコード」であれば、外部仕様は不要

そんなわけがあるか
コードが完璧でも客が読めなきゃ意味ねーだろ

ところで、GPLは人のおっぱいを横からいじくりまわすので
オレはいやなんだが おまえらはどうよ

>>187
おっぱいの話はこちらでどうぞ↓

【GPL】ライセンス問題討論すれ4【BDSL】
http://pc8.2ch.net/test/read.cgi/linux/1107439063/l50

1で言ってるドキュメントって、粒度ってゆーか枠ってゆーかそんな視点で見たとして
ソースコードなのかな？
もっと全体→部分でいうところの、全体寄りのものなのでは？
ソースコードって所詮部分のレベルでしかないじゃん

おっぱいを
女性の全てと捉えるか、ただのパーツとして捉えるか
の違いだな

ドキュメント整備されていないソフトウェアは保守することができない。
コーディングされていないソフトウェアは使用することができない。

>ドキュメント整備されていないソフトウェアは保守することができない。
OSSは？

×コーディングされていないソフトウェアは使用することができない。
○ソースコードが無いプログラムは保守する事が出来ない

>>192
ドキュメントが整備されて無いOSSって大抵放置されてないか？
まぁ良く使われるからドキュメントも整備するんだって展開になると鶏と卵だけど。

>>192
ドキュメント無しのOSSの場合、保守者＝開発者。

設計書を書いて客とレビューした。

・ファイルの先頭を「０バイト目」と書いたら「先頭は１バイト目である」と怒られた。
・データの遷移図で元データを右側に書いたら「元データは左側に書くべきである」と怒られた。

修正したがなんか納得できん

図の類は左から右が原則。
ファイル先頭を0オリジンとするか1オリジンとするかは文化によって異なる。
ただし、単位が文字や行ならば1オリジンになることが多い。

>>195
お前はものを数えるときに0から数えるのか？
アプリの内部形式では0から数えるとしても、客も見る設計書に書くの場合は
日常で使う1オリジンを使うべきだと思うが。

「左から右」つうのは、「文をそういう方向に書く人の方が多いから」が理由だと思うな。
こんど「下から上」というのを書いてみたら？

0オリジンは「先頭からの変位」を表現しているから、設計書にはそのような記述をすれば良かったと思うよ。

実は、人間は上から下、左から右に視線を移動するものらしい。
だからこそ、左から右に綴るのが一般的なわけで。
逆に綴る言語が幾つかあるが、それらの国でも数値はアラビア数字で左から右に書く。
従って、左から右に図を書く方が理に適っている。

>>199
違う。左から右へ視線移動するのは言語による。
左から右へ文章が記述されるヘブライ語とか
縦書き日本語とか

>>200
言語に拠らずに左から右と聞いたのですよ。
目を瞑って歩くと自然と左に曲がっていくことと関連があるとかないとか。

自分の手首を動かしてみるといい。
上から下と下から上、左から右と右から左、
どちらが書くときに楽かを考えれば答えはおのずと出るだろう。
もちろん右利きなことが前提だが。
ドキュメントをしっかり作るのもそれと同じことだ。

運動力学的視点からは、手は外側に動かすより内側に動かす方が力が入る
とか言ってみたりする

結局、右脳と左脳の働きの違いだろ？
利き手も

だから、正確な操作のマウスは右手で
イマジネーションが必要な如意棒は左手で

左利きが多いヤンキーは左脳が劣っている香具師が多いって事なのか！

右脳が優れている？

>>198
俺的には最終的に得られるものが何なのかを
真っ先に書いておいたほうが喜ばれると思ってた。

実はこの続きがあって、ＤＢの更新表でも
「カラム：値」と表記していたので、怒られたことを
踏まえて「値：カラム」と書き直したらまた怒られたorz

そりゃ怒られる。つーか、呆れられるな。

怒られたって、単に指摘されただけでは？
もしその程度で怒られたのであれば、客がＤＱＮと考えたほうがよいかと。

↓よく訓練されたドキュンメイト

doxygen

ソース読んだら何を行ってるのかは分かるけど、
何故それを行う必要があるのかは分からない。
後者の部分に関しては、
なんらかの方法で明示されて無いとあとあと困る。
ドキュメント化でもコメント埋め込みでも、手段は問わないが。

でもそれはプログラムレベルの話ではないような気がする。

説明書と仕様の草案、
一緒くたに書きながら設計するのが一番いいんでない？

正直ドキュメント読むのもめんどくせーんだが、
書かなきゃ、後半えらい事になる。

誰用に作るドキュメントなのか作ってる奴等は知らない。
手渡しで収めても誰が必要としてたのか判明しない
だれも読まないのだから当然だけど

IPAってドキュメント読んだ事あんのかね？ぜってードキュメントの体積しか見てない
誰かまっさらなA4用紙1袋を中に挟んで出してみてよ

パラパラめくるぐらいはするのでは？

パラパラ・・・
「うむ。ちゃんと字と図で埋まってるな。」
「おｋ、おｋ。」
ハンコポン！

・・・と、こんなもんだろな。

>>215
まあ、１ｃｍで100万円くれるんだから、読んでいようがいまいが気にしない。

サンプルコード
（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;}

圧縮率よさそうでつな