2ちゃんねる ■掲示板に戻る■ 全部 1- 最新50    

■ このスレッドは過去ログ倉庫に格納されています

いきなりコードを書くな。設計してから書け。 その4

1 :仕様書無しさん:2016/02/13(土) 23:07:16.05 .net
ソフトウェア設計とは何か?
http://knagano.tumblr.com/post/11941519742/
http://web.archive.org/web/20080803072849/www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

私は自らが理解しているソフトウェア開発のライフサイクルを再吟味することにより,
工学的な設計基準を本当に満足しているソフトウェア・ドキュメントというものが,
ソースコード・リスティングだけであるという結論に到達したのです。

この仮定に対しては,賛否両論さまざまな意見が存在しているはずです。 このため本記事では,
真のソフトウェア設計が最終的なソースコードであると仮定した場合に,この仮定から導き出される帰結のいくつかを検証しています。

ソースコードがソフトウェア設計であると考えることによって重大な帰結が導き出されます。
この帰結はあまりにも重要かつ自明であるものの,ほとんどのソフトウェア組織において盲点となっているものです。
それは,ソフトウェアの製造(ビルド)が安価なものであるという事実です。
あまりにも安いため安価なものとして見なす必要すらなく,ほとんど無料といっても良いくらいなのです。

ソースコードがソフトウェア設計であると考えた場合,ソフトウェアの本当の製造は
コンパイラとリンカによって行われることになるわけです。 私たち自身もソフトウェア・システム全体の
コンパイルとリンクのプロセスを,しばしば「ビルドを行う("doing a build")」と呼んでいます。

ソースコードがソフトウェア設計であると考えた場合,

要約すると

コーディングは,信じられている以上に意味のある作業です。 コードによって設計を描き出すプロセスはしばしば,
見逃しや追加設計を行う必要性を暴き出してくれるのです。 こういったことを早期に行えば,設計はより優れたものとなるわけです。

テスティングとデバッギングは,設計アクティビティです。 これらは,他の工学分野における設計の検証と洗練プロセスと等価なものなのです。

すべての設計アクティビティは相互に作用します。 優れたソフトウェア設計プロセスはこのことを
認識しているため,様々な設計ステップによって変更の必要性が顕在化した場合,大胆なまでの設計変更を許しています。

2 :仕様書無しさん:2016/02/13(土) 23:24:14.50 .net
寒いと風邪をひく・・・間違い
寒いと免疫力が低くなって様々な病気にかかりやすくなる・・・正解


別に風邪をひくと決まったわけじゃない。

3 :仕様書無しさん:2016/02/13(土) 23:26:11.43 .net
>>2
寒いと免疫力が低くなる?お前それで論文書けるぞ、すげえな

4 :仕様書無しさん:2016/02/13(土) 23:28:21.59 .net
>>2
こんな論理的な考えはプログラマーにしかできない。プログラマーってやっぱすごい。

5 :仕様書無しさん:2016/02/13(土) 23:29:18.51 .net
まだやんの?
適当にコード書き始めて失敗してるプロジェクトだらけの現状見れば4も続ける意味ないだろ。
俺の言うこと聞けよっていう派遣コーダとseの無意味な煽り合いにしかなってないし、ソフトウェア業界は小学生レベルのゴミしかいないって言ってるようなもん

6 :仕様書無しさん:2016/02/13(土) 23:29:28.03 .net
カッカしすぎだぜ似非SE

7 :仕様書無しさん:2016/02/13(土) 23:30:32.92 .net
>>6
なかよくやろうよ

8 :仕様書無しさん:2016/02/13(土) 23:31:02.27 .net
そんなに嫌ならコーダーやめてSEになればいいのに

無理だろうけどw

9 :仕様書無しさん:2016/02/13(土) 23:31:59.22 .net
>>8
コーダーが楽なんだよ、言わせんな

10 :仕様書無しさん:2016/02/13(土) 23:39:51.44 .net
>>1が今までの>>1を変えてしまったから
スレタイと>>1の内容が全然噛み合わなくなってるな

まあ重要だから改めて

1992年「ソフトウェア設計とは何か?」
http://knagano.tumblr.com/post/11941519742/


20年以上も前に、コーディングで設計することの重要性を示した内容
設計においてプログラミングスキルは不可欠で(そりゃま当然の話)
プログラムの書けない似非SEはこの世にいらない
そしてプログラミングを設計に活かすことを推奨している内容

11 :仕様書無しさん:2016/02/13(土) 23:41:33.58 .net
プログラミングに精通してると要件定義も設計も超簡単だよね
プログラムが書けない自称SEには死ぬほど難しいみたいだけど

12 :仕様書無しさん:2016/02/13(土) 23:44:38.25 .net
>>3
> 寒いと免疫力が低くなる?お前それで論文書けるぞ、すげえな

「寒さは本当に風邪のもと」、米イエール大が研究発表
http://jp.reuters.com/article/cold-yale-idJPKBN0KF06320150106

13 :仕様書無しさん:2016/02/13(土) 23:46:45.23 .net
>>12
もう論文がありますなw

似非SEってどこまでバカなんだろう

14 :仕様書無しさん:2016/02/13(土) 23:48:12.11 .net
>>12
論文が出続けてるってことは、結論が出てないってことだ。最先端の研究に携わってるなんて尊敬するわー。

15 :仕様書無しさん:2016/02/13(土) 23:49:56.38 .net
>>13
論文が何か勘違いしてるよ、君。もう一度大学に戻って教えてもらいな。
あ、高卒かwww

16 :仕様書無しさん:2016/02/13(土) 23:50:22.99 .net
>>13
論文があるから何なの?

17 :仕様書無しさん:2016/02/13(土) 23:51:33.85 .net
>>15
専門卒だよバカにすんな

18 :仕様書無しさん:2016/02/13(土) 23:53:00.37 .net
論文の立ち位置わかってないやつ多すぎワロタwww

19 :仕様書無しさん:2016/02/13(土) 23:54:02.89 .net
>>18
SEやコーダーに論文なんて求められないからな。プログラマーと違って。

20 :仕様書無しさん:2016/02/13(土) 23:54:21.50 .net
釣れるときはほんとうによく釣れるわw

21 :仕様書無しさん:2016/02/13(土) 23:55:04.24 .net
>>20
ご丁寧にリンクまでな。

22 :仕様書無しさん:2016/02/13(土) 23:55:43.40 .net
>>14
理論上みんながそう思ってるから同じ方向を目指して研究してるんだろ
アインシュタインの相対性理論がいまだ完全には証明されてなくて
それを証明するために世界中の研究者が法外な額の設備で実証に向けて研究してるのと同じで

もしかして何が何でも反対意見を言うことに義務感を持ってねえ?
職場にたまにいるよ、とにかく反対意見ばっかり言う奴

23 :仕様書無しさん:2016/02/13(土) 23:58:04.39 .net
今度は免疫の話から論点を外そうと必死な似非SE

24 :仕様書無しさん:2016/02/13(土) 23:58:31.18 .net
>>22
だから最先端の研究に携われてすごいねって羨ましがってるんだよ

25 :仕様書無しさん:2016/02/14(日) 00:01:17.66 .net
>>23
ぼくと免疫の話する?

26 :仕様書無しさん:2016/02/14(日) 00:01:43.87 .net
>>25
一緒に解剖しようぜ

27 :仕様書無しさん:2016/02/14(日) 00:02:17.83 .net
ここまで全部一人

28 :仕様書無しさん:2016/02/14(日) 00:03:44.02 .net
>>24
自殺者まで出してる某細胞のニュースとか見てると
あんましそんな気にはなれんな

29 :仕様書無しさん:2016/02/14(日) 00:05:22.45 .net
>>28
えーウサギでもかって解剖しようよ

30 :仕様書無しさん:2016/02/14(日) 00:07:19.72 .net
>>29
解剖の目的は何だよ
最近多い小動物虐殺に快感をおぼえるタイプか?

31 :仕様書無しさん:2016/02/14(日) 00:10:02.84 .net
>>30
解剖したことないの?あの極めてシステマティックな機能美…プログラマーには共感するところが多いと思うけど。

32 :仕様書無しさん:2016/02/14(日) 00:19:06.55 .net
解剖ってスカートをめくる奴か?

33 :仕様書無しさん:2016/02/14(日) 00:21:16.34 .net
>>32
おもしろくない、やり直し

34 :仕様書無しさん:2016/02/14(日) 00:25:42.60 .net
スカートめくる方は茶巾絞りってやつだった。

35 :仕様書無しさん:2016/02/14(日) 00:28:20.53 .net
>>34
年齢を感じるな

36 :仕様書無しさん:2016/02/14(日) 00:29:01.76 .net
>>34
50代のプログラマーいる?Part10 [無断転載禁止]©2ch.net
http://tamae.2ch.net/test/read.cgi/prog/1453507186/

37 :仕様書無しさん:2016/02/14(日) 01:04:27.40 .net
話を戻すとやっぱりコードは設計書なんだよね。

例えばスイッチを押すとランプがつくという処理の設計図。
文字だとあまりにも簡単にかけるけど、設計は設計。

38 :仕様書無しさん:2016/02/14(日) 01:13:12.00 .net
>>31
通報かな

39 :仕様書無しさん:2016/02/14(日) 06:16:34.21 .net
>>31
お前の同類の精神異常者に、床に張り付けにされて
麻酔なしで腹をかっさばいてもらったら?
小動物虐殺に快感をおぼえる小者は、文字通り死ななきゃ治らない

40 :仕様書無しさん:2016/02/14(日) 10:10:45.09 .net
>>31
医者に見てもらった?
ちょっと君のことが心配

41 :仕様書無しさん:2016/02/14(日) 11:58:44.97 .net
最後に愛は勝つから心配ない

42 :仕様書無しさん:2016/02/14(日) 19:13:04.18 .net
チョコくれ

43 :仕様書無しさん:2016/02/15(月) 11:09:50.00 .net
日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む
http://simplearchitect.hatenablog.com/entry/2016/02/15/080413

くだらん(コードではない)設計書を作れとか言ってる奴、
読めよ

44 :仕様書無しさん:2016/02/15(月) 12:21:51.85 .net
その前にその下らんコードをもう少しマシにしてくれよ

45 :仕様書無しさん:2016/02/15(月) 12:52:47.31 .net
コードの重要性を理解していないところには無理だろうな。
コードは(コードではない)設計書よりも重要なもの。
当たり前の話だけどなw

46 :仕様書無しさん:2016/02/15(月) 17:29:39.41 .net
>>45
欧米はちゃんと要件定義くらいは直ぐ書くぞ

47 :仕様書無しさん:2016/02/15(月) 17:38:23.97 .net
>>46
それを見せてくれたら信じるよw

48 :仕様書無しさん:2016/02/15(月) 17:47:58.88 .net
要件なんてたいして変わらないものを
毎回やってるのが日本だよ。

欧米ではパッケージを導入する。
自社業務システムを独自に開発することはない。
つまり要件定義なんてものは客が出すものではないってことだ。

システムを導入して、そのシステムの方に柔軟な人間が合わせる。
日本は逆をやってる。

49 :仕様書無しさん:2016/02/15(月) 20:32:46.04 .net
>>48
自分の仕事の枠だけで考えるなよ

50 :仕様書無しさん:2016/02/16(火) 00:34:53.98 .net
>>43
これ見て設計書が要らないって結論になる思考回路はヤバイ
自分の中で決まってる結論に向けて物事の解釈を曲げてしまう奴が一番タチが悪い

51 :仕様書無しさん:2016/02/16(火) 01:05:38.22 .net
>>43の書き込みを見て、自分の都合のいい解釈をする思考回路が悪い
自分の中で決まってる結論に向けて物事の解釈を曲げてしまう奴が一番タチが悪い

52 :仕様書無しさん:2016/02/16(火) 07:12:04.72 .net
>>43
いいね
日本でもスタイルをいじりやすい小規模企業あたりは
近いことを実践してるところは割とあったりする

まず上下関係がなくて立場が全員同じだからストレスがない
役職名で呼ぶのなんて社長くらいだし、カジュアルな会社だと
社長を付けないで名前で呼んだりってところも多い
上から話す奴がいないのでストレスが少なく仕事が円滑に進むし
仕事も早いし、クオリティも高い

上下関係が厳しいところほど形に拘りがあって会議、報告書、プレゼン、
このあたりにやたらと時間を掛ける割合が増えてくる
当然スピードは遅く、会議やプレゼンは参加者全員がコスト
なにより実務者は実務に専念できなくなりクオリティも落ちる

どんな仕事でもスピード感は大事だよね
実務時間を減らしてしまったら手抜きでしか時間を割けなくなる

53 :仕様書無しさん:2016/02/16(火) 10:18:01.36 .net
俺が作るコードではない設計書は有用なもの
お前が作るコードではない設計書はくだらんもの

というの、いい加減やめてもらえませんかね

54 :仕様書無しさん:2016/02/16(火) 10:22:44.25 .net
無駄な仕事で足を引っ張るやつの多いこと

55 :仕様書無しさん:2016/02/16(火) 11:02:56.01 .net
お前らの論点はウォーターフォールがダメって事では無いんだよな?
アジャイル、DDD最高!V字モデルで設計?ありえないってわけじゃ無いだろ?
>>43にある様な文化的な話として、特に顕著な例としてお役所文書的な設計書なんて要らねって事で理解あってるよな?

56 :仕様書無しさん:2016/02/16(火) 11:55:36.03 .net
>>55
いまどきアジャイルでDDDじゃないところは早く潰れたほうがいいよ
3週ぐらい周回遅れだから

57 :仕様書無しさん:2016/02/16(火) 12:02:56.39 .net
3週くらいならたいしたことないな

58 :仕様書無しさん:2016/02/16(火) 12:05:26.53 .net
>>56
適材適所

59 :仕様書無しさん:2016/02/16(火) 12:14:15.74 .net
>>58
ユーザーの欲しいものを作るのが大多数のプログラマの仕事なわけだけど、
ウォーターフォールのほうが適した(よりユーザーの要求を満たす)状況って例えば?

60 :仕様書無しさん:2016/02/16(火) 12:27:29.56 .net
ユーザーの欲しい物を作るのに開発手法は関係ないですから

61 :仕様書無しさん:2016/02/16(火) 13:19:50.03 .net
ユーザが自分の欲しいものが何であるかをわかっているということはまれ。
品質面において、その傾向が顕著。

62 :仕様書無しさん:2016/02/16(火) 13:22:00.94 .net
FJネクスト エフ・ジェー・ネクスト 迷惑電話6評判 [無断転載禁止]・2ch.net

http://hayabusa6.2ch.net/test/read.cgi/estate/1453977144/

63 :仕様書無しさん:2016/02/16(火) 13:26:53.11 .net
>>60
> ユーザーの欲しい物を作るのに開発手法は関係ないですから
関係あるよ。
アジャイルは、ウォーターフォールとは顧客との関係が異なるし、
DDDは、顧客の関心事を分析モデル化する手法。

64 :仕様書無しさん:2016/02/16(火) 13:32:44.49 .net
>>60
あー、またこいつ屁理屈こねそうな予感

65 :仕様書無しさん:2016/02/16(火) 13:41:30.97 .net
ウォーターフォールは、もはや大規模開発(数百人月以上)以外では不要でしょ

66 :仕様書無しさん:2016/02/16(火) 13:43:51.08 .net
大手SIer主導プロジェクト以外ではもういらんでしょ

67 :仕様書無しさん:2016/02/16(火) 14:44:34.75 .net
>>55
> お前らの論点はウォーターフォールがダメって事では無いんだよな?

ウォータフォールでも必要ない資料を作らないで
つまり無駄な上位工程をすっ飛ばして、いきなり下位工程を
やるようなことをしていいならOKだよ。

これをウォータフォールって呼ばないと思うがねw

基本的に上位工程でわかるはずがないことを、机上の空論で
考えて決定するし、反論は許さないって方法ががいけない。
さっと方向性だけ決めてすぐに動くものを作って検証。
これにまさるスピードはない。

68 :仕様書無しさん:2016/02/16(火) 14:47:25.61 .net
>>65
なんでそんな大規模開発が出来上がるのかがさっぱりわからんわw

無駄な資料を作るのに時間がかかって、
無駄な資料を読むのに時間がかかってるだけじゃないのかねぇ

69 :仕様書無しさん:2016/02/16(火) 15:34:22.27 .net
>>68
> なんでそんな大規模開発が出来上がるのかがさっぱりわからんわw
どんだけ視野が狭いんだよ

70 :仕様書無しさん:2016/02/16(火) 15:42:58.41 .net
>>67
ほんと頭悪いなぁ

お前がウォーターフォールと呼ぶものでコメントしろよ

71 :仕様書無しさん:2016/02/16(火) 15:44:18.69 .net
>>69
そういうレスじゃなくて、
大規模になってしまう理由のほうを言ってね。

開発効率が悪いから大したことがないシステムでも
大規模になってしまう。

72 :仕様書無しさん:2016/02/16(火) 15:45:40.05 .net
何か言い返したいけど言い返す言葉が思いつかない。

「ばーかばーか、お前の母ちゃんでーべーそ」

よし、言い返したぞ!(何も言い返していない)

73 :仕様書無しさん:2016/02/16(火) 15:46:40.44 .net
>>71
じゃ、銀行のシステム統合を100人月くらいでやってくれよ

74 :仕様書無しさん:2016/02/16(火) 15:48:03.37 .net
>>73
だから、何人月ぐらいかかるのは
○○という理由で当然だっていう
計算方法を書けよ。

結局、お前だって、時間がかかる根拠
わかってないんじゃないか。

75 :仕様書無しさん:2016/02/16(火) 15:51:05.51 .net
>>74
> なんでそんな大規模開発が出来上がるのかがさっぱりわからんわw
なぜなら、システムの規模がでかいから

こんなこともわからんのか

76 :仕様書無しさん:2016/02/16(火) 15:51:46.32 .net
開発する人がいます。
システムが失敗した時全責任を押し付けられたくありません。

上司が居ます。
でもシステムが失敗した時全責任を押し付けられたくありません。

さらに上司が居ます。
でもシステムが失敗した時全責任を押し付けられたくありません。

さらに上司が居ます。
でもシステムが失敗した時全責任を押し付けられたくありません。

責任持ちますけど、その分高い給料ください。

その部下
責任の一部を請け負いますけど、、その分高い給料ください。

その部下
責任の一部を請け負いますけど、、その分高い給料ください。

その部下
責任の一部を請け負いますけど、、その分高い給料ください。

こうやって責任者の数が増えて金額も膨大になっていくw

77 :仕様書無しさん:2016/02/16(火) 15:52:47.43 .net
>>75
> なぜなら、システムの規模がでかいから

答えになってねぇよw

利用者の多さと、システムの規模は比例しない。
データの多さと、システムの規模も比例しない。

78 :仕様書無しさん:2016/02/16(火) 15:52:58.76 .net
>>68
10人のエンジニアが1年がかりであっさり100人月を越えるわけだけど、数百人月って規模感がほんとにわかんないの?
経験値も想像力も低すぎ。恥ずかしいから口出さないほうがいいレベル。

79 :仕様書無しさん:2016/02/16(火) 15:55:54.17 .net
> 10人のエンジニアが1年がかりであっさり100人月を越えるわけだけど、数百人月って規模感がほんとにわかんないの?

俺に言われてもなぁ。

数百人月が大規模なんでしょう?w

80 :仕様書無しさん:2016/02/16(火) 15:56:30.08 .net
65 名前:仕様書無しさん[sage] 投稿日:2016/02/16(火) 13:41:30.97
ウォーターフォールは、もはや大規模開発(数百人月以上)以外では不要でしょ

81 :仕様書無しさん:2016/02/16(火) 15:58:42.15 .net
100人月と言われても、生産性は100倍位あるのだから、
10000人月にも1人月にもなったりする。
人月じゃ規模なんてわからねぇよ。

82 :仕様書無しさん:2016/02/16(火) 15:58:55.70 .net
>>77
> 利用者の多さと、システムの規模は比例しない。
> データの多さと、システムの規模も比例しない。
ど素人か、はたまた想像力ゼロなのか

これでも読んどけ
http://www.ipa.go.jp/sec/softwareengineering/std/ent01-c.html

83 :仕様書無しさん:2016/02/16(火) 16:00:19.68 .net
生産性は100倍位、差があるのだから、

84 :仕様書無しさん:2016/02/16(火) 16:00:59.28 .net
>>82
まーた、反論できない。

結局お前、お前自身は何の根拠も持ってないじゃんw

85 :仕様書無しさん:2016/02/16(火) 16:04:45.51 .net
>>84
なんの反論だか

> なんでそんな大規模開発が出来上がるのかがさっぱりわからんわw

もともと規模がでかい(エンタープライズ系とか言われる)なら、開発規模もでかいだろ
エンタープライズ系のでかいシステムでも100人月あればできるっしょとか言うのか

86 :仕様書無しさん:2016/02/16(火) 16:07:43.61 .net
100人月を大規模といったのは俺じゃないし、
銀行のシステムを100人月でできるとも言ってない。

全部お前が言い出したことだろ?


大したことがないシステムが大規模になるのは
無駄な資料作り過ぎじゃねーのかって言ってる。

87 :仕様書無しさん:2016/02/16(火) 16:10:20.17 .net
>>86
> 全部お前が言い出したことだろ?
は?俺も言ってないし

> 大したことがないシステムが大規模になるのは
「たいしたことがあるシステム」が大規模になるって言ってるんだが

88 :仕様書無しさん:2016/02/16(火) 16:13:12.86 .net
>>87
俺は最初から「たいしたことがないシステム」が大規模になってるのは
無駄な資料を作りすぎてるからって話をしてるんだが?

一般企業で必要とされるようなシステムのほとんどは
たいしたことがないシステムだよ。
本当に大規模なシステムなんてめったに存在しない。

89 :仕様書無しさん:2016/02/16(火) 16:14:30.93 .net
いや俺じゃねーし

90 :仕様書無しさん:2016/02/16(火) 16:15:14.12 .net
大企業の基幹システムなんて100万行くらいはざらな世界なのに、数百人月程度の規模も想像できない奴がいるとは。

91 :仕様書無しさん:2016/02/16(火) 16:15:41.19 .net
>>88
> 無駄な資料を作りすぎてるからって話をしてるんだが?
というつもりにしかすぎないことを自覚しましょう

> 本当に大規模なシステムなんてめったに存在しない。
お前の「めったに」がどれくらいか、定数的に示せ

92 :仕様書無しさん:2016/02/16(火) 16:17:33.90 .net
>>88
お前が心の中で「大したことないシステム」って前提を置いてることなんて他人にはわかるわけないんだが

93 :仕様書無しさん:2016/02/16(火) 16:17:46.05 .net
めったに=5年に1度

94 :仕様書無しさん:2016/02/16(火) 16:18:28.99 .net
どこからが「大規模」なのか知らないが、数千人月超のシステムなんてざらでしょ。
大きくなればなるほど、ウォーターフォール(スパイラル絡めながら)なとこが多いでしょ。
第○次開発とかいって、2,3ライン走って完成。

95 :仕様書無しさん:2016/02/16(火) 16:18:35.34 .net
>>90
> 大企業の基幹システムなんて100万行くらいはざらな世界なのに
行数で規模なんて判定できない。
開発効率が悪いだけだろw

>>91
> お前の「めったに」がどれくらいか、定数的に示せ
銀行以外全てでいいんじゃね?
お前、人生で何年、銀行のシステムを作り続けてるんだ?w

96 :仕様書無しさん:2016/02/16(火) 16:19:18.26 .net
>>94
開発効率が悪いから、大規模になっちゃってるんだろうね。

97 :仕様書無しさん:2016/02/16(火) 16:20:43.09 .net
「大規模システム」なんて存在しません病

98 :仕様書無しさん:2016/02/16(火) 16:22:55.76 .net
>>95
銀行ぐらいしか想像できないとか…
こいつ最大で何人月くらいのシステムに関わってきたんだろ。
50人月くらいか?いや、50人月の規模感がわかればその10倍の規模なんてざらにあることも想像できるよな…

99 :仕様書無しさん:2016/02/16(火) 16:23:05.84 .net
わしゃ30ねんぢゃ

100 :仕様書無しさん:2016/02/16(火) 16:23:52.46 .net
開発効率がわるければ開発工数が膨らむのは事実だが、
だからといって、大規模システムの全て(あるいは大半)が、開発効率の悪さの結果だというのは誤り。

101 :仕様書無しさん:2016/02/16(火) 16:24:49.48 .net
大手SIerの実績調べれば、大規模システムの例なんて腐るほど見つかるのに

102 :仕様書無しさん:2016/02/16(火) 17:48:43.77 .net
SIer=開発効率が悪い代表例なので

大手SIerとにはあると言ってる時点で、
開発効率が悪いところにしか無いってイメージになるなw

103 :仕様書無しさん:2016/02/16(火) 20:05:56.61 .net
無限にタダで直してくれるんなら、設計書いらないよね。

104 :仕様書無しさん:2016/02/16(火) 21:28:10.20 .net
>>60
関係ありすぎ。
とりあえずウォーターフォールは客にとって融通が利きにくく
開発サイドにしても柔軟に対応し難い。
なにより、ここにいるような作れない無能が上流担当じゃ
もう話にならない。

105 :仕様書無しさん:2016/02/16(火) 21:30:14.54 .net
>>103
設計書がないと無料になる理屈がさっぱりわからん

106 :仕様書無しさん:2016/02/16(火) 21:31:02.51 .net
無限とは言わんが延々と客にダメ出しされ続けてるやつ多そうだなw

107 :仕様書無しさん:2016/02/16(火) 21:33:44.30 .net
>>106
わけわからん、仕様書で客先承認取ってるんだろ
ダメ出しは仕様を満たしてない限りは新規受注扱いだろ

108 :仕様書無しさん:2016/02/16(火) 21:36:52.20 .net
>>107
だろって俺に言われてもw
それが出来ないからここでブーたれてんだろお前w

109 :仕様書無しさん:2016/02/16(火) 21:48:22.81 .net
>>108
わけわからん、俺がどこでぶーたれたの?
ダメ出しねえし、仕様にない話は追加仕様として見積もってるし

110 :仕様書無しさん:2016/02/16(火) 21:50:36.78 .net
>>103 >>106
で、設計書がないと無料になる理屈を
論理的に穴なく簡潔に説明してくれ

111 :仕様書無しさん:2016/02/16(火) 21:53:25.29 .net
>>109
じゃあ何しに俺に絡んできたんだよw
お前の方が訳わからんわw

112 :仕様書無しさん:2016/02/16(火) 22:31:53.13 .net
>>111
誰だよお前

113 :仕様書無しさん:2016/02/16(火) 23:14:53.43 .net
お前ら匿名の影に隠れる卑怯者の分際で自己主張が激しいな

114 :仕様書無しさん:2016/02/16(火) 23:47:35.84 .net
設計してから書けってのは一見正しいけど、
それはあくまでレビュー体制が整っている場合の話
誰の指摘も確認も貰わずに設計書書いてコーディングして…
なんてことしてたら直にコーディング始めるのと大差ない

115 :仕様書無しさん:2016/02/17(水) 00:00:37.20 .net
>>114
そうでもなくね?
設計は頭を使う。コーディングは手を使う。
一つのことに集中することによって設計の質も高まるし、
コードの質も高まる。コーディング時に頭を使うのはさながら
携帯電話をみながら車を運転するようなもの。事故の元。

116 :仕様書無しさん:2016/02/17(水) 00:06:31.91 .net
>>115
それはコーディングが清書って意味だよな
なら設計書も、頭を使わず書き写すだけでよいコードと同等のレベルで書く必要がある
つまり設計書=コード

