2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

ソースコードを日本語訳したレベルの詳細設計書ってどう? [無断転載禁止]©2ch.net

1 :仕様書無しさん:2016/09/26(月) 22:56:23.89
これって普通なん?

2 :仕様書無しさん:2016/09/26(月) 23:08:52.90
それは設計書じゃなくて、
ソースを変換しただけじゃないの?

簡潔でわかりやすい詳細設計書というのは、
ソースを作るよりずっと時間がかかるんだよ。

3 :仕様書無しさん:2016/09/26(月) 23:09:49.20
おれの経験では、
詳細設計書に3日かけたところは、
ソースを打ち込むのは1時間とか、
そんな感じ。

4 :仕様書無しさん:2016/09/27(火) 00:58:24.41
詳細設計という紙が大事なんじゃなくて
そこに詰め込まれているアイデアや予想、下調べの積み重ねが大事なんだよ
いきなりコーディングをはじめるやつは、ソースをいじりながら設計してるだけ
紙とエクセルとコードのどれで設計するかは個性の問題だろう
結局はアウトプットで勝負するしかないのだから

5 :仕様書無しさん:2016/09/27(火) 01:11:11.68
設計が悪ければ、いくらコードを書いてもやり直しだ。

6 :仕様書無しさん:2016/09/27(火) 02:59:17.95
設計書書くよりコード書いてる方が実際の動きが読めるんだけど
設計書じゃ矛盾ないように書かれてるけど、実際コード書くと矛盾が見えてきたり
コード書く前に完璧な設計書ってできてるの見たことないわ

7 :仕様書無しさん:2016/09/27(火) 03:12:17.41
設計が悪いとは、そもそもの実装の方向性から間違ってるという意味で、
コードで矛盾を修正したところで設計は良くならない。
適切な設計ならコード量が1/10になったりする。

8 :仕様書無しさん:2016/09/27(火) 06:57:03.99
詳細設計書とかいらねえから適切な要件定義書を残しておいてください(小声)

9 :仕様書無しさん:2016/09/27(火) 08:22:42.08
要件曖昧ズブズブなお仕事
楽しいです(^q^)

10 :仕様書無しさん:2016/09/28(水) 00:03:56.17
>>6
考えてから書けって言ってるだけだよ
紙やエクセルシートが大事だとは言ってない
コードを書きながら考えるという手法も間違ってないよ
もちろん、削除して書き直しだけどね(失敗した設計図の紙を丸めて捨てるように)

ある程度の経験を積めば、コードを書かないとわからないってことは
ほとんどなくなるんだろうね
毎回同じようなものを書いてると特にね

11 :仕様書無しさん:2016/09/28(水) 21:27:17.82
>>10
学ぶことをやめたジジイおつ

12 :仕様書無しさん:2016/09/28(水) 23:41:28.66
考えてからコーディングしないと飽きるよ

13 :仕様書無しさん:2016/10/01(土) 23:01:25.39
で、詳細設計書には結局なに書けばいいの?

14 :仕様書無しさん:2016/10/01(土) 23:03:14.59
疑似コードとコメント書いてますよw

15 :仕様書無しさん:2016/10/02(日) 19:27:50.93
>>6
それはあなたの経験が足りないから。

16 :仕様書無しさん:2016/10/02(日) 19:31:22.28
>>13
コードを見なくても作りがわかるドキュメント

17 :仕様書無しさん:2016/10/02(日) 21:49:15.46
結局コード読めない人でもレビューできるようにするための文書でしょ。
実装の上では全く不要な代物。

18 :仕様書無しさん:2016/10/02(日) 21:54:09.27
>>13
そこには処理を箇条書きにして、何を入力にして何を出力するのか書くんじゃね?

19 :仕様書無しさん:2016/10/02(日) 22:22:23.48
それは構成仕様

20 :仕様書無しさん:2016/10/02(日) 22:35:13.82
改修作業請け負ったものの設計書が影も形も存在せず
とりあえずの体裁としてVB和翻訳設計書を書かされる羽目になった思い出

コード自体当時の担当者を(自主規制)したくなるほどのクオリティだったが
それはまた別の話

21 :仕様書無しさん:2016/10/03(月) 06:00:33.83
>>17
実装なら設計書ありきの話だろ。

プロは設計に時間をかけて、コーディングは超短時間で終わる。

22 :仕様書無しさん:2016/10/03(月) 08:14:36.61
設計を頭の中でするっていう人はいるかもしれないけど
設計せずに実装する人はいないよね?
コーディングしながら書き換えていくっていうのは
経験のない初心者なら仕方ないけど・・・

23 :仕様書無しさん:2016/10/03(月) 10:15:14.88
どんなに、きちんとした日本語だとしても解釈問題って永久に消えない。
だから、ユーザー現場で開発するアジャイルが一番なんだよ。

24 :仕様書無しさん:2016/10/03(月) 20:09:06.04
>>23
アジャイルというよりスパイラルだけどな。

アジャイルは技術的検証が必要な小さなものになら向いているが、そうでなければうまくいかない。

もともと欧米人は文章だけの資料を作りたがるから、認識がなかなか合わない。

だからアジャイルなんてものが出てくるw

25 :仕様書無しさん:2016/10/03(月) 21:14:02.87
改修だったら事前に絶対ソース見る訳だから

コーディングせずに設計するって
直し方分かってるのにその場は我慢してまず紙に書いておいて
改めてもう一度ソースに戻るってだけだよな

特にオリジナルのソースが汚い場合にはこの方法はキツイ

26 :仕様書無しさん:2016/10/04(火) 00:08:34.26
改修の一番最初の段階(現場レベル)ってのは
既存バグの修正やリファクタリングだろ?

27 :仕様書無しさん:2016/10/04(火) 01:53:26.74
>>26
リファクタリングはありえない。

いきなり仕様が勝手に変わる、障害がおきる可能性もあるし。

リファクタリングは何か改修のついでにやる程度。

もう本番が動いているものに対してはリスクが大きすぎる。

28 :仕様書無しさん:2016/10/04(火) 06:49:43.47
>>26
リファクタリングはありえる

リファクタ無き強引な改修はさらなるバグを誘発、将来の改修が更に困難になることも

29 :仕様書無しさん:2016/10/04(火) 08:31:14.51
動いてるもん弄るな。

30 :仕様書無しさん:2016/10/04(火) 22:43:38.16
これから弄るんだからリファクタリングしたっていいんだよ
どうせ最終的にはテストするんだからな

31 :仕様書無しさん:2016/10/05(水) 01:52:02.65
>>28
それはリファクタリングではなく作り替え。

32 :仕様書無しさん:2016/10/05(水) 05:03:20.48
リファクタリングができない是即ち動いてるのが奇跡だからで候

33 :仕様書無しさん:2016/10/05(水) 05:52:26.15
>>6
> コード書く前に完璧な設計書ってできてるの見たことないわ

それはお前が若いからだ。
おそらく30代ぐらいまでで、簡易言語やWeb系やってる人のなかには
見たことないってのも沢山いると思う。

それは時代の流れで
しかたのないことかもしれない。

みんながドキュメント書けない(書かない)馬鹿プログラマに
なってゆくんだよ。

34 :仕様書無しさん:2016/10/05(水) 06:57:33.71
>>31
リファクタリング=作り替えw
脳みそ動いてますか?

35 :仕様書無しさん:2016/10/05(水) 06:59:49.68
>>33

>みんながドキュメント書けない(書かない)馬鹿プログラマに
なってゆくんだよ。

ここまでくると宗教のような洗脳ですね
ドキュメント教w

36 :仕様書無しさん:2016/10/05(水) 08:35:04.22
必要に応じて必要な粒度で作りゃいいだけのことじゃないかね
俺の職場では納品物として形だけ作る文化だぜ、アプリ作った後にな

37 :仕様書無しさん:2016/10/05(水) 19:18:07.82
いまはもうないがプログラム設計書のことを詳細設計書というやつがいるけど、それがソースコードを言葉で書いたようなものなんだよな。

38 :仕様書無しさん:2016/10/05(水) 19:25:09.17
ソースコードをただ日本語訳したようなものは設計書ではない。

そんな設計書があるなら、それは設計自体がおかしい。

39 :仕様書無しさん:2016/10/05(水) 20:25:04.94
>>21
設計に時間かけるのは分かるけど、ソースの日本語訳レベルの設計書が必要って言ってるならあなたはかなりハイレベルだと思う。

40 :仕様書無しさん:2016/10/05(水) 20:47:07.99
>>39
デマゴーグ

41 :仕様書無しさん:2016/10/05(水) 21:11:10.68
NASAなんかでは、プログラマは余計なことを考えず仕様書をただひたすらプログラムコードに変換するだけの存在らしい
仕様書の品質についてどうやって保ってるのかは知らないが

42 :仕様書無しさん:2016/10/05(水) 21:26:15.96
>>39
そんなコードそのままみたいな設計書はいらないけど、プログラマでも低レベルのコーダーにやらせるとなると、サンプルプログラムがないとひどいものにはなる。

だからいまは詳細設計とコーディングは同じひとがやるのが普通だけど、汎用機の世界のひとや年配は、いまだにプログラム設計書レベルの設計書を作るよな。

43 :仕様書無しさん:2016/10/05(水) 21:27:58.17
>>41
それは一部の人間だろw

どうせインド人だろうな。

44 :仕様書無しさん:2016/10/05(水) 21:30:24.52
それと仕様書と設計書の違いが分からない人間がいるのは万国共通らしい。

45 :仕様書無しさん:2016/10/05(水) 22:41:28.78
紙→鉄に変わる機械の製造のと違って
記号→記号だからな

変数とか関数とかエディタ介した方が見やすいし

46 :仕様書無しさん:2016/10/05(水) 23:08:37.12
モジュールなりクラスの入出力を「厳格に」決めればいいだけだろ。
使用したアルゴリズムをコメント2,3行で書いとけばいい。