117 :仕様書無しさん:2016/02/17(水) 00:13:20.58 .net
>>116
設計書はいい加減に書くべきだ。
[設定ファイルで指定した回数ループ]とかでいい。
コーディング時は
Config config = Config.loadFrom...
for (int i = 0; ...
とか書かなければいけないが、それくらいなら
頭なくてもできるだろ。右手の毛細血管の思考力で事足りる。
左手は添えるだけ。

118 :仕様書無しさん:2016/02/17(水) 00:19:20.16 .net
>>117
> 設計書はいい加減に書くべきだ。
手を使うってこと?

意味不明なんだけどw

119 :仕様書無しさん:2016/02/17(水) 00:21:21.07 .net
>>117
> [設定ファイルで指定した回数ループ]とかでいい。

doLoop(config.loopCount)

でいいやん?
日本語で書きたくなったら、それをコードにすればいいんやで?

120 :仕様書無しさん:2016/02/17(水) 01:13:05.26 .net
ありふれたプログラムを書きたいのなら設計書書けばいい
これまで存在しない概念のプログラム書くのに設計書なんて書いてたらありふれたものになってしまう

設計書が必要なプログラムなんて、誰でも組めるんだよね
そんなコードばかり書いていて何が楽しいんだろ

121 :仕様書無しさん:2016/02/17(水) 01:14:30.15 .net
>>120
ありふれたプログラムばかり書いてる人が言っても説得力ないんじゃないですか?

122 :仕様書無しさん:2016/02/17(水) 01:20:11.89 .net
>>121
(笑)

123 :仕様書無しさん:2016/02/17(水) 05:39:17.18 .net
計算は頭を使う。解答は手を使う。
一つのことに集中することによって計算の質も高まるし、
解答の質も高まる。解答時に頭を使うのはさながら
交通標識をみながら車を運転するようなもの。事故の元。

124 :仕様書無しさん:2016/02/17(水) 06:12:03.01 .net
あいかわらず珍論奇論の宝庫やねここw
これがコーダーの気組みってやつですかw

125 :仕様書無しさん:2016/02/17(水) 06:27:07.33 .net
>>117
なるほど
設計とコーディングのどっちにも頭使わないから
お前が作ったものはバグだらけなんだな

126 :仕様書無しさん:2016/02/17(水) 07:21:46.76 .net
また論破されてコーダー発言か、わかりやすい子だね
設計書が必要な子は単純なんだね

127 :仕様書無しさん:2016/02/17(水) 07:58:10.35 .net
「実際にコード書いてみないとわかりません」
技術力がありませんと自己申告してるのと一緒

128 :仕様書無しさん:2016/02/17(水) 09:30:49.58 .net
>>127
わかる

129 :仕様書無しさん:2016/02/17(水) 09:37:05.68 .net
大抵のプログラミングは誰がやっても同じだけど、解析演算系だとセンスが出るよ
設計書なんてちまちま書いているようなテンプレ開発者にはパフォーマンス出すのは無理
遅くても仕様ですって言い訳するでしょ

設計書設計書言うのはつぶしがきかない文系プログラマ
誰にでも代えがきくマックのバイトみたいなもの

130 :仕様書無しさん:2016/02/17(水) 09:52:23.94 .net
>>129
お前のやってる仕事と同等以上の成果が出せる奴もたくさんいるよーんw

131 :仕様書無しさん:2016/02/17(水) 10:09:07.19 .net
>>130
そりゃそうだ。それを否定するつもりはない
無勉で慶應入ったけどそれ以上の人はいるし
副業PGで月50〜100万稼いでるけどそれ以上の人はいるし

チームで作業するような誰かに足を引っ張られる仕事は避けてる
設計書設計書いうような人と仕事するのは効率悪い
設計書書いてるのに何故バグが出るのか理解不能

132 :仕様書無しさん:2016/02/17(水) 11:15:12.36 .net
>>117
> 設計書はいい加減に書くべきだ。
> [設定ファイルで指定した回数ループ]とかでいい。

今時こんな設計書書く奴いるのかwww
1万行のコード書くのに、設計書何ページ書いてんだよwww

133 :仕様書無しさん:2016/02/17(水) 11:27:43.06 .net
>>131
優秀なプログラマでPGって言葉使う人は見たことないなあw

134 :仕様書無しさん:2016/02/17(水) 11:59:32.66 .net
こんな設計書書いてるのかな。

1 ・・・
2 設定ファイルを読み込む
3 以下の処理を設定ファイルで指定した回数ループ
3-1 ・・・
3-2 ・・・
・・・
3-3 以下の処理を・・・回ループ
3-3-1 ・・・
3-3-2 ・・・
・・・
3-4 ・・・の場合以下の処理を実行
3-4-1 ・・・
3-4-2 ・・・
・・・
3-5 ・・・
・・・
4 ・・・・
・・・

135 :仕様書無しさん:2016/02/17(水) 12:49:06.66 .net
>>134
2と3の間に処理が追加され、涙目で項番を振り直す

136 :仕様書無しさん:2016/02/17(水) 12:52:46.98 .net
さっき追加した処理やっぱいらねーわと言われ、再び涙目で項番を振り直す

137 :仕様書無しさん:2016/02/17(水) 13:15:55.62 .net
>>135
なんでもExcelマンには手動で項番振り直す発想しかないんだな

138 :仕様書無しさん:2016/02/17(水) 13:29:33.83 .net
設計書の「指摘事項」のドキュメントが、これまた「第○章 3-2の指摘」とか書かれていて
項番を振り直すことが許されてない

139 :仕様書無しさん:2016/02/17(水) 13:31:21.34 .net
ほんと、しょうもないことに工数使うよな。

140 :仕様書無しさん:2016/02/17(水) 13:43:07.45 .net
> 「第○章 3-2の指摘」
↑を信じて第○章 3-2を見たところ全く無関係の内容でしばし迷子になる

141 :仕様書無しさん:2016/02/17(水) 13:48:09.10 .net
> 3-4 3-1-2の結果が…の場合以下の処理を実行
    ↑どこかで項番を振り直し忘れて身元不明の3-1-2

142 :仕様書無しさん:2016/02/17(水) 13:48:58.29 .net
「2'」とか「3-3'-1」とか「3''-2'-1'''」とかになってカオス

143 :仕様書無しさん:2016/02/17(水) 13:56:09.94 .net
>>117
> 設計書はいい加減に書くべきだ。
> [設定ファイルで指定した回数ループ]とかでいい。

誰が何の目的で読むのか解らない設計書の典型

144 :仕様書無しさん:2016/02/17(水) 14:24:07.05 .net
>>117
> Config config = Config.loadFrom...
> for (int i = 0; ...
何このゴミコード

loadFromってことは設定ファイルから読み込むってことか?
設定内容を変えてテストするには
testHoge()
{
  Config config = Config.loadFrom...
  config.set('hoge', 20);
  config.save();

  Model model = Model.new();
  model.fuga();
  // assert
}
とかして、tearDown()で設定ファイルの内容を元に戻したりするのか?
ダサすぐる
  

145 :仕様書無しさん:2016/02/17(水) 14:34:58.68 .net
>>117
コードを書くときに頭を使わないから
> Config config = Config.loadFrom...
> for (int i = 0; ...
こんなコード書くんだよ。

146 :仕様書無しさん:2016/02/17(水) 14:38:02.62 .net
まさにこれか。

ソースコード見ればその人の技術力や考え方がわかる
http://tamae.2ch.net/test/read.cgi/prog/1402759653/

147 :仕様書無しさん:2016/02/17(水) 14:41:38.49 .net
>>144
ConfigのモッククラスにloadFromを実装、ぐらいはやるだろうせめて
どっちみちダサいなw

148 :仕様書無しさん:2016/02/17(水) 14:44:51.28 .net
>>129
そういうコードほど、
仕様書必要だと思うんだが

149 :仕様書無しさん:2016/02/17(水) 16:17:32.63 .net
>>148
パフォーマンスが重要なコードを書く場合、アプローチが二通りあって
・まず普通にコードを書いて、パフォーマンスを測定しボトルネックを解消していく
・コードを書く段階で細かくパフォーマンスのことを考慮するコードをにして、それを積み重ねる

前者で済む場合もあれば、後者の戦略でいった方が良い場合ある。
そして、後者の戦略は秘伝のタレ的要素があり、事前に設計書を書くなんて無理。
たとえば、こんなコードを書く。 http://myoga.web.fc2.com/prog/cpp/opti03.htm

150 :仕様書無しさん:2016/02/17(水) 16:19:19.89 .net
>>144
じゃあどうするのが至高なのか語れない時点でお前はただのいちゃもん屋でありゴミコードよりゴミな精神の持ち主

151 :仕様書無しさん:2016/02/17(水) 16:21:55.26 .net
あと、こういう事を考えながらコード書いたり。
http://myoga.web.fc2.com/prog/cpp/opti02.htm

152 :仕様書無しさん:2016/02/17(水) 16:23:25.47 .net
>>150
> じゃあどうするのが至高なのか語れない
そういうスレじゃないし

土下座して教えを請うなら考えてやってもいい

153 :仕様書無しさん:2016/02/17(水) 16:41:22.05 .net
>>152
簡潔に言えよ。できませんって。

154 :仕様書無しさん:2016/02/17(水) 16:52:44.20 .net
>>153
お前こそ白状しろよ

何が指摘されてるのかわかりませんって

155 :仕様書無しさん:2016/02/17(水) 16:53:29.71 .net
まぁ>>144のテストコード見て何も思わないんだったら、何言っても無駄かもな

156 :仕様書無しさん:2016/02/17(水) 17:07:24.08 .net
コードも駄目だが
>>117
> とか書かなければいけないが、それくらいなら
> 頭なくてもできるだろ。右手の毛細血管の思考力で事足りる。
> 左手は添えるだけ。
という認識なのがもっと駄目。

コード書くときは考えながら書け。

157 :仕様書無しさん:2016/02/17(水) 17:20:03.99 .net
>>115
> 設計は頭を使う。コーディングは手を使う。
> 一つのことに集中することによって設計の質も高まるし、
> コードの質も高まる。

全然高まってねぇw

158 :仕様書無しさん:2016/02/17(水) 18:00:11.79 .net
フルボッコw

159 :仕様書無しさん:2016/02/17(水) 18:03:03.46 .net
https://www.youtube.com/watch?v=lopqXAj87J8

160 :仕様書無しさん:2016/02/17(水) 18:26:58.04 .net
コード書く前にフローチャートを書くだろ?
それが設計書。

コードは設計書じゃないよ。

161 :仕様書無しさん:2016/02/17(水) 18:43:03.64 .net
設計書書いてその通り作って何が楽しいの?

162 :仕様書無しさん:2016/02/17(水) 18:53:41.86 .net
仕事は楽しむためのものじゃない。
プロ野球選手は楽しむために試合をしてるんじゃない。
儲けるために仕事をしているだけだ。

163 :仕様書無しさん:2016/02/17(水) 18:55:55.42 .net
つまらない人生だね
それで年収500以下だったら目も当てられない

164 :仕様書無しさん:2016/02/17(水) 18:58:40.85 .net
人生とは仕事の時間を除いた部分のことだ。
仕事で稼いだ金で人生を謳歌するんだよ。
仕事が人生とか哀れすぎるw

165 :仕様書無しさん:2016/02/17(水) 19:20:39.05 .net
確かにあわれだ
設計書なんて書いてるような奴らは無駄な時間、無駄な仕事してるから残業まみれだろうしね
不要になれば代役がいつでもきくから給料も低いんでしょ

166 :仕様書無しさん:2016/02/17(水) 19:48:30.57 .net
>>161
設計書書く。
プログラム作る。
お金もらう。
バレンタインが終わって値下げされたチョコを買う。
食べる。
美味しい。

つまり人生が楽しい。

167 :仕様書無しさん:2016/02/17(水) 19:50:33.86 .net
>>163
人生を楽しもうとしているユーチューバの方々だって
ときおり営業スマイルが見え隠れするだろ。
楽しいことばかりじゃないけれど本気で生きるってとても素敵なことだと
思うから本気で設計書くべきだ。

168 :仕様書無しさん:2016/02/17(水) 19:55:29.39 .net
>>165
寿司職人がお米をむぎゅむぎゅするのも時間の無駄。
しかし、寿司職人は自分の仕事に誇りを持っているし、お客さんも
そのむぎゅむぎゅを見て高いお金を出しても口にしたいと思う。
だから僕たちは一文字一文字魂込めて設計書を書くべきだ。
そしたらお客さんにもその思いはきっと伝わる。

169 :仕様書無しさん:2016/02/17(水) 21:16:48.07 .net
基本的に仕事は楽しいなぁ
パズル解きみたいな事やって金もらえるから最高だわ
自分でパズル解いても金もらえんしw

170 :仕様書無しさん:2016/02/17(水) 21:17:37.28 .net
自分でというかプライベートで解いてもねぇ

171 :仕様書無しさん:2016/02/17(水) 23:55:46.94 .net
また派遣の作業者が暴れてんのか

172 :仕様書無しさん:2016/02/18(木) 00:16:02.57 .net
>>134
今のPJがこれだわ
「項番末尾のピリオドが抜けてる」とか糞みたいなレビューされて死にそう

173 :仕様書無しさん:2016/02/18(木) 00:23:48.62 .net
>>172
カワイソス

174 :仕様書無しさん:2016/02/18(木) 00:31:27.75 .net
レビューでtypoを教えてくれるのはありがたいけどなー

175 :仕様書無しさん:2016/02/18(木) 00:37:20.39 .net
ああ、1.2.3.とかの項番で死にそうなのか
「2.5.2.4.1.のループを終了する」
とかマジで頭痛くなるw

176 :仕様書無しさん:2016/02/18(木) 00:38:23.96 .net
昔やったことあるけど、今はさすがにないな

177 :仕様書無しさん:2016/02/18(木) 00:40:26.18 .net
wordとかなら自動採番だけどな

178 :仕様書無しさん:2016/02/18(木) 00:47:10.87 .net
> レビューでtypoを教えてくれるのはありがたいけどなー

ぶっちゃけ、そういうのは直してくれたほうが早いと思うんだがな。

179 :仕様書無しさん:2016/02/18(木) 00:47:26.25 .net
>>177
そんな機能を使うのはズルだ。

180 :仕様書無しさん:2016/02/18(木) 00:54:25.74 .net
お前らってネットで文句垂れるだけで現実を改善しようとはしないのな

181 :仕様書無しさん:2016/02/18(木) 00:56:34.99 .net
>>172
「『3. 3.2』の『.』がボールドになってる」とかな

182 :仕様書無しさん:2016/02/18(木) 01:11:36.22 .net
>>181
神は細部に宿るんだよ。わかったらとっとと直せ。同じミスは二度とするな。

183 :仕様書無しさん:2016/02/18(木) 01:44:17.57 .net
あー言いそう

184 :仕様書無しさん:2016/02/18(木) 02:18:22.38 .net
メンゲルベルクじゃないんだから

185 :仕様書無しさん:2016/02/18(木) 07:03:59.72 .net
>お前らってネットで文句垂れるだけで現実を改善しようとはしないのな

ネットでは、タイプの練習と、クリエイティブが発揮できる
吉本よりも、俺のほうがうけると思っている
プログラマは才能な

おまえらの文、主語がないから文章になっていないよ、
プログラムの才能が無いんでないの

186 :仕様書無しさん:2016/02/18(木) 07:22:42.45 .net
どんなジャンルにも才能は必ずあるのに
プログラミングだけは才能を強く否定したがる人がいる

その人とは、作れないのにこの業界にいる人

187 :仕様書無しさん:2016/02/18(木) 07:26:59.57 .net
>>131
学歴自慢とか人間性最悪やん

188 :仕様書無しさん:2016/02/18(木) 07:30:04.93 .net
学歴自慢をする人は、そこで止まっちゃった人

189 :仕様書無しさん:2016/02/18(木) 10:57:37.26 .net
慶應程度が自慢に見える程このスレの住人はレベル低いのね
頭悪い自覚があるのに自分のやり方が正しいと思えるのは何でなんだろ
どうせインラインアセンブラも書いたことないんでしょ

190 :仕様書無しさん:2016/02/18(木) 11:12:45.80 .net
> どうせインラインアセンブラも書いたことないんでしょ

突然のインラインアセンブラww
そこにお前のアイデンティティがあるんだろうなw

191 :仕様書無しさん:2016/02/18(木) 11:17:32.85 .net
https://www.youtube.com/watch?v=JOdFOSa73C8

192 :仕様書無しさん:2016/02/18(木) 11:27:03.27 .net
【ビジネス】なぜ能力の低い人ほど自分を「過大評価」するのか [無断転載禁止]©2ch.net
http://potato.2ch.net/test/read.cgi/bizplus/1454838582/

193 :仕様書無しさん:2016/02/18(木) 11:41:46.75 .net
設計書は必要
チケット駆動でバックログに書き出すのだって設計書だから

問題なのは誰の為の設計書?ってなる体裁にうるさかったり、記載内容が細かったりする場合だが

・客の要求なら設計書自体が開発物と気持ちを切り替えて書けばいい
・社内的な決まりなら、こんなとこでウダウダ不満を書き連ねずに改善すればいい

194 :仕様書無しさん:2016/02/18(木) 12:38:44.95 .net
社内の決まりは実際には大抵背景があるし、自分の作業にしか目が向かない奴には改善は無理。視座が低いから誰も説得できない。
だからこんなスレが4まで伸びちゃう。

195 :仕様書無しさん:2016/02/18(木) 12:50:45.33 .net
1) 5人のPGをオリに入れます。オリの真ん中にハシゴを設置し、その上にイケてる開発環境を置いておきます。
2) 1人のPGがいきなりコードを書きにハシゴを登ると、残りのPGに罵声が浴びせられるようにPMをセットしておきます。
3) しばらくすると、5人のうちのどれかがハシゴに登ろうとするたび、残りのPGたちがよってたかって攻撃するようになりました。
4) やがて、どのPGもいきなりハシゴに登ろうとはしなくなりました。ハシゴの上にはイケてる開発環境があるのに……。
5) この状況で、1人だけPGを入れ替えます。新しいPG(新入り1号)はハシゴにまっしぐら。もちろん、残りのPGはこれを許さず、痛い目にあわせます。これを何度か繰り返し、新入り1号は理由もわからないまま、ハシゴに登らなくなります。
6) 再び、古参PGのうち1人を入れ替えます。ちょっと前に痛い目を見ていた新入り1号は、ハシゴに登ろうとする新入り2号をやっつける側に回ります。こうして古参サルを1匹ずつ入れ替えていくのですが、そのたびにPGたちは同じことを繰り返します。
7) 今や、オリの中にいるのは新入り1号から5号まで。どのPGも罵声をひっかけられたことがないというのに、ハシゴに登ろうとするPGをみんなでとっちめる、という行動は結局残ったまま。
8) PGたちに「どうしてハシゴを登る子をいじめるの?」という質問をしたなら、きっとこう答えるのでしょう――「わかんない。ここではそうするのがきまりだから」。

196 :仕様書無しさん:2016/02/18(木) 19:32:07.59 .net
今日も設計書書かないでクソコード量産してやったぜさまあ

197 :仕様書無しさん:2016/02/18(木) 19:33:21.92 .net
今日も必死だな 作れない設計書君

198 :仕様書無しさん:2016/02/18(木) 19:36:24.15 .net
>>197
お前一日中ここに張り付いてんのかよ気持悪いやつだなw

199 :仕様書無しさん:2016/02/18(木) 19:45:00.70 .net
>>198
お前一日中見張ってるのかよキショイなw

200 :仕様書無しさん:2016/02/18(木) 19:47:44.88 .net
このスレもついに掃き溜めにまで堕ちたかw

201 :仕様書無しさん:2016/02/18(木) 19:52:14.22 .net
>>194
自分で考える力が弱い人間は頭がカタいのよ
考える力を失った宗教団体の信者を改心させるのなんてほぼ無理だろ?

202 :仕様書無しさん:2016/02/19(金) 00:07:02.79 .net
「わかんない。ここではそうするのがきまりだから」

203 :仕様書無しさん:2016/02/19(金) 00:38:59.73 .net
なんというか、仕事が楽しくないと、
反対に、プログラミングが苦しいというのでは、病気になる
たとえば、「休みもコードを書いているのがいい」というタイプ
そういうのがプログラマだな
まあ、学生のときは数学が好きというのかな。
youtubeでプログラマが言っていたが、
数学について、「だれでも納得できる答えがあるからいい」というわけ
俺も数学にその快感があること分かるな

204 :仕様書無しさん:2016/02/19(金) 00:56:14.01 .net
文系には数学の感覚がワカランだろうとおもうわけ
文系は、そうしたパズル的なのより、
暗記して点数が取れるというのに価値観をもっているのではないか
今年の新入社員なんだが、難しい資格を持っている。
だが俺は彼に違和感がある、彼はすぐ答えを求めようとする点だ
プログラマというのは、創造的なんだけどね

205 :仕様書無しさん:2016/02/19(金) 01:01:47.49 .net
難しい資格=応用情報技術者試験

206 :仕様書無しさん:2016/02/19(金) 03:48:57.66 .net
応用情報技術者試験は簡単な資格だろw
「高度」の範囲には入ってないぞ。
https://www.jitec.ipa.go.jp/1_11seido/seido_gaiyo.html

そういうことも知らないんだろうな。>>205

207 :仕様書無しさん:2016/02/19(金) 03:58:57.84 .net
204の職場のレベルによる

208 :仕様書無しさん:2016/02/19(金) 04:09:57.66 .net
難しい資格と濁してるところがミソ

209 :仕様書無しさん:2016/02/19(金) 08:32:32.35 .net
>>205
無勉で取れた
趣味のレベルで分かる問題しか出ない

210 :仕様書無しさん:2016/02/19(金) 08:40:38.17 .net
204「…(基本情報技術者のことだったなんていまさら言えねえ)」

211 :仕様書無しさん:2016/02/19(金) 09:59:07.27 .net
>>209
盛ってる臭いがプンプンしますねぇw

212 :仕様書無しさん:2016/02/19(金) 11:06:38.21 .net
「趣味のレベル」ってところがいかにもw
「実務の延長」ならともかく

213 :仕様書無しさん:2016/02/19(金) 11:22:44.44 .net
あんなん趣味で覚えるとか、どんな変態趣味趣向してんだよw

214 :仕様書無しさん:2016/02/19(金) 11:35:47.76 .net
趣味のレベルで合格点が取れる、ならまだわかるけど“趣味のレベルで分かる問題しか出ない”だからな
マネジメントやらストラテジ系の用語も趣味で押さえてるってw

215 :仕様書無しさん:2016/02/19(金) 11:39:57.10 .net
自分を大きく見せたいお年頃なんだろうな