47 :仕様書無しさん:2016/10/05(水) 23:10:32.15
>>41
なんだNASAの真似をすれば良いわけか。
簡単そうだな。

48 :仕様書無しさん:2016/10/05(水) 23:11:49.93
いきなりエクセル使って設計すんな。
なんどもエクセル書き直して
恥ずかしいと思わんのか?

49 :仕様書無しさん:2016/10/06(木) 00:54:47.95
>>44
テスト仕様書とテスト設計署の違いを説明できる人をまだ見たことがない

50 :仕様書無しさん:2016/10/06(木) 06:36:58.98
>>49
前者は文書で
後者は分署だな

51 :仕様書無しさん:2016/10/07(金) 02:01:14.74
>>50
ポリスかよw

52 :仕様書無しさん:2016/10/07(金) 10:24:41.69
誤字のせいで台無しだなw

53 :仕様書無しさん:2016/10/07(金) 19:57:35.81
>>51
消防署だろw

54 :仕様書無しさん:2016/10/07(金) 22:01:28.44
しょーもない

55 :仕様書無しさん:2016/10/07(金) 23:30:25.83
>>54
おまえのところは署もないのか?

ああ、刑務所に入っているから分からないのか。

56 :仕様書無しさん:2016/10/07(金) 23:36:17.48
>>53
くだらない

57 :仕様書無しさん:2016/10/07(金) 23:40:56.65
>>55
刑務所風に言えば6点

58 :仕様書無しさん:2016/10/07(金) 23:43:24.61
私は1日署長をやったことあります!

59 :仕様書無しさん:2016/10/07(金) 23:46:22.19
詳細設計書つくるんならソースでもきれいにして桶

60 :仕様書無しさん:2016/10/08(土) 00:40:35.30
>>42
いや、サンプルプログラムはあった方がそりゃいいよ。それはまさに設計じゃん。
ここで言ってるのは個別の業務ロジックそれぞれに対する日本語訳レベルの設計書が必要なのかって話でしょ。

61 :仕様書無しさん:2016/10/08(土) 02:22:30.08
詳細設計があれば修正しやすいでしょ
だっておまえら実装すぐ間違えるから、仕様の推理にノイズが入るし

62 :仕様書無しさん:2016/10/08(土) 14:41:09.62
詳細設計にノイズが入っているのが100%だからな

63 :仕様書無しさん:2016/10/15(土) 23:52:42.24
どいつもこいつもだめだな
詳細設計ってものは言語は何であれ同じ業務ロジックが記述できるように作るものなんだよ
お前ら何十年後とかにシステムのリプレースとかやったことないんだろ
そのときに基本設計、詳細設計のありがたみが分かるよ
入社5年目の俺が言う

しっかりした思想とロジックが入っていればあとはどうとでもなる
糞コードができるのは、プログラマの力量不足でもあり、設計思想が貧弱だった所為でもある

効率の悪いコードとコメントアウト(コメントではない)の嵐
同じコードを2度書くなと何度言えばわかるのか
適切なデータ構造もアルゴリズムも選べないやつは必要ない

ああ、すっきり
怖かった〜

64 :仕様書無しさん:2016/10/16(日) 04:17:06.11
> お前ら何十年後とかにシステムのリプレースとかやったことないんだろ
> そのときに基本設計、詳細設計のありがたみが分かるよ

せやな。だから

http://cloud.watch.impress.co.jp/docs/news/597350.html
>  長期にわたって運用されるシステムの保守開発現場では、保守運用のために
> ソースコードの修正・変更が発生するが、そうした変更は設計書に反映されるのが前提になっている。
> しかし、度重なるシステム改修や技術者不足などの理由により、修正・変更内容の
> 反映漏れによるソースコードと設計書の隔たりといった不備や、ソースコード内容が
> 記載されていないなど、設計書自体の不足がしばしば発生する。


こんなことにならないように、基本設計、詳細設計を修正があるたびに
バグや矛盾や曖昧なところがないようにに書き換えような。
そしてちゃんとテストもしような。基本設計、詳細設計の段階で。


ソースコードではできてることを、基本設計、詳細設計になると
怠けるやつは誰だろうな。

65 :仕様書無しさん:2016/10/18(火) 07:59:09.85
初期段階の設計書があるだけでも
保守は楽

66 :仕様書無しさん:2016/10/20(木) 22:27:01.18
仕様書と設計書は普通
詳細設計書はあほ

67 :仕様書無しさん:2016/11/06(日) 16:42:56.87
詳細設計書とソースコードが漏れなく一致していればいいけど
過去の担当者がそれをおざなりにしてるせいでえらい苦労したわ

なんで過去の担当者の責任をこっちが被らないといけないんだよ・・・

68 :仕様書無しさん:2016/11/06(日) 16:54:31.75
まぁそういうドブ仕事させるためにお前に金払ってるわけだから

69 :KAC:2016/12/03(土) 13:00:42.19
詳細設計書がなぜあるのか考えたほうがいい

詳細設計書は三十年前にもあった概念だろ?
三十年前といえば、コンピュータなんてほとんどない時代。
設計は全て机上(紙)で行われていた。PCなんて使わない。

限られたマシン時間の中で如何に早く入力するかというのが
コーディングに求められる唯一の事。
コーディング指示書レベルの詳細設計書がなければ、
入力時間がもったいない。(マシンの時間は人件費よりも高かった)

詳細設計書というのは、そういう時代の名残。
いまでは作業者全員がPC持ってるだろうし、PCがターゲットだったり、
ターゲットとの接続はネットワーク化されて共有化されていたり・・・

とにかく、入力と設計を同時に行っても他人に迷惑のかからない
環境になった今では、詳細設計書にそこまで時間を書ける必要はない。
詳細設計のアウトプットはソースコードで十分だろう。

70 :仕様書無しさん:2016/12/03(土) 13:21:29.95
そういう雑な設計で作ると設計やコードが重複するし保守方法も機能ごとにバラバラになるしアスペクトの追加やアーキテクチャの変更も難しくなる
機械には迷惑かけないかもしれないけど人間にとっては完全に迷惑行為だよ

71 :仕様書無しさん:2016/12/03(土) 13:46:07.12
>>70
どんなに完璧な詳細設計書を作っても、いきなり、数人で
コーディング開始すると、コードは滅茶苦茶になったりするんですけど

優秀精鋭(1,2人程度)でコーディングを開始し、
共通のコードや、お手本となるプログラムを作成し、
その後、徐々に人数を増やしていくやり方なら、失敗しにくいと思うわ

開発初期の頃のコードの作りがかなり重要だと思ってる

72 :仕様書無しさん:2016/12/03(土) 13:47:25.57
優秀精鋭なんて言葉はおかしいな
文章書きなおしてたらそうなた

73 :仕様書無しさん:2016/12/03(土) 14:28:06.13
>>71
そういう状況なら最初から設計パターンを設計書に書けばいい
適切なモデル図と適度な説明はコードよりも正確に早く理解出来る
後は設計書に書かれたパターンに従いコードを書くだけ
コードからパターンを再発見する手間とリスクがないので生産性が高くなる

74 :仕様書無しさん:2016/12/03(土) 14:32:02.45
要するに完璧な設計書と思っていたものが間違っているだけで
優秀なプログラマが書いたコードのエッセンスを設計書に書くべきだった
使えない設計書を完璧な設計書と言って納めてきたクズを否定するのは正しい
しかし設計書の利点を否定する理由にはならない

75 :仕様書無しさん:2016/12/03(土) 15:04:48.32
>>73
> 後は設計書に書かれたパターンに従いコードを書くだけ

それやってみたいわw

で、コードに書くだけでいいという
「設計書に書かれたパターン」の一例を見せてくれ。

そんなの見たことないんでなw

76 :仕様書無しさん:2016/12/03(土) 15:10:27.70
>>75
一例はあなたがもう知ってるでしょ
優秀精鋭が書いたコードを解析すれば後続も書けるって自分で言ってるじゃない
それを設計書に図と文章で書くだけだよ

77 :仕様書無しさん:2016/12/03(土) 15:17:52.50
> 優秀精鋭が書いたコードを解析すれば後続も書けるって自分で言ってるじゃない
> それを設計書に図と文章で書くだけだよ

それってコードと何が違うの?w
内容的に同じものを2回書く理由は?
ないよね。じゃあどちらか一つにしましょう。

78 :仕様書無しさん:2016/12/03(土) 15:24:32.91
じゃあどちらか一つにしましょう。
と言われた時、設計書だけ書いてコードは書かない。
自動生成しましょう。ってならないのはなぜか?

まあ分かるよねw
設計書にはコードに書いてある情報の一部しかない。
それみてもコードは書けないということ。

79 :仕様書無しさん:2016/12/03(土) 15:25:42.97
>>77
レス読んでよ
図と文章で説明するってレスしたでしょ
コードに画像組み込むわけにはいかないだろう
そんなんで設計書が悪いなんて言っても説得力ゼロだよ
マトモに読んでないだけだろ

80 :仕様書無しさん:2016/12/03(土) 15:34:49.42
>>78
なんでこの手の人ってすぐに自動生成に持って行きたがるんだろう
設計書はコード生成のソースではなくコードを書く人間にとって読みやすく理解しやすい形で情報をまとめたものだ
新人研修で教わるような基本的なことでしょこれ

81 :仕様書無しさん:2016/12/03(土) 15:36:06.52
>>79
だから、で、コードに書くだけでいいという
「設計書に書かれたパターン」の一例を見せてくれ。
って言ってるんだが?

設計書にはコードに書いてある情報の一部しか書かれていない。
設計書を見てもコンポーネントの構成がわかるだけだ。

コードを読むことの助けになるだけであって、
設計書から誰もが同じコードをかけるわけがない。

優秀精鋭が書いたコードを解析すれば後続も書けるのは
そこに、設計書の内容+コード の情報があるから
だけどコードがない設計書は、明らかに情報が足りてないんだよ。

足りてるというのなら・・・話は最初に戻るな
コードに書くだけでいいという
「設計書に書かれたパターン」の一例を見せてくれ。

82 :仕様書無しさん:2016/12/03(土) 15:39:45.52
>>80
> なんでこの手の人ってすぐに自動生成に持って行きたがるんだろう
> 設計書はコード生成のソースではなくコードを書く人間にとって読みやすく理解しやすい形で情報をまとめたものだ

なんでこの手の人ってコードが読みにくくて理解できないと思い込んでるんだろ?
技術力がないから?w

自動生成っていうのは、すべての情報が曖昧ではなく
揃っているのであれば、自動生成が可能だからだ。

自動生成ができないのであれば「読みやすく理解しやすい形で情報をまとめたもの」には
情報が曖昧で欠けているということの証明になる。

だから自動生成できない=設計書には情報がかけている=そこからコードを作り出すことは出来ない。
これが成り立つ。

83 :仕様書無しさん:2016/12/03(土) 15:44:35.05
で、設計書を詳細にすればするほど、それをコードに落としやすくはなるが、
現実にある設計書は、ほとんどコードに落とせないものばかりだ。

コンポーネントの構成を理解する程度が関の山だろう。

コードに落とせるレベルまでの設計書を書いたらコストが膨大になってしまうからだ。
自然言語という曖昧な言語で、動くわけでもないからテストも不可能だしな。

84 :仕様書無しさん:2016/12/03(土) 15:45:09.43
仕様変更があると設計書とソースのリンクが取れなっていくって
単純に仕様書担当のSEなりプログラマなりの怠慢でしかないよな

85 :仕様書無しさん:2016/12/03(土) 15:47:35.68
>>84
怠慢をやめるのはいいが、リンクを取るための作業をするなら
単にコストがかかるだけだぞw

仕様変更があったとき一箇所を変えるだけで良くしておくと、
コストはかからなくなる。

怠慢というのは、同じ情報を複数箇所に分散させる行為だろう。
だから、どちらか一箇所にしましょう。

86 :仕様書無しさん:2016/12/03(土) 15:57:29.68
アンチ設計書くんは設計書はプログラマ以外の利害関係者も読むし口を挟むって前提をどこかに置き忘れてるよな
コード読めない利害関係者とコードでコミュニケーションをとるなんて凄まじいコストになるぞ

87 :仕様書無しさん:2016/12/03(土) 16:01:17.00
>>86
だったら「うちでは利害関係のために設計書は書くものです」って
言えばいいだけでは?

ソフトウェアを作る上では必要ないと言ってることに対して
矛盾はしないだろう?w

88 :仕様書無しさん:2016/12/03(土) 16:07:09.92
>>83
逆だよ
詳細まで煮詰めすぎるとコード化しにくくなる
自動生成できるほど詳細な設計書から自動生成したコードは整合性が取れないから動かないことがほぼ保証される
コードの生成ができるほどの濃密な設計書は役立たずってことだ
だから完全性は無いが殆ど正確でコードを書く人が理解しやすい図と文章という構成で設計書を作らなければならない
完全なコードに置き換える作業は人間が手で行う必要がある
最初から完全なコードを書くことは完全な設計書を書くことができないように不可能だから必ず設計書からスタートしなければならない

89 :仕様書無しさん:2016/12/03(土) 16:09:12.11
>>87
必須ではないが有用だよ
もちろん使いこなせないバカにとっては有害になりうる
君や君の同僚にとっては有害だった
それだけの話なんだよね
これ以上は不毛な議論になってしまうな

90 :仕様書無しさん:2016/12/03(土) 16:09:23.64
設計書なんて客から金をむしり取るためのものなのに、
そこに技術的価値があると言い張るからいけない。

91 :仕様書無しさん:2016/12/03(土) 16:12:08.14
>>88
> 自動生成できるほど詳細な設計書から自動生成したコードは整合性が取れないから動かないことがほぼ保証される

なんで自動生成したコードを書き換えるんw
自動生成できるなら書き換える必要が無いはずだ。

自動生成できずに、手動で書き換えるから
整合性が取れなくなってんだろw

いい加減設計書からコードは自動生成できないって認めてしまえよ。
そしてその理由が、設計書には情報が足りてないからだって理解しろ。
自動生成が悪なんじゃないんだよ。(例えばソースコードからバイナリの生成は自動化できてる)

その元となる設計書の存在が悪なんだよ。

92 :KAC:2016/12/03(土) 16:15:08.11
>>88
> 詳細まで煮詰めすぎるとコード化しにくくなる

はぁ?
いくら何でもそりゃただの馬鹿だ。
なんのために設計するのか理解してから設計しろ。

93 :仕様書無しさん:2016/12/03(土) 16:18:29.26
>>89
> 必須ではないが有用だよ
俺は有用かどうかの話なんかしてない。

コードに書くだけでいいという
「設計書に書かれたパターン」

というものは存在しないと言ってる。


設計書なんてコンポーネントの構成を理解するため物でしかない。
そこからコードは作れない。理由は何度も言うが設計書には必要な情報がかけているから。


コストを無視するならば、有用なものであるのは確かだよ?
設計書を読んでそこから理解するのと、何もない状態から理解するのでは設計書を読むほうが早いだろう。

だけどそこには「設計書を作るというコスト」と「設計書を読むというコスト」がかかっている。
そして有用なのは0(設計書もコードもない)場合との比較だ。

設計書を作るコストを、優秀精鋭がコードを作るコストに転用してしまえば、
もっとコストを抑えられる。そういう意味で無用なものとなる。

あんたが言ってるのは「0に比べれば有用」と言ってるだけで
コードに比べれば有用ではないしコストを無視している。

まあ、コストを釣り上げるために設計書を作っているというのであるならば
わざとコストがかかる方法を選んでいるんだろうけどなw

94 :仕様書無しさん:2016/12/03(土) 16:21:52.54
どうせコードを書くことは省略できないのだから
設計書なんてものは、必要最小限であればあるほど良い。

そうすれば、設計書を書くコストは抑えられるし、
設計書を読むコストも抑えられる。

(コードはどうせ読まなければならない。
ただしコードの量を減らして読まなければならない量を減らすことは重要。)

95 :仕様書無しさん:2016/12/03(土) 16:24:08.33
一人のプログラマで最初から最後まで開発して、システムが死ぬまでずっと面倒みるなら
詳細設計書なしでもなんとかなるとは思うが、そんなもん理想論だからなあ

96 :仕様書無しさん:2016/12/03(土) 16:25:41.42
>>95
でもコードあるでしょ?

97 :KAC:2016/12/03(土) 16:26:26.41
>>93
話が変な方向に飛躍しているな。
本来の詳細設計書とは、
「コードに書くだけでいい」というレベルの記載がされているものをさす。

設計書からコードが起こせないというのはお前の勝手な思いこみ。

98 :仕様書無しさん:2016/12/03(土) 16:27:41.30
詳細設計書があるからバッチリです!
システム修正できます!
ってコード読まないで言うやつはいないだろうね。

詳細設計書あった所でそこからコードを推察出来ないことの証拠な。

いや、コードを推察できるレベルの詳細設計書というものを
見せてくれることができれば、俺も納得するんだよ?w

99 :仕様書無しさん:2016/12/03(土) 16:27:52.00
プログラマだけでコードで設計とかありえないだろ
コードは正確だけどモデルがそもそも間違ってるから矛盾が発生して製造が滞るなんて現場じゃよくあることじゃん
そういう時にコードしか設計資料がなかったらステークホルダーとどうコミュニケーションとるんだよ
コード原理主義者の理想論はビジネスじゃ全く通用しないぞ
学生のお遊びじゃないんだから責任感持ってしっかりしてよ

100 :仕様書無しさん:2016/12/03(土) 16:29:14.68
>>97
> 本来の詳細設計書とは、
> 「コードに書くだけでいい」というレベルの記載がされているものをさす。

だからそいうのを見せてくれって言ってるんだが。


神がいれば、どんな問題でも解決できる。
といった所で、実際には神いねーだろ?って話
いくら偶像つくってこれが神だぞーと言った所で
それ神じゃねーしwww

101 :仕様書無しさん:2016/12/03(土) 16:32:01.64
>>99
> ステークホルダーとどうコミュニケーションとるんだよ

やっぱりそこにたどりつくんだよなw
開発するために必要なものじゃなくて、
非技術者とのコミュニケーション用だって言えばいいじゃん。

俺だって、投資家に出資してもらうための
派手なデモは必要だって思うよ?

102 :仕様書無しさん:2016/12/03(土) 16:35:06.13
>>96
自分が一切開発に携わってないプロジェクトでも、何してるかはコード見ればギリギリわかるが
なぜしてるのかはより上位ドキュメントがないと無理。時間制限もあるのに解読なんてしてられん

103 :仕様書無しさん:2016/12/03(土) 16:37:06.10
>>93
コストの話だしたら余計にコードベース設計の方が不利だぞ
設計とは無縁のコーダーにはわからないだろうけど設計するには対象となるドメインを理解しなければならない
そしてドメインを理解するには残念ながら顧客と真剣に議論し合うしかないのが現実だ
もちろん顧客はコードなど読めないからこのプロセスにはコード以外の資料が絶対に必要になる
その資料を整理して体裁を整えると設計書になるんだよ
コードだけで顧客と議論してもなんの進展もしないで時間ばかりが過ぎていく
この業界では時間ってのは最も重いコストだ

104 :KAC:2016/12/03(土) 16:38:38.32
>>100
なんだ。ただの無知か。

SPDとかYACとか見ればどういうものかわかるだろ。
詳細設計書見たこと無いならさっと言えよ。。。

105 :仕様書無しさん:2016/12/03(土) 16:46:02.97
>>101
前提から噛み合ってないんだから話し合っても無駄だよね
顧客を含めたプロジェクトメンバーとのコミュニケーションを設計プロセスに含めるか含めないか
そこからズレてるんだからどこまでいっても平行線だよ