216 :仕様書無しさん:2016/02/19(金) 12:23:21.19 .net
共通フレーム2013にハマッてます(キリ

217 :仕様書無しさん:2016/02/19(金) 12:25:27.84 .net
コーダーって脳が子供のままなんだね

218 :仕様書無しさん:2016/02/19(金) 13:05:06.07 .net
FJネクスト エフ・ジェー・ネクスト 迷惑電話6評判 [無断転載禁止]・2ch.net

http://hayabusa6.2ch.net/test/read.cgi/estate/1453977144/

219 :仕様書無しさん:2016/02/19(金) 13:08:28.06 .net
議論でなくて悪口いうだけなら
消えろよ

220 :仕様書無しさん:2016/02/19(金) 13:09:25.58 .net
おっ、>>209か!?

221 :仕様書無しさん:2016/02/19(金) 14:03:00.24 .net
ここはゆとり世代が多いのかな?
モデムやカプラーで通信していた世代なら自然に身に付く内容ばかりだよ
好きでも無いのにコード書かなきゃいけないなんて可哀想に

222 :仕様書無しさん:2016/02/19(金) 14:34:25.02 .net
楽できるとおもって就職したんだろうけど、現実は・・・・

223 :仕様書無しさん:2016/02/19(金) 15:56:29.52 .net
実務の仕事は楽だよ
チームじゃなく単独でやってるから
楽過ぎて副業の方が収入多くなる程

224 :仕様書無しさん:2016/02/19(金) 16:21:20.53 .net
>マネジメントやらストラテジ系の用語も趣味で押さえてるってw

↑スルーされたw
モデムやカプラーで学ぶ情報ストラテジwww

225 :仕様書無しさん:2016/02/19(金) 16:52:47.60 .net
誰かを叩き続けないと生きていけないんだろうか

226 :仕様書無しさん:2016/02/19(金) 17:12:56.76 .net
>>225
それは娯楽がないと生きていけないんだろうかって言ってるのと同じ

227 :仕様書無しさん:2016/02/19(金) 17:22:44.76 .net
どこが同じなのか、俺には理解不能

228 :仕様書無しさん:2016/02/19(金) 17:36:47.15 .net
唯一の娯楽が他人を叩くことなんだよ
察してやれ

229 :仕様書無しさん:2016/02/19(金) 18:11:33.05 .net
>>127
> 「実際にコード書いてみないとわかりません」

普通の人は、
「実際にコード書いてみると、新たな発見がある」
と思っている。

230 :仕様書無しさん:2016/02/19(金) 18:14:15.25 .net
>>229
コード書くまで発見できない無能
研究開発でもしてるんですかあ〜〜〜???

231 :仕様書無しさん:2016/02/19(金) 18:17:54.90 .net
>>230
コード書いてる途中で、ここリファクタリングしようとか思わないのか?

232 :仕様書無しさん:2016/02/19(金) 18:21:54.26 .net
設計書(コード)は頭にある設計を書き出すだけ
全て頭の中で考えていれば、新たな発見などありえない。

233 :仕様書無しさん:2016/02/19(金) 18:22:54.84 .net
そういうこと言ってるから、>>117みたいなマヌケなコード書いても平気なんだよな

234 :仕様書無しさん:2016/02/19(金) 18:27:21.77 .net
>>232
よほど簡単なプログラムしか書いてないんですね。

235 :仕様書無しさん:2016/02/19(金) 18:29:10.19 .net
お前ら頭の中でフローチャートとか書かないのか?
それを紙に書いて、コーダーに渡すだろ。

まさか消しゴムとか使ってないよな?
下書き無しで一発で書くのがプロだ。

236 :仕様書無しさん:2016/02/19(金) 18:31:26.41 .net
学校の演習はやれて当然
先生に肉体労働だって教えてもらわなかった?

237 :仕様書無しさん:2016/02/19(金) 18:33:31.14 .net
>>235
1990年頃の話ですか

238 :仕様書無しさん:2016/02/19(金) 18:36:17.40 .net
>>235
そういうこと言ってるから、>>117みたいなマヌケなコード書いても平気なんだよな

239 :仕様書無しさん:2016/02/19(金) 18:41:42.09 .net
チマチマステップ実行してる奴って、コード書いてみなきゃ判らない!って人なんだろーなって思うよ。

240 :仕様書無しさん:2016/02/19(金) 18:43:40.12 .net
頭の中で書けるレベルの簡単なフローチャートなんぞ
紙に書いても役に立たないだろ

241 :仕様書無しさん:2016/02/19(金) 22:25:15.88 .net
>>232
開発言語はそれ自体が設計ツール
できあがったものは設計書

>>235
フローチャートは書かないな
そんなのすっ飛ばして、書くべきコードが既に見えてる

242 :仕様書無しさん:2016/02/19(金) 22:29:23.39 .net
>>239
無駄な時間をかけてひたすら考えて
一発で動かすことに喜びを感じる変態なのはわかるが

時間をかけずにササッと書いて期待通りに動くか
ステップ実行で変数を確認すりゃ、無駄に考えて
時間を無駄にするストレスもなく、あっと言う間だよな
それでもほとんどが一発で動いちゃうけど

243 :仕様書無しさん:2016/02/19(金) 22:46:50.43 .net
アマグラマで初めて業務ついたらコードが汚すぎて全然追えなかった。
コードがぎっしりで目がしぱしぱです。

244 :仕様書無しさん:2016/02/19(金) 23:40:32.72 .net
>>224
そんなの知らなくてもあれだけ簡単な試験なんだから受かるよ
現にしらんし

245 :仕様書無しさん:2016/02/20(土) 02:14:10.11 .net
綺麗なコードにこだわりがあるようなことをアピールするくせに、変数やメソッドの名前がデタラメな英語の奴いるよなwww

246 :仕様書無しさん:2016/02/20(土) 02:17:06.93 .net
デタラメな英語使っといてなにがリーダブルコードだw

247 :仕様書無しさん:2016/02/20(土) 05:43:08.52 .net
>>244
趣味のレベルで分かる問題「しか出ない」って>>209は言ってるよw
YOUは誰?w

248 :仕様書無しさん:2016/02/20(土) 06:01:40.95 .net
>>245
日本語をローマ字名にしそうなキミよりはマシ
iの一文字でも用途が一発で伝わる変数に長ったらしい名前を付ける奴が一番迷惑

249 :仕様書無しさん:2016/02/20(土) 12:59:03.39 .net
>>226
早く死ね

250 :仕様書無しさん:2016/02/20(土) 13:55:37.11 .net
【主な偽装請負従犯要員SEの作業】
[技術不要の使い捨てスキル]
コマンド
データ > ロジック
簡単ロジック
大量データ
SE適性不要
IT資格不要
大卒資格不要
文科系対象
体育系対象
商業系業種
業務系処理

[業務ソフト作り捨てツール]
ノンプログラミングツール
フレームワーク
COBOL
VB
.net
Java
Web
DB
ERP
SAP

251 :仕様書無しさん:2016/02/20(土) 16:01:46.63 .net
>>149
まず数式とアルゴリズム書けよ
それとテストケース

252 :仕様書無しさん:2016/02/20(土) 17:05:10.16 .net
コーダー静かだな…心を入れ替えて設計書でも書いてんのか?

253 :仕様書無しさん:2016/02/20(土) 17:42:04.12 .net
設計書ってコードのことだよw

254 :仕様書無しさん:2016/02/20(土) 19:04:21.68 .net
「コードは設計書」正にその通りと思うが、それはせいぜい詳細設計書だ
コード以外のドキュメントは書くべきだ

コード自体の説明じゃないぞ、そんなものはコード(=詳細設計書)の中に書いとけ
あくまで何を考えてコードを書いたのか他人にわかるドキュメントな
辻褄合わせの下手くそコードは何を考えて書いたのか、まともな文章にまとめられないことに気づく

255 :仕様書無しさん:2016/02/20(土) 19:41:19.24 .net
書かないとは言ってないんだがね
必要な書類ならいつでも、当然後からでもいくらでも書ける
開発時に必要ないというだけの話

256 :仕様書無しさん:2016/02/20(土) 19:51:33.09 .net
>>255
かわいそうに

257 :仕様書無しさん:2016/02/20(土) 20:45:09.17 .net
開発時にドキュメント書きながらコードをブラッシュアップするのと、
開発後に自分のクソコードに気付いて、不毛なドキュメントでっち上げに四苦八苦するのと、
ドキュメントも書かず自分のクソコードにも気づかずに、他人の恨みを買うのと
どれがいい?

258 :仕様書無しさん:2016/02/20(土) 20:55:26.33 .net
開発時にフローチャートレベルのきっちりとしたドキュメントを書けば
コードもきっちり出来上がる。

259 :仕様書無しさん:2016/02/20(土) 21:08:02.54 .net
フローチャート
1960年代の話?

260 :仕様書無しさん:2016/02/20(土) 21:17:54.01 .net
>>258
できない。
どの言語でどのフレームワークで作るか決めて、その仕様に合わせてから、設計書を書かないと、かけ離れた設計書なる。

261 :仕様書無しさん:2016/02/20(土) 21:56:02.42 .net
>>258
お前はそうしないと、まともなもんが作れないだけの話でさ

262 :仕様書無しさん:2016/02/20(土) 21:57:31.95 .net
>>257
選択肢すくねー、よほど開発技量と設計力が無いんだな

263 :仕様書無しさん:2016/02/20(土) 22:24:08.23 .net
まったくだ。開発技量と設計力があれば
全部フローチャートでかける。

264 :仕様書無しさん:2016/02/20(土) 22:31:14.48 .net
>>263
フローチャートで何が書けるって?

265 :仕様書無しさん:2016/02/20(土) 22:38:34.06 .net
>>264
ちょっと拡張する必要はあるけど、何でも書けるよ

266 :仕様書無しさん:2016/02/20(土) 22:55:57.76 .net
全部フローで書く理由って何?
フローは精々大まかな運用整理位にしか使わないな
その程度ならわざわざドキュメント化するほどでもなく
メモの走り書きで十分

267 :仕様書無しさん:2016/02/20(土) 23:00:04.28 .net
芸術作品とかじゃね?
遠くから見たらモナリザの微笑だけど、近くで見たら無数のフローチャートとか

268 :仕様書無しさん:2016/02/20(土) 23:15:47.22 .net
>>266
フローチャートまで書かないと
俺の設計を全て反映できないから。

269 :仕様書無しさん:2016/02/20(土) 23:17:56.87 .net
>>258は"フローチャートレベルの設計書"と書いているのに、
"フローチャートの設計書"だと思ってる奴の多いことw

フローチャートが万能だとは俺も思わないけどさ

270 :仕様書無しさん:2016/02/20(土) 23:25:23.42 .net
>>269
コードに近いフローを書くならコードでよくね?
ループも条件分岐も視覚的かつ直感的だし
書いたら即座に実行デバッグまでできてしまう便利さ

271 :仕様書無しさん:2016/02/20(土) 23:38:59.58 .net
コードが読めない人のために書くんだろ

272 :仕様書無しさん:2016/02/20(土) 23:49:38.42 .net
コードを読めない人がフローチャート読んで何するの?
読んだところで意味ないよね
今どきはフローチャートなど挿絵替わりにしか使わない

273 :仕様書無しさん:2016/02/20(土) 23:56:32.88 .net
>>271
だったら後から書いてもいいよな

274 :仕様書無しさん:2016/02/21(日) 00:00:31.76 .net
コードが読めなくても
設計に口出ししたい人は山ほどいるんだよ
自分が設計に参加してる気になれるからね

275 :仕様書無しさん:2016/02/21(日) 00:03:02.72 .net
一番いらねえ存在w

276 :仕様書無しさん:2016/02/21(日) 00:07:27.78 .net
重要なところはちゃんと設計して設計書に起こすよ。
お前らに設計書なしで任せるところはどう実装してもらっても構わないクリティカルじゃないところだけ。
それを御大層に「コード=設計書」とか言いながら実装するのは構わないけど、納期は守れよ。

277 :仕様書無しさん:2016/02/21(日) 00:22:58.45 .net
>>270
フローチャートレベルの設計書

フローチャートの設計書
は言葉は似ていても全く違う

そこを分からずに、あーだーこーだ言ってるバカが多すぎる


ちなみに、俺はフローチャートなんてくだらねえ糞だと思ってる
フローチャートなんて書く奴はバカ

278 :仕様書無しさん:2016/02/21(日) 00:39:07.63 .net
フローチャートが要らんのなら、
フローチャートレベルの設計書もフローチャートの設計書も要らんだろ

279 :仕様書無しさん:2016/02/21(日) 00:44:31.31 .net
>>276
重要じゃないところってなんだ? 全部重要だろ
簡単な誰でもできるところは設計書もどきを書いて
お前じゃ手が着けられない部分は丸投げしてるだけじゃん

280 :仕様書無しさん:2016/02/21(日) 00:49:50.27 .net
コードを書くだけの仕事を丸投げだと思ってるってある意味幸せですね

281 :仕様書無しさん:2016/02/21(日) 00:56:40.59 .net
>>276
コード書かずに納期を圧迫するやつが多いんだ。
動くものを作らなければ出来るわけがないのに
いくら頑張っても完璧になることがありえないし、
動くこともない資料作成に無駄な時間を書けたら駄目だ。

282 :仕様書無しさん:2016/02/21(日) 01:13:33.27 .net
>>279
全部重要って、重み付けができない思考停止野郎ですかw

283 :仕様書無しさん:2016/02/21(日) 01:27:34.14 .net
重要だろうとなかろうと
勝手に作っていいと丸投げしてる時点でスキルは信用してるわけだ
じゃなければ何かあったときに設計放棄した奴の全面責任だしな

284 :仕様書無しさん:2016/02/21(日) 01:38:40.07 .net
ソースを読んでもわからない情報はドキュメント化すべき。
フローチャートレベルの設計書は要らない。

285 :仕様書無しさん:2016/02/21(日) 01:51:24.42 .net
>>277
> フローチャートなんて書く奴はバカ

Web系やモバイルアプリ、ゲームなど馬鹿でも作れるソフトを作ってる奴らに

フローチャートは必要ない。

だから書く必要はない。

286 :仕様書無しさん:2016/02/21(日) 02:13:04.42 .net
>>285
つまり、書いている所はどういう所?

287 :仕様書無しさん:2016/02/21(日) 09:39:20.82 .net
使い捨て早死に貧困の助長SEは大迷惑
相場下がって迷惑だから偽装請負の従犯は辞めろ!

・1,000万円/年以下低レベルの会社は辞めろ
・80万円/月以下低レベルの契約は辞めろ
・5,000円/時間以下低レベルの契約は辞めろ
・多重契約は辞めろ
・不利益な現場は辞めろ
・残業見積りは辞めろ
・時間外労働違反は辞めろ
・契約外納期は守るな
・客先指示に従うな
・知的財産を渡するな
・残業しないで学習しろ
・残業しないで副業しろ
・損害は訴えろ

【非婚】SI受注SEは3億円以下の低生涯収入【離婚】
http://hanabi.2ch.net/test/read.cgi/infosys/1451213054/

288 :仕様書無しさん:2016/02/21(日) 10:37:53.28 .net
フローチャート、ほとんどの場合いらないけど、たまに書く場面があるんだよなぁ。
どういう場面か、うまくぼかしていえないけど

289 :仕様書無しさん:2016/02/21(日) 11:02:41.72 .net
>>276
これ

290 :仕様書無しさん:2016/02/21(日) 11:14:34.44 .net
>>288
ぼかさなくていいじゃん。特定されると思ってるなら自意識過剰。

291 :仕様書無しさん:2016/02/21(日) 11:32:07.30 .net
>>290
じゃあ言うけど、名寄せにからんだところだよ。親子関係とか、禁止、削除、子供ののせかえがある奴

292 :仕様書無しさん:2016/02/21(日) 12:18:15.55 .net
>>239
>>チマチマステップ実行してる奴って、コード書いてみなきゃ判らない!って人なんだろーなって思うよ。

こいう人はマイコンに向かない。
マイコン開発はオシロが生命みたいなもんだけど。
一行一行に時間を掛ける

反対にWindowアプリは盛り込んだ機能によってという世界だから
行数がべらぼうになる

293 :仕様書無しさん:2016/02/21(日) 12:55:31.87 .net
つまりマイコンの場合、実行しているときの変数が分からない。
そういう環境でやるわけ
hoge(int a)
{
int A = 3/a;
return A;
}
とやって実際の値ってなんだろうかというのは,
類推なわけだ。
hoge(int a)
{
 int A;
 if( a){
  A = 3/a;
 }

とはやらないな。
0の除算回避というやつ

294 :仕様書無しさん:2016/02/21(日) 13:19:45.54 .net
hogeの仕様書いてください
入力で0を受け付けるのか
受け付ける場合はどう振舞うのか

295 :仕様書無しさん:2016/02/21(日) 13:32:03.56 .net
仕様を設計と勘違いしている人が多い。
データベースに保存する項目とか
ユーザーインターフェースとかは
仕様であって設計じゃない

296 :仕様書無しさん:2016/02/21(日) 13:44:45.15 .net
>>295
その項目を何に使うのかを記したのが仕様書
UIで何をするのかを記したのが仕様書
仕様書は目的を示すもの

データベースに保存するっていうのは方法
UIにテキストボックスを配置するのは方法
設計書は方法を示すもの

297 :仕様書無しさん:2016/02/21(日) 13:49:13.69 .net
>>295
勘違いしてるのはあんたでしょ

298 :仕様書無しさん:2016/02/21(日) 13:50:14.82 .net
仕様を設計するという仕事のアウトプットを仕様と呼ぶ人と設計と呼ぶ人

299 :仕様書無しさん:2016/02/21(日) 14:18:35.91 .net
>>293
よく判んないけど、何でaが0かどうかのチェックしないの?

300 :仕様書無しさん:2016/02/21(日) 14:52:32.56 .net
>>295、.>>296
あなた方が仕様としているものはすべて、その前に他の誰かが設計した内容だ
仕様書と呼ぶか設計書と呼ぶかは立場の違いでしかない

301 :仕様書無しさん:2016/02/21(日) 14:56:13.43 .net
>>300
仕様が書かれているのが仕様書。
設計が書かれているのが設計書。

302 :仕様書無しさん:2016/02/21(日) 14:59:33.94 .net
つまり誰かが設計した仕様が書かれているドキュメントは
仕様書であり、設計書でもあるのだ

303 :仕様書無しさん:2016/02/21(日) 15:25:09.07 .net
ぶっちゃけ
>>293
程度のコードでも設計書いるな。なんだか判んないから。

304 :仕様書無しさん:2016/02/21(日) 15:31:08.96 .net
>>303
コード=設計書なのだから、>>293は設計書を書くのが下手くそだということだ。
別途コード以外の設計書を作らせたとしても、下手くそに役に立つドキュメントは作れないし、
ゴミ設計書がコードと合わせてふたつになるだけ。

305 :仕様書無しさん:2016/02/21(日) 15:31:48.03 .net
>>302
逆に誰も設計してない仕様ってあるの?
実質的に設計してないに等しいだろってのはあると思うが

306 :仕様書無しさん:2016/02/21(日) 15:35:26.73 .net
>>305
だからすべては設計書だと言える
コードも設計書だしER図も設計書だしフローチャートも設計書
バイナリもCPUに解釈してもらうための設計書

307 :仕様書無しさん:2016/02/21(日) 15:36:57.04 .net
つまり設計書⊇仕様書である、と

308 :仕様書無しさん:2016/02/21(日) 15:41:10.22 .net
詳細設計書も、作る側から見ると設計書であり、それを渡されるコーダー側から見ると仕様書である

309 :仕様書無しさん:2016/02/21(日) 15:43:47.18 .net
>>308
なるほど、コーダが「設計書は必要ない」という理由がわかった

310 :仕様書無しさん:2016/02/21(日) 15:46:04.95 .net
>>306-307
概ね同意だが、さすがに文字でかかれてないものは「書」じゃないだろ
データだろ

311 :仕様書無しさん:2016/02/21(日) 16:02:26.85 .net
全部が設計書だとして、だったら、ここにいる作れない人が書いてるらしい「設計書」って
一体どの設計書? 要件定義設計書?

312 :仕様書無しさん:2016/02/21(日) 16:20:46.31 .net
>>311
まず「ここにいる作れない人」が誰かわからんし、
「書いてるらしい」って、書いてるかどうかもわからんものをどの設計書かまでわかるわけがない

313 :仕様書無しさん:2016/02/21(日) 16:40:43.48 .net
>>312
なんでわからんの?理解力足りなくない?

314 :仕様書無しさん:2016/02/21(日) 16:53:43.60 .net
これでわかると思ってるなら致命的だね

315 :仕様書無しさん:2016/02/21(日) 16:54:54.03 .net
わからないことを偉そうに言うな

316 :仕様書無しさん:2016/02/21(日) 16:55:47.82 .net
ワンパラ読めば余裕でわかる内容だ

317 :仕様書無しさん:2016/02/21(日) 16:56:26.70 .net
ワンパラっつーのはワン・パラグラフの略ね

318 :仕様書無しさん:2016/02/21(日) 17:21:22.10 .net
>>299
>よく判んないけど、何でaが0かどうかのチェックしないの?

マイコンの場合
0の除算がありましたとダイアログが出ない。

Windowsの場合はダイアログが出るから気付くわけ

そんなもんだよ。
そこまで作り手は神経を注がない

319 :仕様書無しさん:2016/02/21(日) 17:31:20.32 .net
>>318
底辺らしい回答

320 :仕様書無しさん:2016/02/21(日) 17:56:58.91 .net
的確すぎる一言に感心したw

321 :仕様書無しさん:2016/02/21(日) 18:16:57.92 .net
>>318
おばかwww

322 :仕様書無しさん:2016/02/21(日) 18:47:11.79 .net
>>312
設計書を書けと言っている作れない人

323 :仕様書無しさん:2016/02/21(日) 19:01:34.05 .net
コード書けるし、わかりやすい設計書も書けますって人が一番だよね

324 :仕様書無しさん:2016/02/21(日) 19:06:27.76 .net
まぁ、設計書っていうのはコードもしくはコードを書くための資料だからね。
何が必要で何が必要ないかは、コード書く人でないとわからない。

325 :仕様書無しさん:2016/02/21(日) 19:08:41.79 .net
>>318
お前アホだろ

326 :仕様書無しさん:2016/02/21(日) 19:36:14.81 .net
>>324
設計書は運用時にも参照するからなあ。
あれどうなってるんだっけと聞かれたときにすぐに答えられるように
大雑把でいいから概要をまとめておくと便利。

327 :仕様書無しさん:2016/02/21(日) 19:44:23.44 .net
>>324
そうだね、そうなると存在意義がわからないのは
詳細設計書を元にコードだけ書く人(コーダー)と
コードを書かず詳細設計書だけ書く人(なんちゃって設計者)

なぜわざわざ2人で別々に、同じような成果物を2つ生み出す体制にしているのか

328 :仕様書無しさん:2016/02/21(日) 19:50:35.50 .net
>>326
確信もなく大ざっぱな情報だけで客に即答するの?

329 :仕様書無しさん:2016/02/21(日) 19:58:40.34 .net
>>318
他のマイコン屋を巻き添えにするな
馬鹿はおまえ一人で十分だ

330 :仕様書無しさん:2016/02/21(日) 19:59:28.28 .net
>>328
どこにも即答って書いてないよ?
確信持って、答えればいいよね?

焦点は、コードの一行一行の情報を伝えるかどうかですか?
こんなの大雑把でいいんですよw

331 :仕様書無しさん:2016/02/21(日) 22:03:14.55 .net
お?コード=設計書って言い張るのはもう諦めたのか?

332 :仕様書無しさん:2016/02/21(日) 22:11:25.95 .net
コードは設計書だよw

333 :仕様書無しさん:2016/02/21(日) 22:24:30.22 .net
コードも設計書
コード以外の設計書も必要

334 :仕様書無しさん:2016/02/21(日) 22:25:42.53 .net
コードは必須の設計書。
それ以外はコードを理解しやすくるための補助的な資料。
とみなすのが一番正確

335 :仕様書無しさん:2016/02/21(日) 22:43:05.54 .net
コードは必須の設計書
それ以外はコードに乗らない情報をまとめた資料で、プロならこちらも必須

コードから見えるのはそのソフトの動作だけ
バグなのかアホなのかそれとも何か事情があるのかわからないから保守のしようがない
コードだけならポリシーがむちゃくちゃでも動くように書けてしまう

336 :仕様書無しさん:2016/02/21(日) 23:09:03.22 .net
必須じゃないよw

> バグなのかアホなのかそれとも何か事情があるのかわからないから保守のしようがない
それは仕様書とテストで担保するべきこと。
テストの自動化(それもまたコード)があれば保守は簡単になる。


> コードだけならポリシーがむちゃくちゃでも動くように書けてしまう
お前はコードではない設計書をがあればむちゃくちゃにならないと
いいたいんだろうが、そんなことはない。

なぜならコードじゃない設計書がむちゃくちゃでも動くから。
間違っていても足りないことがあっても、コードさえあれば動く。


コードがむちゃくちゃにならないようにするには、コードそのものをレビューするしかない。
いくらコードじゃない部分に力を入れても、コード(設計書)の品質は上がらない。

337 :仕様書無しさん:2016/02/21(日) 23:22:29.94 .net
コーダーがくるぞ…

338 :仕様書無しさん:2016/02/21(日) 23:23:01.34 .net
もうきてたwww

339 :仕様書無しさん:2016/02/21(日) 23:47:46.16 .net
>>336
> それは仕様書とテストで担保するべきこと。

コーダーにとっては仕様書かもしれんが、それはプログラマが書いた設計書だ(>>308参照)
そういう意味でコーダーなら「設計書は必要ない」というのは致し方ない(>>309参照)

> なぜならコードじゃない設計書がむちゃくちゃでも動くから。
> 間違っていても足りないことがあっても、コードさえあれば動く。

もちろんコードは動くが、逆にそんなコードでは設計書が書けないはず。
コード書いて動かして丸投げじゃなく、プロなら責任もって筋の通る設計書を書けということだ。

> コードがむちゃくちゃにならないようにするには、コードそのものをレビューするしかない。

そのときに見るのは詳細ロジックではないぞ。
レビュー時にソフトウェア構成をホワイトボードで説明してくれてもいいが、
書きあがるの待ってられんから、レビュー前に設計書に書いとけ。

340 :仕様書無しさん:2016/02/21(日) 23:50:52.43 .net
>>339

>>308参照ってなんだよw
どっかの偉い人ならまだしも、無名の誰かが
言ったことが何の参考になるのか。

仕様書と設計書は別。
仕様書は客のためのものであり、
設計書は開発者のためのもの。

341 :仕様書無しさん:2016/02/22(月) 00:03:21.44 .net
>>340
会社の打ち合わせでも無名の担当者どうしだが、なんのために議事録をとると思う?
議論の流れを参照しろということだ

> 仕様書は客のためのものであり、
> 設計書は開発者のためのもの。

アホだろ
おまえに渡された仕様書は、客のためのものですか?
客がそのレベルの仕様書を見ますか?

342 :仕様書無しさん:2016/02/22(月) 00:06:21.88 .net
>>339
> コード書いて動かして丸投げじゃなく、プロなら責任もって筋の通る設計書を書けということだ。

コード=設計書なら、当然のことだろ。
バグがない設計書を作るのは当たり前のことだ。

問題はコードではない設計書しか書かないやつ。
動くコードっていうのは検証が出来る状態でもある。
正しく設計できたという検証だ。その検証をやらないうちは
その設計が正しいと言ってはいけない。

> 書きあがるの待ってられんから、レビュー前に設計書に書いとけ。
まさか書き上がるまでレビューしないのか?

1日2日で終わる程度ならそれでもいいが、
1週間とかなったら、レビューで問題があったらまるまる1週間無駄になるだろ。
開発を1日程度で終わるような小さな単位に分けて、その単位でレビューしろよ。

お前のその言い方から、コードではない設計書よりも、コードのほうが時間が時間がかかる
と言っているように思えるが(俺は反対だと思ってる。だからコードではない設計書を減らせと言ってる)
時間がかかるならばなおのこと早期にレビューしないといけない。

皮肉だよな。 お前はコードを書き上がるのを待ってるんだろ?
俺は待ってないんだよw

343 :仕様書無しさん:2016/02/22(月) 00:07:37.64 .net
>>341
お前、客に見せないで仕様決めてんの?

344 :仕様書無しさん:2016/02/22(月) 00:09:39.89 .net
>>341
> 議論の流れを参照しろということだ

だから、今もその議論の流れを続けてるんだが?
>>308>>309は結論じゃない。一人の間違った意見でしかない。

345 :仕様書無しさん:2016/02/22(月) 00:11:38.10 .net
果たしてコードを書く人に設計書ではなく仕様書を渡されることがあるのだろうか?

それはまるで、コードを書く人が設計をしているように思える。

346 :仕様書無しさん:2016/02/22(月) 00:27:13.88 .net
>>342
> コード=設計書なら、当然のことだろ。

コードは設計書に含まれるが、コード=設計書ではない。

> 問題はコードではない設計書しか書かないやつ。

設計書のレベルによる。
詳細設計書しかかかないやつは確かに意味ないが、
システム設計書を書く人がコードまで書く必要はない。

> 開発を1日程度で終わるような小さな単位に分けて、その単位でレビューしろよ。

誰がシステムをその単位に分割してると思ってる?
プログラマが機能を合理的に分割し、それを設計書に残してるんだ。

> 皮肉だよな。 お前はコードを書き上がるのを待ってるんだろ?
> 俺は待ってないんだよw

俺も待ってない。コードと設計書は並行して書く。

347 :仕様書無しさん:2016/02/22(月) 00:28:28.19 .net
>>343
客に見せるのは、機能仕様とシステム設計、せいぜいソフトウェア設計までだ
おまえに渡されるレベルのは見せてないと思うぞ

>>344
結論を参照しろじゃなくて、議論の流れを参照しろ
参照ぐらいでめんどくさがってぐだぐだ言わないように

348 :仕様書無しさん:2016/02/22(月) 00:39:50.78 .net
コーダーが発狂し始めたと聞いて

349 :仕様書無しさん:2016/02/22(月) 00:50:32.42 .net
いや、これはむしろコーダーの通常状態といっていい

350 :仕様書無しさん:2016/02/22(月) 00:51:03.08 .net
>>349
ごめん俺が間違ってたわ

351 :仕様書無しさん:2016/02/22(月) 00:53:14.69 .net
みごとな自作自演w

352 :仕様書無しさん:2016/02/22(月) 00:56:09.05 .net
>>351
照れるから褒めるなよ

353 :仕様書無しさん:2016/02/22(月) 00:56:46.97 .net
皮肉もわからないんだなw

354 :仕様書無しさん:2016/02/22(月) 00:58:46.51 .net
>>353
プログラマー様にはわからないらしい。おれ?コーダーだけど何か?

355 :仕様書無しさん:2016/02/22(月) 01:01:18.27 .net
開き直られるとスッキリ

356 :仕様書無しさん:2016/02/22(月) 01:11:41.64 .net
>>347
> 客に見せるのは、機能仕様とシステム設計、せいぜいソフトウェア設計までだ
> おまえに渡されるレベルのは見せてないと思うぞ

だからお前はいつもトラブってるんだよw

357 :仕様書無しさん:2016/02/22(月) 01:12:28.94 .net
>>356
だってぼくコーダーだし

358 :仕様書無しさん:2016/02/22(月) 01:17:51.65 .net
>>357
そういうのいいから

359 :仕様書無しさん:2016/02/22(月) 01:26:21.88 .net
ソフトウェア設計とは何か?
http://knagano.tumblr.com/post/11941519742/
http://web.archive.org/web/20080803072849/www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html


ソースコードがソフトウェア設計であると考えることによって重大な帰結が導き出されます。
この帰結はあまりにも重要かつ自明であるものの,ほとんどのソフトウェア組織において盲点となっているものです。
それは,ソフトウェアの製造(ビルド)が安価なものであるという事実です。
あまりにも安いため安価なものとして見なす必要すらなく,ほとんど無料といっても良いくらいなのです。

360 :仕様書無しさん:2016/02/22(月) 02:26:44.64 .net
>>358
ごめんね

361 :仕様書無しさん:2016/02/22(月) 06:55:06.11 .net
>>330
・コードをまるで見ずに書類の情報だけで回答する
・1行1行説明する
君の中では、このとてつもなく両極端な選択肢しかないの?
コードを読んで、該当個所の流れを簡潔に言葉で説明する
これが最良なんだけど

>>326の「すぐ」って、上の「コードをまるで見ずに〜」という意味だよね
つまり書類確認だけで即答

設計できない奴と話してると、曖昧な発言が多くて疲れるわ
プログラミングに曖昧は御法度なんだから発言は明確にしてほしいね

362 :仕様書無しさん:2016/02/22(月) 06:57:00.67 .net
>>335
それを定めるのは仕様書

開発できない(=設計できない)人は
仕様書も設計書扱いにしてほしいみたいだけど

363 :仕様書無しさん:2016/02/22(月) 07:18:08.24 .net
> >>326の「すぐ」って、上の「コードをまるで見ずに〜」という意味だよね
> つまり書類確認だけで即答

どこにもそんなことは書いていません
思い込みで決めつける。

もしかしてコードを読むのに時間がかかる人なのか?

364 :仕様書無しさん:2016/02/22(月) 07:25:54.52 .net
>>363
否定するだけじゃなくてさ、ちゃんと他の捉え方を書こうよ
まあ、そんなものないから否定だけなんだろうけど

365 :仕様書無しさん:2016/02/22(月) 08:17:31.32 .net
また、文字でやりとりしていない事を
勝手に創りだすキチガイが湧いてる・・・

366 :仕様書無しさん:2016/02/22(月) 11:17:15.50 .net
>>365
自分の意図を、あますところなく明確に書けるようになってから文句言え。

367 :仕様書無しさん:2016/02/22(月) 11:29:08.80 .net
>>366
明確になってないからって**勝手に**補完するのはよくないですよw

368 :仕様書無しさん:2016/02/22(月) 11:57:41.34 .net
補完なしには成り立たないレベルのコメントしか書けてないということに気づいていない

369 :仕様書無しさん:2016/02/22(月) 12:00:37.67 .net
> 設計書は運用時にも参照するからなあ。
> あれどうなってるんだっけと聞かれたときにすぐに答えられるように
> 大雑把でいいから概要をまとめておくと便利。

普通に(補完して)読めば、

あれどうなってるんだっけと(顧客から)聞かれたときにすぐに答えられるように
(設計書は)大雑把でいいから概要をまとめておくと便利。
(そうすれば、その設計書を見ればすぐに答えられる)

370 :仕様書無しさん:2016/02/22(月) 12:03:45.28 .net
コードを読むのに時間がかからないんだったら、最初からコード読んで回答すれば

371 :仕様書無しさん:2016/02/22(月) 12:06:55.05 .net
臨機応変ってのが出来ないなら、会社なり客が決めたくだらないフォーマットの仕様書をダラダラ書けば良いじゃん
時間や規模やメンバーや将来性や色々判断して動けないなら決められた枠を疑わずに動けよ

372 :仕様書無しさん:2016/02/22(月) 12:13:09.32 .net
社内フォーマットがくだらないという前提w

373 :仕様書無しさん:2016/02/22(月) 13:10:52.73 .net
きゃくきゃく言ってるが、二次請け以下の奴が言う「客」と、ダイレクトに顧客にソフトウェアを
提供するところでは文脈が変わってくるな

374 :仕様書無しさん:2016/02/22(月) 13:20:24.26 .net
エンドユーザーの意識次第だがな。

375 :仕様書無しさん:2016/02/22(月) 13:24:02.23 .net
>>372
社内規定のフォーマットが適してるならここでキャンキャン騒がないだろう

376 :仕様書無しさん:2016/02/22(月) 13:26:27.11 .net
>>373
客が決めたって言ってんだから客とのパワーバランスは想像つくだろう

377 :仕様書無しさん:2016/02/22(月) 14:08:07.39 .net
>>376
パワーバランスなんか問題にしてませんが

378 :仕様書無しさん:2016/02/22(月) 16:30:16.27 .net
>>376
なんで客が決定することとパワーバランスが関係あるんだよw
あんたの所は「お客様は神様です。」なのか?

379 :仕様書無しさん:2016/02/22(月) 17:51:40.00 .net
設計書、設計書騒いでる奴の文章力がなさ過ぎて草
この分だと、まともな設計書なんか書けないだろうな

380 :仕様書無しさん:2016/02/22(月) 20:56:01.09 .net
つべこべ言ってねーでまずは設計書書けよ
レビューでダメ出し喰らうのが怖いんか?

381 :仕様書無しさん:2016/02/22(月) 21:04:50.20 .net
そんなに欲しかったら後から書いてやるよ

382 :仕様書無しさん:2016/02/22(月) 22:47:57.12 .net
後でも先でもいいからソフトウェアのリリース日までに
レビュー込みで終わるように書け

383 :仕様書無しさん:2016/02/22(月) 23:35:06.41 .net
コーダー君のいう客って、派遣先の開発会社の社員のことなの?

そう思って読んだら、話が凄くすんなり入ってくるんだが

384 :仕様書無しさん:2016/02/22(月) 23:38:51.17 .net
>>380のダメ出し=>>172

385 :仕様書無しさん:2016/02/22(月) 23:56:50.24 .net
>>382
書くのお前だろ、半端な仕事すんじゃねえぞ

386 :仕様書無しさん:2016/02/23(火) 00:01:24.92 .net
>>383
派遣先の人間を客と思ってるのはお前くらいだろ

387 :仕様書無しさん:2016/02/23(火) 00:08:30.52 .net
図星らしい反応

388 :仕様書無しさん:2016/02/23(火) 01:28:12.40 .net
派遣先

389 :仕様書無しさん:2016/02/23(火) 07:28:51.97 .net
修正時は仕様書はあるといいけど設計書はいらんな
新規開発時はあってもなくてもいいから、なくていい

390 :仕様書無しさん:2016/02/23(火) 10:28:01.81 .net
>>386
派遣会社にとって、派遣先の人間が客じゃなけりゃ、誰が客なんだよ?

391 :仕様書無しさん:2016/02/23(火) 11:44:46.72 .net
客って言葉だけでトンチンカンな事言う輩がいるんだから、用語の定義からしてあげないといけないのが現実
結局認識が違いました、聞いてませんでした、合意済みだと思いますとか責任逃れするのが多いから、ドキュメント書かないといけないのが現状
責任逃れが先行するからプロダクトが二の次になるし、単価も上がるし、雇い主、請け負いの関係がより強調される
プロダクトを主眼としたエンジニアは自由とお金と責任を手に入れる
2パターンのエンジニアがそれぞれの価値観で話してるから分かり合えないんだろうな

392 :仕様書無しさん:2016/02/23(火) 12:28:09.68 .net
二人のエンジニアとコーダー一匹
だろ

393 :仕様書無しさん:2016/02/23(火) 12:47:35.57 .net
>>392
せめて人間扱いはしてください…

394 :仕様書無しさん:2016/02/23(火) 12:54:40.48 .net
>>391
> ドキュメント書かないといけないのが現状

要件定義書が必要だと言うことと、このスレで話題の(詳細)設計書は別の話なのに、
ごっちゃにするようなお前がいるから荒れるんだよ

395 :仕様書無しさん:2016/02/23(火) 13:28:40.04 .net
エンジニアって2パターンしか存在しなかったのか

396 :仕様書無しさん:2016/02/23(火) 13:47:57.81 .net
>>391
> 2パターンのエンジニアがそれぞれの価値観で話してるから分かり合えないんだろうな
違うよ
原因は>>368

397 :仕様書無しさん:2016/02/23(火) 17:39:12.83 .net
>>391
どんなにドキュメント書いても打ち合わせしても、認識が違う事なんてざらなんだけどね。
http://nyumon-info.com/column/bl01.html

398 :仕様書無しさん:2016/02/23(火) 17:45:14.32 .net
>>394
最後まで読もうね

399 :仕様書無しさん:2016/02/23(火) 18:02:34.69 .net
>>398
お前こそこのスレ読んで、ドキュメントというのが(詳細)設計書だということに気付

400 :仕様書無しさん:2016/02/23(火) 18:08:11.56 .net
>>398
最後まで読むと何がわかるのかしらんが、最後は間違っている
原因は>>368

401 :仕様書無しさん:2016/02/23(火) 18:08:33.04 .net
客は現在の仕事をよく知っているかもしれないが、
将来どうすればいいかを知っているわけじゃない。

客は自分の担当のことはよく知っているが、
担当外のことをよく知っているわけじゃない。

客は実はシステム開発担当者であって、システムを実際に使う人ではない。
何が必要かを完全に把握しているわけじゃない。

402 :仕様書無しさん:2016/02/23(火) 18:10:27.95 .net
まぎらわしいから、「エンドユーザ」「元請け」という単語使え

403 :仕様書無しさん:2016/02/23(火) 18:47:34.22 .net
コミュ障でプログラムもろくに書けません。
どうしたらいいですか?

404 :仕様書無しさん:2016/02/23(火) 19:39:55.86 .net
>>403
コミュとプログラムは関係ない
勉強せよ

405 :仕様書無しさん:2016/02/23(火) 19:44:23.16 .net
コミュ障は知らんがアスペが作るプログラムはUIにアスペらしさが出るぞ
お前らも気をつけろよ

406 :仕様書無しさん:2016/02/23(火) 20:13:18.26 .net
時給換算5,000円以下のSEの皆様へ

相場下がって迷惑ですので、SE辞めてもらえませんか?
主婦SE以下の時間報酬レベルですよ。
こちらこそ優秀なSEの離職で大損害なんですから。

発注者より

407 :仕様書無しさん:2016/02/23(火) 20:55:20.95 .net
>>405
アスペらしいってどんな感じのプログラム?

408 :仕様書無しさん:2016/02/23(火) 21:30:54.30 .net
謎のパラメータを山のように指定させ、ひたすら複雑なアウトプットを行うが、
何の機能かまったくわからんUIとか

409 :仕様書無しさん:2016/02/23(火) 21:32:34.03 .net
>>407
ユーザーに対して常に正確で完全な入力を要求する頑固で融通がきかないUIだな
ほとんど使わないパラメーターが必須入力だったり
誤った入力に対しては断固として実行を拒否したり
ありがちだろ?
適当に空気を読んで動いてくれればいいんだよ、ユーザーを疲れさすな。

410 :仕様書無しさん:2016/02/23(火) 21:48:03.86 .net
アスペルガー症候群ってどんなものか知らなかったが
客観的思考ができず、何かに強い拘りがあるって
ここにいる設計書を書けとしつこく言ってる連中がまさにそれじゃん

プログラムだと、組み込み業界の人間が作ったソフトがほぼほぼ
>>409みたいな感じだ、無機質というか、人間味がないというか
業務系とかそっちの人間は人が使う前提で考え作るけど

411 :仕様書無しさん:2016/02/23(火) 22:10:17.85 .net
で、決まったデータしか来ない前提で作られてて
異常データを判定してもいないので、よく落ちる

412 :仕様書無しさん:2016/02/23(火) 22:26:45.90 .net
>>410
> アスペルガー症候群ってどんなものか知らなかったが

いや、きみのことだよ
行間が読むことが苦手で、どんな話題のときでも自分の関心事や拘りを話す

413 :仕様書無しさん:2016/02/23(火) 22:29:04.39 .net
・ドキュメントとして、仕様書はいるけど、設計書はいらない。
・設計書はソースコードを指す
でよくないか。
それなら双方納得じゃね。

俺は面倒だから、上記の仕様書を、設計書って呼ぶけど。

414 :仕様書無しさん:2016/02/23(火) 22:36:36.68 .net
>>412
どんな時でも話題をぶり撒けるなんて、すげえコミュ力だな俺

少ない情報で他人を勝手にカテゴライズし思い込むタイプの君は
統合失調症、略して統失かな?
アスペと統失のダブルコンボは治すのも骨が折れるだろうね

415 :仕様書無しさん:2016/02/23(火) 22:37:37.50 .net
>>413
仕様書を設計書と呼ぶ方がなにかと面倒だろ

416 :仕様書無しさん:2016/02/23(火) 22:49:31.44 .net
>>415
じゃお前はさ、設計書書けって言われたら、「ソースコードが唯一の設計書で〜」っていい始めんの?めんどくさくね?
仕様書は書くんだから、これが仕様書って言えばいいじゃん。

417 :仕様書無しさん:2016/02/23(火) 22:58:40.43 .net
>>416
後からで良けりゃ書くよ、ソースから
事前に書けってんなら断る
最後の行は何を言ってるんだ? 設計書と呼びたいんじゃなかったの?

418 :仕様書無しさん:2016/02/23(火) 23:02:23.73 .net
設計ってのは仕様を踏まえたうえで行う作業で
仕様書と設計書は似ても似つかない別物

仕様は目標を決めること
設計は目標を実現するための手段や手順を決めること

仕様:
全国の子供達が官製はがきに書いてテレ朝に送ってくる
ドラえもんの秘密道具
(お子様でもできる)

設計:
その送られてきた秘密道具の実現・具現化に向けて
持てる技術と経験と知識で頭をフルに使い考えること
(最低限、実現するだけの技術的スキルは必須)

419 :仕様書無しさん:2016/02/23(火) 23:08:23.59 .net
アスペのコーダー君に理解できるように解説しよう

彼(>>416)は、キミがめんどくさそうなので大岡裁きでお開きにしたいのだ

420 :仕様書無しさん:2016/02/23(火) 23:08:24.71 .net
>>409
うーん

よくわからん

421 :仕様書無しさん:2016/02/23(火) 23:09:50.45 .net
急に笑いとりにきたこいつは何者ww
(お子様でもできる)

422 :仕様書無しさん:2016/02/23(火) 23:10:57.25 .net
もちろん、中には高度な技術力を持った人間の判断が必要な仕様もある
技術的にどうにもならない人間には到底無理だけど

実現性すら自分ではわかってないのに「こういうの作れ」が子供達のレベルの仕事

423 :仕様書無しさん:2016/02/23(火) 23:17:19.53 .net
>>419
アスペで統失のキミは、少しは頭を整理してから書こうね
整理してもダメなのかもしれないけど

424 :仕様書無しさん:2016/02/23(火) 23:32:37.44 .net
やっぱり頭ん中整理する意味でも設計は先にやるべきだな。

425 :仕様書無しさん:2016/02/23(火) 23:38:29.01 .net
結局、開発できない人間がIT業界にいたところで
やれることなんて精々子供と同じレベルの内容

オママゴトで遊んでる役に立たない高すぎるコスト

426 :仕様書無しさん:2016/02/23(火) 23:49:45.49 .net
>>413
普段、設計書という名目のただの仕様書を書いて
それをプログラマに投げてデカイツラをしてる子供が

自分の書いてるものがただの仕様書だと知って
仕様書を設計書と呼ばせたくて必死になってるママゴト君だったのね

427 :仕様書無しさん:2016/02/23(火) 23:50:35.16 .net
ここレベルの低い奴しかいないね
自分じゃないと思ってるそこのお前、お前のことだよw

428 :仕様書無しさん:2016/02/23(火) 23:58:53.08 .net
>>412
行間を読むには伏線が必要だけど、全くないよな
後から出ると後出しじゃんけんと言えるくらいに
読めるとしたら超能力者くらいだろう

拘りは人間ならあって当然だけど
それを他人に強要したらアスペだな
俺ら強要はしないし

429 :仕様書無しさん:2016/02/24(水) 00:24:03.70 .net
言語によっても設計の意図を表しやすい/難いってのもあるしね
例えば名前空間や細かなアクセス制限が出来るとかは、呼び出せるAPIを制御出来るから構造的に説得力がある
C言語はヘッダに書いたら誰でも呼び出し出来てしまうけど、下位層(例えばミドルウェア層)から上位層(例えばアプリケーション層)のヘッダは常識的に行わない
でもこれは決まりごとベースの制約なので、説得力って意味に関してはJavaでカプセル化による呼び出し制約に軍配が上がるし

※もちろんヘッダの話は常識的な事だから、これ位最低限分かるエンジニアと仕事がしたいのは当たり前だけど、、、やらかす奴って居るからね

430 :仕様書無しさん:2016/02/24(水) 00:26:52.64 .net
>上位層(例えばアプリケーション層)のヘッダは常識的に行わない
上位層のヘッダのincludeは常識的に行わない
ミスった

431 :仕様書無しさん:2016/02/24(水) 00:53:28.60 .net
>>429
javaで、上から呼び出せるけど、下からは呼ばせないなんて制御できないよね

432 :仕様書無しさん:2016/02/24(水) 06:41:26.37 .net
>>431
>>429はそれ位もわかってないコーダーだから仕方ない

433 :仕様書無しさん:2016/02/24(水) 07:10:51.14 .net
無秩序に叩くだけの猿カンベン

434 :仕様書無しさん:2016/02/24(水) 07:17:57.29 .net
厚切りジェイソン、NHKでプログラミング番組 Why!?プログラミング
http://www.oricon.co.jp/news/2067309/full/
http://contents.oricon.co.jp/upimg/news/20160223/2067309_201602230638350001456205037c.jpg
「ほとんどなんでもできちゃう」「可能性は無限大」

厚切りジェイソンと2対のパペットが絡んで展開していく同番組は、
マサチューセッツ工科大学のメディアラボが開発した教育用言語「スクラッチ」を
使って、プログラミングの面白さや本質を伝えていく番組。

435 :仕様書無しさん:2016/02/24(水) 07:22:05.14 .net
13日の金曜日

436 :仕様書無しさん:2016/02/24(水) 11:25:02.37 .net
肉体労働から抜け出せない人たちのスクツ?ここ

437 :仕様書無しさん:2016/02/25(木) 07:54:15.98 .net
「データはロジック設計より先」
だと思うんすよ
SQLでテーブルとかストアド定義してサンプルのデータ入れて
仕様書はそれ使って説明するもの

438 :仕様書無しさん:2016/02/25(木) 08:40:09.82 .net
ストアドはデータではなくロジックです。

439 :仕様書無しさん:2016/02/25(木) 08:41:02.88 .net
あとテーブル定義はコードです。

440 :仕様書無しさん:2016/02/25(木) 09:56:59.70 .net
ER図もコードです
概念を符号化したものがコードなんだから

441 :仕様書無しさん:2016/02/25(木) 11:06:37.78 .net
テーブルはORマッパーが生成するものだから、プログラマが関与する必要はない。
プログラムから見て、DBはブラックボックスです。リポジトリとして抽象化されているので、実際にデータが格納されるのが
RDBだとか、SQL投げてデータ取得してるとか、そんな詳細は気にしなくていい。
要するに、リポジトリに永続化されるデータとはオブジェクトのことで、オブジェクトの仕様はコードにすべて書いてあるのだから、
テーブル定義書なんてものは必要ない。そもそもテーブルの定義自体しないのだから。

# チューニングのためにORマッパーが吐き出すクエリを精査することもあるが、それはまた別の話。

442 :仕様書無しさん:2016/02/25(木) 11:20:01.46 .net
職場のExcel君がフローチャート作り始めた

443 :仕様書無しさん:2016/02/25(木) 14:11:43.41 .net
>>441
> テーブルはORマッパーが生成するものだから、プログラマが関与する必要はない。
何を言ってるんだ?

O/Rマッパーを使う場合は、オブジェクト指向としてクラス定義をプログラマが行って
そのクラス定義からテーブルが作られるんだから、完全にプログラマの仕事だろ。

444 :仕様書無しさん:2016/02/25(木) 15:12:25.90 .net
>>441
> RDBだとか、SQL投げてデータ取得してるとか、そんな詳細は気にしなくていい。
こうして、joinも知らないプログラマーができあがる

445 :仕様書無しさん:2016/02/25(木) 17:05:23.27 .net
>>444
joinを知ってるかどうかは優れたプログラマの要件ではない。
RDBに関わりのないドメインなんていくらでもあります。

446 :仕様書無しさん:2016/02/25(木) 17:11:39.60 .net
また論理的思考の出来ない奴が荒らしに来た

447 :仕様書無しさん:2016/02/25(木) 17:41:42.60 .net
O/Rマッパーって、君らが使ってる一つのものが、世界で唯一のO/Rマッパーじゃないんやで

448 :仕様書無しさん:2016/02/25(木) 18:23:13.59 .net
>>445
DB使っててjoinを知らなけりゃ優れたプログラマなんかじゃないよ

449 :仕様書無しさん:2016/02/25(木) 18:24:40.87 .net
テーブルを自動でつくるやつって、使った事ないけど、インデックスってどうなるんだ?
あと、表領域を分けたい場合は?
運用のためのビューはどうすんの

450 :仕様書無しさん:2016/02/25(木) 18:26:31.24 .net
>>445
rdbに関係ないドメインなら、O/Rマッパーいらないだろ

451 :仕様書無しさん:2016/02/25(木) 20:31:50.62 .net
時給換算5,000円以下のSEの皆様へ

相場が下がって迷惑ですので、SE辞めてもらえませんか?
主婦SE以下の時給換算レベルですよ。
学習期間や契約終了の不利益リスクにどう対処するおつもりですか?
こちらこそ優秀なSEの離職で大損害なんですから。

発注者より

452 :仕様書無しさん:2016/02/25(木) 20:33:41.61 .net
結局みんなDBアクセス周りはどう設計してるの?
まさかいまだにDAOとか言ってる人はいないよね?

453 :仕様書無しさん:2016/02/25(木) 20:43:03.85 .net
>>452
俺はこれを支持する。

ORMがアンチパターンである11の理由
http://tech.a-listers.jp/2011/06/16/orm_is_an_antipattern/

454 :仕様書無しさん:2016/02/25(木) 20:43:53.39 .net
MicrosoftのDAOとはまた古風な響きですね

455 :仕様書無しさん:2016/02/25(木) 20:44:20.11 .net
お前らプログラマを自称してるけど、難しいところは全部ライブラリ任せなんだよな。
冷凍食品をチンして盛り付けるだけで料理人名乗ってるみたいなもんだよね。
お前らの言う設計も、どう盛り付けるかみたいな話でしょ?

456 :仕様書無しさん:2016/02/25(木) 20:49:19.93 .net
俺なりの感覚(他の人は当然違う)

バッチじゃないDBシステムだと、
6割 => SQLってORMで事足りるシンプルSQL
3割 => ORMの機能をふんだんに使った"濃厚な"SQL
1割 => ORMでどう実装すんのよ・・・これ

バッチ系だと
1割
3割
6割

457 :仕様書無しさん:2016/02/25(木) 21:10:49.22 .net
DDDやらない人は普通にSQL書いて結果をDTOに詰め替えてればいいよw
どうせトランザクションスクリプトでしょ君たち。

458 :仕様書無しさん:2016/02/25(木) 21:40:28.35 .net
EntityFrameworkにハマってしまった

459 :仕様書無しさん:2016/02/25(木) 21:40:52.25 .net
O/RマッパーってSQLを自動的に作るものって
考えてる人がいるけど、そういう考えで使うものは
SQLビルダであってO/Rマッパーではない。

O/Rマッパーはデータベース全体のデータを
オブジェクト指向用語でいうオブジェクトの集まりで表現するもの

データを表現したものであって、SQL(処理)を表現したものじゃない。
テーブルのデータはもとよりテーブル同士の関連をオブジェクトで表現するものなので、
つまりリレーションがなければO/Rマッパーで扱うことは出来ない。

だから
> 3割 => ORMの機能をふんだんに使った"濃厚な"SQL
これこそがO/Rマッパーの正しい使い方

> 1割 => ORMでどう実装すんのよ・・・これ
これはデータを表現するのではなく、処理を書こうとしているからそうなる。
データとして表現するのは難しくはない。ただパフォーマンスがでるかどうかは別問題。

460 :仕様書無しさん:2016/02/25(木) 21:48:45.85 .net
>>459
君の言葉を借りると、SQLはデータを表現したもので、処理を表現したものではないのだが。

461 :仕様書無しさん:2016/02/25(木) 21:50:56.05 .net
SQL・・・Structured Query Language
構造化 問合せ 言語

問合せ というのは 処理だ

462 :仕様書無しさん:2016/02/25(木) 21:52:04.00 .net
O/R(elation) マッパーであって
O/SQL マッパーではないのだよ。

463 :仕様書無しさん:2016/02/25(木) 22:02:14.22 .net
どえらい珍論を撒き散らしたいようだな。
ちなみにリレーションてテーブルの事なのだが
君は何か勘違いしてるだろ。

464 :仕様書無しさん:2016/02/25(木) 22:09:55.43 .net
そうだよ?
O/Rマッパーはリレーション(テーブル)をマッピングすることであって、
問合せ(SQL)をマッピングすることじゃない。

「テーブルのデータはもとよりテーブル同士の関連をオブジェクトで表現するものなので」
って>>459で書いたじゃないか?

465 :仕様書無しさん:2016/02/25(木) 22:18:50.15 .net
>>459
偉そうな口調で言うわりには、パフォーマンス無視した理論ガチガチトークですかw
生SQLの世界だと、色々テクを使ってパフォーマンスが出るようなものは、
ORMじゃ実現ほぼ無理(どうやるのよwww)なんで、生SQL書いてるわ(SQL方言は最後の手段)
SQLで処理を書く? なんとも意味不明・・・

466 :仕様書無しさん:2016/02/25(木) 22:20:42.73 .net
>>464
ではそのテーブル同士の関連を表現する言語がSQLな訳だから
君の理屈ではO/RマッパーとSQLは同じ目的を持つ代物という事になるな。

467 :仕様書無しさん:2016/02/25(木) 22:23:32.78 .net
>>459
誰かの書いた短文を、長文へと妄想で膨らませるのはマジでカンベンしてくれ

468 :仕様書無しさん:2016/02/25(木) 22:25:14.63 .net
>>465
はぁ? 俺>>453な。

O/Rマッパーを勘違いしている人がいるって言っただけで、
俺はO/Rマッパーを支持しているわけじゃない。

間違ったO/Rマッパーの使い方を見て、その理由を考察し、
O/Rマッパーの使い方を理解し、そして自分で実際に使ってみて
正しくO/Rマッパーを使えると確証を得た上で、
やれば出来るけどORMは使わないほうがいいと思ってるんだが。

特に最近のウェブAPI(APIはどちらかと言えば処理)を見ていると
データをオブジェクト指向として扱うのは遠回りだって分かってる。

469 :仕様書無しさん:2016/02/25(木) 22:29:43.12 .net
>>466
SQLがサポートされているからSQLを使うってだけ。

本来は抽象的な考え方であるテーブルと関連を
オブジェクトにマッピングするものがO/Rマッパー

だからSQLを考慮する必要はない。
データと構造を作ってオブジェクト指向的なオブジェクトとして
扱えばあとは自動的にSQLを発行してくれるってだけ。

O/Rマッパーを使う上ではデータと関連だけを考えていればいいんだよ。

470 :仕様書無しさん:2016/02/25(木) 22:32:11.79 .net
要するにO/RマッパーもSQLもよく分かってないのに大層な大口を叩いてたって事か。
どえらいややこしい奴だな。

471 :仕様書無しさん:2016/02/25(木) 22:35:28.53 .net
なんか話の流れと無関係に、自分の結論を押し付けたいやつがいるw

472 :仕様書無しさん:2016/02/25(木) 22:40:25.28 .net
講義したがりの長文厨房がまじでウザイw
もっと手短に気楽にレスしようぜ
長文書きたい奴は自分のプログにでも書け

473 :仕様書無しさん:2016/02/25(木) 22:45:03.98 .net
データベースしらんからついていけない

474 :仕様書無しさん:2016/02/25(木) 23:03:48.58 .net
テーブルごとにDAOを作ってみたけど失敗だった。
あっち見たりこっち見たりしなければいけないし、
複数のテーブルにまたがる処理を書く場所がない。
SQLを表現するQueryオブジェクトとそれを処理するEntityManagerで
ごりごり書いたほうが保守しやすい。

475 :仕様書無しさん:2016/02/25(木) 23:20:59.96 .net
> 複数のテーブルにまたがる処理を書く場所がない。

これがO/Rマッパー使ったときによく出てくる問題な。
テーブルと処理が別れていて、処理のみを書こうとしているからこうなる。

データベースの中身っていうのはでっかい一つのデータなんだよ。
その一つのデータをどの側面から見るかって話。

データ(テーブル)同士には関連がある。
でっかいデータを一つのテーブルという側面から覗き見た時、
一番浅い層では、そのテーブル自体が見え、もう少し深く覗き込めば、関連したデータが見える。
また別のテーブルという側面から見た時、深く覗き込むことで同じデータを違う側面から見ることが出来る。

複数のテーブルにまたがる処理っていうのは、単にどの側面からデータを操作するかってことでしかない。
簡単に言えば複数のテーブルにまたがる処理は、どれかのテーブル(側面・オブジェクト)に対して
全データを渡して処理を実行すればいい。あとはそのオブジェクトが内部でよきに計らう。

O/Rマッパーを使ってオブジェクト指向用語でいうオブジェクトに変換したのだから、
中身(テーブル)がどうなっているかを考える必要はない。
オブジェクト指向的に自然な形でメソッドを作ってそれを呼び出せばいいのだ。

だがここまでやるには、O/Rマッパーを正しく理解していなければならず、
> 3割 => ORMの機能をふんだんに使った"濃厚な"SQL
つまりこの実現が必要不可欠であり、データベース全体がどうつながっているかを
完全に定義しなければいけないので、それを正しくやるのは難しく
難しい割に遠回りでしかないと思ってるから>>453を支持している。

476 :仕様書無しさん:2016/02/26(金) 00:05:40.06 .net
CQRSで解決済みの問題でいつまでもグダグダ言ってんじゃねえよド素人ども

477 :仕様書無しさん:2016/02/26(金) 00:10:17.02 .net
最近その用語を知ったの?w

478 :仕様書無しさん:2016/02/26(金) 00:27:07.70 .net
だーれも書かないけどさ、ビューの一言で解決しねえの?

479 :仕様書無しさん:2016/02/26(金) 00:37:31.99 .net
しねぇよw

480 :仕様書無しさん:2016/02/26(金) 00:44:15.82 .net
SQL書きゃいいんじゃね?
見えないところで何されてるかわからんものを使うよりかえってシンプル

481 :仕様書無しさん:2016/02/26(金) 00:50:12.53 .net
>>480
お前みたいな奴って、似たようなSQLを量産してDRY原則を破る、もしくは無理に共通化しようとして
使いづらいことこの上なしな問い合わせインタフェース作っちゃうんですよねw

482 :仕様書無しさん:2016/02/26(金) 00:58:31.46 .net
>>481
無理しないと共通化できない程度なの君?
SQL使うだけでそこまで壊れるほど嫌悪感丸出しになるのは
チューニング一つできないから?

483 :仕様書無しさん:2016/02/26(金) 01:01:05.27 .net
>>482
なんでチューニングが出てくるんだよアホw

484 :仕様書無しさん:2016/02/26(金) 01:05:57.75 .net
SQLは共通言語だよ、DB毎に多少の個性はあるが
誰でも簡単に使えて、誰でも簡単に読める
この上ないほどのメリット

485 :仕様書無しさん:2016/02/26(金) 17:57:32.85 .net
最初からORMだと、JOINの結合順序のこととか知らずに育ちそう

486 :仕様書無しさん:2016/02/26(金) 18:40:04.17 .net
ORMでいきなりコードから書く人って、
設計せずにいきなりコード書くというのに似てる
(DB設計せずにコードから書き始めるという意味で)

487 :仕様書無しさん:2016/02/26(金) 18:41:33.61 .net
JOINの結合順序を手動でやらなきゃいけない
古いRDBMSを使ってるの?

488 :仕様書無しさん:2016/02/26(金) 19:20:32.45 .net
簡単とかドヤ顔してる奴に教えを乞うても
バカにするばかりのコミュ障しかおらん

489 :仕様書無しさん:2016/02/26(金) 19:30:10.19 .net
ORMの目的の一つに、移植性の確保があるけど、正直どうでもいいんだよなぁ。RDBMSを変更するなんてあるか?

490 :仕様書無しさん:2016/02/26(金) 19:36:48.99 .net
>>489
フレームワークとか使っていないからそう感じるんだと思う。

フレームワークを使っているならば、データベースは
適切なものを選びたいわけで、どんなデータベースでも
同じやり方で開発できるのは重要

変更するためではなくて、選ぶために必要。

491 :仕様書無しさん:2016/02/26(金) 19:44:15.56 .net
>>490
フレームワークを使う?作るじゃなくてか?
あと、何フレームワークか知らんが、DBアクセスするようなのあったっけ。

492 :仕様書無しさん:2016/02/26(金) 19:44:32.27 .net
どんな道具でも同じ使い方しかしないなら適切な道具を選ぶ意味はないのだが
矛盾してるねえ

493 :仕様書無しさん:2016/02/26(金) 19:49:25.03 .net
>>492
例えばすでにPostgreSQLを使っていて
効率化のためにフレームワークやらライブラリを導入する時、
対応していないと使えないだろ?
便利なものでも使えない。

>>492
矛盾してない。MySQLとPostgreSQLとOracleだって
どれも同じ使い方(SQL)使うじゃないか。
使い方が同じでも性能や機能に差はあるんだよ。

494 :仕様書無しさん:2016/02/26(金) 19:54:29.62 .net
データベース君はもういいよ

495 :仕様書無しさん:2016/02/26(金) 19:55:39.49 .net
もういいと言われてもな〜w
俺は自由に好きなことを書き込むし。

嫌なら見なければいいんじゃね?

496 :仕様書無しさん:2016/02/26(金) 20:00:35.79 .net
>>486
DB設計がエンティティとなるオブジェクトの設計に変わっただけで、データ設計はしてることには変わりないんですが。
ウォーターフォールな人はDBの設計が終わってないとコード書き始められないんでしょうけど。
で、あとから出てきたDB設計の不都合をアプリで吸収するとw

497 :仕様書無しさん:2016/02/26(金) 20:02:24.43 .net
>>496
モデリングツールかエクセル使わないと
設計しているとは認めない

498 :仕様書無しさん:2016/02/26(金) 20:03:03.76 .net
同じ使い方で機能に違いがあったら世の中大混乱に陥るのだが
矛盾してるねえ

499 :仕様書無しさん:2016/02/26(金) 20:06:42.76 .net
同じ使い方で機能に差があるものなんてたくさんあるだろ。
家電の範囲だけで考えてもたくさんあるぞ。
洗濯機、掃除機、冷蔵庫

500 :仕様書無しさん:2016/02/26(金) 20:10:22.29 .net
>>492
DBを選ぶ要件がアプリ視点だけって視界狭すぎでしょ
分散化とかいろいろあるじゃん

501 :仕様書無しさん:2016/02/26(金) 20:13:11.74 .net
君の家では洗濯機のスイッチを押すとビールが冷えるのか
カオスだねえ

502 :仕様書無しさん:2016/02/26(金) 20:14:52.89 .net
>>492
パッケージとかユーザーがDB製品を選べるようになってるのあるじゃん
やったことない?見たこともない?

503 :仕様書無しさん:2016/02/26(金) 20:16:42.50 .net
>>501
つまり洗濯機のスイッチを押せば
どの洗濯機でも洗濯されるってことだろ?

どんな道具でも同じ使い方ができることの重要性を
お前は語っているわけだが、

自分で言った言葉、矛盾してないかい?w

504 :仕様書無しさん:2016/02/26(金) 20:17:37.46 .net
〉486
EFなんか良いんじゃないかな

505 :仕様書無しさん:2016/02/26(金) 20:17:54.78 .net
どんな道具でも同じ使い方が出来るから、
自由にいろんなものを選べるわけなんだよな。

RDBMSでも洗濯機でも

変更するためではなくて選ぶために重要なこと。

506 :仕様書無しさん:2016/02/26(金) 20:24:26.07 .net
同じ使い方で機能に違いがあると言ってるのは俺ではないのだが
というか君だよねえ

507 :仕様書無しさん:2016/02/26(金) 20:26:09.24 .net
>>506
「同じ使い方で機能に違い」で検索してもお前しか引っかからないが?w
「同じ使い方で機能に差がある」なら見つかるがねぇ。

「差がある」と「違いがある」の違いがわかんない?
違いあるのは良くないんだよ。

508 :仕様書無しさん:2016/02/26(金) 20:28:45.16 .net
俺は機能に差があるのは良くないと言ってるんだがな
屁理屈だねえ

509 :仕様書無しさん:2016/02/26(金) 20:31:48.98 .net
>>508
屁理屈はお前だよね?

お前は洗濯機のボタンを押したら
ビールが冷えると言う、全く「違った」機能をいい出した
これが屁理屈以外のなんだって言うんだ?

俺が言ってるのは洗濯機のボタンを押したら
どれでも洗濯するが、その洗濯機能は製品ごとに差があるって話をしてるんだよ。
知ってるか?ナイアガラビート洗浄(笑)

510 :仕様書無しさん:2016/02/26(金) 20:35:11.94 .net
笑ってごまかそうとしてももう遅いんだけどねえ君は機能と性能の違い分かってるのか
分かってないよねえ

511 :仕様書無しさん:2016/02/26(金) 20:35:46.54 .net
>>510
もう言い返せなくなった?
今回は何も言ってないね。

512 :仕様書無しさん:2016/02/26(金) 20:37:37.41 .net
君は機能と性能の違いが分かっているのか
答えられないよねえ

513 :仕様書無しさん:2016/02/26(金) 20:38:06.60 .net
ループさせるな

514 :仕様書無しさん:2016/02/26(金) 20:40:04.60 .net
今回は完全論破だったなw

515 :仕様書無しさん:2016/02/26(金) 22:03:58.60 .net
データ君うざいわ

516 :仕様書無しさん:2016/02/26(金) 22:22:09.86 .net
で、お前らCode KataのBusiness Logicはどう設計すんだよ

517 :仕様書無しさん:2016/02/26(金) 22:48:59.70 .net
そこに設計(コード)書いてあんだろ?
それみろよw

518 :仕様書無しさん:2016/02/26(金) 23:06:59.69 .net
>>517
実装案のひとつも思いつかない人はレスしなくていいです

519 :仕様書無しさん:2016/02/27(土) 00:06:07.35 .net
具体的な実装の話になったら黙っちゃう

520 :仕様書無しさん:2016/02/27(土) 00:55:13.16 .net
>>517が答えてくれるはず。

521 :仕様書無しさん:2016/02/27(土) 01:04:18.97 .net
いきなりコードを抜くな。電断してから抜け

522 :仕様書無しさん:2016/02/27(土) 05:27:53.12 .net
SI業界の元請け系の会社で働いてる。火消しばかりだけど。
会社で一度もよい設計書に出会ったことがない。
よいソースには時々出会う。
十代前半から趣味でOSSのソースを読んだり,直したりしているが,こんなにレベルが低いのは思うのはSI業界だけだ。

思うに,この業界には上流から下流まで通しで考えられる人が少なすぎる。
まともなソースがかける人が基本設計と詳細設計をやればいいのに。
プログラム設計みたいな無駄なもの書いてる暇あったら,コメントとテストコードを先にかけばいいのに。

だいたいどのプロジェクトも基本設計はほぼ白紙,詳細設計はめるでプログラム設計みたい,プログラム設計はソースの直訳っていう。

523 :仕様書無しさん:2016/02/27(土) 05:51:59.31 .net
>>486
性能やさんとか,DBやさんも時々火消しとしてやるが,アホが書くDB設計やアホが書くSQLよりORMの方がましなことが多いぞ。
そして日本はアホだらけだぞ。
インデックスの仕組みさえ,駆動表の仕組みさえ理解してない奴らが設計製造してるんだ。
IDっていうカラム名で一意じゃないなんてザラだ。

>>497
そもそも設計にドキュメントなんて必須じゃない。
プロジェクトのサイズやメンバーの腕次第だろう。
そしてExcelはドキュメントに使ったら負けの始まりだ。
アホを集めて戦う覚悟の場合は唯一の味方になるが。

524 :仕様書無しさん:2016/02/27(土) 06:10:24.36 .net
人によってまちまちなんだが
基本設計、詳細設計、プログラム設計
それぞれの役割は?

基本設計(というか基本仕様書)で、既にコーディング可能なんだが

525 :仕様書無しさん:2016/02/27(土) 10:30:36.47 .net
素人にやらせるための詳細設計なんだろけど
コード書いたことない人が設計やるから
最後はデスマで・・・・・・

526 :仕様書無しさん:2016/02/27(土) 11:14:38.45 .net
>>524
基本的には同意見だけど、モジュール間のapi仕様はどこに書くの?
結果が0の時、nullなのか、サイズ0のリストが返ってくるのかとか。

527 :仕様書無しさん:2016/02/27(土) 11:17:57.14 .net
ちょっと思ったけど、C#のnull許容型が、全ての型で使えればコードで表現できるな

528 :仕様書無しさん:2016/02/27(土) 11:28:39.27 .net
>>526
いやいやそれはドキュメントコメントに書けよ

529 :仕様書無しさん:2016/02/27(土) 12:04:25.31 .net
>>528
ドキュメントコメント書く、javadocかなんかで出力、レビューokなら、実装開始って、流れなら文句はないけど。

530 :仕様書無しさん:2016/02/27(土) 12:09:40.90 .net
そんなのいちいちレビューしてられるか

531 :仕様書無しさん:2016/02/27(土) 12:12:41.64 .net
>>526
これはコメントで済む話
それ以前に、返す値がおかしいけど
>=0は件数、<0はエラーとなるように作れば曖昧さが消える

中には型に柔軟性のあるPHPとかはエラーはfalse
正常時は別の型の値を返すなんてこともできる
というか公式がそういう作りで便利すぎるけど

532 :仕様書無しさん:2016/02/27(土) 12:15:16.00 .net
>>525
素人に作らせるための詳細設計も無駄だし
作り方を知らない人間の設計も無駄

533 :仕様書無しさん:2016/02/27(土) 12:17:08.83 .net
ちょっとよく判らないんだけど、お前ら複数人で開発するときどうしてんの?

534 :仕様書無しさん:2016/02/27(土) 12:19:18.86 .net
>>533
そもそもドカタたくさん集めて力仕事で回すような仕事しないからなー
実装の前にインタフェース作って、はいこれ呼び出して、で通じるし

535 :仕様書無しさん:2016/02/27(土) 12:43:29.42 .net
黙ってれば何の問題もないのにいちいち負け惜しみのような事を言いたがるやつ

536 :仕様書無しさん:2016/02/27(土) 12:57:39.01 .net
プログラマにほんと多いよな
他者非難ばかりする奴

537 :仕様書無しさん:2016/02/27(土) 13:04:27.51 .net
プログラマは多くないよ、作れない人間に>>535なのが多い

プログラマはもっと言うべきだな
間違ってなければ黙ってると損しか残らない

538 :仕様書無しさん:2016/02/27(土) 13:07:27.13 .net
プログラマを他者非難ばかりする>>535-536

539 :仕様書無しさん:2016/02/27(土) 13:12:35.27 .net
>>537
じゃあ君はどうやってるのか聞かせてよ

540 :仕様書無しさん:2016/02/27(土) 13:47:16.56 .net
>>539
正しいことは正しい、間違ってることは間違ってると指摘するよ
あらぬ濡れ衣を着せようとする奴がいれば徹底的に叩く

541 :仕様書無しさん:2016/02/27(土) 13:49:36.83 .net
>>540
そうじゃなくてww

542 :仕様書無しさん:2016/02/27(土) 13:53:34.59 .net
ずっと待ってたのか、待たせて悪かったな
そうじゃないって、何の話?

543 :仕様書無しさん:2016/02/27(土) 14:17:53.79 .net
なに言ってんだこいつ恥ずかしくないのかな

544 :仕様書無しさん:2016/02/27(土) 14:34:14.81 .net
ただの鎖自慢?

545 :仕様書無しさん:2016/02/27(土) 14:36:27.22 .net
設計書がいるかどうかは規模によるんだろ。規模小さければ行き当たりばったりでもなんとかなるからな

546 :仕様書無しさん:2016/02/27(土) 14:49:19.49 .net
>>545
経験少ない人には行き当たりばったりに見えるかもしれないね

547 :仕様書無しさん:2016/02/27(土) 15:06:58.78 .net
>>546
繋ぎ目はどうやって決めてんだよボケが

548 :仕様書無しさん:2016/02/27(土) 15:10:31.86 .net
× 行き当たりばったり
○ 臨機応変

549 :仕様書無しさん:2016/02/27(土) 15:14:35.81 .net
>>545
間接的には規模
直接的には頭数

550 :仕様書無しさん:2016/02/27(土) 15:16:51.94 .net
>>547
分担による

551 :仕様書無しさん:2016/02/27(土) 15:21:44.54 .net
>>547
実装から自ずと決まる

552 :仕様書無しさん:2016/02/27(土) 15:34:24.35 .net
http://hatedaihatsu.web.fc2.com/tsundere.html

553 :仕様書無しさん:2016/02/27(土) 22:05:34.98 .net
>>543
質問に答えられないお前が最も恥ずかしい
自分でも分かってないからだろうけどw

554 :仕様書無しさん:2016/02/27(土) 22:07:21.86 .net
>>545
それを言ったら設計書も行き当たりばったりだな
コーディングは兼設計だよ

555 :仕様書無しさん:2016/02/27(土) 22:53:13.42 .net
>>553
恥ずかしい奴って言われたらお前のほうが恥ずかしいと返す
こんなテンプレ通りの奴には臨機応変なコードは書けないだろうなw

556 :仕様書無しさん:2016/02/27(土) 23:16:10.33 .net
>>555
なに言ってんだこいつ恥ずかしくないのかな

557 :仕様書無しさん:2016/02/27(土) 23:18:40.27 .net
バカの相手をする時は同じ目線で相手しないと
ブーメランであることを気付かせられないからね

558 :仕様書無しさん:2016/02/27(土) 23:36:13.64 .net
相変わらず盛り上ってますね

559 :仕様書無しさん:2016/02/27(土) 23:48:26.56 .net
>>524
設計書はあまり分類を考えず、ドキュメントの一言でまとめてる。

その分類だと基本設計書が何層にも分かれるが、主に機能や約束を定義しコミュニケーションを明確化する役割だ。
詳細設計書は、工数の調整、価値の付加(設計済マークを付けるようなもの)、監査対策などの役割がある。
プログラム設計書になると、そんなの作ってて給料貰えるならむしろやりたいぐらいだ。

560 :仕様書無しさん:2016/02/27(土) 23:49:03.48 .net
>>134
SAP ABAP開発だとこれがデフォなんだよなぁ…

561 :仕様書無しさん:2016/02/28(日) 00:17:19.48 .net
で、Code KataのBusiness rulesはどう設計すんの?

562 :仕様書無しさん:2016/02/28(日) 00:42:33.21 .net
よくわからんが、Yahoo知恵袋で聞いた方が誰か教えてくれると思う

563 :仕様書無しさん:2016/02/28(日) 01:01:12.97 .net
>>561
まず言い出しっぺのお前が途中まででもいいからやればいいよ。

みたいな具体的に指示すると
だまっちゃうんだよなw

564 :仕様書無しさん:2016/02/28(日) 01:15:22.12 .net
英語読めませんって素直に言えば

565 :仕様書無しさん:2016/02/28(日) 01:25:05.88 .net
>>561
英語読めないから、自分で何もやらないの?

566 :仕様書無しさん:2016/02/28(日) 01:49:13.51 .net
できないくせにやればできるみたいな雰囲気出してくる奴

567 :仕様書無しさん:2016/02/28(日) 03:14:03.37 .net
俺はCode Kataをしってるんだぜー。
お前らBusiness rules設計できるか?
ほらやってみせろよ

568 :仕様書無しさん:2016/02/28(日) 06:47:49.81 .net
>>559
何層にもというか、開発に必要な情報をまとめるだけの話
細かすぎても作りにくいだけだし、かといって曖昧な部分も
絶対にあってはいけない、曖昧では作れないから

作れないSEが書いてくる書類は、無駄なところは細かく
必要なところは曖昧という、まるで使えないものを出してくる
この辺をうまくやる為には、これから作るものを一人でも
開発ができるくらい、豊富な開発経験が不可欠

詳細設計書に何らかの価値があるとしても
成果物と相違があっては無価値どころかツッコミ対象になる
どうしても必要だというなら後から作るべきだな
詳細設計で工数は増える一方だから調整に使うのは無意味

569 :仕様書無しさん:2016/02/28(日) 07:31:40.16 .net
>>568
文章KISS

570 :仕様書無しさん:2016/02/28(日) 07:59:54.88 .net
設計する人間は、俺一人で作らなくちゃいけない
くらいのプレッシャーを持って設計してもらいたいもの
作れない上に他人任せだからナメた設計擬きをしやがる

作れる人間の設計なら、この辺は問題ない

571 :仕様書無しさん:2016/02/28(日) 08:02:56.61 .net
>>569
DAI語?

572 :仕様書無しさん:2016/02/28(日) 08:17:13.68 .net
五代GO!

573 :仕様書無しさん:2016/02/28(日) 08:23:15.17 .net
作れないSEさんへの文句は職場で直接言ってくれないか

574 :仕様書無しさん:2016/02/28(日) 09:05:53.82 .net
>>573
そんな奴に設計なんざやらせてないから大丈夫

それよりも業界全体がそんな作れない自称SEで今は溢れてしまってるのだから
ローカルな話で終わらせるより、もっとグローバルなところで言わないと
1スレとはいえ2ch、拡散力は侮れない
開発もできないのに設計屋を名乗ってる奴こそ自分の発言には要注意だ

575 :仕様書無しさん:2016/02/28(日) 09:15:28.07 .net
設計しないで実装入るなら、最後まで責任を持てよ
全部放り出して逃げやがった

576 :仕様書無しさん:2016/02/28(日) 09:24:49.79 .net
>>574
それは君が行くところだけだろ
勝手に業界全体の話にすんなよ短絡的な奴だな

577 :仕様書無しさん:2016/02/28(日) 09:30:17.55 .net
>>575
むしろ設計したやつが最後まで責任持たないことのほうが多い。
てめーがまちがってるだろ、なおせや。っていうのが多い。

578 :仕様書無しさん:2016/02/28(日) 09:33:24.32 .net
まあカスは逃げ出してもらった方がいいけどね。
最後まで現場荒らされても最悪だよ。

579 :仕様書無しさん:2016/02/28(日) 09:48:03.36 .net
>>568
> 何層にもというか、開発に必要な情報をまとめるだけの話

開発とはプログラミングのことだけじゃないぞ。
設計書を書くにも上位の設計書が要る。
何を実現するか、ネットワーク構成や情報管理はどうするか
徐々に具体化していき、最下層にプログラミングがあるわけだ。

> 作れないSEが書いてくる書類は、

SEでも何でもいいが、ビジネスパートナーが出した
ドキュメントの質やコードの質が悪いなら
改善提案をするなり、こき下ろすなり個別で解決してくれ。
力関係で難しい場合は根回しなどで味方を増やせ。

> 詳細設計で工数は増える一方だから調整に使うのは無意味

調整ってことは増やすのが目的だ。
減らすのが目的なら効率化なりなんなりの言葉を使う。

580 :仕様書無しさん:2016/02/28(日) 09:51:24.23 .net
> 力関係で難しい場合は根回しなどで味方を増やせ。

それって本来は、上の立場の人がやる仕事じゃね?

581 :仕様書無しさん:2016/02/28(日) 09:55:03.42 .net
>>580
あらゆる人はすべて自分のために根回しする。
下の立場でも対抗しないから改善されないんだ。

582 :仕様書無しさん:2016/02/28(日) 10:01:36.55 .net
お話中すんませんが、随分とストレス溜まりそうな事やってるのね
設計書だの根回しだの、まじで尊敬するよ
みなさん、シニアデベロッパーとかシステムアーキテクトなの?

ただ、設計上の理論や方針を、会社じゃなくてここで"吠える"のか?
その理由や心理がよくわからんのです
完全に"吠える"対象が間違ってると思うんだけどね

プログラマやプログラミングについて、あーだこーだ駄弁ったりするならいいんだけどねー

583 :仕様書無しさん:2016/02/28(日) 10:12:21.78 .net
一つ言い忘れたが、>>581をする場合出世はあきらめてくれ。
上司は、会社の業務を改善したり会社に利益をもたらした人を評価するわけじゃない。
自分のストレスを軽減してくれたり、自分のために理不尽を受け入れてくれる人を近くに置きたがる。

584 :仕様書無しさん:2016/02/28(日) 10:19:47.51 .net
>>582
そこは犬と同じだ。
近くで誰か吠えはじめたら、何であろうと吠え返す。
2chはそれで成り立っている。

585 :仕様書無しさん:2016/02/28(日) 10:24:16.20 .net
>>581
いや、高い給料もらってるんだから
それぐらいやるべきだよね?って話。

586 :仕様書無しさん:2016/02/28(日) 10:31:49.67 .net
>>583
上がだめだと何も良くならない典型的な例だね。

関係ないけど、たまに偉い人が本を読めとか、
意識高い系が本を読んでるとか言ってるけどさ、
この業界にいるお偉いさんはピープルウェアは読まないとだめだよ。

587 :仕様書無しさん:2016/02/28(日) 10:46:29.42 .net
>>585
上司 vs 部下の対立がある場合の話をしてるんだが。
きみが根回しないってなら好都合だよ。
上司が根回しして全部きみが至らないせいにするだけだ。

>>586
本だけ読んでる上司ほどやっかいだ。
実際の開発の感覚が欠落したまま本を読んで解釈がちょっとずれている。
表面的な知識で「こうやればうまくいくはず」で仕切るので
ど素人よりもやっかいなクレーマーど素人と化す。

588 :仕様書無しさん:2016/02/28(日) 10:55:54.91 .net
> 上司が根回しして全部きみが至らないせいにするだけだ。

うん。だから上司が会社をだめしているわけだよね。

589 :仕様書無しさん:2016/02/28(日) 10:59:35.16 .net
きみ=法人なのかw

590 :仕様書無しさん:2016/02/28(日) 11:14:46.02 .net
>>588
そうとも限らない。問題が起こった後であれば、
会社としては上司の責任であるより、部下のミス扱であった方がダメージが少ない。
きみのせいにすることは会社にとって利益になる。

591 :仕様書無しさん:2016/02/28(日) 11:21:57.99 .net
???
なんで誰かのせいにするのさ?

誰のせいにもしなければ、いいだけじゃん。

592 :仕様書無しさん:2016/02/28(日) 11:44:38.53 .net
なんだ?全部運が悪かったですます気かw

593 :仕様書無しさん:2016/02/28(日) 11:49:47.30 .net
>>591
そういうやさしい世界に住みたいよね。ネコとが象とかさ。
でも密猟者とかが怖いし、もう人間なんて滅びてしまえばいいのに。

594 :仕様書無しさん:2016/02/28(日) 11:58:29.51 .net
>>592
会社からしてみれば、誰のせいにしたとしても、
社員に対して損害賠償を請求できるわけないんで
(意図的に犯罪行為をしない限り)
誰かのせいにするだけ無駄でしょ?

595 :仕様書無しさん:2016/02/28(日) 12:09:16.47 .net
>>594
全部運が悪かっただけですわで済ますと、
損害賠償はこないが、もちろん次の仕事も来ない。
永久に改善されない問題が積み重なり、開発力は徐々に下がり、客がいなくなってご倒産。

596 :仕様書無しさん:2016/02/28(日) 12:25:16.35 .net
>>595
意味がわからん。
誰かのせいにして終わったほうが、次から仕事来ないだろ。

問題点を修正して改善することが重要なことであり
誰かのせいにしても何も解決しない。

罪を憎んで人を憎まずと一緒だよ。
失敗を憎んで人を憎まず。

597 :仕様書無しさん:2016/02/28(日) 13:01:55.35 .net
>>596
いいかい、問題があるってことは、誰かが必ず動かなきゃいけないってことだ。

問題が開発プロセスであれば、改善に動くのは上司の責任になる。
延々と改善案を出し議論をし、以前の納品物から、会社の人事体制まで巻き込んで
見直さなくちゃならん。

問題点がきみの能力不足に起因するなら、改善策として担当を入れ替えれば済む。
客への報告も直接原因のみで簡単、あとはチームレベル勝手にやってくれって話になる。
そのうちプロセスの欠陥もうまくフォローして立ち回ってくれる人が入ってくるさ。

会社といっても経営陣も個人の集まりだ。
めんどくさいことに時間取られたくないと思っているが、さて、どちらで収束させたい?

598 :仕様書無しさん:2016/02/28(日) 13:15:20.56 .net
設計が必要だと思うのは
ソースいじる前にちゃんと考えておけば
手戻りが減るからよ

ソースが清書なら
設計書は下書き

599 :仕様書無しさん:2016/02/28(日) 13:19:11.36 .net
>>571
>>568はStupid

600 :仕様書無しさん:2016/02/28(日) 13:30:14.35 .net
>>598
例えば、英文を描く前に、日本文で考えておけば手戻りが減る?
清書前に下書きはするが、他人には意味が解らないレベルのことをメモ帳に書くぐらいかな。

設計書が必要なのは手戻りを防ぐためじゃない、定義や情報を明確化するためだ。

601 :仕様書無しさん:2016/02/28(日) 13:36:27.37 .net
やっぱり具体的にどう設計するかみたいな話より、誰が悪いあれが悪い言ってるほうが好きなんだねみんなw

602 :仕様書無しさん:2016/02/28(日) 13:40:59.98 .net
>>600
これ

603 :仕様書無しさん:2016/02/28(日) 13:44:50.41 .net
>>598
設計書書くなら清書しろよ
それからソースでも下書きしろよ
ソースの清書中に設計ミスに気づいたら
設計書修正する分の手戻りが増えるじゃん

604 :仕様書無しさん:2016/02/28(日) 15:55:25.56 .net
>>603
ソースの下書きってなに?

605 :仕様書無しさん:2016/02/28(日) 20:16:54.38 .net
>>597
>+ 問題点がきみの能力不足に起因するなら、改善策として担当を入れ替えれば済む。

そのやり方が上手く行ったためしはない。

なぜならば、入れ替えた担当の方が能力が上とは限らないから。

もし能力が上の人がいるのであれば、そもそも最初からそいつにやらせればいい。

結局のところ入れ替える担当は存在するが、入れ替えてもすまない。
逆に知識がリセットされるから悪くなる。

606 :仕様書無しさん:2016/02/28(日) 20:31:26.36 .net
昔、パンチャーさんにコード書いた紙を渡してたから
でも、打ち損じもあるので
そのことをいってるのでは

607 :仕様書無しさん:2016/02/28(日) 21:56:28.95 .net
>>605
> もし能力が上の人がいるのであれば、そもそも最初からそいつにやらせればいい。

能力が合う合わないなんてものはしばらく一緒に仕事してみないとわからないからね。
コストパフォーマンスとの兼ね合いもあるし。

> 結局のところ入れ替える担当は存在するが、入れ替えてもすまない。
> 逆に知識がリセットされるから悪くなる。

仕様や人脈を握ってない人なら、次回案件で入れ替えてもロスはあまりないんよ。
問題点が本当にきみの能力不足に起因するなら、人を入れ替えればいくらかマシになる確率が高いんよ。

608 :仕様書無しさん:2016/02/28(日) 23:00:52.76 .net
俺の場合、自分がコピペープログラマの時は、ディスプレイを長時間眺めていたのだが、
最近は、紙に書いている時間が長い。だからコードを打つときは清書みたいな感じだな。
同じようなルーチンができるときは、共通の部分を作って流用する。
同じような処理を共通にできないか設計する、という感じになる。
ひたすらコードを書くというのは、ありえない。

609 :仕様書無しさん:2016/02/28(日) 23:06:18.42 .net
>>607
> 能力が合う合わないなんてものはしばらく一緒に仕事してみないとわからないからね。

だからこそ「担当者を入れ替えれば済む」わけがないんだよね。

そんなに簡単に済むことなら、最初から能力があっている人を使えばいいわけで、
しばらく一緒に仕事して見る時間がかかるってことはそれもコストになる。

610 :仕様書無しさん:2016/02/28(日) 23:08:53.76 .net
>>608
そしてその紙の下書きは捨てるでしょう?
それとも下書きを保守したいと思う?

それが(コードではない)設計書を作らないってことなんだよ。

611 :仕様書無しさん:2016/02/28(日) 23:12:11.37 .net
>>610
紙に書いた思考のプロセスはコードからは読み取れない

612 :仕様書無しさん:2016/02/28(日) 23:16:03.59 .net
>>611
その思考のプロセスが必要ならば、思考のプロセスだけを書けばいい。
ソースコードのコメントとして。

思考のプロセスは、(最終結果以外は)過去に考えて廃止したことであるため
保守する必要はないし、廃案なので問題があってもバグが有っても関係ない。
こういうのはメンテナンスの手間が要らないのであっても問題ない。

問題なのは、ソースコードと同期を取らなければいけない(コードではない)
設計書が残っていること。これがあるとメンテナンスに時間がかかり
時として間違ったことを書かれて逆に開発の問題となることもある。

思考のプロセスが本当に必要ならば
思考のプロセス+最終結果(=ソースコード)だけあればいい。

613 :仕様書無しさん:2016/02/28(日) 23:24:49.93 .net
>>609
> しばらく一緒に仕事して見る時間がかかるってことはそれもコストになる。

コストはかかってるが、それはサンクコスト(埋没費用)という。
使い続けても取り返せないばかりか、放っといたら埋没費用は
膨れ上がる一方だから、変えた方が安上がり。

614 :仕様書無しさん:2016/02/28(日) 23:27:13.83 .net
>>613
えとさ、同じ製品の新品に交換するんじゃないんだよ。

全く別のものに変える。それが以前よりもいいって
保証はどこにあるのさ?

まず話はそこだよね。

615 :仕様書無しさん:2016/02/28(日) 23:29:14.83 .net
>>612
Code KataのBusiness rulesはどう設計しますか?

616 :仕様書無しさん:2016/02/28(日) 23:29:48.66 .net
>>615
言い出しっぺのあなたが先にやりなさい。
途中まででもいいから

617 :仕様書無しさん:2016/02/28(日) 23:30:16.03 .net
という風に具体的に作業をしろって言ったら
>>615は逃げるんだよなw

618 :仕様書無しさん:2016/02/28(日) 23:33:09.28 .net
埋没費用っていうのは、放っといたら膨れ上がるから変えろって言う意味じゃなくて
埋没費用の事を考えても仕方ないから、考えずにその後のことで考えろって話だよ。

だから>>614の言うように、今の人(がやった損失を考えずに)と新しい人を比べて
交換したほうがいいかどうかで考えるべき。

で、能力が合うか合わないかなんてしばらく一緒に仕事してみなきゃ
わかんないって言ってる時点で、新しい人の方が優れているかなんてわからないと
自分で言ってるわけで、論理が破綻してるんだよねw

619 :仕様書無しさん:2016/02/28(日) 23:37:24.80 .net
>>616
設計無理そう?

620 :仕様書無しさん:2016/02/28(日) 23:39:15.37 .net
Code KataのBusiness rules、口だけの人かどうか判別するのにいいと思うんだけどな。
今のところ全員口だけという残念な結果だけど。

621 :仕様書無しさん:2016/02/28(日) 23:40:58.06 .net
>>615
言い出しっぺなのに、設計むりなの?

622 :仕様書無しさん:2016/02/28(日) 23:41:27.40 .net
Code KataのBusiness rules。
言い出しっぺにやれというと、いっつもやらずに逃げるよなw

623 :仕様書無しさん:2016/02/28(日) 23:43:07.10 .net
>>621
僕はプログラミング初めてまだ2週間なので。
あなたやればできるような口ぶりですけど無理ですか?

624 :仕様書無しさん:2016/02/28(日) 23:45:21.30 .net
>>623
私はプログラミング初めて1週間でプログラミングは
知りませんが、物事の道理ってものは知っています。

こういうものは言い出しっぺがまずやるべきです。

625 :仕様書無しさん:2016/02/28(日) 23:45:55.35 .net
英語の問題だったのが不味かったかな

626 :仕様書無しさん:2016/02/28(日) 23:46:30.22 .net
言い出しっぺさんは英語読めないんでしょうね。

627 :仕様書無しさん:2016/02/28(日) 23:47:32.68 .net
あ、プログラミング初めて2週間とか言ってますし、
入社試験なんじゃないですかね?
ここで宿題してもらおうと考えてる。卑怯なやつですわw

628 :仕様書無しさん:2016/02/28(日) 23:48:15.95 .net
できる人ひとりぐらいはいないもんかなー

629 :仕様書無しさん:2016/02/28(日) 23:49:59.35 .net
>>576
もし俺の行くところだけならありえない高確率だな。
こんな場所にすら何人もいるってのに。

>>579
>何を実現するか、ネットワーク構成や情報管理はどうするか
それ設計書じゃなくて仕様書だから。

>調整ってことは増やすのが目的だ。
工数を増やすのが詳細設計書の目的なら、いらんな。

>>599
脳みそ不自由なの?

630 :仕様書無しさん:2016/02/28(日) 23:52:28.36 .net
なにを言っても口だけでしょ

631 :仕様書無しさん:2016/02/28(日) 23:54:36.82 .net
この中でCSの博士持ってる人どれくらいいる?

632 :仕様書無しさん:2016/02/28(日) 23:57:05.16 .net
>>608
紙に書かないと共通化すべき場所すらもわからないの?

633 :仕様書無しさん:2016/02/29(月) 00:03:23.19 .net
>>614
投資ってのは確率の問題だ。保証があるのなんて銀行預金ぐらいだぞ。

あなたが平均よりダメなら、代わりは平均的にあなたよりマシな確率が高い。
この場合、あなたを別の人に代えることは合理的な選択だ。

634 :仕様書無しさん:2016/02/29(月) 00:04:45.99 .net
まだ小学生レベルの言い合いしてんのか。
これだから技術派遣なんだよお前ら

635 :仕様書無しさん:2016/02/29(月) 00:18:28.02 .net
>>633
それだと最初から平均より上を選ばなかった理由は何?ってことになるが?

全員の能力と、平均が分かっているならば、最初から優れた人をアサインすれば良いわけで、
しばらく使ってみなければ、能力がわからないというならば、
他の人もしばらく使ってみなければ、能力がわからない。

636 :仕様書無しさん:2016/02/29(月) 00:18:34.70 .net
>>634
Kataできる人ひとりもいないレベルです

637 :仕様書無しさん:2016/02/29(月) 00:18:57.11 .net
面白そうな話だと思ったがもうスレが枯れてたか

638 :仕様書無しさん:2016/02/29(月) 00:20:36.85 .net
>>636
言い出しっぺがやらないからなw

639 :仕様書無しさん:2016/02/29(月) 00:38:46.44 .net
>>635
そもそも確率とか期待値って知ってる?
世の中すべてのことは結果なんてズバリわかんないし、わかんなくてもきみを切るのが合理的という話をしてるんだが

640 :仕様書無しさん:2016/02/29(月) 00:42:19.70 .net
>>639
むしろ君を切るほうが合理的じゃね?w
わかんなくても君を切るほうが合理的って話をしてる。

641 :仕様書無しさん:2016/02/29(月) 00:49:06.18 .net
やり方を変えるのではなく、人を変えるというのは九割以上失敗する。
個人の能力に頼っているということだから。

つまり「技能」と「技術」のうち、
個人の技能に頼ってる会社は成功しない。

642 :仕様書無しさん:2016/02/29(月) 01:03:01.75 .net
現実的に切られそうだから必死なの?

643 :仕様書無しさん:2016/02/29(月) 01:07:25.89 .net
煽りフェーズに移行しましたw

644 :仕様書無しさん:2016/02/29(月) 01:12:05.72 .net
プログラマってかっとなる人多過ぎね

645 :仕様書無しさん:2016/02/29(月) 01:20:28.58 .net
むしろ、煽りフェーズは終わって人生相談フェーズ

646 :仕様書無しさん:2016/02/29(月) 02:00:53.33 .net
>>644
様つけろや

647 :仕様書無しさん:2016/02/29(月) 02:26:11.81 .net
お前らも見たことあるだろ
担当者がコロコロ変わる駄目プロジェクト

648 :仕様書無しさん:2016/02/29(月) 02:37:50.91 .net
プロジェクトもキチンと設計しないとな

649 :仕様書無しさん:2016/02/29(月) 04:45:45.28 .net
>>638
言い出しっぺのせいにして難を逃れたつもりかもしれないけど、お前ができないのはもうバレてるから
できる体を装わなくていいよ初心者さん

650 :仕様書無しさん:2016/02/29(月) 06:06:15.25 .net
と書くことの目的は、言わなくてもわかるな?w

651 :仕様書無しさん:2016/02/29(月) 06:34:51.61 .net
>>629
文章KISS

652 :sage:2016/02/29(月) 06:35:35.31 .net
派遣PGがわからないことを教えてやろう。
・どうしてプロジェクトはデスマばかりなのに、なぜ開発手法を変えようとしないんだろう?
って思っているんだろ。

まず、全プロジェクトの割合からいったら、デスマになるプロジェクトってそんなにないんだよ。数%くらい。
そんなに利幅とってるわけじゃないんで、デスマだらけなら会社が潰れるよね。

で、派遣PGからみてデスマだらけに見えるのは、デスマになったプロジェクトに、派遣PGを集めて投入してるからなんだよ。

最後に問いかけな。
「9割以上成功する方法があるのに、あなたはそれを変えようと思いますか?」

653 :仕様書無しさん:2016/02/29(月) 06:51:01.19 .net
>>644
そりゃ開発できないSEのような、居ない方が仕事が楽になる奴がうるさいからな

654 :仕様書無しさん:2016/02/29(月) 06:56:03.99 .net
>>651
お前のは文章にすらなってないけどな
簡潔に書くと、作れない自称SEは話を変な方向に持っていこうとして
無駄レス状態にシフトするからな

655 :仕様書無しさん:2016/02/29(月) 07:22:11.42 .net
>>652
いやw 9割が失敗ってデータもあるやんw

[結果報告]9割がプロジェクトの失敗を繰り返す
http://itpro.nikkeibp.co.jp/article/Watcher/20111219/376881/

そういう偉そうなことを言うなら、まず9割が成功っていう
データを出したら?

前提となるデータが間違っていたら、結果もおかしくなるよね?

656 :仕様書無しさん:2016/02/29(月) 07:31:44.68 .net
>>652
優秀な人が吸収してくれてるから
管理能力のない君にはデスマが隠れて見えてないだけ

657 :仕様書無しさん:2016/02/29(月) 07:39:34.80 .net
>>656
9割も失敗してんだwww
じゃあ何でやり方変えないの

658 :仕様書無しさん:2016/02/29(月) 08:09:21.64 .net
デスマになったからって儲けがないわけでは限らないからな。
プロジェクトの失敗というのは基本的に発注者が損をしているのよ。
当初の予定よりも費用がかかったとか時間がかかったとか。
つまり受注者はデスマになったとしてもその分の金を顧客から奪えれば儲けは出る。

だからデスマに体力絶えられるような経験の浅い若い人を集めてさらに
デスマを加速させ、35歳定年などという馬鹿げた風習を作り出し、
効率の悪い人数を大量に集めた。だからコストがかかるんですという人月計算を採用し、
客から金を取るためのコミュニーケーション能力(笑)を重視し
そして改善を行わずに同じことを繰り返す。これがSIerなわけ。

659 :仕様書無しさん:2016/02/29(月) 08:17:50.74 .net
儲けがでてんだったらそれで良くね。何に不満があるんだよ。

660 :仕様書無しさん:2016/02/29(月) 08:34:09.77 .net
>>654>>569の意味をやっと理解できたようだ

661 :仕様書無しさん:2016/02/29(月) 08:40:20.93 .net
>>659
どんなブラックな会社であっても、
倒産しない限り儲けは出てるんだよ。"会社"の儲けはな。

何に不満があるのか?って言うまでもないだろ。

662 :仕様書無しさん:2016/02/29(月) 10:53:40.30 .net
>>504
EFのcode firstってブログ記事読んだレベルの知識しかないけど、あれで開発してる奴なんているのかな?

663 :仕様書無しさん:2016/02/29(月) 12:18:45.09 .net
>>661
具体的に何が不満なんだよ

664 :仕様書無しさん:2016/02/29(月) 12:31:07.89 .net
コーダー、SI業界を憂う

665 :仕様書無しさん:2016/02/29(月) 12:42:51.90 .net
>>662
老害は生のSQLじゃないと理解できないみたいだから、老害が仕切ってるプロジェクトでは今後も使われることはないだろうねw

666 :仕様書無しさん:2016/02/29(月) 12:57:03.56 .net
大丈夫。VSのバージョンがいくつか進めば、EFなんてなかったことになるんだから。

667 :仕様書無しさん:2016/02/29(月) 18:02:03.97 .net
おじさんはSQLが見えないと不安
より抽象度の高い新しいプログラミング言語が使えないのに似ている

668 :仕様書無しさん:2016/02/29(月) 18:55:19.96 .net
AP側の技術って、現れては消えていくのを何度もみてきてるからなあ。
それに比べたら、RDBMSはこれからもずっと残ってくだろ。
だから特定のテーブル構造を要求するORMはクソだと思うよ。
現状、一番いけてるORMは、MyBatisだな。

669 :仕様書無しさん:2016/02/29(月) 19:25:50.26 .net
時給換算5,000円以下のSEの皆様へ

相場が下がって迷惑ですので、SE辞めてもらえませんか?
主婦SE以下の時給換算レベルですよ。
学習や設備や営業や管理や裁判等の費用も含まれてるのですよ。
こちらこそ優秀なSEの離職で大損害なんですから。

発注者より

670 :仕様書無しさん:2016/02/29(月) 19:59:52.85 .net
EFは結構いけてると思う

671 :仕様書無しさん:2016/02/29(月) 20:32:09.06 .net
JPA + Flywayでいいじゃん

672 :仕様書無しさん:2016/02/29(月) 20:56:33.25 .net
>>668
わかってないなら無理に発言しなくていいよ

673 :仕様書無しさん:2016/02/29(月) 21:31:11.94 .net
>>657
作り方も知らない給料泥棒の無能を引きずり下ろせれば一発で解決だよ

674 :仕様書無しさん:2016/02/29(月) 21:32:37.81 .net
>>660
お前みたいに全知全能じゃないので

675 :仕様書無しさん:2016/02/29(月) 21:37:55.92 .net
>>667
設計書が書けないからコードをいきなり書く、と同じくらいアホな捉え方だな
抽象化するほど簡単なのに、なんで難しいことになっちゃうのか?

676 :仕様書無しさん:2016/02/29(月) 21:43:29.21 .net
>>672
その言い方のレス、この板のいろんなスレッドで見るけど、
嫌がらせのレスにしか見えないから、やめた方がいいよ

677 :仕様書無しさん:2016/02/29(月) 22:00:06.50 .net
>>676
嫌がらせっていうか、図星を突くレスです。
だって、>>668を見て、こいつにORMをそれなりに本格的に適用した経験があると思う?

678 :仕様書無しさん:2016/02/29(月) 22:02:53.95 .net
>>677
お前10年やっても対して変わんないんだろうな

679 :仕様書無しさん:2016/02/29(月) 22:08:15.05 .net
>>675
高度な抽象化ができないのが老害おじさん。
手続きが大好きなんです。だって書いてあるように動くから。

680 :仕様書無しさん:2016/02/29(月) 22:08:56.85 .net
そもそもさ、ここにいる奴って何で失敗の責任とらないの。外野から見てると、何で同じ失敗ばかりすんのか理解できないんだけど

681 :仕様書無しさん:2016/02/29(月) 22:11:06.46 .net
>>668
> だから特定のテーブル構造を要求するORMはクソだと思うよ。

このセリフひとつとっても馬鹿丸出しなんだよなあ。こいつほんとにORM使ったことあるのかよっていう。
怒らないから正直に告白して?使ったことなくて言ってるんでしょ?

682 :仕様書無しさん:2016/02/29(月) 22:18:04.08 .net
>>681
例えば正規化崩したい時とか、縦持ちテーブルとかどうするんだ

683 :仕様書無しさん:2016/02/29(月) 22:21:24.58 .net
>>682
は?正規化崩すならそういうエンティティ定義すればいいだけだし、縦持ちに至ってはそれ普通のテーブル設計じゃんw
アホなの?お前の国では横持ちが標準で縦持ちはイレギュラーなの?

684 :仕様書無しさん:2016/02/29(月) 22:21:46.26 .net
あとさぁ俺ORMを否定してる訳じゃなくて、コードファーストアプローチを否定してるだけなんだよね。

685 :仕様書無しさん:2016/02/29(月) 23:06:05.91 .net
>>679
高度な抽象化ってどこが高度なの?

スパゲティは歳くっててもガキでも関係なく初心者なら誰でも書きそうだけど
逆にプログラムを沢山書いてる人は極力手を抜きたいから抽象化しまくる
しかもメッチャ汎用的で使い勝手が良い

686 :仕様書無しさん:2016/03/01(火) 07:13:34.90 .net
>>667で老害は抽象化された機能が使えないといった内容を書いてるのに
なんで>>679では抽象化できない、に変化してるんだ?
罵るだけで考えなしの奴は、発言がブレるね

687 :仕様書無しさん:2016/03/01(火) 07:44:24.16 .net
そもそもプログラム書くのに抽象化とかいらんねん
誰やこんな厨二用語考えたの…

688 :仕様書無しさん:2016/03/01(火) 07:52:10.82 .net
>>686
いちいち煽ってるようには見えるが、発言がブレてるようには見えんぞ

689 :仕様書無しさん:2016/03/01(火) 07:53:43.10 .net
>>686
抽象化して考えられないから抽象化された機能が使えない。同じことですよ。
これが同じことだってわからないのはまさに抽象化できないからだねw

690 :仕様書無しさん:2016/03/01(火) 09:19:11.48 .net
むしろ具体的に考えられないから抽象論に逃げる奴のが困る。

691 :仕様書無しさん:2016/03/01(火) 20:01:34.20 .net
関数を作ることなんか、抽象化の一歩だと
思うんだが、これは抽象化にはいらんのかな?

692 :仕様書無しさん:2016/03/01(火) 23:29:54.50 .net
抽象化はソフトウェア開発における強力な武器だけどね、

アホがそこにまったく汎用性のないルーチンをダイレクトに埋め込んで、
抽象化が死んで、ただの散らかった処理群が出来上がるという皮肉。

693 :仕様書無しさん:2016/03/01(火) 23:50:11.93 .net
>>692
汎用性がないルーチンでもメリットはあるんだぞー!

例えばコードAがあったとする。
まあ最初は不確定要素が多いから考えない。

そしてコードAをコピペして修正して作ったコードBがあるとする。
その作成に○時間かかったとする。

そしてまたコードAをコピペして修正してコードCを作らなければならないとする。
どれくらい時間がかかるか?
そう、前回の経験から同じ○時間かかると予測される。

こうすることで、一つの汎用性がある関数を
汎用性がない関数に分けることで、正確な見積もりを出しつつ
工数を増やすことが出来る。工数=人月=費用なので
これをクライアントに請求できるわけだ。

汎用的な関数に一つにしてしまうと、見積が不正確で儲けも減るが、
汎用性がないルーチンにすることで、ほぼ正確な見積で儲けを増やすことが出来る。

694 :仕様書無しさん:2016/03/01(火) 23:55:42.62 .net
抽象化するから工数がこのくらい減りました
こんな機能のライブラリを作ってあるので工数このくらいです
こんな馬鹿正直な見積出さねえ、安いわ工数少ないわ死ぬわ

695 :仕様書無しさん:2016/03/02(水) 00:09:49.31 .net
客は抽象化とかどうでもいいので平気で個別処理を要求してきます。

696 :仕様書無しさん:2016/03/02(水) 00:11:48.94 .net
>>693
ネタはやめてください

697 :仕様書無しさん:2016/03/02(水) 00:14:05.33 .net
>>695
そりゃそうだ
なぜ客が実装方法なんて気にしなきゃならない

698 :仕様書無しさん:2016/03/02(水) 00:17:23.72 .net
抽象化してもその場の工数は減らないけどね、
やらないとどんどんメンテ不能になって、後任者に殴り倒されるから注意な

699 :仕様書無しさん:2016/03/02(水) 00:22:31.75 .net
>>696
ネタじゃない。
マジでコボラーとかこういう感覚だから。

そもそも昔のCOBOLには関数がない。
ルーチンはあるけどローカル変数や引数を使ったらだめ(新しい機能だから)とか
そういう決まりもあったりして汎用化がものすごくしづらいんだよ。

だから汎用化が出来ない前提で考えた結果、
このやり方(汎用性がないルーチンを作る)が普通だと思ってしまい、
その前提のもとで工数計算をしている。

だから1画面n時間だから10画面あったら10×n時間ですねとか当たり前にありえるw
実はこれは時間が多くなるからまだいい方で10画面で10×n時間はコストが高すぎるから
1画面に減らしたらn時間になりますね。みたいな流れになってデスマになる。

抽象化して効率化を上げた状態の工数を言ってしまうと
知らない所で仕様を減らして勝手に工数を減らされるwww

700 :仕様書無しさん:2016/03/02(水) 00:55:10.35 .net
コボラーなんて別の世界の話だろ。嬉々として持ち出すようなネタかよ。

701 :仕様書無しさん:2016/03/02(水) 07:19:18.26 .net
抽象化って言葉の使い方おかしくね?
共通の処理をくくりだして、一つの処理にまとめるのって、集約だろ

702 :仕様書無しさん:2016/03/02(水) 07:21:47.78 .net
せやね、やってる事は汎化や共通化なのに抽象化って言って格好つけてるだけw

703 :仕様書無しさん:2016/03/02(水) 07:23:38.35 .net
>>701
抽象化しないで集約したら、どうなるか?

責務ではなく似たような処理をまとめようとする。
こういうのは、一つの機能を修正する時、あちこちに散らばって
メンテナンスしづらいコードになる。

抽象化と集約は明らかに別物

704 :仕様書無しさん:2016/03/02(水) 07:40:45.78 .net
>>703
抽象化じゃ工数減らないだろ。

705 :仕様書無しさん:2016/03/02(水) 08:10:16.59 .net
>>704
>>698

706 :仕様書無しさん:2016/03/02(水) 08:14:41.42 .net
抽象化とは、概念の階層構造を作ることですよ。
集約、とは同一階層で分類することです。

707 :仕様書無しさん:2016/03/02(水) 08:19:10.86 .net
>>699
>>705

708 :仕様書無しさん:2016/03/02(水) 09:38:31.29 .net
でも、コードの再利用なんかした事無いなぁ。
毎回環境も石も言語も違う仕事だからなぁ

709 :仕様書無しさん:2016/03/02(水) 10:29:10.65 .net
>>708
てことはお前はこの会話に参加する資格がないんだから黙ってろ

710 :仕様書無しさん:2016/03/02(水) 10:35:29.53 .net
つか、似た様な案件って、パッケージのカスタムじゃダメなのか?

711 :仕様書無しさん:2016/03/02(水) 10:39:57.93 .net
>>710
似たような案件じゃないと再利用できないと思ってるんだw

712 :仕様書無しさん:2016/03/02(水) 10:43:19.46 .net
unixみたいに有り物組み合わせりゃ出来るんだろ?
なんでコードをまた書くんだよ。

713 :仕様書無しさん:2016/03/02(水) 12:29:31.67 .net
>>703
その話がそもそも抽象化とは関係ないね
責務がどうとかも抽象化の関心の範囲ではないし

714 :仕様書無しさん:2016/03/02(水) 20:21:22.12 .net
>>708
どっと疲れる

715 :仕様書無しさん:2016/03/02(水) 20:24:13.86 .net
>>708
過去にC++で作った表示周りのソースを
ちょっと修正しただけで簡単にJavaやC#に移植できたけど
ましてや同じC言語同士の移植なら大部分が活かせるだろう
作りが下手くそだとそうはいかないだろうけど

716 :仕様書無しさん:2016/03/03(木) 01:55:26.85 .net
>>715
表示周りに使っていたライブラリは何?

717 :仕様書無しさん:2016/03/03(木) 11:11:04.40 .net
『設計』という言葉が嫌い

718 :仕様書無しさん:2016/03/03(木) 11:45:51.93 .net
>>717
できないからって自棄になるなよ。
コード=設計書なんだから、コードが書けている時点で設計がまったくできていないわけではない。
あとは練習と試行錯誤あるのみ。

719 :仕様書無しさん:2016/03/03(木) 12:02:11.23 .net
自棄になってはいない。設計という言葉を使う人が嫌いなだけだ

720 :仕様書無しさん:2016/03/03(木) 12:31:39.38 .net
>>719
じゃあなんて呼ぶの?

721 :仕様書無しさん:2016/03/03(木) 12:45:54.97 .net
呼ばない。そんな胡散臭い言葉使わない

722 :仕様書無しさん:2016/03/03(木) 12:48:38.66 .net
共通の用語が使えない技術者なんかいらんわw

723 :仕様書無しさん:2016/03/03(木) 12:49:12.32 .net
>>721
だから設計の変わりになんて言葉使ってんのw
それをなんと呼ぶかに関わらず、設計という行為が必要なことには違いないんだから

724 :仕様書無しさん:2016/03/03(木) 12:50:12.23 .net
俺はプログラミングという言葉が嫌い。コーディングのほうがいい。

725 :仕様書無しさん:2016/03/03(木) 15:12:04.60 .net
>>723
変わりの言葉は使わない

726 :仕様書無しさん:2016/03/03(木) 19:17:56.31 .net
>>725
いきなりソース書くな


それだけ

727 :仕様書無しさん:2016/03/03(木) 19:47:45.68 .net
いきなり設計書書くな、と同じだな

728 :仕様書無しさん:2016/03/03(木) 20:50:37.69 .net
頭おかしいのかな

729 :仕様書無しさん:2016/03/03(木) 21:23:56.11 .net
設計しながらコードじゃない設計書は書かないだろ
そんな奴がいたら指差して噴き出すわ

コードじゃない設計書は設計した上で書面化するもの
清書と設計を同時にやるとか非効率の極み

その点、プログラミングなら設計と清書と成果物が同時にできる

730 :仕様書無しさん:2016/03/03(木) 21:28:41.80 .net
また爆弾投下してしまったかな

コードじゃない設計書が必要な奴は、聞いてると
事前に必要って奴と、後で必要って奴の二手に分かれるね
両方で必要って奴は見ない、辻褄合わなくなるから

事前に必要なら後からは必要ないし(完成時点で情報の古い、役に立たないデブリになってるから)
後から必要ならソースから起こした方が手軽で正確で早い、つまり事前に作る意味ない

731 :仕様書無しさん:2016/03/03(木) 21:55:12.20 .net
いちいち「コードじゃない設計書」とか言ってるの笑えるなw

732 :仕様書無しさん:2016/03/03(木) 22:04:55.42 .net
だからさ、建て前で書かされる設計書と、頭の整理の為に書く設計とは似て非なるものだと何度言えば。

733 :仕様書無しさん:2016/03/03(木) 22:09:11.68 .net
>>730
お前はクビだ

734 :仕様書無しさん:2016/03/03(木) 22:10:14.79 .net
いきなりコード書いて試行錯誤する方が楽なのはおれも同じ
でもそれじゃダメだよって話

735 :仕様書無しさん:2016/03/03(木) 23:09:08.29 .net
>>729
設計とプログラミングが同時にできるなら、
人によっては、設計と設計書のタイピングが同時にできるはずでは?

>>730
> 後から必要ならソースから起こした方が手軽で正確で早い、つまり事前に作る意味ない

プログラム設計書はね。俺もそんなもの不要と思う。
しかし機能設計とかなしで一体何のコードを書き始める気だ?
コーダーならコーディングの他にするべきことがないかもしれんが。

736 :仕様書無しさん:2016/03/03(木) 23:26:26.93 .net
オナニーじゃないのだから、どう考えてその実装にしたのか、その説明が必要。

737 :仕様書無しさん:2016/03/03(木) 23:58:16.28 .net
Webアプリみたいにフレームワークがあって、穴埋めだけするなら設計書なんて書かずにレビューを手厚くする方がいいかもしれないけど、自分でフレームワークから作って複数人で開発とかなら設計書は書くでしょ

738 :仕様書無しさん:2016/03/04(金) 00:04:18.68 .net
設計書がなくても理解しやすいコードも確かにあるよ。
でもお前らが書くコードはそうじゃないんだから、コードのわかりにくさを設計書でカバーしとけw

739 :仕様書無しさん:2016/03/04(金) 00:20:37.49 .net
ここに居る大半は穴埋め作業しかしない頭数要員なので設計書など書かない
むしろ設計が必要な頭を使う作業など任されないんだろう

740 :仕様書無しさん:2016/03/04(金) 05:39:59.47 .net
>>731
設計書必要派が繰り返し強調してたからな

741 :仕様書無しさん:2016/03/04(金) 05:43:12.66 .net
>>734
なぜ?
作法だからってんなら、この上ないアホだが

742 :仕様書無しさん:2016/03/04(金) 05:47:15.19 .net
>>731
コードも設計書というか、コードが設計書なのだから
そう言わないといけない。

コードでない設計書っていうのは、設計書(コード)を理解を
早めるための簡略図とかドキュメントにすぎないんだよ。

つまり、

・設計書 (UML図等)
・実装 (コード)

ではなくて、

・設計書(コード に補助的なコメントやUML図等を加えたもの)
・実装 (設計書より生成した実行ファイル)

が、現実を正しく反映させた姿

743 :仕様書無しさん:2016/03/04(金) 05:47:59.30 .net
>>724
いきなりUML図書いて試行錯誤するの何が違うのだ?

744 :743:2016/03/04(金) 05:48:26.64 .net
間違えた。

>>734
いきなりUML図書いて試行錯誤するの何が違うのだ?

745 :仕様書無しさん:2016/03/04(金) 05:57:02.76 .net
まだ居るかと思って爆弾投下してみたが、効果は絶大だな
やはり事前にと後からの二手に綺麗に分かれてるなw

>>735
設計書を書くことに特化したツールがあるならそうかもね
そんなツールはないけど

仕様が決まれば作れる、その時点で設計も大部分が終わってるし
後から必要なのは仕様書であって設計書ではない

746 :仕様書無しさん:2016/03/04(金) 06:06:16.46 .net
>>736
実装部分の説明はコメントに書くもんだろ
実装前の設計書になんか書かねえ

>>737-739
なに、穴埋めって?
そんな開発聞いたこともないけど
開発したこともない度素人臭がプンプンしてるな

747 :仕様書無しさん:2016/03/04(金) 07:16:24.85 .net
>>745
> やはり事前にと後からの二手に綺麗に分かれてるなw
いや両方やるぞ?

コメントを先に書くか、あとに書くかの話程度にしか思ってない。

全体の流れを把握したいときは先にコメント書くし、
コード書いた時コードだけじゃ分かりにくいなと思ったら
後からコメントを追加する。

それと一緒だよ。

748 :仕様書無しさん:2016/03/04(金) 07:18:46.24 .net
webアプリなら、ページの仕様と、DB側の仕様だけあれば、まぁ作れるよね。
ざっくりいって、DBを更新する、参照するの二種類しかないわけだし

749 :仕様書無しさん:2016/03/04(金) 07:22:26.29 .net
機械や電気回路とソフトウェアで比較すると分かりやすいかも

機械や電気回路の設計図が、ソフトウェアのソースコードに相当する
もうわかるよな

750 :仕様書無しさん:2016/03/04(金) 07:25:39.77 .net
>>748
どうしてWebアプリなら、なの?
ページのないWebアプリもあるけど
機能を限定してるのか、業界知らないか、視野が狭いか

751 :仕様書無しさん:2016/03/04(金) 07:27:16.08 .net
>>747
>コメントを先に書くか、あとに書くかの話程度にしか思ってない。
意味分からん

752 :仕様書無しさん:2016/03/04(金) 07:47:44.84 .net
>>750
ああ、公開apiとか?
そりゃ設計するでしょ

753 :仕様書無しさん:2016/03/04(金) 08:13:27.79 .net
いきなりオナニーするな。セックスしてからやれ
と一緒だな

754 :仕様書無しさん:2016/03/04(金) 11:15:18.16 .net
で、コードのことを設計書と呼ぶとなにが嬉しいの?

755 :仕様書無しさん:2016/03/04(金) 12:05:21.79 .net
>>754
プログラマー様のプライドが保たれる

756 :仕様書無しさん:2016/03/04(金) 12:28:56.81 .net
自分がコーダーである事に薄々感づいていながらもプログラマーやSEになる事も出来ない
悲しきコーダー達の精一杯の強がりですね

757 :仕様書無しさん:2016/03/04(金) 12:46:25.64 .net
>>756
ぼくはプログラマーやで

758 :仕様書無しさん:2016/03/04(金) 13:47:52.26 .net
>>754
名前っていうのは重要。
間違った名前で呼ぶと、間違った形で本質を捉えられてしまう。

コードを実装と呼ぶことで、頭を使わない簡単な作業だと
勘違いされてしまったがために、多くの弊害が起きている。

759 :仕様書無しさん:2016/03/04(金) 14:10:55.95 .net
なぜ「実装」が頭を使わない簡単な作業と思った

760 :仕様書無しさん:2016/03/04(金) 14:14:43.55 .net
>>759
設計と区別した名前で呼んでいるから

実際にやっている作業を考えれば、設計そのものなのに、
設計と実装というふうに違う名前で呼ぶと
実装には設計が含まれていないように感じられる。

設計がない作業はすごく簡単だと思うよ。

761 :仕様書無しさん:2016/03/04(金) 14:16:17.19 .net
>>760
英語ではdesignとimplementationなんだが、implementationが頭を使わない簡単な作業とでも?

762 :仕様書無しさん:2016/03/04(金) 14:20:25.87 .net
>>760
> 設計と実装というふうに違う名前で呼ぶと
> 実装には設計が含まれていないように感じられる。
それは、お前の個人的な感想だろ

763 :仕様書無しさん:2016/03/04(金) 14:20:52.65 .net
>>760
被害妄想強すぎだろw

764 :仕様書無しさん:2016/03/04(金) 14:22:17.77 .net
そもそも、コードを実装と呼ぶ事なんてないから。
コーディング=実装だろ。

765 :仕様書無しさん:2016/03/04(金) 14:25:47.39 .net
まぁ、普通の人の理解はこうでしょうな。

> 何かに必要な機能が(仕様書などで)明らかにされていても、それはまだ理念上の存在でしかなく、
> 現実の世界では作動していない。また、求められる機能が明らかになっていても、その機能を実現
> するための装備や方法が多種類ある場合もあり、それが最終的には定まっていないこともある。
> 実装というのは、理念的段階にとどまる何らかの機能を、具現化させること(実際に動く具体的なもの
> として現実世界に出現させること)である。
wikipediaより。

766 :仕様書無しさん:2016/03/04(金) 19:57:31.83 .net
>>746
バカはサンデープログラマだけやってろ

767 :仕様書無しさん:2016/03/04(金) 21:13:26.36 .net
コーディングそのものが難しいって思うことがあんまりないんだけど、どんなのが難しいんだろ

768 :仕様書無しさん:2016/03/04(金) 21:26:18.71 .net
>>756
弱い頭でもプログラマとコーダーの区別が
ようやくできるようになってきたのか

次はプログラミングできない奴は
SEにすらなれないことを覚えような

769 :仕様書無しさん:2016/03/04(金) 21:28:40.04 .net
多くの場合プログラミングが出来ないやつがSEになる。

770 :仕様書無しさん:2016/03/04(金) 21:29:18.31 .net
>>767
そういうことは、ここに沢山いる
設計書が必要な作れない自称SEに聞けや

771 :仕様書無しさん:2016/03/04(金) 21:38:22.37 .net
>>754
実際にはコード=設計書ではなく、設計書と同等かそれ以上

772 :仕様書無しさん:2016/03/04(金) 22:03:44.83 .net
お前どうしてそんなに必死なん?

773 :仕様書無しさん:2016/03/04(金) 23:04:54.80 .net
>>767
マルチスレッド

774 :仕様書無しさん:2016/03/04(金) 23:06:17.33 .net
>>773
どんな環境を想定して言ってる?
いまどきはマルチスレッドを簡単に扱う言語の拡張やライブラリが充実してると思うんだけど

775 :仕様書無しさん:2016/03/04(金) 23:56:37.19 .net
>>773
マルチスレッドでややこしいのは、レースコンディションとかデットロックだと思うけど、それって設計レベルの話だよね

776 :仕様書無しさん:2016/03/05(土) 00:06:16.53 .net
ライブラリとかフレームワークとかのリファレンスがショボくて
実際にコード書いて動かしてみないと設計もままならないケース

777 :仕様書無しさん:2016/03/05(土) 03:57:30.91 .net
設計(デザイン)は重要。
みなさんは設計をするときにどんなことに気をつけていますか?


アーキテクチャよりも設計を重視しよう ? 米政府18Fチームの提案
(Choose design over architecture)
http://postd.cc/choose-design-over-architecture/

「デザイン」というのは、ソフトウェアの世界では曖昧な単語です。
一方では、「デザイン」はグラフィックのユーザエクスペリエンスを表すために使われます。
他方では、エンジニアリングの世界でいうソフトウェアの「デザイン」は、
互いに独立した小さなモジュラコンポーネントを構築する過程を指します。
どちらのタイプのデザインも、アーキテクチャ第一の計画によって発生する
技術的負債をプロジェクトが負わないためには不可欠なものです。以下に、
ユーザエクスペリエンスのデザインとソフトウェアのデザインに焦点を当てることで、
プロジェクトが技術的負債を避けることを可能にする方法を挙げます。

778 :仕様書無しさん:2016/03/05(土) 07:07:17.94 .net
>>776
ライブラリとか、フレームワークって、開発を楽にするために採用するから、本末転倒だよね。
最初の選定時に、リファレンスがちゃんとしたものを選べばいいだけでは?

779 :仕様書無しさん:2016/03/05(土) 07:34:31.89 .net
>>776
どのフレームワークでも大抵そんなもんだろ
設計と同じで、机上でウダウダやってるより実際に動かしてみた方が早い

780 :仕様書無しさん:2016/03/05(土) 07:37:44.32 .net
要するに机上で設計書を書くためにウダウダやってるより
プログラミングで設計を兼ねた方が一石n鳥

そういうスタイルに変わってきてるんだよ今は
つまり尚更、開発できない奴に設計は無理、作れない奴は用無し

781 :仕様書無しさん:2016/03/05(土) 07:48:17.30 .net
動くものを作るのに時間がかかるんだよ!って
言っている人がいるわけで。

782 :仕様書無しさん:2016/03/05(土) 08:44:18.43 .net
>>780
プログラマー様カッコいい!!

783 :仕様書無しさん:2016/03/05(土) 12:15:56.68 .net
早死に貧困の助長は迷惑だから偽装請負の従犯は辞めろ!
相場下がって迷惑だから報酬増やすか作業減らせ!

・1,000万円/年以下の会社は辞めろ
・80万円/月以下の契約は辞めろ
・5,000円/時間以下の契約は辞めろ
・多重契約は辞めろ
・不利益な現場は辞めろ
・残業見積りは辞めろ
・時間外労働違反は辞めろ
・契約外納期は守るな
・客先指示に従うな
・知的財産を渡するな
・残業しないで学習しろ
・残業しないで副業しろ
・損害は訴えろ

【非婚】SI受注SEは3億円以下の低生涯収入【離婚】
http://hanabi.2ch.net/test/read.cgi/infosys/1451213054/

784 :仕様書無しさん:2016/03/05(土) 12:34:54.98 .net
コード=設計書君がこのスレで一番作れないやつなんだよなあ

785 :仕様書無しさん:2016/03/05(土) 13:03:53.70 .net
>>779-780
あんたらわかってるね

786 :仕様書無しさん:2016/03/05(土) 13:04:44.11 .net
>要するに机上で設計書を書くためにウダウダやってるより
>プログラミングで設計を兼ねた方が一石n鳥

そいうのを止めよ、というのが「いきなりコードを書くな!」という思想なんだけど
頭の中でシミュレーションできないなんて頭がしょぼいよね

シミュレーションできないと、デバッグもたいへんじゃない?
一行ごとに変数の値を見ながら動作確認しているの?

787 :仕様書無しさん:2016/03/05(土) 13:16:47.85 .net
>>778
机上で設計することに拘らなければいいので一応楽にはなってる

788 :仕様書無しさん:2016/03/05(土) 13:18:32.76 .net
ブラックボックスのリバースエンジニアリングを脳内だけでできるという凄い人>>786が現れました

789 :仕様書無しさん:2016/03/05(土) 13:22:05.53 .net
>>780
おまえ一人でそのコード死ぬまで保守しろよ

790 :仕様書無しさん:2016/03/05(土) 13:30:13.58 .net
コードの寿命をせいぜい3年と考えると余裕だな

791 :仕様書無しさん:2016/03/05(土) 13:45:55.79 .net
>コードの寿命をせいぜい3年と考えると余裕だな

三年でこの業界からおさらばだよね。行き詰まりで

792 :仕様書無しさん:2016/03/05(土) 13:46:03.97 .net
まあ、設計書自体が要らないってのはだいたい次の3つのケースだね。

自分が書いたコードなど自分以外誰も見ないし他人に関係ないと思っている新人、
別のエンジニアが起こした設計ドキュメントを仕様書として渡されている新人、
ソフトなんてとりあえずその場で動いてりゃいいからという職場。

793 :仕様書無しさん:2016/03/05(土) 13:47:40.50 .net
俺の周りではね

794 :仕様書無しさん:2016/03/05(土) 14:53:43.89 .net
Cなんか、20年現役でコード動いてるがな。

795 :仕様書無しさん:2016/03/05(土) 15:25:00.94 .net
設計書を必要と言う作れない人たちが
死に物狂い中

796 :仕様書無しさん:2016/03/05(土) 15:28:15.86 .net
>>786
そういうのを止める理由が全く無いんだが
なんで止めなきゃいけないの? できないから?
できない奴が作る設計書なんて、こっちからゴメンだけど

797 :仕様書無しさん:2016/03/05(土) 15:33:28.48 .net
設計書要らない派って、何を元にコーディングするんだ?

798 :仕様書無しさん:2016/03/05(土) 15:49:00.51 .net
派遣先の誰かが設計し、「これが仕様だよ」と渡されたものを元にでしょうね

799 :仕様書無しさん:2016/03/05(土) 15:50:54.54 .net
>>786
> 頭の中でシミュレーションできないなんて頭がしょぼいよね

頭の中でシミュレートしたものをコードに書いているに決まってるだろ?

800 :仕様書無しさん:2016/03/05(土) 15:51:13.87 .net
>>797
> 設計書要らない派って、何を元にコーディングするんだ?

仕様だろ?

801 :仕様書無しさん:2016/03/05(土) 15:56:52.87 .net
>>800
要するに>>798でしょう

802 :仕様書無しさん:2016/03/05(土) 16:02:53.72 .net
ああ、仕様があるんならいいよ。ありとあらゆるドキュメントがないわけじゃないんだろ。

803 :仕様書無しさん:2016/03/05(土) 16:04:03.43 .net
>>801
意味がわからん。

一般的に、仕様 → 設計 の流れで
仕事は進むんだが、

「誰かが設計してこれが仕様だよと渡す」って意味不明

804 :仕様書無しさん:2016/03/05(土) 16:09:05.11 .net
>>802
> ああ、仕様があるんならいいよ。ありとあらゆるドキュメントがないわけじゃないんだろ。
そりゃそうだよ。

設計書っていうのはコードがメインとなるべきだって話で、
コードを書く時に参考にする資料があること自体は何の問題もない
ただそれは「必要な場合に作るもの」であって、絶対に作るものではない。

805 :仕様書無しさん:2016/03/05(土) 16:17:20.33 .net
>>803
あらゆるドキュメントはすべて誰かが設計して作ったものだ。
そしてきみのところに来る頃には、
もう追加の設計書が要らないレベルまで落とし込まれてるってだけだ。

仕様
 ↓
設計 → 設計書(仕様書)
           ↓
           設計 → 設計書(仕様書)
                      ↓
                      設計 → 製作物

806 :仕様書無しさん:2016/03/05(土) 17:16:15.38 .net
>>805
お前は用語の定義がおかしい

807 :仕様書無しさん:2016/03/05(土) 17:44:03.52 .net
>>806
ドキュメントに階層構造があることに異論はないんだね?
では>>805の図の用語のみ、定義がおかしくないように書き直してみてくれ。

808 :仕様書無しさん:2016/03/05(土) 17:50:04.44 .net
これぐらいなもんだろ。

仕様 → 設計書 → 製作物

809 :仕様書無しさん:2016/03/05(土) 18:00:20.40 .net
つまり、おまえは自分の作業範囲内でしか物を考えられない人なんだねw

810 :仕様書無しさん:2016/03/05(土) 18:20:10.63 .net
>>809
なんで他社の範囲まで考えないといけないんだよw

811 :仕様書無しさん:2016/03/05(土) 18:30:20.40 .net
>>810
そうか、きみは派遣さんだから、そこに書いてない部分は全部 「他社から出てきた仕様」 だね

きみがそんなもの全然気にする必要ないわw

812 :仕様書無しさん:2016/03/05(土) 18:41:58.47 .net
>>797
設計書は何をもとに書くんだ? それが答え

813 :仕様書無しさん:2016/03/05(土) 18:51:07.68 .net
>>811
今俺は「他社」って言ったよね?

正社員にとっての他社が、
お前にとっては自社にでもなるのか?

814 :仕様書無しさん:2016/03/05(土) 19:01:42.73 .net
もはや日本語の解読不可能感が半端ない

815 :仕様書無しさん:2016/03/05(土) 19:30:42.06 .net
他社って言って派遣とか言うぐらいだからなぁ。
そういう話してないのわからないんだろうね。

816 :仕様書無しさん:2016/03/05(土) 19:33:32.64 .net
何言ってんのこいつwもう休めw

817 :仕様書無しさん:2016/03/05(土) 20:27:01.92 .net
>>805
これは一体何が起きてるの?
子請け孫請けの外注でもこんな異常事態起きないだろ

818 :仕様書無しさん:2016/03/05(土) 20:35:37.85 .net
>>816
何も言わないなら、バイバイねw

819 :仕様書無しさん:2016/03/05(土) 20:37:01.64 .net
>>817
仕様を元に設計したものを、仕様書と名前を変えて渡すらしい。

そしてその仕様書(設計済みのもの)から
さらに設計をするらしいwww

意味不明過ぎるなw

820 :仕様書無しさん:2016/03/05(土) 21:08:53.76 .net
意味不明な事になるから、設計書は必要、でいいじゃん

821 :仕様書無しさん:2016/03/05(土) 21:30:55.28 .net
>>817、819
多少の知識でもあれば、これなら理解できるか?
大きなプロジェクトでは往々にしてもっと階層構造は多くなる。

要件定義
 ↓
 設計 → システム仕様書
          ↓
         設計 → ソフトウェア仕様書
                   ↓
                  設計 → コーディング

822 :仕様書無しさん:2016/03/05(土) 21:42:34.83 .net
つうか普通こんなんじゃ全く済まないと思うが、
おまえらとことん小規模開発しか知らんのな

823 :仕様書無しさん:2016/03/05(土) 22:27:23.44 .net
>>821を正しく訂正するとこうなる

要件定義
 ↓
システム仕様書
 ↓
ソフトウェア仕様書
 ↓
設計
 ↓
コーディング

824 :仕様書無しさん:2016/03/05(土) 22:29:21.44 .net
>>822
大規模っていうのは量が多いだけで
工程が増えるわけじゃない

825 :仕様書無しさん:2016/03/05(土) 22:36:50.83 .net
世迷い事はいいわ

大規模な証券システム等の要求仕様だけみて
ダイレクトにコーディングから入れるもんなら入ってみ

826 :仕様書無しさん:2016/03/05(土) 22:38:46.51 .net
パソコンにプログラム打ち込むこと以外
やりたくない底辺が、言い訳してるだけのスレ

827 :仕様書無しさん:2016/03/05(土) 22:42:29.91 .net
>>825
それなんだよな
小規模システムの方法論で大規模いけると思ってる身の程知らずばかり

828 :仕様書無しさん:2016/03/05(土) 22:51:15.63 .net
大規模コーダーvs小規模コーダーの構図

829 :仕様書無しさん:2016/03/05(土) 23:01:13.52 .net
コーダーって何かわかってる?

830 :仕様書無しさん:2016/03/05(土) 23:07:30.20 .net
>>827
設計を見直せカスがww
大規模も小さなコンポーネントの固まりに過ぎない。

831 :仕様書無しさん:2016/03/05(土) 23:11:23.82 .net
>>825
何度も言ってるよね?
必要な場合には作ればいいって。

それにコードが設計書であるってだけで
それ以外に設計書がないとは言っていない。

なんでそう何度も勘違いするの?

832 :仕様書無しさん:2016/03/05(土) 23:14:33.14 .net
>>823
成果物に着目したフローというわけではなく、
あえて一箇所にだけ「設計」という用語を残した意図は?
合理的に説明できる?

>>830
それをいうなら車だって鉄の部品の固まりに過ぎない
日曜日に工作で作ってみたらどうだい?

833 :仕様書無しさん:2016/03/05(土) 23:19:47.55 .net
>>831
きみの話題が合ってない
>>825は設計書があるないの話じゃなく、規模によって必要な工程や設計書の種類が増えるという話だ

834 :仕様書無しさん:2016/03/05(土) 23:28:27.80 .net
俺らプログラマーのすごさを全然わかってないな

835 :仕様書無しさん:2016/03/05(土) 23:56:47.55 .net
設計書かないと、管理する側が成果物を出されるまで
プログラマーがどんな認識や設計で、本当に仕様が満たせているのか、納期や品質はどうなのか
何も状況が見通せなくなるだろうから管理のしようがなくなると思う。

836 :仕様書無しさん:2016/03/06(日) 00:27:37.36 .net
管理する側が状況を見通せないのは、設計書だろうとコードだろうと同じ。
相手と同じ目線で協力体制を築いけない人は、形式にこだわってもうまくいかない。

それより設計書がなくて困るのは他の開発者だ。

837 :仕様書無しさん:2016/03/06(日) 06:36:29.63 .net
管理能力のある奴が作れる人間なら仕様書で共有可能だし
作れない奴だったら設計書を見たところで何がわかるんだと

838 :仕様書無しさん:2016/03/06(日) 06:43:16.96 .net
あ、設計書が必要と言ってる奴は、仕様書もなぜか設計書と呼んでるんだっけ?

839 :仕様書無しさん:2016/03/06(日) 06:45:55.12 .net
>>805>>821が全然違う件
>>805は異常だが、>>821>>823の流れだよな

840 :仕様書無しさん:2016/03/06(日) 06:52:22.87 .net
要件定義
基本設計
詳細設計
コーディング

でいいじゃん。仕様を設計と呼ぶな?知らんよそんなの。

841 :仕様書無しさん:2016/03/06(日) 06:59:54.96 .net
詳細設計書いらねえ

842 :仕様書無しさん:2016/03/06(日) 07:23:08.79 .net
>>841
840だけど、詳細設計要らんかもね。
スケジュール引っ張る時、詳細設計、コーディング、単体テストはひとまとめにして1人の担当者にアサインしてるよ。
詳細設計入れとくのは、スケジュールをレビューされたときに、詳細設計は?何て言う指摘を回避するためだね。

あと、基本設計には、トラザクションの範囲とか、例外の扱いみたいのも書いておくよ。自由にやらせると、収集つかなくなることは書いておく。

843 :仕様書無しさん:2016/03/06(日) 08:12:28.76 .net
>>842
表向きには極々ドノーマルなやり方だな
だが実際にはこうだ

要件定義
基本仕様作成
基本設計(基本設計「書」は必要に応じて作成)
詳細設計兼プログラム作成兼単体テスト

仕事で書類を書くというルールがあったり複数人で作る場合は
基本設計書までは書く場合もあるけど
共有すべき点が少なかったらわざわざ基本設計書と分けずに
基本仕様に入れてしまう
(逆に共有すべき点が多い場合は、仕様に致命的な問題あり)

基本仕様書があれば設計の大部分はすぐに出来上がるので
小規模、大規模に関わらずプログラミング工程に移行できる

844 :仕様書無しさん:2016/03/06(日) 08:17:15.59 .net
仕様書はWhatがかかれていて
設計書はHowがかかれているんじゃなかったっけ?

845 :仕様書無しさん:2016/03/06(日) 08:57:41.54 .net
>>844
ごちゃ混ぜに書けという訳じゃないが、いろんな書類に分かれるほど
後で見る必要が出てきた時に「正確な情報」を「探す」手間が大きくなる
残ってる書類同士で内容が噛み合ってないってこと経験ない?
仕様変更、仕様追加が発生する度に、新規作成時に用意した
いくつもある書類ファイル全てに目を通して修正してたら
大変どころの話じゃない

後のことも考えて、極力まとめて書くのが保守性の高い資料
新規開発時も、開発者の立場では、その方が助かる場合が多い
書類は客のため以上に、開発者のために作成するものだから

完成したら後は知らない
何かあったらプログラマヨロシクって奴にはまあ無理な仕事

846 :仕様書無しさん:2016/03/06(日) 09:15:58.60 .net
>>843
共有すべき点が多いと仕様に問題あり、ってのがよくわからん

847 :仕様書無しさん:2016/03/06(日) 10:13:00.69 .net
>>792
>まあ、設計書自体が要らないってのはだいたい次の3つのケースだね。
>自分が書いたコードなど自分以外誰も見ないし他人に関係ないと思っている新人、
(後の二つは省く)

今の流れは設計の必要性について大規模の場合が述べられているが、
小規模でも設計図を書く習慣をもつといいわけ
プログラマがユーザから要求を聞きながら、
コードが浮かんでくるというのは、プログラマ的に優れているからでもない。
それで唐突にコードを書いても、手直しな。

設計図を書いてそれからコードに直していくというのがいい。
唐突にコードを書きなぐっていると、全体が見えなくなる
そのときにあらかじめ設計図があると役に立つということだな

設計図があるといっても、それを手直ししながら進めるという感じだが
行き詰まり(手戻り)を防ぐ手段に役立つ

848 :仕様書無しさん:2016/03/06(日) 11:28:59.47 .net
>>839
各設計に対するアウトプットが、具体名か抽象名かの違いしかないが?
用語を抽象化されただけでわからなくなるって職業的に致命的

849 :仕様書無しさん:2016/03/06(日) 11:38:49.11 .net
>>847
だいたい同意だが、
全体が見えてない人は設計図から書こうが見えてないのは一緒。
設計図そのものに手詰まりや手戻りが発生するのも一緒だ。

設計書を書くのは他のエンジニアとの情報共有のため、
またドキュメント化できるレベルの明確なポリシーで設計をするようにと思ってる。

詳細レベルの設計書が渡されているなら唐突にコードだけ書いたっていい。
コード上で設計しながら設計書にも書きつつやっても構わない。
ただ最終的にどこにも設計書がないのは問題と思う。

850 :仕様書無しさん:2016/03/06(日) 11:47:47.32 .net
>>844
まあそうなんだが、上流工程の設計書に書かれたHowが、下流工程にとっての仕様Whatになる

851 :仕様書無しさん:2016/03/06(日) 12:21:32.80 .net
> まあそうなんだが、上流工程の設計書に書かれたHowが、下流工程にとっての仕様Whatになる

その理屈で言えば、コードではない設計には、コードを書く人にとってのWhatが書かれていない。

852 :仕様書無しさん:2016/03/06(日) 12:22:16.59 .net
ちょっと訂正

その理屈で言えば、コードを書く人が見るコードではない設計書には、
コードを書く人にとってのWhatが書かれていない。

853 :仕様書無しさん:2016/03/06(日) 12:25:30.14 .net
なぜならば、
「コードを書く人が見る(コードではない)設計書」を作る工程と
コードを書く工程は同一のものなんだよね。

今は本来分けてはいけない工程を、無理やり分けて
その一部を中途半端にやってるようなもの。

コードを書く工程が設計と考え、その工程で参考として
作るドキュメントと考えれば、きれいに収まる。

854 :仕様書無しさん:2016/03/06(日) 12:56:15.52 .net
>>851-853
プログラム設計書の話をしてる?
だいたい基本設計書レベルの話をしてるつもりなんだが?

さっき言ったように誰かが詳細に書いてくれているなら、おまえが書く必要はないわ
おまえがそういうレベルの仕事をしているというだけ

855 :仕様書無しさん:2016/03/06(日) 13:07:24.07 .net
話が通じなかったのかな?
図解するね。


上位工程の生成物
|  │
|  │
| 設計書(コードではない)
|  │
↓  ↓
コ ー ド


こういうこと。(コードではない)設計書を作る工程と
コードを作る工程が全く一緒だから、
このように参照する上位工程の生成物がどちらも同じになる。

もちろん疑問点があったときに調べるとか言う些細なものじゃない。
同じ「上位工程の生成物」を使ってコードを書くし、
「上位工程の生成物」がないとコードは書けない。

856 :仕様書無しさん:2016/03/06(日) 13:17:03.32 .net
>>855
話が通じてないのはおまえ
そんなわけの分からん位置にあるものなんてプログラム設計書としか考えられんだろ?

んなもん満場一致で要らんといっとろうが。何と戦ってるんだ?

857 :仕様書無しさん:2016/03/06(日) 13:26:09.14 .net
>>855
まずおまえが設計書にどんなことを書かされてるか説明しろ
ホントに要らんものの可能性もあるからな
でないと永久に話が噛み合わん

858 :仕様書無しさん:2016/03/06(日) 13:30:58.36 .net
インデントが深くなればサブルーチンとして関数分けをするのだが
そうでないと見難いから。ネストが深いのは読み手に負担だな

で、関数分けする。するとその関数に変数をどうするか、ということを考える
このときに構造体をつかって渡すと楽だとか、
渡す変数が少ないからずらずら書くとかだな。
構造体をできるだけ共通にしておくと見通しが立つ
そいう判断をする

859 :仕様書無しさん:2016/03/06(日) 13:34:29.68 .net
>>858
ええと、きみは誰で、誰に対するレスだ?

860 :仕様書無しさん:2016/03/06(日) 14:02:58.12 .net
俺は858だが、俺の文が理解できないようでは
プログラマとは言えない
プログラマの思考を述べている。
それが設計図に書かれるべき内容だ。
プログラマの思考は変数の型とか関数の関連を考えるわけ

861 :仕様書無しさん:2016/03/06(日) 14:08:09.24 .net
要するに、プログラマーが最上位と

862 :仕様書無しさん:2016/03/06(日) 14:18:23.75 .net
>>861
そういうの、ホント痛いんだよね。
どんだけ現実で虐げられてんだよ。

863 :仕様書無しさん:2016/03/06(日) 14:28:34.15 .net
>>858
そういう構造体渡すのって、クラス化して解決するのが普通じゃない?
もしかして、クラス使わず全て関数で書いてるの?

864 :仕様書無しさん:2016/03/06(日) 14:30:01.05 .net
>>858
そういう構造体渡すのって、クラス化して解決するのが普通じゃない?
もしかして、クラス使わず全て関数で書いてるの?

865 :仕様書無しさん:2016/03/06(日) 14:30:03.83 .net
>>858
そういう構造体渡すのって、クラス化して解決するのが普通じゃない?
もしかして、クラス使わず全て関数で書いてるの?

866 :仕様書無しさん:2016/03/06(日) 14:36:11.16 .net
>>860
文が理解できないのじゃなくて
「きみは誰で、誰に対するレス」かを聞いてるのだが。

> プログラマの思考を述べている。
> それが設計図に書かれるべき内容だ。

きみが書かされてる設計図が>>858のような内容なら、その設計図は要らん。
以上。


>>863-865
んなもんプログラム言語にもよる、かなりどうでもいい

867 :仕様書無しさん:2016/03/06(日) 14:53:34.41 .net
>>866
プログラミング言語による部分もあるかもしれないが、
クラス化する考え方は言語関係ないよ
オブジェクト志向の話ね

それをどうでもいいと言ってるあたりが初心者っぽい意見だなw

868 :仕様書無しさん:2016/03/06(日) 14:58:28.48 .net
>>867
言語によってはクラスなんて概念のないのもあるでしょう。
そういう言語でも無理やりオブジェクト指向的な設計を
取り入れることはできるが、往々にしてデメリットの方が多い。

オブジェクト指向はメモリをバカ食いするので
ファームウェア等では嫌われる。

そんなもので実情に合わせてケースバイケースだ。
今の話題としてはどうでもいい。

869 :仕様書無しさん:2016/03/06(日) 15:01:31.77 .net
>>868
>オブジェクト指向はメモリをバカ食いするので
こう言える言える具体的な理由は?

870 :仕様書無しさん:2016/03/06(日) 15:09:22.80 .net
>>868
オブジェクト指向がメモリをバカ食いするって正気で言ってるのか?
クラス化したって構造体アドレスを引数で渡したってパフォーマンスは変わらないよ
ポリモーフィズム導入してもせいぜい関数ポインタが増えるくらい

メモリは多少食うとはいえ、バカ食いまでは行かんぞw

871 :仕様書無しさん:2016/03/06(日) 15:14:55.86 .net
オブジェクト指向とかデザインパターンとかよくわからずに否定してる人がいるっぽいね
クラスの無いC言語だって、構造体にデータまとめて関数に渡すという考えはオブジェクト指向で言うカプセル化とほぼ一緒なんだよね
これこそまさに設計能力が無くてコーディングだけできればいいじゃんっていう人の考え方じゃんw
設計能力ある人はコードからも簡単に設計書おこせるくらいソースが整備されている

872 :仕様書無しさん:2016/03/06(日) 15:17:26.76 .net
>>869
クラスの継承や仮想ポインタによって余分にデータ領域を取ったり。
オブジェクト指向的な設計ポリシーもプログラム自体の見通しは良いのだが、
どうしても実体化されるオブジェクトが増えやすい傾向にあり、
メモリを食いつぶしやすいね。

もちろんその辺も考えて緻密にプログラム組めばいいかもしれないが、
それだとオブジェクト指向を取り入れるメリットもないので、
結局のところファームウェアではC++よりC言語が使われる。

873 :仕様書無しさん:2016/03/06(日) 15:20:24.83 .net
少なくとも>>858のやり方は設計せずいきなりコードを書いて行き詰ったら小手先で対応するやり方だな
インデントが深いからという理由だけで関数分けすればいいって話じゃない
サブルーチン化の主な目的は処理の使いまわしだからね
まあ、その辺は脳内だけでも設計してからコーディングすればいい話なんだけど

874 :仕様書無しさん:2016/03/06(日) 15:26:06.39 .net
>>872
クラスの継承だけではメモリは食いつぶさないよ
食いつぶすのは仮想関数使ってその関数ポインタがクラスの隠しメンバに追加されるからだよ

875 :仕様書無しさん:2016/03/06(日) 15:32:25.06 .net
>>872
ファームウェアはC言語主流かもしれないが
それ以外の開発だとオブジェクト指向取り入れるのが普通だよ
なんかファームウェア前提で語られてるっぽいけどw

あと、「実体化されるオブジェクトが増えやすい」っていう意味が分かんないw
設計が一緒ならオブジェクトの数が変わるのが謎

876 :仕様書無しさん:2016/03/06(日) 15:33:26.41 .net
>>874
仮想関数以外の関数は継承してもメモリ増えないけど、
変数については実体化したとき領域取られるでしょう。

そもそも、そういうコンパイルレベルの話だけじゃなくてさ、
設計ポリシーの違いのため、メモリを食いやすいプログラムになるという話だ。

877 :仕様書無しさん:2016/03/06(日) 15:38:30.02 .net
>>875
> なんかファームウェア前提で語られてるっぽいけどw

ファームウェアについて質問されたから答えてるだけで
そもそもケースバイケースといっとろうが。

> 設計が一緒ならオブジェクトの数が変わるのが謎

言語だけ変えて設計まったくかえなかったらそうだが、なぜC++使う?
C++使うってことは、オブジェクト指向設計を取り入れるからでしょう。

878 :仕様書無しさん:2016/03/06(日) 16:10:12.34 .net
>>877
ファームウェア限定の話にするとして、
じゃあなんでネスト深いから関数化するの?

関数化すればその分スタックメモリ消費するよね?
それくらいメモリにシビアな環境ならコールスタックの深さを制限するのも重要だと思うが。
割り込み処理が頻繁に入るとさらにスタック消費するでしょ。

879 :仕様書無しさん:2016/03/06(日) 16:19:41.90 .net
C++にはインライン展開っていう関数コールをなくす機能があるけど
C言語で同じことやるとマクロ展開しかできない
この点でもC++のほうが有利

C++使うにしてもクラスさえ使わなければC言語と変わらん
C++はC言語のスーパーセットなんだし

880 :仕様書無しさん:2016/03/06(日) 16:22:21.43 .net
>>878
ネスト深いから関数化するなんて誰が言った?>>858は俺じゃないぞ。

俺が書いたのは、>>857, >>859, >>866, >>868, >>872, >>876, >>877
OK?

881 :仕様書無しさん:2016/03/06(日) 16:26:25.81 .net
>>880
すまん、俺の勘違いだった。
なら問題は無い。

882 :仕様書無しさん:2016/03/06(日) 16:28:45.19 .net
C言語でも関数をインライン展開すること できまっせ
(頭のいいコンパイラは自動でインライン展開)

883 :仕様書無しさん:2016/03/06(日) 16:30:05.32 .net
関連する話になるけど、メモリ数百Byteのマイコンでプログラムしたときは
コールスタック深すぎてプログラム暴走させたことがあったな…
変数はできるだけstatic領域で固定で確保させていた

884 :仕様書無しさん:2016/03/06(日) 16:36:41.69 .net
インライン展開されてるかどうか確認するにはコンパイルされたアセンブリコードを見ることだな

885 :仕様書無しさん:2016/03/06(日) 16:48:09.46 .net
>>883
ファームの世界では今でもよくある。大きな領域はstaticで取るね。
量産品の装置は想定ギリギリしかメモリ積んでない。
メモリの値段の差は知れてても、大量生産すると経費もバカにならないからね。

886 :仕様書無しさん:2016/03/06(日) 17:19:15.22 .net
メモリが少ないほうが管理は楽だよな。

887 :仕様書無しさん:2016/03/06(日) 18:51:26.41 .net
>>847
コードが見えてくるんじゃなくて、過程と完成図が見える
設計書を書くのだって同じだろ
それが話を聞くだけですぐに出来てしまうだけの話

888 :仕様書無しさん:2016/03/06(日) 18:57:41.07 .net
>>858はどこからどう見てもプログラマじゃないだろ
そんなこともわからんレベルの連中なのか

889 :仕様書無しさん:2016/03/06(日) 19:03:18.62 .net
>>888
>>858はプログラマーと思う」なんて誰か書いてるの?

890 :仕様書無しさん:2016/03/06(日) 19:08:43.88 .net
>>858はどこからどう見てもプログラマだろ

891 :仕様書無しさん:2016/03/06(日) 19:14:09.97 .net
>>847
>唐突にコードを書きなぐっていると、全体が見えなくなる
なんで書きなぐるのよ?
そんな程度の初心者なら設計書を通しても、同じ書きなぐりコードになるぜ

892 :仕様書無しさん:2016/03/06(日) 19:21:24.15 .net
唐突に設計書を書きなぐっていると、全体も詳細も見えなくなるww

893 :仕様書無しさん:2016/03/06(日) 20:29:54.70 .net
>>888
プログラマだけど初心者プログラマ

894 :仕様書無しさん:2016/03/06(日) 20:58:59.81 .net
唐突に仕様書を書きなぐっていると、何をやっているのか訳がわからなくなるww

895 :仕様書無しさん:2016/03/06(日) 21:00:13.67 .net
唐突にコンパイルすると、エラ−になるww

896 :仕様書無しさん:2016/03/06(日) 21:03:23.55 .net
どれも情報の扱いとそれに起因するエラーの構造は同じ

897 :仕様書無しさん:2016/03/06(日) 21:09:30.36 .net
エラ−

898 :仕様書無しさん:2016/03/06(日) 21:09:58.89 .net
コ−ド

899 :仕様書無しさん:2016/03/06(日) 21:20:17.96 .net
いきなり書き始め、出来上がったプログラムが暴走したことってない?

900 :仕様書無しさん:2016/03/06(日) 21:51:44.41 .net
>>899
いきなり書こうが、慎重書こうが、
出来上がったばかりのテストもしてないプログラムが正常に動くと思うのがそもそも大間違い

901 :仕様書無しさん:2016/03/06(日) 22:01:36.05 .net
コンパイルエラーなんぞ、デバッグのうちに入らない

902 :仕様書無しさん:2016/03/06(日) 23:00:35.08 .net
>>899
コンパイルエラーはあるが暴走はないな
ほぼ期待通りに動く

903 :仕様書無しさん:2016/03/06(日) 23:09:31.56 .net
そりゃ最近のVisualStudio開発環境なんかだと
暴走するようなコードをわざと書こうと思ったって全部コンパイラではじかれるからね

904 :仕様書無しさん:2016/03/06(日) 23:11:23.80 .net
>>903
たとえばどんなコード?
そんな暴走するようなコードそもそも書いたことないから知らないわ

905 :仕様書無しさん:2016/03/06(日) 23:27:37.28 .net
天災さんはデスマとご縁がないんですね

906 :仕様書無しさん:2016/03/06(日) 23:29:14.08 .net
入門者がやる課題をコピペして動きましたとかかな
そういう人いたな

907 :仕様書無しさん:2016/03/06(日) 23:34:37.54 .net
>>904
プログラムの実行位置やプログラムそのものを壊すコードを書いたらいい
例なら >>883 とかが書いてるだろ

908 :仕様書無しさん:2016/03/06(日) 23:38:29.39 .net
>>907
それでコンパイラがエラーになるの?
コードで書いてくれ

909 :仕様書無しさん:2016/03/06(日) 23:40:47.67 .net
>>905
管理者が全く管理してないからデスマだらけだよ
そう見えないだけで

910 :仕様書無しさん:2016/03/06(日) 23:43:11.49 .net
デスマデスマっていうけど、どんな状態なんだよ。デスマって、言いたいだけちゃうんかい

911 :仕様書無しさん:2016/03/06(日) 23:45:02.29 .net
>>908
コンパイルエラーにはならないよ
無限再帰するコード書けば簡単に再現できる

912 :仕様書無しさん:2016/03/06(日) 23:49:23.86 .net
>>910
たとえばプロジェクト1本でもギリギリのスケジュールなのに
4つ5つ同時に仕事を振ってくるとかな

スケジュールが空くことにはやたらと神経質だけど
あっぷあっぷのスケジュールに詰め込みまくることには制限ない
典型的なスケジュール管理ひとつまともにできない管理職

>>911
>>903-904を読み直せ

913 :仕様書無しさん:2016/03/06(日) 23:52:30.56 .net
>>912
そうなんだ。ちなみに何人くらいの会社?

914 :仕様書無しさん:2016/03/06(日) 23:53:51.84 .net
同僚の自殺を経験してからが一人前よw

915 :仕様書無しさん:2016/03/06(日) 23:54:10.93 .net
>>913
君の会社は何人?

916 :仕様書無しさん:2016/03/06(日) 23:56:21.66 .net
>>914
得意先の自殺者はいるが身内はいないな
壊れた奴は何人も知ってる
入れ替わりが激しい所とか、上司を見ればわかるよね

917 :仕様書無しさん:2016/03/07(月) 00:03:11.58 .net
>>915
5000人くらい

918 :仕様書無しさん:2016/03/07(月) 00:04:59.76 .net
>>917
だったら君の話の方が楽しそうだ、中小の俺なんかよりね

919 :仕様書無しさん:2016/03/07(月) 00:14:35.37 .net
>>918
俺も昔10人くらいの零細いたときはそんな感じだったよ。

920 :仕様書無しさん:2016/03/07(月) 00:16:40.34 .net
当たり前の話だけど、マンパワー頼りの管理職は存在理由が無い
開発できないSE(サブエキストラ)も同様に
ただのコスト

921 :仕様書無しさん:2016/03/07(月) 00:19:54.11 .net
>>919
俺が零細に居た時は技術力も管理能力も高い人間しかいなかったから
デスマは一切なかったな

922 :仕様書無しさん:2016/03/07(月) 00:40:57.31 .net
>>908
ググれよ

923 :仕様書無しさん:2016/03/07(月) 02:06:03.18 .net
ttp://www.geocities.co.jp/Playtown-Spade/4804/prog_c5.htm
スタックを破壊して、暴走するプログラムの例・・・

#include<stdio.h>
#include<string.h>

char *foo( void );

main( ) {
char *a;

a = foo( );
puts( a );

}

char *foo( void )
{
char a[] = "ABC";
char b[] = "DEF";

strcat( a, b ); /*文字列の領域を超えてコピーしている*/

return(a); /* returnすべきアドレスを保存したスタックが壊されている
ので、ここから暴走する */
}

924 :仕様書無しさん:2016/03/07(月) 06:31:25.64 .net
どうもSEの人って自分たちの仕事をプログラミングと切り離したがるけど、
海外の人と日本のプログラマーはSEがやっているような設計も
自分たちの仕事だと思ってるんだよね。
SI業界以外では実際にそうなってる。
SI業界だけが特殊。

925 :仕様書無しさん:2016/03/07(月) 06:42:26.42 .net
>>922
キーワード頼むわ

926 :仕様書無しさん:2016/03/07(月) 06:47:02.41 .net
>>923
そんなC言語やってりゃ誰でも知ってる基本中の基本のオーバーフローはどうでもいいから
>>903
>そりゃ最近のVisualStudio開発環境なんかだと
>暴走するようなコードをわざと書こうと思ったって全部コンパイラではじかれるからね
のコードを教えてくれよ

927 :仕様書無しさん:2016/03/07(月) 06:54:18.77 .net
>>926
もう許してやれよ。。。
コンパイルエラーじゃ検知できないよ。

928 :仕様書無しさん:2016/03/07(月) 06:54:30.85 .net
>>926
こんなやつ
http://hpcgi2.nifty.com/natupaji/bbs/patio.cgi?mode=view&no=3046

929 :仕様書無しさん:2016/03/07(月) 07:01:42.50 .net
>>928
それただの非推奨関数だから新しいの使えっていう警告やん
無視しても問題ないコードを書いてりゃそのまま使える
間違った使い方してりゃ推奨関数でも落とす

930 :仕様書無しさん:2016/03/07(月) 07:04:24.92 .net
>>927
C言語も知らん似非SEが開発面で適当なことほざいてると
さすがにね、黙ってられん

931 :仕様書無しさん:2016/03/07(月) 07:05:07.72 .net
ああ言えばこう言うw

932 :仕様書無しさん:2016/03/07(月) 07:20:04.45 .net
>>931
それは通常、屁理屈を言う奴に使う言葉だよね

>>923 >>928
こんな全く答えになってないものを平気でチョイスしてくるアホが自称SEを名乗ってたら
会社で一体何の仕事してんだよと思う、やれる仕事あんのか?
不備もトラブルも全てプログラマが吸収してくれて
辛うじてバランスが保たれてるってところか

933 :仕様書無しさん:2016/03/07(月) 07:55:18.39 .net
むしろVisualStudioで暴走させる例を書いてから家

934 :仕様書無しさん:2016/03/07(月) 08:09:35.63 .net
デスマは上のほうの人たちにはいいことだらけだから野放し?

935 :仕様書無しさん:2016/03/07(月) 08:55:38.92 .net
無能実態派遣残業して時間報酬相場下げるな!
【知的財産と契約料金の搾取促進者ばかり】
[生涯損害助長SI受注SEを追放すべき]
偽装請負従犯SEの動機
コミュニケーション障害
コンピュータ趣味
人格障害
文系大卒
低偏差値大卒
情報処理資格非保有者

偽装請負従犯SEの迷惑
無償プログラム提供
事前面接
契約外期限遵守
客先指示遵守
知的財産譲渡
中間搾取促進
低予備工数見積
時間外労働違反
残業見積
無料追加
学習不足
裁判苦手
対人障害
健康障害
孤独死

偽装請負従犯SEの代償
低収入低技術
非婚離婚
鬱病早死

936 :仕様書無しさん:2016/03/07(月) 10:47:47.36 .net
>>884
マップファイル

937 :仕様書無しさん:2016/03/07(月) 13:37:44.56 .net
>>903
おらさっさと例を書けよハゲ

938 :仕様書無しさん:2016/03/07(月) 14:03:44.48 .net
>>937
自分で考えろ

939 :仕様書無しさん:2016/03/07(月) 14:10:14.66 .net
ホラ吹き>>903

940 :仕様書無しさん:2016/03/07(月) 14:29:02.63 .net
>>903
初期化してない変数が有ると警告が出るとかを言いたかったんだろ?
早く謝っとけ 笑

941 :仕様書無しさん:2016/03/07(月) 21:26:46.23 .net
>>933
誰宛?

942 :仕様書無しさん:2016/03/07(月) 21:57:53.87 .net
まあ>>903は学生かSIerの新人だってことはよくわかったよ
自分の知らないことを適当に書くから頓珍漢な内容になるんだ

943 :仕様書無しさん:2016/03/07(月) 22:00:26.80 .net
PHPしか知らないWeb系の分際でCを語ろうとするからこういうことになる

944 :仕様書無しさん:2016/03/07(月) 22:21:35.48 .net
>>943
>>903はC言語どころかプログラマでもなく
「設計書を書けと言っている作れない自称SE」だぞ
そう、お前だ

945 :仕様書無しさん:2016/03/07(月) 22:32:27.60 .net
おまえら、共通言語基盤(CLI)の上で動くC#などの言語で
なかなかプログラムは暴走せんぞ?

例えば>>911が言ってたこんなコード書いても、スタックを食いつぶしたら
「System.StackOverflowException」を検出してちゃんと止まってくれる。
private void Load(object sender, EventArgs e)
{
  sub(1);
}
private void sub(int a)
{
  sub(a);
}

>>923のC言語みたいにこんなコードも書けないようになってる。
char a[] = "ABC";
char b[] = "DEF";
strcat( a, b );

さあ、さっさとC#でプログラムを暴走させる例を書けw

946 :仕様書無しさん:2016/03/07(月) 22:46:31.47 .net
>>945
> なかなかプログラムは暴走せんぞ?

曖昧な言い方で保険かけてるのダサいなー

947 :仕様書無しさん:2016/03/07(月) 22:50:44.04 .net
>>945
書けるじゃん

VC
CString a = L"ABC";
CString b = L"DEF";
a += b;

C#
string a = "ABC";
string b = "DEF";
a += b;

コンパイルでエラーにしてくれるコードを早く書けよ。

948 :仕様書無しさん:2016/03/07(月) 22:56:33.80 .net
>>945
>「System.StackOverflowException」を検出してちゃんと止まってくれる。
ただの実行中例外じゃん、Cにも例外くらいあるぜ

>>923のC言語みたいにこんなコードも書けないようになってる。
>char a[] = "ABC";
>char b[] = "DEF";
>strcat( a, b );
これは何が言いたいのかさっぱりわからん

>さあ、さっさとC#でプログラムを暴走させる例を書けw
こっちが知りたい、早く「暴走するようなコードをわざと書いて
コンパイルエラーで止めてくれるコード」を早く書けよ

949 :仕様書無しさん:2016/03/07(月) 22:56:59.77 .net
>>947
すごく疑問なんだが、
きみはそれでスタックが壊れると思って書いたのかな?

950 :仕様書無しさん:2016/03/07(月) 22:59:22.09 .net
>948
C#でそのコード書いてみ
な、コンパイルエラーで通らないだろ?

951 :仕様書無しさん:2016/03/07(月) 23:03:31.04 .net
>>949
C#と全く同等のコードをVC++で書いただけだが?

952 :仕様書無しさん:2016/03/07(月) 23:04:28.20 .net
>>950
そりゃ>>945の文法、メッチャ間違ってるからな

953 :仕様書無しさん:2016/03/07(月) 23:06:11.11 .net
>>950
まさかたぁ思うけど、>>950こいつは
VC++とC#を同じ言語と思ってる奴だったりする?

954 :仕様書無しさん:2016/03/07(月) 23:08:46.30 .net
>>948
スタック食いつぶした時点でちゃんと例外で止まってくれる
な、暴走しないだろ
昔ながらの純粋なC言語なら暴走するんだこれが

>>951
つまりそれでスタックが壊れると思ってるわけだねw

>>952-953
御託はいいからC#でコンパイルできて暴走できるコード書いてみ

955 :仕様書無しさん:2016/03/07(月) 23:10:59.84 .net
>>954
string[] a = {"ABC", "DEF"};
a[2] = "GHI";

ごくごく単純な領域外アクセスなのに
まったくコンパイルエラー起きんな

なんで例外の話いきなり始めてんの?

956 :仕様書無しさん:2016/03/07(月) 23:16:39.62 .net
Cの方は処理系は何を想定してんだ?

957 :仕様書無しさん:2016/03/07(月) 23:18:01.77 .net
>>955
コンパイルは通るが、やはり暴走せんね
「インデックスが配列の境界外です」
ちゃんと検出してくれる

958 :仕様書無しさん:2016/03/07(月) 23:18:50.56 .net
>>954
御託はいいからって、>>952は重要だろ
C言語のコードをC#に書いたら文法エラーでコンパイル通りません
あたりめーじゃん

959 :仕様書無しさん:2016/03/07(月) 23:19:34.64 .net
c#でもunsafeとか使えばなんとかなるんじゃね

960 :仕様書無しさん:2016/03/07(月) 23:19:38.18 .net
>>957
だからなんで例外の話をしてんの?
コンパイル時点で止めてくれるって話でしょ?

961 :仕様書無しさん:2016/03/07(月) 23:21:47.87 .net
>>958
だからそれと同等にスタック破壊や暴走できるコードを
C#でコンパイルできるように書いてみ

962 :仕様書無しさん:2016/03/07(月) 23:22:44.01 .net
どうも話を曲げようと必死だから引用しちゃう

>903 仕様書無しさん sage 2016/03/06(日) 23:09:31.56
>そりゃ最近のVisualStudio開発環境なんかだと
>暴走するようなコードをわざと書こうと思ったって全部コンパイラではじかれるからね

>全 部 コ ン パ イ ラ で  は じ か れ る か ら ね

963 :仕様書無しさん:2016/03/07(月) 23:27:27.05 .net
>>961

>903
>暴走するようなコードをわざと書こうと思ったって全部コンパイラではじかれるからね

>904
>そんな暴走するようなコードそもそも書いたことないから知らないわ

俺は知らないと言った、お前が知ってるんだろ?
書け

964 :仕様書無しさん:2016/03/07(月) 23:28:53.67 .net
>>962
おまえのよりどころは「全部」という、たった一レス中のひとことか?

965 :仕様書無しさん:2016/03/07(月) 23:32:58.55 .net
>>963
Cでは何人もの人が書いてるし
C#では難しいつってんだろうが

何を書けと?

966 :仕様書無しさん:2016/03/07(月) 23:35:30.79 .net
>>964
はいはい
>コ ン パ イ ラ で  は じ か れ る か ら ね

967 :仕様書無しさん:2016/03/07(月) 23:36:58.78 .net
>>965
Cでどこに書いた?
俺はCでもコンパイルエラーで止められる暴走コードを一つも知らないんだが

968 :仕様書無しさん:2016/03/07(月) 23:40:17.96 .net
>>965
つまり元々VC++の話をしてたってことだよね
>>903はC#の話じゃないんだよね

969 :仕様書無しさん:2016/03/07(月) 23:46:01.80 .net
>>966
そう、C#はCのような融通がきかず
危険なポインタ操作は文法的にはじかれるな

>>967
おまえはCで暴走するコードを聞いたかったんじゃないのかい?
だからみんな教えてくれてたんだぞw

> 俺はCでもコンパイルエラーで止められる暴走コードを一つも知らないんだが
そんなもん俺も知らんわ
VisualStudioっつってんのに、C言語だと思ったんかいな?

970 :仕様書無しさん:2016/03/07(月) 23:52:36.45 .net
>>969
もう支離滅裂

971 :仕様書無しさん:2016/03/07(月) 23:55:32.84 .net
>そんな暴走するようなコードそもそも書いたことないから知らないわ

この一文見たら 「暴走するコードの例」 を聞きたいと思うよな?
ほぼ10人が10人そう思う
親切に書いていた人たちが不憫だ

972 :仕様書無しさん:2016/03/08(火) 00:07:11.36 .net
>>969
C#でポインタ使うならunsafeだがコンパイラじゃ弾かれないが?

973 :仕様書無しさん:2016/03/08(火) 00:10:56.98 .net
>>969
>暴走するようなコードをわざと書こうと思ったって全部コンパイラではじかれるからね

わかってるからこう書いたんじゃないの?
暴走しまくりだよ、お前が
この世に生まれてくる前にコンパイルエラーにならなかったみたいだな

974 :仕様書無しさん:2016/03/08(火) 00:17:45.10 .net
>>971
>>903-904を普通に読んだら
どう捻くっても絶対にそうは思わないな

975 :仕様書無しさん:2016/03/08(火) 00:19:06.02 .net
>>971
お前だけの誤解が解けたところで、改めて>>903の質問に答えろ

976 :仕様書無しさん:2016/03/08(火) 00:20:36.96 .net
ああ、都合よく勘違いしようとするから、事細かに書かないといけないんだよな

>>903に対する>>904の質問に答えろ

977 :仕様書無しさん:2016/03/08(火) 00:22:37.77 .net
>>973
903を読まずに、その1文だけ読んで
なぜかC言語の例を書き始めたエスパーがいるってことかw

978 :仕様書無しさん:2016/03/08(火) 00:30:44.32 .net
>>972
よくできました
ようやく抜け道見つけたね

>>974
現に俺以外に、親切な人ふたりが暴走コードの例を教えてたが?

では寝るわ、あとはレス読み返せ
おやすみバーイ

979 :仕様書無しさん:2016/03/08(火) 00:30:46.45 .net
第三者視点でみてると粘着気持ち悪すぎるな

980 :仕様書無しさん:2016/03/08(火) 00:44:18.31 .net
>>977>>971宛だ

981 :仕様書無しさん:2016/03/08(火) 00:45:15.71 .net
>>979
第三者視点だとおもしれーけど

982 :仕様書無しさん:2016/03/08(火) 00:49:09.16 .net
>>979
だってプログラマー様だもん

983 :仕様書無しさん:2016/03/08(火) 00:51:14.63 .net
>>979
それはキミが第三者ではなく当事者だからさ

984 :仕様書無しさん:2016/03/08(火) 00:51:49.62 .net
>>983
残念。洞察力ないね。

985 :仕様書無しさん:2016/03/08(火) 00:55:57.29 .net
火消しに必死な903

986 :仕様書無しさん:2016/03/08(火) 10:10:21.02 .net
「システムがアクセスを許していないメモリにアクセス」すると暴走する。
「IOポートに書き込んではいけない値を書き込んでプログラムが暴走する」
では説明できないかな?

987 :仕様書無しさん:2016/03/08(火) 10:14:44.63 .net
>>986
> 「システムがアクセスを許していないメモリにアクセス」すると暴走する。
> 「IOポートに書き込んではいけない値を書き込んでプログラムが暴走する」
> では説明できないかな?

必要条件ではあるが、十分条件では無いな。

988 :仕様書無しさん:2016/03/08(火) 10:19:50.08 .net
アクセス違反でOSからプロセス落とされるのが暴走と言うのか微妙だな。

while(1);
は暴走じゃないのか?

なにを語りたいのかさっぱり分からん。

989 :仕様書無しさん:2016/03/08(火) 14:04:49.13 .net
全部コンパイラではじかれるからね

990 :仕様書無しさん:2016/03/08(火) 14:22:57.21 .net
そりゃこんなレベルの奴がいきなりコード書いたらバグだらけだわ

991 :仕様書無しさん:2016/03/08(火) 18:26:08.87 .net
>>988
暴走じゃねーだろ。
意図してるんなら。

992 :仕様書無しさん:2016/03/08(火) 18:29:48.29 .net
意図して書いたコードなら、そいつの脳が暴走している

993 :仕様書無しさん:2016/03/08(火) 19:23:25.33 .net
19 名前:仕様書無しさん [sage] :2016/03/08(火) 14:59:40.82
料理人「皿で語れ」
ボクサー「拳で語れ」
PG「コードで語れ」
SE「エクセルで語れ」

994 :仕様書無しさん:2016/03/08(火) 19:31:41.24 .net
北朝鮮「チャーハンで語れ」

995 :仕様書無しさん:2016/03/08(火) 23:41:45.07 .net
>>992
このソースコードの60行目、65行目
https://github.com/scanlime/fadecandy/blob/master/firmware/startup.c

while(1); があるが、こいつの脳が暴走してんのかいな?

996 :仕様書無しさん:2016/03/09(水) 02:59:35.75 .net
http://hayabusa6.2ch.net/test/read.cgi/pc2nanmin/1439353617/216
        ↑  ↑  ↑  ↑  ↑ 

997 :仕様書無しさん:2016/03/09(水) 08:13:24.21 .net
告訴の趣旨
 被告訴人は、以下に該当すると考えるので、被告訴人の厳重な処罰を求めるため告訴します。
 職務経歴書を提示した事前面接を実施 または 偽装請負 または 偽装出向
  労働者派遣法第26条(契約の内容等)、職業安定法第44条(労働者供給)に違反
 多重派遣・多重出向
  労働基準法第6条(中間搾取の禁止)に違反
疎明資料
 事前面接日時、場所、出席者、資料のコピー、音声記録
 就業場所・就業期間・就業時間
 指揮命令
  指示を誰が行っているかの記録、音声記録
 仕事で使う道具や、資材の負担(所有)のあり方
  業務で使用しているパソコン・備品などの所有者
 契約書
  請負、雇用契約書、出向指示など書面のコピー

刑事告訴ガイダンス
★和解金の相場は犯罪者の去年の年収の半額です。社長や役員で数千万〜1億円、管理職で500〜1000万円、営業個人については200〜500万円程度。
★痴漢も民事でなく刑事事案ですが、裁判所が和解金を被害者に支払わせて解決するのが絶対的過半数です。和解で解決しない事案、つまり公訴までいって判例となる事例を探すほうが難しいことでしょう。
★録音は一方の当事者が取る限り合法です。※加害者に録音の同意を求める必要はありません。
★告訴状を検察に提出しても受理されなければ加害者側には知られることはありません。不受理の場合は何事も起きてないように粛々と振る舞ってください。
★告訴を取り下げるとき検察に提出した資料は全て返却されます。また検察があなたが提出した証拠をあなたの許可なく裁判の証拠として使用はできません。告訴を取り下げたのちの録音資料には当事者の立場が失われるため証拠能力はありません。
★和解時に告訴した事実は秘匿事項となります。犯罪者が秘密保持契約に違反した場合の損害賠償金は「即決和解」か「公正証書」で最低5000万円〜にしましょう。支払いを拒否すれば強制執行手続きを地方裁判所に上訴(裁判不要)してください。
★派遣会社や事業会社が同業者に情報をリークしたなら競合他社に弱みを握られます。余程信用のおける相手でなければリークはできないでしょう。漏らした方の口が軽ければ事実は分かります。また密告してくれた事業者には損害賠償金の3割を謝礼金として渡してください。

998 :仕様書無しさん:2016/03/09(水) 15:09:26.64 .net
ume

総レス数 998
240 KB
掲示板に戻る 全部 前100 次100 最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★