106 :KAC:2016/12/03(土) 16:46:05.97
>>103
話をややこしくすんな。
「その資料を整理して体裁を整えると設計書になるんだよ」
それは仕様書でやるべき話。
少なくとも、このスレの議題である"詳細設計書"はそこには使わない。

107 :仕様書無しさん:2016/12/03(土) 16:48:27.76
>>103
基本設計書までは客とレビューするけど
詳細設計書はいちいち客とレビューとかする?

108 :仕様書無しさん:2016/12/03(土) 16:53:29.39
>>106
モデル設計は仕様じゃなくて文字通り設計でしょ
金額と消費税率を入力してボタンを押すと税込価格が表示される
これは仕様
税込価格とは金額と消費税率+1の積である
これはモデル設計

109 :KAC:2016/12/03(土) 17:02:31.65
>>108
モデル設計と詳細設計を混同すんな。

つか、モデル設計を顧客の合意とんなよ・・・
モデル設計の内容にミスがあって仕様を満たせなくても
この内容は「顧客と合意済みだ」とか言いはるのか?

客と合意をとるのはあくまでも「仕様」の範囲にしとけ。

110 :仕様書無しさん:2016/12/03(土) 17:09:28.02
>>109
合意の有る無しの話じゃねぇよ
顧客の協力なしに正しくモデリングできるわけないだろ
妄想の世界を相手にシステム開発してるんじゃねえんだよ

111 :KAC:2016/12/03(土) 17:11:47.08
>>110
で、その仕様を詰めるための「モデリング」と
今回話題になってる「詳細設計書」に何の関係が?

112 :仕様書無しさん:2016/12/03(土) 17:13:39.06
何かバグが見つかった
調べてみるとコードに誤りはなさそうだ
どいやら詳細設計書のこのモデルのページに間違いがあるようだ
お客さんに設計書を見せて正しいモデルになるよう議論しよう

これがまっとうな対応な

113 :仕様書無しさん:2016/12/03(土) 17:17:49.76
>>112
ちゃんとした仕様書を作って客と合意してから作業しましょう。
これが普通の対応な?

詳細設計書にしか客との合意事項が現れない時点で異常だと気づけ。

114 :仕様書無しさん:2016/12/03(土) 17:28:29.67
>>113
顧客とコミュニケーションを取れる、かつ、仕様書から容易にソースに反映できる形式であること
バグがあっても良いが、随時、修正を施さなければならない
顧客との同意書ではなく、顧客の業務知識をより正確にコードに反映させるためのツール
詳細設計書ってのはそういうものだ
何を作るかの同意は別の文書でやるべきことであってその文書の話はしていない

115 :KAC:2016/12/03(土) 19:00:12.33
>>114
>詳細設計書ってのはそういうものだ

はぁ?
詳細設計書とはなにか調べてから出直してこい

116 :仕様書無しさん:2016/12/03(土) 20:46:05.65
さあ盛り上がってきまたし!

117 :仕様書無しさん:2016/12/03(土) 21:12:56.24
さあ盛り下がってしまいました↓

118 :仕様書無しさん:2016/12/04(日) 01:14:49.64
>>114
ん?
>顧客の業務知識をより正確にコードに反映させる
これはちょっと違うな。

業務知識とコード(具体的な実装)の間には、最低限もう1枚挟まないといけないと思うよ。

119 :仕様書無しさん:2016/12/04(日) 01:16:31.62
というか、そもそもプログラマとSEでは必要なスキルセットが違うので、
無理して顧客とか業務とか要件とか解ったふりして語らなくていいと思う。
「知りません」「できません」で問題ないんじゃない?

120 :仕様書無しさん:2016/12/04(日) 01:21:19.62
>>35
普通は、要件定義書と基本設計書は同じレベルの人が作って、
詳細設計とコーディングは、これまた同じレベルの人が作る。
なので、通常はコードが欠ける人は詳細設計がかけるレベルであると思ってよい。
基本設計と詳細設計のほうに大きな溝があるんだよ。
ドキュメント教うんぬんよりも、スキルとしてくっついてるんだよ。
だからかけないこともないと思うが、書かない習慣もどうかと思う。

121 :仕様書無しさん:2016/12/04(日) 02:01:34.56
>>114
> 顧客との同意書ではなく、顧客の業務知識をより正確にコードに反映させるためのツール
> 詳細設計書ってのはそういうものだ

実際には伝言ゲームで間に一人増えただけだけどなw

業務知識を正確に反映させるためには、顧客が直接プログラミングするのがいい。
当たり前だろ?コミュニケーションの数は少なければ少ないほどより正確なる。

それができないなら、顧客とプログラマが直接やり取りする。
その時に使うコミュニケーションツールは両者がわかるものでなければ意味がない。
これも当たり前だろ?

じゃあ詳細設計書は顧客が理解できるのか?って話。顧客は詳細設計書を理解できない。
つまり詳細設計書では顧客の業務知識を正確にコードに反映させることは出来ない。

詳細設計書でできることは詳細設計書を書いたやつと、それを見るやつの
コミュニケーションツールだよ。けっして顧客の業務知識を伝えられるもの
なんて思ってはいけない。

122 :仕様書無しさん:2016/12/04(日) 03:30:11.21
皆さんの詳細設計書に対する思い入れは凄いですね〜
はっきり言ってバカです

123 :仕様書無しさん:2016/12/04(日) 04:48:05.42
ここいらでバーンと詳細設計書を公開すれば
流れは変わるんだけどな。
オープンソースはできるのだから詳細設計書を公開することが
できないわけがない。

124 :仕様書無しさん:2016/12/04(日) 08:38:13.24
>>123
フェイスブックやツイッターを公開してるのだから、
源泉徴収票や健康診断結果を公開することができないわけがない。

125 :仕様書無しさん:2016/12/04(日) 08:51:52.62
そもそも詳細設計書ってひとくくりにして議論するのが間違いですよね
唯一普遍の詳細設計書など存在しないのだから、うちの会社ではこうしてます、へえそうなんですか、以上の議論はできません
以上をもちまして、このディスカッションは閉じさせて頂きます
以後、書き込みは控えてください

126 :仕様書無しさん:2016/12/04(日) 10:13:39.38
>>124
まとはずれ

127 :KAC:2016/12/04(日) 17:32:58.25
>>123
公開もなにも・・・
フローチャートとか見た事ないか?

128 :仕様書無しさん:2016/12/04(日) 20:21:27.86
時間がないときはソースコードの日本語訳どころか
ソースコードそのものをコピペしたものを納品したりしてるわ

129 :仕様書無しさん:2016/12/04(日) 20:29:35.18
>>128
いや、流石にDoxygenくらいかけようぜ・・・

130 :仕様書無しさん:2016/12/04(日) 20:50:17.11
>>127
> フローチャートとか見た事ないか?

何のソフトウェアの?

131 :仕様書無しさん:2016/12/04(日) 20:55:31.95
>>130
素人は黙ってたほうがいいよ

132 :仕様書無しさん:2016/12/04(日) 21:01:42.91
>>131
いや質問しているだけだが?
別にフローチャートじゃなくてもいいよ

話を戻すぞ。
ソースコード公開できるんだから
その詳細設計だって公開できるはずだろ。
それを公開しているソフトウェアを教えてくれ

133 :仕様書無しさん:2016/12/04(日) 21:04:54.23
>>132
話が戻ってないぞ。
素人は黙ってたほうがいいよ

134 :仕様書無しさん:2016/12/04(日) 21:15:08.62
戻ってるよな?
意味は同じだからまんま前の話を持ってきてもいいんだぜ?

123 自分:仕様書無しさん[sage] 投稿日:2016/12/04(日) 04:48:05.42
ここいらでバーンと詳細設計書を公開すれば
流れは変わるんだけどな。
オープンソースはできるのだから詳細設計書を公開することが
できないわけがない。

135 :仕様書無しさん:2016/12/04(日) 21:20:15.57
>>134
話の流れくらい読もうぜ

136 :仕様書無しさん:2016/12/04(日) 21:43:05.60
図や表ってソースコードでどう書くんだ?
アスキーアート?

137 :仕様書無しさん:2016/12/04(日) 22:13:55.25
>>135
それでソースコードとともに公開されている
詳細設計書はどこにあるの?

138 :仕様書無しさん:2016/12/04(日) 22:14:10.04
>>136
PlantUML

139 :仕様書無しさん:2016/12/04(日) 22:15:04.40
>>136
文章で説明するんじゃないか?
20cmの線分ABの中点Pに直行する10cm線分PDがあり・・・・とか

140 :仕様書無しさん:2016/12/04(日) 22:21:18.74
>>139
そんな文章書くぐらいならコードでよくね?

141 :仕様書無しさん:2016/12/04(日) 22:22:40.53
うむ、COBOL以外の言語は
自然言語を直接翻訳したような文法ではなくて
数学的な式に近いから曖昧さがなくて簡潔に記述できるんだよな。
結局コードで書くのが一番という結論

142 :仕様書無しさん:2016/12/05(月) 13:17:18.51
うん。
これから仕様書や設計書は図も含めて全てプログラムで書こう。

143 :仕様書無しさん:2016/12/05(月) 18:51:06.23
微積分とか数学記号はどう書くの?
TeXコード埋め込むの?

144 :仕様書無しさん:2016/12/06(火) 00:54:35.45
アスキーアート並みに苦心して書くんだ。

145 :仕様書無しさん:2016/12/06(火) 18:57:22.33
黒塗りの四角と白抜きの四角でドット絵でどうだ
フォントを小さくすれば滑らかで美しいグラフィックになる

146 :仕様書無しさん:2016/12/06(火) 19:11:47.87
コボルの文法って曖昧さがあるのか?

147 :仕様書無しさん:2016/12/06(火) 23:06:58.25
ない。
一切ない。
絶対にない!
あったらびっくりだろうな。

148 :仕様書無しさん:2016/12/06(火) 23:57:54.99
じゃあCOBOLは曖昧さがないのに
自然言語に近づける意味あるのか?

149 :仕様書無しさん:2016/12/07(水) 00:50:15.82
昔は簡潔な記述よりも、自然言語に近い方が
可読性が高いって考えられていた時代があったんだよ。

だってみんなプログラミング言語を知らなかったわけだからね。
今のようにプログラミング言語をスラスラとみんな読めるように
なるとは考えていなかった。

150 :仕様書無しさん:2016/12/15(木) 23:07:36.59
基本設計書は「こう作ります」ってのを書いて
詳細設計書はどこの会社でも書くところはもうソース貼り付けろよってレベルのもんを
深夜残業して書かされたな
ぶっちゃけ詳細設計書はソース書いてから作ったほうが早い気がする

そもそもこの粒度で詳細設計書を書くことは絶対見積りに入ってないし
おそらく詳細設計書は作るだけで検討などしてる時間はないのではないか?

という経験から詳細設計書は基本設計書とソースのつなぎをする程度の内容でいいのではないかと思う

クラス図→絶対役に立たない
シーケンス図→何も表現できない
処理フロー→ソース見たほうが早い

詳細設計書によくある項目って全部役に立たない

151 :仕様書無しさん:2016/12/15(木) 23:14:34.50
コードだと複数ファイルを開き処理を追わなければ関連やシーケンスが見えてこない
絵に書いておけば紙一枚眺めるだけで一瞬で内容を理解できる
コードが設計として役に立つのはメソッドまでだよ
メソッド程度のサイズならコードの方が早く理解できて正確である事が多いことを認めよう

152 :仕様書無しさん:2016/12/16(金) 00:38:15.25
>>151
関連っていらなくね?
大事なのはどの機能がどのクラスやメソッドで実現されているかであって
関連は別にいらねぇ

153 :仕様書無しさん:2016/12/16(金) 03:08:34.87
>>151
設計なんてディレクトリツリーを見ればわかることだよ

154 :仕様書無しさん:2016/12/16(金) 03:08:52.28
ディレクトリツリーとファイル名な

155 :仕様書無しさん:2016/12/16(金) 05:59:58.16
変なおじさん「道路の写真が何枚かあれば道路網がどうなってるかわかるよ」

常識人「地図って知ってる?」

156 :仕様書無しさん:2016/12/16(金) 08:15:43.33
仕様を固めないで行き当たりばったりのプロジェクトに参加させられた時が一番きついわ

何回仕様変更して何回ソース書き直せばいいんだよ

157 :仕様書無しさん:2016/12/16(金) 08:19:20.92
R&D部門だとよくあるけど

158 :仕様書無しさん:2016/12/16(金) 09:06:10.87
変なおじさん「青写真が何枚かあれば設計がどうなってるかわかるよ」

常識人「ソースコードって知ってる?」

159 :仕様書無しさん:2016/12/16(金) 09:13:59.75
>>156
問題は仕様変更した時に再見積りしない空気
ケツそのままで走るのを作業をボイコットしてでもやめさせないと
でもその辺は状況に応じてって感じだと思う

160 :仕様書無しさん:2016/12/16(金) 09:17:18.93
基本設計書にやることが書いてあって
詳細設計書に基本設計書とソースのつなぎが書いてあれば情報は十分だよ
大手の求める詳細設計書はソースの逆変換に他ならない

161 :仕様書無しさん:2016/12/16(金) 18:53:20.64
みたいなこと言ってる子って仕事で設計書書いたことないんだろうな

162 :仕様書無しさん:2016/12/16(金) 19:29:49.14
いい年したオッサンに向かって子とかいうオッサンwキモwww

163 :仕様書無しさん:2016/12/16(金) 19:34:19.72
ここは社会人が来るスレだよ
君みたいな坊やにはまだ早いんじゃないかな

164 :仕様書無しさん:2016/12/16(金) 19:43:04.48
>>163
いや俺もオッサンなんだがwお前ほどキモくないけどwww

165 :仕様書無しさん:2016/12/16(金) 20:21:22.32
>>164
背伸びしたい年頃なのはわかるよ

166 :仕様書無しさん:2016/12/16(金) 20:37:46.81
なにこいつ常軌を逸したキモさだなw

167 :仕様書無しさん:2016/12/17(土) 08:41:53.92
顧客・ユーザーと直接話をして仕様書等々を作成したことないやつは、語る資格なし

168 :仕様書無しさん:2016/12/17(土) 09:27:08.99
>>167
そもそも、プログラム組めないバカはそれすら語る資格ないわけで・・・

169 :仕様書無しさん:2016/12/17(土) 15:55:31.43
プログラム組めるのは前提条件です
そのうえで>>167をやってないやつは語る資格なし

170 :仕様書無しさん:2016/12/17(土) 22:14:16.88
細かすぎる設計書でもあるだけマシだろ
現実世界の詳細設計書は細かすぎるどころかスカスカのゴミじゃねえか
上流が悉く仕事をしていないからな
細かすぎるなんて贅沢な不満なら言ってみたいわ

171 :仕様書無しさん:2016/12/17(土) 22:35:49.80
> 現実世界の詳細設計書は細かすぎるどころかスカスカのゴミじゃねえか

だからいらんって言ってるの。

そもそも当たり前だろ。
細かいことを考えるレベルじゃないのに、
細かいことなんてかけるわけない。

できもしないことをすんなって言ってんの

172 :仕様書無しさん:2016/12/17(土) 23:01:44.71
詳細設計書を書く上流って…そういう世界もあるのか……

173 :仕様書無しさん:2016/12/17(土) 23:55:55.66
>>172
そういう現場はもちろんソース書いてから設計書書くよ
担当者もそうするであろうことを見越してスケジュールをする
厄介なのは精度はソースレベルを要求するくせに期間がそれに伴っていないとき

174 :仕様書無しさん:2016/12/18(日) 01:26:39.62
http://qiita.com/nnnmanatsuxu/items/99114f0400b2d79ecc4f

COBOLの現場にいた時は、上の例以上の粒度で詳細設計書書かされてたよ。
ワークレコードの何バイト目にセットするかだったり、繰り返し処理の開始、終了、増分も書いたり。
メリットはほとんどない(どころかデメリットが圧倒的に大きい)けど昔からそうやってるから今もそれを踏襲してる、みたいなことがやたら多い現場だった

175 :仕様書無しさん:2016/12/18(日) 08:36:22.98
コボルは知らんがコボルには固定長フィールドの読み込みAPIしかないってんならフィールド長を設計書に書くべきだろ
自分がデリミタだと思ってたカンマは実はデータの一部で正しくはフィールド長を根拠に読み込む必要があるってことも当然あり得るわけだ
フィールド長を設計書から省略していいのはファイル形式が明確にCSVでありCSVを読み込むAPIがサポートされてる時だけだ

176 :仕様書無しさん:2016/12/18(日) 09:10:04.98
>>175
いまはいろんな読み方できるけど、
コボルは固定長が基本、で設計書にフィールド情報は絶対にのせる
ほぼそれがメインと言っていい。

177 :仕様書無しさん:2016/12/18(日) 22:48:17.40
              ミミ ヽヽヽヽリリノノノノ
             ミ   ,,、,、,、,、,、,、,、、 彡 / ̄`Y  ̄ヽ
              l  i''"        i彡/ / / l | | lヽヽ
             .| 」   ⌒' '⌒  |/ // ⌒  ⌒ヽ
             ,r-/   -・=-, 、-・=- ||/  (●) (●)
             l       ノ( 、_, )ヽ  || |   ⌒ ・ィ  ヽ
              ー'    ノ、__!!_,.  ||   ト-=-ァ ノ
              |.     ヽニニソ   l |   |-r 、/ /|
              ヽ           /.|| | \_`ニ'_/ ||
          /⌒\〆⌒ヽ"ーー" ⌒ヽ/⌒ヽ _ノ          
         ../  ノつ\ ・     ・ /_人. ヽ /     
  グッポ o0○/  /( 3  \  ∩  / `-と ) ○0o         
      (  ` /、_ノヽ     (:::)(:::)    /_ノ' '!   )゜
       \_)    |   : : : __   : : :|  ノ(_ノ
     グッポ    ((  ヽ__ | | __ノ /     ))   
            / ⌒    (:::)(:::)    ⌒ー―、
       ( ⌒ ̄ ̄       人          ヽ 
       \  \______ノ ヽ____./   )  .__/ ̄/   /二二二/_  /'''7    / ̄  ̄/  / ̄/ /'''7
.        \  \              /  /  /___.    ̄./ / __  /  / / ___ /  ̄   ̄/   ̄  / ./ 
          \  \           /  /    ノ / /i ̄!. ̄  __,ノ /  / /_ノ / ~/ /二,.´  ____.ノ ./ 
          ε(  ̄ ̄)         ( ̄ ̄ )3   /_,./__./ ヽ、_>  /____,/ /_____,.ノ i____/  /______./

178 :仕様書無しさん:2016/12/20(火) 02:08:55.37
無いよりは合った方が断然良いけど
ちゃんとメンテできないならいらない

179 :仕様書無しさん:2016/12/20(火) 14:00:40.43
>>178
ちゃんとメンテできる書き方ってのもあるじゃない?

180 :仕様書無しさん:2016/12/20(火) 19:50:01.21
メンテはまず不可能だから要点をうまく捉えた抽象的な内容にせざるをえない
だから作図が有効なんだね

181 :仕様書無しさん:2016/12/22(木) 23:42:11.82
文芸的プログラミング

182 :仕様書無しさん:2016/12/23(金) 09:51:30.66
設計書はアート

183 :仕様書無しさん:2016/12/23(金) 22:22:31.43
アートは引越しセンター

184 :仕様書無しさん:2017/01/11(水) 19:44:30.96
詳細設計のお仕事が回ってきて憂鬱だ
コーディングより高難度の詳細設計を書かされて
コーディングは低品質な外注にぶん投げ
マネジメントと受け入れテストも押し付けられた
もうやだ一人で仕事したい

185 :仕様書無しさん:2017/01/11(水) 22:19:47.34
>>184
意味が解らん。
一人で仕事すりゃいいじゃねーか。

誰かいないと仕事できないのか?

186 :仕様書無しさん:2017/01/11(水) 22:50:27.40
営業とか居ないと困るな

187 :仕様書無しさん:2017/01/13(金) 21:52:22.32
詳細設計として価値のあるコンテンツって何だ?

188 :仕様書無しさん:2017/01/13(金) 22:01:41.06
>>187
APIマニュアル、テストコード、サンプル

189 :仕様書無しさん:2017/01/13(金) 22:21:29.51
>>187
状態遷移図・表
プロセス・タスク構成/関連図

190 :仕様書無しさん:2017/01/13(金) 22:39:01.15
>>189
それ結構欲しいけど、図とか表ってアップデートするのめんどくセーんだよなぁ
なんとかならんかねぇ

191 :仕様書無しさん:2017/01/13(金) 22:55:41.70
>>190
AA

192 :仕様書無しさん:2017/01/13(金) 23:00:09.08
>>191
そっちの方が難易度たけーよw

193 :仕様書無しさん:2017/01/13(金) 23:01:38.61
図を生成するコードとデータを書く
なお製品コードより複雑な模様

194 :仕様書無しさん:2017/01/14(土) 06:21:23.08
>>192
>>191じゃないけど、AAを書くお手軽ツールがあるんだよ

195 :仕様書無しさん:2017/01/14(土) 08:55:37.67
>>194
画像から変換する奴じゃなくて?
urlくださいな

196 :仕様書無しさん:2017/01/16(月) 19:54:37.73
複雑なSQLの詳細設計をどう書くべきかいつも悩む
SQLは頭の中に出来てるけど日本語で説明って難しいんだよな
設計して外注するよりその場でコード書いた方が時間かからない……
営利企業としてなんか見失ってる

197 :仕様書無しさん:2017/01/16(月) 20:52:02.80
>>196
手書きで書いた図をスマホで撮って貼り付けしたらいいんじゃないか?

198 :KAC:2017/01/17(火) 21:12:11.38
>>196
詳細設計終わってから外注する事自体が間違いだろ
詳細設計から外注するか、試験から外注すべきだと思うが

199 :仕様書無しさん:2017/01/21(土) 12:54:40.92
>>196
マジレス

別シートとかに生のSQL文を書いて、管理番号で参照する

結果取得 (SELECT-1-1)
DB更新 (UPDATE-2-1)

もしくは、SQLを詳細設計書に記述する独自記法を決めて、それで記述すればおk
テーブルセルの背景色とかフォントを工夫する
構造的な見た目はSQLと殆ど同じw
Fとかでは、そうだった

あまりにも馬鹿らしいな・・・
もうそういうのに関わる仕事はしなくなったけど

200 :仕様書無しさん:2017/01/21(土) 12:57:15.88
>>196
引数を渡す時は

SELECT-1-1に
SELECT * FROM USERS WHERE ID = :ID
とか引数を記述して

SELECT-1-1 (ID: 画面[ユーザID])
みたいな感じ

ああ、思い出してもあほらしいわ

201 :仕様書無しさん:2017/02/07(火) 18:42:00.46
なぜかSQLをベタ書きするところはいまだにあるんだよな。あれ謎だわ。

202 :仕様書無しさん:2017/02/07(火) 22:05:13.69
のちのちのメンテで役に立つのは
・コーディングの元となった詳細設計書
・コーディングが終わってから書いた詳細設計書
さて、どっちかな?...

203 :仕様書無しさん:2017/02/07(火) 23:31:08.05
>>202
コーディングの元になった設計書。

204 :仕様書無しさん:2017/02/07(火) 23:35:38.65
>>201
引当に使うキーは別として
フィールドの粒度で細かく説明しないとだめな時点で設計が失敗してるとは思うが
世の中結構そうやって作っちゃうやつが多い

205 :仕様書無しさん:2017/02/08(水) 07:37:52.27
何もしていない普通の一般人の自宅に隠しカメラを取り付け
それをネットでリアルタイム配信

仲間という人間に対する盗聴盗撮生ネット配信の会

しかけたカメラの映像
乗っ取っているPCの画像をリアルタイムで生配信中
集団で仲間の私生活を覗いて楽しんでいる

そんなことが今この国では行われています

206 :仕様書無しさん:2017/02/08(水) 12:10:19.96
>>203
正解

207 :仕様書無しさん:2017/02/09(木) 01:29:54.76
>>202
どっちも殆ど役に立たん。

208 :仕様書無しさん:2017/02/09(木) 01:58:13.18
>>207
お前は無能

209 :仕様書無しさん:2017/02/11(土) 14:26:18.48
詳細設計書って後から見ても、殆ど役にたたない
メンテされずにコードと乖離してたり、嘘や間違いだらけ
そもそも、ドキュメントって、簡単に馬鹿でもメンテできる概要レベルしか残しちゃダメだわ

210 :仕様書無しさん:2017/02/11(土) 15:29:03.41
>>202
> のちのちのメンテで役に立つのは

コードだろ?

既存システムのソースコード解析および設計書作成を自動化「設計書リカバリーサービス」を提供開始
http://www.nttdata.com/jp/ja/news/release/2013/042402.html

> 長期にわたって運用されるシステムでは人手のかかる設計書整備の不備・不足による保守開発の
> 困難さや有識者依存の業務が問題となっています。また、システム更改を行う場合も仕様が
> 不明確で問題化するケースもあります。システムを正しく理解するために設計書の
> 不備・不足を解消するには、既存システムのソースコードを解析する必要があるため、
> 多大な時間を要していました。

> 背景

> システムの保守開発現場では保守運用の為、ソースコードの修正・変更が随時発生し、
> その対応内容を設計書へ反映させます。しかし度重なるシステム改修や技術者不足などの理由により、
> 修正・変更内容の反映漏れによるソースコードと設計書の乖離といった不備や、ソースコード内容が
> 記載されていないという設計書自体の不足がしばしば発生していることがあります。

> 特に長期にわたって運用されているシステムではこの傾向が顕著で、システム改修などの保守開発が
> 困難となる問題が発生しています。その一方で保守開発の現場では、変更要求発生時などに迅速かつ
> 正確な対応が求められており、設計書の不備・不足はシステム改修内容の決定判断や、
> 正確なシステム改修の妨げになるため大きな問題となっています。

211 :仕様書無しさん:2017/02/11(土) 18:14:44.30
>>210
営業乙

212 :仕様書無しさん:2017/02/11(土) 20:47:34.99
>>210
お前、自分で貼った文章の内容すら理解できないのか?

213 :仕様書無しさん:2017/02/11(土) 21:10:15.59
>>210
各設計書のマークがExcelであることに不安を感じた

214 :仕様書無しさん:2017/02/12(日) 10:34:50.93
詳細設計の粒度はプログラミングをする人間のレベルに合わせるのが現実的。

215 :仕様書無しさん:2017/02/12(日) 10:47:29.03
pseudo code

216 :仕様書無しさん:2017/02/12(日) 11:06:18.89
>>214
おい、なんで新卒様に俺らが合わせないといかんのだ?

217 :仕様書無しさん:2017/02/12(日) 11:12:24.44
>>216
出来上がってきたプログラムを書き直すのが面倒だから。

218 :仕様書無しさん:2017/02/12(日) 13:46:18.65
>>216
修正するのも将来の新卒や質や経緯のわからない借りてきた派遣の仕事になるんだろうから、意味のある詳細設計なら新卒にあわせないと。
形だけ納品して後は知らない、なら適当に書いておけばいいさ。後で呼び出される心配なければね。
その前に読めんわからんとクレーム上がってくるかもしれないけど。

219 :仕様書無しさん:2017/02/12(日) 13:53:53.83
入社したばかりの新卒が作ったシステムです
高いのは仕方ないでしょう?

とか言うつもりかwww

220 :仕様書無しさん:2017/02/12(日) 14:06:44.26
>>218
役に立つなら良いんだけど、放置されてるのたくさん見てるからなあ。

ドキュメントが殆ど無いような案件でリフォームするような仕事したことあるけど作業も半ばまできて、たまたま雑談してる時に別の案件で終了した奴の中に今作業しているのと殆ど同じものがあることを聞いた。
こっちはドキュメントがかなり詳細に残っていて作りもしっかりしてるし、DBで言えばフィールドを少し増やせばそのまま使えるような奴だったけど結局使われなかったな。

詳細なドキュメントが残ってても詳細を知ってる奴が残っていないと放置されたままゴミ箱行きになることも多い。

221 :仕様書無しさん:2017/02/12(日) 15:06:44.85
結局SI業界っていうのは、素人がシステム作ってるんだよ

222 :仕様書無しさん:2017/02/12(日) 15:14:34.47
そもそもpseudo codeというれっきとした名前が有るんだからそれを使ってくれ。

223 :仕様書無しさん:2017/02/12(日) 16:37:39.05
pseudo codeってなんだ擬似コードのことか。
日本語で言えよ。わかりづらい

224 :仕様書無しさん:2017/02/12(日) 18:15:43.41
>>223
常識レベルだよ・・・頭大丈夫かい?

225 :仕様書無しさん:2017/02/12(日) 18:24:28.39
常識レベルの低い奴に限って
それ常識だよ、とか言うんだよな。

根性がひんまがってる低知能に多い現象。
これ常識www

226 :仕様書無しさん:2017/02/12(日) 18:41:12.30
時々仕事できないくせにカッコつけた言葉使いたがる奴には「それって何なの?」と圧力的に聞くことがあるな。
で、説明受けた後で「なんだ、〜のことかあ」って返す。

勿論、こちらが上司+自他共に技術レベルが上と認められてる場合だけどね。

227 :仕様書無しさん:2017/02/12(日) 18:45:37.14
カッコつけた言葉って?
「ちょ待てよ」とか?

228 :仕様書無しさん:2017/02/12(日) 18:50:15.97
>>210
それテラソルナの売り文句だろ

229 :仕様書無しさん:2017/02/12(日) 20:28:33.39
Pseudocode程度でカッコ付けって、どんだけレベル低いんだよ。

230 :仕様書無しさん:2017/02/12(日) 20:33:17.46
日本語で通るもので且つ日本語の方が分かりやすい場合は全部カッコつけてると判断するな。
但し、既に日本で浸透している場合は除く。

けれど、知らない奴に"常識"とか言うような奴ならカッコつけてるという判断をするさ。

231 :仕様書無しさん:2017/02/12(日) 20:49:31.15
成長しないな、それじや

232 :仕様書無しさん:2017/02/12(日) 20:57:10.28
(常識)

233 :仕様書無しさん:2017/02/12(日) 21:08:12.08
プログラム歴1年未満の兵隊をたくさんかき集めて、
無駄に時間をかけて開発するのが
SI業界の常識だろ

234 :仕様書無しさん:2017/02/12(日) 21:57:56.11
>>230
お前が分かりやすいから皆が分かりやすいという訳でもない
同様に日本語の約語より外来のカタカナ語の方が浸透してる例はいくらでもある

235 :仕様書無しさん:2017/02/12(日) 22:03:32.68
漢字が読めない人のために
全部カタカナ or ひらがなで書くべきだ。
可読性重視な

236 :仕様書無しさん:2017/02/12(日) 22:07:40.88
プ…pseudo codeってなんだ?

237 :仕様書無しさん:2017/02/12(日) 23:31:54.67
>>235
可読性を上げるために漢字が使われているんたか?

238 :仕様書無しさん:2017/02/12(日) 23:58:47.94
たか?

239 :仕様書無しさん:2017/02/13(月) 02:03:49.84
>>234
何言ってんの?
浸透してたら除くって日本語分からんのか?
それに当然分かりやすいなら何の問題も無い。
しかし少なくともPseudocodeが分からなかった奴も擬似コードは分かってたわけだよな。
つまりその時点では意志疎通という意味では擬似コードの方が優秀だったわけだ。
にもかかわらず"常識"とか言うから言われちゃうんじゃ無いの?俺みたいな奴に。

あとやたらプロジェクトって言葉を使う奴も地雷臭がするな。
お前1人でチマチマやってるのの何がプロジェクトだよって言いたくなる。
当然、それなりの規模ならプロジェクトで問題ないけど。

自分を大きく見せようとする奴は要注意。

240 :仕様書無しさん:2017/02/13(月) 07:41:50.50
>>239
fizzbuzzでもプロジェクトだけど?
訳のわからんオレオレ定義振りかざして何言っちゃってんのお前w

241 :仕様書無しさん:2017/02/13(月) 07:48:28.12
>>239
プロジェクトの定義もわからんのか

242 :仕様書無しさん:2017/02/13(月) 08:08:11.23
>>239
お前が言葉を知らなさすぎるだけですので

243 :仕様書無しさん:2017/02/13(月) 10:24:56.76
定義の話じゃない。
そりゃ、分類すればプロジェクトだろうよ。
でも、しょうもなくて自分からはプロジェクトなんて恥ずかしくて言えないような案件もあるだろ。

244 :仕様書無しさん:2017/02/13(月) 10:44:50.75
英語の文章を日常的に読むんだから、日本語より先に英語が出てくるのは自然だと思うが

245 :仕様書無しさん:2017/02/13(月) 12:00:18.47
>>243
プロジェクトの定義もわからんのか

246 :仕様書無しさん:2017/02/13(月) 12:08:24.85
既存アプリの劣化クローン作ってひとりプロジェクトとか言ってる奴いるよな
なにかっこつけてんだハゲって周りから思われてることも知らずに

247 :仕様書無しさん:2017/02/13(月) 12:09:24.87
>>245
日本語が理解出来ないなら反論しなくて良いぞ。

248 :仕様書無しさん:2017/02/13(月) 12:25:44.88
>>243
いや恥ずかしいとかそういう問題じゃないからw
どんなプロジェクトでもプロジェクトはプロジェクト
てかお前の方がなんか勘違いしてんじゃね?w

249 :仕様書無しさん:2017/02/13(月) 12:30:02.19
不要なコメントを削除するプロジェクト

250 :仕様書無しさん:2017/02/13(月) 13:22:00.65
>>248
だから日本語分からんのなら反論しなくって良いって。
どんなプロジェクトだろうとプロジェクトはプロジェクトだよ。
これでも分からんか?

251 :仕様書無しさん:2017/02/13(月) 18:34:47.12
プロジェクトひとり

252 :仕様書無しさん:2017/02/13(月) 19:21:40.29
あ〜あ、ムキになっちゃったw

253 :仕様書無しさん:2017/02/13(月) 19:57:25.76
ムキムキー

    (・∀・ )
  /⌒"ー ― ⌒ヽ
  | (_ (__人 )
 (三0∧ミキ)彡ノヽ )
   ̄ ノー―-イ 0三)
   / ヽレ′ヽ  ̄
  /__/ヽ  \
  \ ヽ  \_ )
   Lノ  | /
        ヒ二)

254 :仕様書無しさん:2017/02/13(月) 20:06:32.63
一般人が思うプロジェクトのイメージで言われたら普通あきれるよ。

255 :仕様書無しさん:2017/02/13(月) 22:07:56.29
詳細設計って、C言語設計の名残だろ

OOP対応言語で作ってたら
爆笑しちゃう

256 :KAC:2017/02/13(月) 22:19:51.95
>>255
Rational Roseとか知らない世代なんだろうな

257 :仕様書無しさん:2017/02/13(月) 22:25:22.08
Roseでもmember functionの処理をPseudocodesで書く。

258 :仕様書無しさん:2017/02/13(月) 22:30:15.73
>>257
それは詳細設計では?

259 :仕様書無しさん:2017/02/14(火) 00:26:19.05
詳細設計だな

260 :仕様書無しさん:2017/02/14(火) 01:34:15.79
>255の爆笑はまだなの?

261 :仕様書無しさん:2017/02/14(火) 03:50:10.85
>>255
詳細設計がどんなレベルかによる。

262 :仕様書無しさん:2017/02/14(火) 08:18:23.62
コードにdocかけよ
そこからドキュメントを起こすツールがあるんだから

263 :仕様書無しさん:2017/02/14(火) 08:31:35.41
>>262
それだと文字がメインになってしまう

264 :仕様書無しさん:2017/02/14(火) 10:31:21.03
>>263
ソースが文字で見づらいってこと?
コメントなんだから邪魔なら畳めばええやん

265 :仕様書無しさん:2017/02/14(火) 12:06:47.60
図が書けないじゃんってことじゃね

266 :仕様書無しさん:2017/02/14(火) 12:50:40.13
あ〜確かにめんどいな
htmlには出来るけどわざわざタグ書くのめんどいんだよね

267 :仕様書無しさん:2017/02/14(火) 13:10:08.48
そこで罫線ですよ

268 :仕様書無しさん:2017/02/14(火) 15:53:13.62
そこでAAですよ

269 :仕様書無しさん:2017/02/14(火) 18:14:08.03
>>268
なるほどaaジェネレータ的なので生成しpreで囲めば行けるかもしれんな…

270 :仕様書無しさん:2017/02/14(火) 23:42:43.96
使い捨てのソフトは設計書いらないけど、長期的に使用する
ソフトは設計書いるよと思う。
設計書の粒度は製品(ソフト)の特性に依ると思う。

271 :仕様書無しさん:2017/02/20(月) 13:29:24.39
設計書(仕様書)無かったら、3000行程度で混乱する
むしろ500行超えた辺りから頭パンクしそうだし、

用途によるけど、(GUIを除いた)
純粋な処理コードだけなら、200行有れば十分だと思うんだが?
[(基本80*200=16000文字)空白除く]

272 :仕様書無しさん:2017/02/21(火) 00:01:55.94
>>271
1クラス3000行?
1メソッド3000行?

273 :仕様書無しさん:2017/02/21(火) 00:37:01.04
>>272
1クラスだけど?

274 :仕様書無しさん:2017/02/21(火) 12:32:27.27
お前らって現実に起きている問題には近視眼的なくせに
ソースコードに対峙したとたん全てを把握する神になろうとするよな
要領のいい人とは真逆だよそれ

275 :仕様書無しさん:2017/02/21(火) 12:48:37.61
>>274
あるある
ソース書いてる時点なんて問題の殆どが解決してなきゃいけない状態なのにね

276 :仕様書無しさん:2017/02/21(火) 14:44:14.71
>>274
> お前らって現実に起きている問題には近視眼的なくせに
え?なに?アフリカの飢餓問題とかそういう話?w

277 :仕様書無しさん:2017/02/21(火) 18:29:00.58
>>276
ワカンネーなら食いつくなよカス

278 :仕様書無しさん:2017/02/21(火) 18:58:43.00
>>277
ワカンネーなら食いつくなよカス

279 :仕様書無しさん:2017/02/21(火) 19:23:27.29
オウム返しがやっとか

280 :仕様書無しさん:2017/02/21(火) 19:40:24.62
>>279
ワカンネーなら食いつくなよカス

281 :仕様書無しさん:2017/03/02(木) 17:26:47.07
わっかんねー
何もかもがわっかんねー

282 :仕様書無しさん:2017/05/21(日) 21:01:50.52
詳細設計書に動くサンプルコード添付したら協力会社さんに喜んでもらえた
いい仕事をした後は気分がいいな

283 :仕様書無しさん:2017/05/22(月) 10:37:40.63
概念とそれに対する処理を明確に定義し、全体のアーキテクチャを記述する
これが設計書であり、あとはフォーマットの違いだけだ

284 :仕様書無しさん:2017/05/22(月) 12:28:09.70
どうやら「僕が考えた最強の設計書」のようだけど残念ながら意味不明

285 :仕様書無しさん:2017/05/22(月) 14:37:25.74
意味わからんだろ?
所詮その程度の頭ってことだ

286 :仕様書無しさん:2017/05/22(月) 15:03:24.89
>>285
なんで自分の公開批評してんの?

287 :仕様書無しさん:2017/05/22(月) 22:56:07.53
>>282
同じ様な事あって、配列の添え字にまた配列とか配列使いまくりだったから、
思いっきりポインタにしてやった事あるなぁ〜。
今思えば無駄な自己主張だったなぁ〜。

288 :仕様書無しさん:2017/05/25(木) 10:05:53.17
>>282
まさに重要なのは動くサンプルコードであって
詳細設計書なんていらないって話だなw

289 :仕様書無しさん:2017/05/28(日) 21:39:22.86
ウチの会社は部署によってやり方が全然違うんだけど
今度のところはソースをExcelに張っつけたのが詳細設計書

以前のところも少ない人数で我流でやってて色々問題を感じていたけど
今回はさすがにちょっと驚いた

でもまー古い既存システムの改修がメインだから
どうやれば正解と言えるのかは実際には難しいんだけどね・・・

290 :仕様書無しさん:2017/05/28(日) 21:42:44.76
あともう1つ驚いたのが
ソースにコメントをロクに書かないという慣習
なんかそれに美学でも持ってるようだwww

僅かに書いてあるコメントも奇妙な言葉使いでほとんど暗号
職人の世界のようでもあるが、とてもアホらしいwww

291 :仕様書無しさん:2017/05/29(月) 00:26:54.09
設計書だってフローチャートだってあるのに、
なんでコメント書かなきゃならないんだ?

292 :仕様書無しさん:2017/05/29(月) 00:34:51.62
設計書だってフローチャートにかかれている情報は
概要でしかないから。ほんの一部でしかないし
概要からは省くような詳細な情報がコメントとして必要

293 :仕様書無しさん:2017/05/29(月) 01:25:01.30
未だにウォーターフォールモデルで開発やってんのか

294 :仕様書無しさん:2017/05/29(月) 03:16:11.02
>>291
あるのに?
なかったらどーすんの?
あっても間違ってたり古い仕様だったらどーすんの?
ソースを読めばいいとでも?
flagという変数を使うクソ野郎もたくさんいるぞ。
せめて何のフラグかコメントしとけば読みやすくなる。
なぜかコメントを邪魔なものだと思ってる人も多いが、
実際は逆なんだよ。
百利あって一害なしだ。

295 :仕様書無しさん:2017/05/29(月) 05:43:38.85
>>294
コメントは行数を増やすためだけのモノ

296 :仕様書無しさん:2017/05/29(月) 07:33:21.71
>>294
仕事でコード書いたことないんだろうな
コメントはコードと同期しないし
コメントを書き換えるのが面倒だからと変な修正をする奴も居る
プライベートのリポジトリ以外ではコメントを禁止した方が良いぞ

297 :仕様書無しさん:2017/05/29(月) 09:41:38.70
>>296
カスしかいない職場で働いてるんだな
かわいそうに

298 :仕様書無しさん:2017/05/29(月) 10:49:21.36
基本、自分も含めてカスだと思う事が不具合を出さない工夫だと思うけどな。
コメントとコードが一致しないなんてのは普通にあるから、むしろコメントを書かないって選択も有効

299 :仕様書無しさん:2017/05/29(月) 11:21:21.91
一致してないなら直してやれよ
と思うんだけどなぁ
まぁめんどくさいのはわかるけどさぁ

300 :仕様書無しさん:2017/05/29(月) 13:25:50.85
>>299
一応言っとくが、コメント直しても試験やり直せよ?

301 :仕様書無しさん:2017/05/29(月) 13:48:23.46
>>300
やり直すわけないだろ
バカか?
コメント消したらなぜか動かないとかいつの時代だよ
ていうかビルドと自動テストで十分なレベルだろ

302 :仕様書無しさん:2017/05/29(月) 14:14:10.84
いまどきは修正したコードが通るパターンを通すだけだからなぁ〜。

303 :仕様書無しさん:2017/05/29(月) 16:25:07.47
てか、IDE使ってるならコメント行非表示にする機能あるだろ?
邪魔だと思ったら表示しなければいいだけ。
なんかさ、一部の勘違い野郎は自分が基準で周りも自分に合わせてくれると
思ってるみたいだが、そんな考え方してると仕事できないだろ。
周りを自分に合わせようとするのはやめれ。
自分が周りに合わせなよ。

304 :仕様書無しさん:2017/05/29(月) 16:43:03.00
>>303
> 周りを自分に合わせようとするのはやめれ。
> 自分が周りに合わせなよ。
両方バランス良くあるべきだと思うよ
クソな環境は可能なら正すべきだし、微妙なラインは妥協すべきだろうし

305 :仕様書無しさん:2017/05/29(月) 20:18:00.65
ドキュメントコメントからXMLを生成する
そのXMLにはデータやスクリプトが埋め込まれてる
それらがないとまともに動かない
そんなクソシステムを保守させられて以来コメントを見ると吐き気や頭痛に襲われるようになってしまった

306 :仕様書無しさん:2017/05/29(月) 23:18:59.39
>>301
あほか
ソースファイル更新したら試験は必須
お前、働いたことすら無いだろ?

307 :仕様書無しさん:2017/05/29(月) 23:39:30.13
>>306
よっぽど暇と人がある部署でダラダラと働いてるんだね

308 :仕様書無しさん:2017/05/29(月) 23:44:13.82
>>307
いまどきテストじゃなくて試験(笑)って言ってるアレな人だから、あんまり刺激するなよ

309 :仕様書無しさん:2017/05/30(火) 00:28:18.23
phpunitとかjunitに通すってことじゃない?

310 :仕様書無しさん:2017/05/30(火) 00:41:09.87
>>308
試験とテストは意味が違うから

311 :仕様書無しさん:2017/05/30(火) 00:41:48.68
>>307
こういう馬鹿がいるから事故が起きる

312 :仕様書無しさん:2017/05/30(火) 01:09:20.53
>>305
俺はPL/SQLで頭痛がする(1関数5000行の衝撃)

>>309
「試験」と言ってる人はおそらく業務系かつ基幹系で、年期入ってる人のようだから
「テスト仕様書記載の項目を手作業でチェックし直し」のことだろう

diff取ってコメント欄しか変わってないならテスト不要だろうが
版管理使ってない所なら誤爆タイプ(ソースを探してるときになんか a とか誤タイプしちゃうアレ)の
チェックって意味でやってもいいかも

俺だったらgitかsvnでローカルに保存しといてdiff取ると思うが
現場によっては勝手にアプリ入れるな、申告しても「そんなツールはダメ」の場合がある
diffっつかWinMergeの類すらもダメ(だからフォルダ別保存でdiffも取れない)
まぁそんな環境ならコメント直しただけでもテストやり直しってのはあるかも

その手の現場で「試験とは不具合を見つけるのが目的、検査表が一回目で全部〇になるのはおかしい」
とか言われたの思い出したことあるな
事前にテスト用コード書いて流して直したりしたんでエラーないのわかってたんだが
以後無作為に1〜2コ×にして、二回目欄に〇にするとかやったな

313 :仕様書無しさん:2017/05/30(火) 01:45:08.77
> その手の現場で「試験とは不具合を見つけるのが目的、検査表が一回目で全部〇になるのはおかしい」

理屈はわからなくはないけど、じゃあ検査表が全部○になるのは
だいたい何回目ぐらいですか?って聞きたくなるな。


試験が不具合を見つけるものであるならば、
試験より前に不具合を見つけるのはやったらいけないのか?

試験より前に不具合を見つけなければ、
それは何十回も試験しなければ全部○になることはないだろう。
どうせその工数入れてないくせに

314 :仕様書無しさん:2017/05/30(火) 02:25:20.86
>>313
なんかよくわからんが、そこの検査表は確か5回目まで欄があったから
あの会社では5回までミスることがあったんだろう

xxxxxをドコソコに入れると何とかと表示されること | × | 2009/3/23 | 〇 | 2009/3/24
yyyyをドコソコに入れるとホゲホゲの値が入ること | 〇 | 2009/3/23 |

みたいなフォーマットだったかな、たしか
まぁ一発書きして適当に手入力で値入れて、そっからテスト仕様書見て動かしてたんじゃないか? 知らんけど……

315 :仕様書無しさん:2017/05/30(火) 02:29:49.56
だいぶ昔か、俺も年食ったな……なんかハンコつくだけでカネがすげぇ入ってくる仕事ない?
あったらカネもらって万札握りしめてサーバラックとか買いに行っちゃうよ

316 :仕様書無しさん:2017/05/30(火) 08:19:37.84
せめてコメントちゃんと書いてくれれば
開発の能率がだいぶ上がることはみんな分かっているはずだと思うが

どうやら「ソースで読む」ことを楽しんでいるようだw

317 :仕様書無しさん:2017/05/30(火) 08:56:21.61
コメント不要って言ってる人たちは、コメントがいらないということを主張したいんじゃなくて、
コメントいらないくらい綺麗なコードを書いてる自分アピールなんだよ
そりゃ自分で実装したコードなら、無茶苦茶な英語で関数や変数の命名してても、コメントなしで読めるよねっていうw

318 :仕様書無しさん:2017/05/30(火) 08:57:31.63
>>310
じゃぁ試験って英語の単語はなんですか?

>>314
NE○だろ
そこの子会社に派遣されてた頃、本部から押し付けられたてたっぽい
かれこれ数年前の話だな

319 :仕様書無しさん:2017/05/30(火) 09:38:20.77
コメント修正くらいじゃコンパイル結果の比較くらいしかしないなぁ。
で、なぜか一致しないんだよなw

82 KB
新着レスの表示

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50
名前: E-mail (省略可) :


read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)