いきなりコードを書くな。設計してから書け。その3 [無断転載禁止]©2ch.netYouTube動画>1本 ->画像>2枚

0001仕様書無しさん2016/02/04(木) 08:30:55.31

（コード以外の）設計書には、設計の全てが書かれてない。

これが事実ですよ。

もし（コード以外の）設計書に設計のすべてが書かれているのであれば、
その設計通りに作ったのであれば、全く同じものが出来るはず。

しかしその通りにならない。
それはつまり、（コード以外の）設計書には、設計のすべてが書かれていないということ。

じゃあ残りの設計はどこに？というと、それはコードしかありえない。
コードが設計書の全てであり、（コード以外の）設計書には本格的に
設計する前段階で必要な、全体の方針が検討されているだけ。

0002仕様書無しさん2016/02/04(木) 08:32:21.13

前スレ>>1

っていうけどさ、そんなレベルの人が設計を書いても設計が
正しいかどうかなんて判定できないと思うんだが？

だって実装した時に書き直しが必要ない完璧な設計を作らないと
いけないわけでしょ？それって実際に実装できる力がないと無理でしょ？

初心者が設計したとしても、ダメな設計しかできず、
どっちみ書き直しが必要になると思うんだ。

それにさ、設計って言うけど、やってることって設計じゃなくて計画でしょ？
○○と○○と○○を作りますって。

以前作ったものと同じようなものは、
設計は要らず計画だけ立てればいい。

以前作ったことがないものは、頭の中で設計しても完璧なものとならず、
仮実装を経て検証して、やっとその設計が正しいことが実証される。

何か間違ってるかな？

0003仕様書無しさん2016/02/04(木) 08:41:44.22

>>1
コードが自然に現れ、設計として形をなす。

なにこの奇妙キテレツ。

カルトの教祖レベルだな。

0004仕様書無しさん2016/02/04(木) 08:44:29.29

>>3
順番が逆ｗ

頭の中で設計をし、その設計を
設計書（コード）ととして書き出す

0005仕様書無しさん2016/02/04(木) 08:54:11.16

>>4
あんたは常にイコールだと言っている。

ときにはコードが設計書だといい、ときには設計書がコードだという。

だとしたら、順序などなく同時に生まれるということか？

人間は言葉で考える。

おまえは思考なしにコードが発生するとも受け取れる発言をしている。

0006仕様書無しさん2016/02/04(木) 09:10:21.67

>>5
お前は「設計」と「設計書」の区別をつけようなｗ

まあ俺も時々間違ってるかもしれんが。

0007仕様書無しさん2016/02/04(木) 09:14:58.11

>>6
おまえは設計=コードだといい、コード=設計書と言っている。

0008仕様書無しさん2016/02/04(木) 09:16:41.89

無からコードが生まれ、有のコードが、設計に転じる。

どういう理屈か説明してくれ。

0009仕様書無しさん2016/02/04(木) 09:21:24.41

>>7
設計書＝コードだよ。
設計＝コードではない。

頭の中で設計したものを記録したものがコード

0010仕様書無しさん2016/02/04(木) 09:28:52.10

>>9
あんたが言ってるのはスレタイへの反論？

いきなりコードを書くな。設計してから書け。
って主張に対して、コードは設計書でありコードを書くこと自体が設計なんだから事前の設計は不要、と言ってるの？

0011仕様書無しさん2016/02/04(木) 09:30:59.54

>>10
スレタイは前からで関係ねーしｗ

それに設計してからコード（設計書）を書く
スレタイの通りじゃねーかｗ

0012仕様書無しさん2016/02/04(木) 09:31:43.12

設計は頭の中でやるんだよ？

0013仕様書無しさん2016/02/04(木) 09:32:22.49

このスレって俺とお前の2人だけだよな

0014仕様書無しさん2016/02/04(木) 09:34:30.41

>>13
俺もいるけど？

0015仕様書無しさん2016/02/04(木) 09:48:58.65

頭の中で設計してるのに、なんでコード=設計になるのか？

設計のアウトプットがコードだろ？

設計という瞑想をするなら、紙に書いた方がいい。

本当はコードを書きながら、設計も考えてるなんていまさら言わないよな？

0016仕様書無しさん2016/02/04(木) 09:58:13.05

> なんでコード=設計になるのか？

ん？

9 自分：仕様書無しさん[sage] 投稿日：2016/02/04(木) 09:21:24.41
>>7
設計書＝コードだよ。
設計＝コードではない。

あ、>>15の勘違いか。

0017仕様書無しさん2016/02/04(木) 10:01:40.81

コード＝設計書って言われても、で？以外の感想がないんだよな。
コードが設計書だろうとそうでなかろうと、やることは変わらないわけだし。
だからコード＝設計書って一生懸命言ってる人の主張がわからない。

0018仕様書無しさん2016/02/04(木) 10:04:36.54

設計も設計書も同じだろ。

それが違うというのがちゃんちゃらおかしい。

設計書に書いてある設計と実装が違うというなら、さらにプログラム設計でもあるんだろ？

0019仕様書無しさん2016/02/04(木) 10:05:44.07

>>17
キチガイだから遊んでやってくれ。

0020仕様書無しさん2016/02/04(木) 10:09:04.70

コード＝設計書でいいじゃないか？
何でそんなに否定してるんだ？

正論なんだから反論がないならば、
否定しなくていいんだよ。

0021仕様書無しさん2016/02/04(木) 10:18:53.90

糞みたいな禅問答は本当はどうでもいいだがな。
設計書を書けって奴と設計書なんて書いてられるかって奴が衝突してるってのが現実。

それを糞みたいな理屈つけてあほみたいな議論になってるってところだな。

0022仕様書無しさん2016/02/04(木) 10:21:26.12

いきなり○○を書くな。エロ本見てからかけ。

0023仕様書無しさん2016/02/04(木) 10:23:59.33

>>21
だからコードが設計書なんだって、
設計書は書いている。

設計書の前段階の方向性を決めるものは
やる必要があるときだけやればいい

0024仕様書無しさん2016/02/04(木) 11:28:59.18

>>15
> 本当はコードを書きながら、設計も考えてるなんていまさら言わないよな？

事前に全てのことを考えるなんてできない。
できるというなら、これから書くコード全てを事前に決めることになり、つまりは
まずコードを書いて、書き終わったら設計終了ということになる。

そんなことはできないので、「設計」はある程度で終えて、コードを書く。

その「ある程度」が人によって違う。
事前に全体の10%程度を考えて、一気に3000行のコードが書ける人もいれば、
100行のコードを書くために、80%程度まで考えないと書けない人もいる。

0025仕様書無しさん2016/02/04(木) 12:21:35.02

コード=設計君が言ってることは実装に間違いはなく自分が脳内にあるものが仕様だってことだよね。
ほんとゴミだわ。個人に依存しないシステムにする気がまったくない。資料を作らずに肝な部分は自分しかわからないようにして雇用を確保しようと必死なんだろうな。

0026仕様書無しさん2016/02/04(木) 12:31:34.31

ゴミというかただの馬鹿

0027仕様書無しさん2016/02/04(木) 12:43:14.13

int main(void){printf(STRING);return 0;}

これの設計書書いて

0028仕様書無しさん2016/02/04(木) 12:50:37.67

>>25
> 資料を作らずに肝な部分は自分しかわからないようにして雇用を確保しようと必死なんだろうな。
普通はコードを読めば何やってるかわかります

0029仕様書無しさん2016/02/04(木) 12:59:05.10

コードレビューでなにやってるのかわからないレベルのコードだったらrejectするか保守用資料書かせればＯＫ

0030仕様書無しさん2016/02/04(木) 13:07:54.57

>>25
> コード=設計君が言ってることは実装に間違いはなく自分が脳内にあるものが仕様だってことだよね。

なんでそこで仕様の話が出てくるんだ？仕様と設計の違いがわかってない。

仕様書が合って、設計を頭で考えて、そして設計書（コード）を書くんだよ

0031仕様書無しさん2016/02/04(木) 13:11:21.83

>>28
> 普通はコードを読めば何やってるかわかります
しかも資料が役に立たないから
コードから設計や仕様を作り出すツールとかあるよなｗ

TERASOLUNA Reengineeringは、ソースコードから設計書を生成するソリューションです。
http://www.terasoluna.jp/product/tool/reengineering.html

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

0032仕様書無しさん2016/02/04(木) 13:13:08.73

命題においての「逆」も真だと思ってる奴が、いつまでたってもぐちぐち言うスレ

0033仕様書無しさん2016/02/04(木) 13:16:26.82

仕様を満たす設計を脳内で考えてコードにアウトプットするという
ごく単純なことが理解できないというのが理解できない。

0034仕様書無しさん2016/02/04(木) 13:16:52.25

だよな、コードを先に書くことの問題が～って言ってる理由は
結局（コードではない）設計書を先に書くことにも当てはまってる。

（コードではない）設計書は設計を最初に全部考えてから書くのか？
いや違う。設計を考えながら（コードではない）設計書を書くし
なんども（コードではない）設計書を修正する。

それはコードである設計書でも同じ。逆も真なのだ。

0035仕様書無しさん2016/02/04(木) 13:19:34.87

最終的にコードは動く状態になるが、途中の段階では、
コードである設計書は必ずしも動く必要はない。

設計書だっていきなり誤字脱字を直した
見栄えのいいものを作るわけじゃないだろう？

ざっと設計して、ざっと設計書（コード）を書いて
設計書は動かなくてもいいものなんだから、
そこでレビューをしてもいい。

最終的に清書して動くコード（設計書）にすればよい。

0036仕様書無しさん2016/02/04(木) 13:19:43.28

コードを書きながら変数名を考えるのも設計
ループをforでするのかwhileかforeachか考えるのも設計
ちょっと複雑になったからメソッドに抽出しようと考えるのも設計
いや、クラスに抽出しようというの設計

0037仕様書無しさん2016/02/04(木) 13:24:04.28

ひどい話：「詳細設計書にクエリの内容全部書け」

0038仕様書無しさん2016/02/04(木) 13:25:14.35

>>37
まさにコード（設計書）読めって案件だなｗ

0039仕様書無しさん2016/02/04(木) 13:30:36.16

スレも変わったし、そろそろ書いておこうか。

前スレ >>54
> > たとえ話がまだ残ってるんだ(しかも曲解されて)。
> 曲解されてというのなら、
> 曲解しない解釈を知っているのだろう。
> それを聞こうか？ｗ

SEが設計書を書いて、プログラマはその設計書通りにプログラムを書けばいいんだから
プログラマには高いスキルは必要ないと言われてた時代があったのよ。
ソフトウェア工場とか言って、工場でプログラマが働けばまるで既存の工業製品みたいに
ソフトを作ることができると言われていた時代ね。
それに対して
「プログラミングは『既存の工業製品に喩えれば設計を行なっているようなもの』だから、
　プログラマに高いスキルが必要ないというのは間違いだ」
という反論が行われたのね。

これで分かるとおり、コーディング＝設計書とも言ってないし、コーディングする前に設計が必要ない
とも言っていないんだけど、曲解するひとはいるんだなぁ。

0040仕様書無しさん2016/02/04(木) 13:31:41.09

>>39
その反論の出典を教えて下さい。
でないと曲解している根拠にすらなりえません。

0041仕様書無しさん2016/02/04(木) 13:41:16.08

>>39
> ソフトウェア工場とか言って、工場でプログラマが働けばまるで既存の工業製品みたいに
> ソフトを作ることができると言われていた時代ね。
そんな時台はありません。

0042仕様書無しさん2016/02/04(木) 13:43:47.47

>>39
> これで分かるとおり、コーディング＝設計書とも言ってないし、コーディングする前に設計が必要ない
> とも言っていないんだけど、

誰が？お前が？

0043仕様書無しさん2016/02/04(木) 13:46:25.54

>>39
ちょっと何を議論したいのかわからんが、前半部分に関しては、いつの時代もそういう妄想を抱く奴がいた/いるというだけの話。
今でもいるでしょ。人月いくらで買う方の人間で。

0044仕様書無しさん2016/02/04(木) 13:46:35.29

>>41
もしかしたら、生まれてなかったかもねー

0045仕様書無しさん2016/02/04(木) 14:11:56.85

もりあがってますね

0046仕様書無しさん2016/02/04(木) 14:28:48.83

>>44
ソフトウェア工学の話なら多分俺の方が詳しいと思うが、何年頃のどこの話なんだ？

そういう提唱や提言を行ったり、実際実践した人/会社もいたが、
> ソフトウェア工場とか言って、工場でプログラマが働けばまるで既存の工業製品みたいに
> ソフトを作ることができると言われていた時代
そのような時代が存在したとは知らない。

0047仕様書無しさん2016/02/04(木) 14:31:06.72

同じものを作る工業製品とは全く違いますからね。
ソフトウェアは同じものを作る必要が無い。

0048仕様書無しさん2016/02/04(木) 14:32:19.65

完璧な設計なんてないし、むしろコード書いてて設計の矛盾に気づくことが多いくらいだから、そういう時に設計側にFBしてやればいいんじゃねーの。

そういう意味で自社で両方やってるとコミュニケーションコスト下がって仕事が進むことに最近気づいた。

以前いたとこは設計別会社で、表現が曖昧な箇所の詳細を聞きに行ったりすると露骨に嫌な顔されることあって最悪だった。

0049仕様書無しさん2016/02/04(木) 14:32:54.05

>>46
できると言われていた時代ですからね。
できてた時代と違う。

0050仕様書無しさん2016/02/04(木) 14:39:09.36

>>49
そういう回答は期待していません。

何年ごろのどこの話ですか？

0051仕様書無しさん2016/02/04(木) 14:40:28.34

>>48
> そういう時に設計側にFBしてやればいいんじゃねーの。
次第に面倒になるよ。

コードではない設計書は修正コストが大きい。
コードは動かさないといけないから、絶対に適切な場所を修正することになるが、
コードではない設計書は修正漏れがあっても動作に影響はないし
どこを修正すればいいか解らない。資料が多ければ多いほど
目を通さなければいけない量が多くなって修正が大変になる。

だから（コードではない）設計書は簡単な概要のみをやって
出来る限りコード側に持ってきたほうがいい。

0052仕様書無しさん2016/02/04(木) 14:41:52.90

>>49
> プログラマには高いスキルは必要ないと言われてた時代があった

じゃ、こっちはいつ頃のどこの話なんだ？

0053仕様書無しさん2016/02/04(木) 14:58:38.87

>>39
コーディング＝設計(書)と言ってる(思っている)人はそれほどめずらしくない。
むしろ共感するプログラマの方が多いんじゃないかとすら思う。

まぁこれでも読んでよ。

What is Software Design?
by Jack W. Reeves
cC++ Journal - 1992
http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

探せば日本語訳もあるかもね。

0054仕様書無しさん2016/02/04(木) 15:00:55.72

ググったら、日本語訳あったわ。

ソフトウェア設計とは何か？
http://web.archive.org/web/20080803072849/www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

0055仕様書無しさん2016/02/04(木) 15:01:31.19

地球が何回回ったときなんだ？

0056仕様書無しさん2016/02/04(木) 15:04:02.03

>>54
これと一緒かな？
http://knagano.tumblr.com/post/11941519742/

魚拓にもあった
http://megalodon.jp/2008-0719-2309-27/www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

0057仕様書無しさん2016/02/04(木) 15:10:30.66

>>53
コーダーには気分のいい内容だからね。

0058仕様書無しさん2016/02/04(木) 15:15:50.42

こういうページもあるね。

The Source Code Is The Design
http://c2.com/cgi/wiki?TheSourceCodeIsTheDesign

> A software developer is more akin to an artist than an assembly line worker, since they are designing in writing source code.

> The position of the article was not that source code makes all other documentation obsolete, it is simply that the act of programming is designing.

0059仕様書無しさん2016/02/04(木) 15:16:10.37

ほう、つまり君には気分悪い内容だったのかな？ｗ

まあ元が英語の文章だからね。
日本みたいにコーダーなんて居ない。

0060仕様書無しさん2016/02/04(木) 15:17:27.85

>>57
くらいの感想を返すしかもうできませんか。

0061仕様書無しさん2016/02/04(木) 15:29:49.47

つか、「設計」が意味するところ摺り合わせから始めないと、話が通じないのでは。

0062仕様書無しさん2016/02/04(木) 15:31:56.04

>>57はアイデンティティーが崩壊しかねないから>>53は読まないほうがいい

0063仕様書無しさん2016/02/04(木) 15:56:46.91

それでもなお、このスレの他者より自分の方が優れていると思っている>>57なのであった。

0064仕様書無しさん2016/02/04(木) 16:02:57.17

>>61
> つか、「設計」が意味するところ摺り合わせから始めないと

少なくとも自分の世界だけの設計やだめだよね。
入った会社がそうやってましたーとか
そんなのじゃだめ。

0065仕様書無しさん2016/02/04(木) 16:18:44.87

詳細設計書という文化のおかげで、みずほの20万人月でうるおう奴も出てくるんです。

0066仕様書無しさん2016/02/04(木) 16:27:37.44

そうだ
世の中穴を掘って埋める仕事で生計を立ててる人が山ほどいるんだ
詳細設計書は必要悪

0067仕様書無しさん2016/02/04(木) 16:47:01.28

そういう案件しかできない自分をなんとかした方がいいと思う。

0068仕様書無しさん2016/02/04(木) 17:11:13.30

できの悪いbotみたいだな。

0069仕様書無しさん2016/02/04(木) 18:34:33.70

「コーディング＝設計」で発狂

0070仕様書無しさん2016/02/04(木) 18:42:02.08

なぜこうしたのかまったくコードから読み取れないコードを作るのが、コード=設計くん。

0071仕様書無しさん2016/02/04(木) 18:56:26.32

ということにしたい

0072仕様書無しさん2016/02/04(木) 19:23:49.64

>>28
半日で作れるような小さいプログラムの話はしてないんで

0073仕様書無しさん2016/02/04(木) 19:32:40.50

普通はコード組まなくてもどう処理するかわかるから設計書を書いて他の人間に渡して作らせるわな。
変数名とかSQLをかいた設計書(？)の存在は知らん。
設計書いらん派はひとりで作る前提なのか？

0074仕様書無しさん2016/02/04(木) 20:37:44.81

ソースコードは人が読むためにある
たまたまコンピューターで動くにすぎない

なんて言葉が俺は好き

0075仕様書無しさん2016/02/04(木) 20:44:36.45

>>73
> 設計書いらん派はひとりで作る前提なのか？

だからコードが設計書だって。
設計書はいるよ。コードなんだから。

コードじゃない設計書の話なら、複雑なところだけ
全体の方向性を決めるために資料を用意すればいいだけ。

全部のコードではない設計書なんていらん。

0076仕様書無しさん2016/02/04(木) 21:10:41.84

>>72
君は半日でどれくらいのものが作れるの？
経験者同士でさえ生産性に100倍以上の差があるような業界なのに
君の100倍の生産能力がある人が半日仕事したらどんな規模になるだろうね

0077仕様書無しさん2016/02/04(木) 21:17:27.11

>>75
> 設計書いらん派はひとりで作る前提なのか？
設計書は一人で作る前提なのか？

みんなで担当に分けて設計すればいいだろ。
バラバラにならいように、みんなで話し合い
ルールを決めて、相互にコードレビューして。

0078仕様書無しさん2016/02/04(木) 21:24:05.31

>>77
結局、直してんじゃねえかw

0079仕様書無しさん2016/02/04(木) 21:26:11.53

設計書がないせいで、何度も書き直しているコード=設計くん。

0080仕様書無しさん2016/02/04(木) 21:26:57.49

0081仕様書無しさん2016/02/04(木) 21:27:44.21

コードは他の製造業なんかで言うところの設計書であって、ソフトウェアの世界ではコードはコード、設計書は設計書なんだから、
混ぜて話されるとめんどくさすぎ。
俺はコーダーじゃない設計者だ、ってプライドアピールしたいだけにしか見えないわ。

0082仕様書無しさん2016/02/04(木) 21:28:04.95

>>79
お前、一回でコードではない設計書を書き上げてるのか？
コードではない設計書も書き直すだろ。

自分で何を言ってるのかわかってないな。
逆もまた真なりって上のほうで書いただろ。
その意味もわかってなかったか。
書き込む前にその逆を考えろってことだよ。

0083仕様書無しさん2016/02/04(木) 21:30:17.67

エクセルで設計書を書くと、修正のたびに
幅調整という、大変な仕事が発生するんだよねｗ

幅調整することが仕事だと思ってたりしてｗ

0084仕様書無しさん2016/02/04(木) 21:33:00.60

>>79
一発でコードに書き起こせる設計書を
お前は一切の書き直しもなく一発で書けるのか、すっげえ

0085仕様書無しさん2016/02/04(木) 21:36:31.90

>>84
おまえの理屈だと頭の中で考える分には修正ではないんだろ？

0086仕様書無しさん2016/02/04(木) 21:39:25.98

プログラミングは人によって100倍も生産性に差があるという。

コードが設計書だと認められない人は、コードが書けない人。
つまり1/100の生産性だから、コードを書くのに時間がかかるのだろう。
だからコードではない設計書だけをやろうとするわけだ。

だがコードは設計書なのだから、設計の速さも1/100なわけで、
そういう人に重要な設計をまかせてはいけない。

それにもかからわずプロジェクトが成功したとしたら、理由ははっきりと分かる。
コード＝設計書なわけで、設計の大部分はプログラマがやっているから
なんとか持ちこたえることが出来る。

0087仕様書無しさん2016/02/04(木) 21:40:25.24

>>85
設計案を3パターン用意するのは、
作りなおしに入るんですか？ｗ

0088仕様書無しさん2016/02/04(木) 21:51:24.84

>>86
設計書を必要としてる人と比較したら1000倍以上の差は出るんじゃないか？

0089仕様書無しさん2016/02/04(木) 21:52:04.22

コード=設計から、またコード=設計書だって。

ぶれまくり。

コードが設計書なら、設計書と言って他人にソースコード渡してみろよw

0090仕様書無しさん2016/02/04(木) 21:54:26.07

>>83
ごめん、意味が分からない
幅調整って何を？

過去何年もくだらない"Excel方眼紙の仕様書"を作成・修正してきたけど、
幅の調整って何か分からないヨ

0091仕様書無しさん2016/02/04(木) 21:57:50.43

どうでもいいが
エクセルの縦と横の幅設定の単位が違うのがいつもイラつく

0092仕様書無しさん2016/02/04(木) 22:00:35.09

>>90
Excelの操作に慣れてない、Excelでのドキュメンテーションの経験不足だから、相手にしない方がいい。

0093仕様書無しさん2016/02/04(木) 22:01:11.27

>>85
俺の理屈ってなに？
俺は>>79の超人ぶりに感心しただけだけどー

まあ設計にブレはないよな
だからこそ設計書をあえて書く必要がないわけで

0094仕様書無しさん2016/02/04(木) 22:03:12.93

>>93
おまえ、仕事してないだろ？

0095仕様書無しさん2016/02/04(木) 22:06:58.15

>>94
設計書を書くという無駄な給料泥棒のような作業を仕事というならしてないね

0096仕様書無しさん2016/02/04(木) 22:08:14.14

俺の設計はぶれない。
間違などない。これでやれ。
出来ないはずなどない。

なぜなら書いてない所は自由だからだ

0097仕様書無しさん2016/02/04(木) 22:11:18.26

設計書が必要な奴って、まず思考範囲が狭い。
だから書かないと忘れる。

次に客観的思考ができない。
常に主観で考えるから設計もゴミだし
>>79みたいに自分に跳ね返ってくる未来が予測できない。

0098仕様書無しさん2016/02/04(木) 22:11:53.29

>>96
そんなに羨ましがるなよ

0099仕様書無しさん2016/02/04(木) 22:13:17.41

思考範囲が狭いから書かないと広げることができない
記憶力が乏しいから書かないと忘れる、だね

0100仕様書無しさん2016/02/04(木) 22:21:52.18

また派遣コーダか

0101仕様書無しさん2016/02/04(木) 22:25:23.10

誰がコーティングレベルまで落とし込んでいると思ってんのかね。

0102仕様書無しさん2016/02/04(木) 23:06:57.52

>>100
コーディングできる派遣さんに設計やって貰った方が
あんたの設計より何倍も優れてると思うよ

0103仕様書無しさん2016/02/04(木) 23:16:11.54

うわぁ

0104仕様書無しさん2016/02/04(木) 23:34:23.86

図星だったらしい

0105仕様書無しさん2016/02/04(木) 23:40:18.56

実際に派遣だった俺に丸投げしてきた現場はあったよw

0106仕様書無しさん2016/02/04(木) 23:46:05.24

きめえｗｗｗ

0107仕様書無しさん2016/02/04(木) 23:47:14.91

>>99
linux 規模になったら詳解 Linuxカーネルあった方がコードは読み易いよ。
確かに意味のない「設計書」と呼ばれるものが多い事は否定しないが。

0108仕様書無しさん2016/02/05(金) 01:46:31.61

>>86
バカ、逆だ。動作みながらじゃなきゃ設計ができないのがコードイコール君。机上でも設計できるほうが有能にきまっている。

0109仕様書無しさん2016/02/05(金) 01:48:40.68

派遣コーダーが上流工程に嫉妬するだけのスレ

0110仕様書無しさん2016/02/05(金) 03:58:47.22

>>107
> linux 規模になったら詳解 Linuxカーネルあった方がコードは読み易いよ。

読みやすい資料の存在は、コードは設計書ではない
という根拠にはならないんだがな。

コード（＝設計書）を理解しやすくするための図ですからね。

0111仕様書無しさん2016/02/05(金) 04:00:51.05

>>108
初心者は動きを見ながら、上級者は頭の中で考える。
そして記述するコードは設計書。

コードが設計書であること反論をお前はしていない。

0112仕様書無しさん2016/02/05(金) 06:20:48.51

>>105
派遣を雇う会社は、工場のラインのように簡単な仕事か
逆に難しくて仕事ができない人しかいない職場だからのほぼ二択だからね

0113仕様書無しさん2016/02/05(金) 06:56:28.46

>>112
現役派遣の俺が知ってる限り
1. 簡単だから社員にやらせず派遣がやる
2. 難しくて社員ができずに派遣がやる
3. 色々と職場が変だから社員が定着せずに派遣がやる
の3パターンかな

1.は時給も安くて毎日定時、時短も可 => 楽だけど超つまらん
2.はピラミッド最上層のSIerとか有名企業 => OSS、インターネット禁止などの糞ルール
3.はWeb系の怪しい中小企業 => 社員の目が死んでる、テストいい加減ｗ

0114仕様書無しさん2016/02/05(金) 07:29:12.04

ブラックの烙印が付いた会社に良い人材は応募してこないし
良い人材ってのが今の世の中ほとんどいなくて希少な存在だし
最後はどんなにブラックでも出してくれる派遣会社に頼るしかないんだよね
そして派遣社員にも見限られて辞めていく

0115仕様書無しさん2016/02/05(金) 08:08:02.82

※ブラック社員の感想です。

0116仕様書無しさん2016/02/05(金) 08:27:20.64

①コードもかけて設計に携わる。設計書を作る。
②コードはかけないが設計に携わる。詳細設計書を強要する。
③コードを書くのが専門。設計スキルもある。
④コードを書くのが専門。設計することはないができると信じている。

このスレは②に強い恨みをもつ④が①に噛みついてるようにみえる。

0117仕様書無しさん2016/02/05(金) 08:29:48.58

>>166
真実はどっちか？
お前がいま噛み付いたのが証拠だよ。

0118仕様書無しさん2016/02/05(金) 08:30:31.83

参照レスもできないのかw

0119仕様書無しさん2016/02/05(金) 08:36:41.38

>設計書がないせいで、何度も書き直しているコード=設計くん。

一日かけて書いたコードをすてることはあるよ
また、設計図をかいても書き直すとはある
合理性の前には、労力を捨てる

0120仕様書無しさん2016/02/05(金) 08:40:13.83

>>119
どんなクラス構造にするかの設計は脳内にしかないの？
クラス図やシーケンス図もいらない派だっけ？

0121仕様書無しさん2016/02/05(金) 08:51:32.49

>>120
クラス図やシーケンス図を書いたからって
コードが設計書ではないことの根拠にはならない。
それらが概要の設計で、コードが完全な設計だってだけのことだ。

0122仕様書無しさん2016/02/05(金) 08:57:44.47

クラス図の話で言えば、クラス図には
public、private、protected、packageという4つの可視性があるが、
それはコードで書いているから十分でありクラス図には一部のみを書けばいい。

privateなどまで含めてコードで書くもの全てをクラス図に書くのは馬鹿げている。
長ったらしくて見づらい図、何を目的とした図なのか？
それを理解していれば、一部だけ書けばいいのは自ずと明らか。

この意見には賛成するだろう？　これに対する反論をするというのなら、話は別だが、
クラス図に書くのは、メソッドクラス変数の一部であることからわかるように
設計の一部しか書いていないということになる。

では残りの設計はどこに書いている？
それがコードだよ。コードは設計書。

0123仕様書無しさん2016/02/05(金) 11:33:31.70

>>90
> ごめん、意味が分からない
> 幅調整って何を？
列の幅調整。
Excelで設計書を書かせるような所は印刷することを要求するが、プレビューではセル内で
折り返されたものが実際に印刷するとさらに一行改行されて切れてたりする。

ということが10年前くらいまでExcelでテスト仕様書を作ってたりしたときに発生してたが、
今でもそうなのかもしれん。

0124仕様書無しさん2016/02/05(金) 11:35:04.64

>>122
コードレビューでクラス図とコードを見比べ、クラス図にないクラスがあると怒られるという悪夢。

0125仕様書無しさん2016/02/05(金) 12:45:39.75

＞クラス図の話で言えば、クラス図には

クラス図というのは各クラスの関係図のことだよ。
素人は設計のこと、かたるなーだ。

各クラスは
Viewのクラス、Form1のクラス(コントロール）、モジュールが集まったクラス
という具合だ。

俺は前で三つのクラスを述べたが、こういう分け方を何と呼ばれているか？　
知っているかな

0126仕様書無しさん2016/02/05(金) 12:47:39.83

>>125
だがそんなのじゃ、同じ設計から同じコードは出来ない。
なぜならメソッドなどが全て書かれていないからだ。

つまりはコードに残りの設計が書かれており
コードは設計書ということなんだよ。
わかるかな？

0127仕様書無しさん2016/02/05(金) 12:50:28.38

あれ？誰でも同じものが作れる論者だったのか。だからこんなキチガイじみた考えしてるんだな。ふに落ちたわ。

0128仕様書無しさん2016/02/05(金) 12:58:47.66

設計通りに作らないのは問題外だが、設計通りに作ったのであれば誰でも同じものになる。
どんな業界でもそれは一緒だ。当たり前だろう。

0129仕様書無しさん2016/02/05(金) 13:12:34.14

>>125
なにかのギャグですか

0130仕様書無しさん2016/02/05(金) 13:13:51.09

ギャグじゃなくて釣り

0131仕様書無しさん2016/02/05(金) 13:20:14.98

このスレにあまりにレベルの低い奴が混じってて、マジなのか釣りなのか判別不能

0132仕様書無しさん2016/02/05(金) 13:21:04.65

>>128もマジなのか釣りなのか判定不能

0133仕様書無しさん2016/02/05(金) 13:25:42.30

>>132
反論できるならしてみていいんだよ

0134仕様書無しさん2016/02/05(金) 13:27:03.28

>>128
そんなわけがない。

0135仕様書無しさん2016/02/05(金) 13:31:54.78

>>133
FizzBuzzで誰が書いても同じになる設計書いてみろよ

0136仕様書無しさん2016/02/05(金) 13:33:33.71

>>135
FizzBuzzというだけなら仕様だけど？

設計書＝コードなので、コード通りに作ったら
誰でも同じものになるよ。

0137仕様書無しさん2016/02/05(金) 13:34:02.32

どうせ、「俺が言う同じはコードが同じになることではない。結果が同じになることだ」とか言い始めるんでしょ。

つまり、釣り。

0138仕様書無しさん2016/02/05(金) 13:35:22.36

神聖かまってちゃん

0139仕様書無しさん2016/02/05(金) 13:36:19.89

レベルが低いと言うより、もはや頭がおかしいレベル

0140仕様書無しさん2016/02/05(金) 13:40:49.87

コード＝設計だからこそ、同じ仕様でも人によってその内容が異なるんだが

0141仕様書無しさん2016/02/05(金) 13:43:09.05

>>137
お前誰にレスしてるの？

コード＝設計書であって、コードをまるまる書き写せば（意味が無いことだが）
まったく同じこと物ができる。

設計書通りに作れば、同じものが出来るということはこういうこと。

コードではない設計書だけみても同じものは出来ない。
だからそのコードではない設計書は、完全な設計書（コード）の簡易版でしかなく
それだけでは設計書として足りないって話なんだけど。

0142仕様書無しさん2016/02/05(金) 13:44:55.52

>>140
そうそう内容が異なるから、コード書いている人が
それぞれ設計しているわけ。

完璧な設計書があって、その設計書通りに作れば
誰でも同じものが出来る。

作れないならば、設計書として足りないということ。
それぞれ内容が異なるものが出来るということは、
足りてないという話。

0143仕様書無しさん2016/02/05(金) 13:50:09.80

>>141
> それだけでは設計書として足りないって話なんだけど。
コードが書けるだけの設計書であれば十分だが？

0144仕様書無しさん2016/02/05(金) 13:55:00.77

>>143
じゃあ何もなくても、コードかけるなｗ

0145仕様書無しさん2016/02/05(金) 13:56:13.52

コード＝設計書と考えると、何もなくても
コードが書けるというのは、すごく腑に落ちるわけよ。

0146仕様書無しさん2016/02/05(金) 13:56:53.55

>>144
お前は書けないの？

0147仕様書無しさん2016/02/05(金) 13:57:48.83

>>146
そりゃかけるでしょｗ
コード＝設計書という前提だと

0148仕様書無しさん2016/02/05(金) 13:59:03.60

>>143
引用の仕方がわざとらしすぎ

> コードではない設計書だけみても同じものは出来ない。
> だからそのコードではない設計書は、完全な設計書（コード）の簡易版でしかなく
> それだけでは設計書として足りないって話なんだけど。

コードではない設計書だけを見ても同じものは出来ないから、
コードではない設計書は、設計書ととして足りないって話。

0149仕様書無しさん2016/02/05(金) 14:00:24.15

何度ループさせれば気が済むんだ
そんな前提などなくとも、仕様さえ固まっていればコードは書ける

0150仕様書無しさん2016/02/05(金) 14:02:05.29

>>148
誰が見ても同じものが出来ないと設計書じゃないの？

0151仕様書無しさん2016/02/05(金) 14:04:26.71

映画とかで設計書を盗むって話があるけど、
それは設計書があれば同じものが作れるからなわけで、

ソフトウェア業界だと（コードではない）設計書を盗むといわれても
そんなの盗んでどうするんだとしか思わないなｗ
もっともコード＝設計書という意味だとして、コードを盗まれたら大変なことになるけど。

0152仕様書無しさん2016/02/05(金) 14:04:41.38

>>148
> コードではない設計書だけを見ても同じものは出来ないから、
> コードではない設計書は、設計書ととして足りないって話。
一体何を主張したいんだ。

「足りてる」設計書はコードのみである

って主張したいのか？

0153仕様書無しさん2016/02/05(金) 14:05:01.79

>>150
そうだよ。だから映画とかでスパイは設計書を盗むの
同じものを作るためにね。

0154仕様書無しさん2016/02/05(金) 14:05:55.94

仕様を先に聞いてくるな
まず動くものを見せろ　要件もデザインも
話はそれからだ（実話）

0155仕様書無しさん2016/02/05(金) 14:07:05.83

>>152
コード＝設計書って主張をしてる。

そこから発展して、
いきなりコード（＝設計書だから）を書くのも間違ってないし、
（コードではない）設計書にムダなことをずらずら書くのは意味が無い
って主張をしている。

必要なところだけやればいいんですよ。コードではない設計書はね。
どうせコード（＝設計書）は書くのだから。

0156仕様書無しさん2016/02/05(金) 14:08:03.25

>>155
何言ってんの？
コードが書けるだけの設計書があれば十分だろ？
何回言わせるの？

0157仕様書無しさん2016/02/05(金) 14:10:38.80

>>156
だから変な引用をするなって。

> コードではない設計書だけみても同じものは出来ない。
> だからそのコードではない設計書は、完全な設計書（コード）の簡易版でしかなく
> それだけでは設計書として足りないって話なんだけど。

コードではない設計書だけを見ても同じものは出来ないから、
コードではない設計書は、設計書ととして足りないって話。

0158仕様書無しさん2016/02/05(金) 14:10:44.46

そこのお二人は、単語の定義書を出してないから食い違ってもめてるんですなｗ
あるある

0159仕様書無しさん2016/02/05(金) 14:10:58.80

>>155
お前の主張、すでに1992年にC++ Journalの記事になってたぞ

0160仕様書無しさん2016/02/05(金) 14:11:41.83

>>156
お前の主張は何？

今話をしているのはコード＝設計書であるって話なんだが、

まず前提として、お前の意見は
コード＝設計書でいいんだよな？

0161仕様書無しさん2016/02/05(金) 14:12:08.89

>>159
知ってる。その記事は正しい。

0162仕様書無しさん2016/02/05(金) 14:17:55.99

>>160
「コード＝設計書」に関してなら、お前がそう言いたいのなら別に否定はしない

俺はてっきり「コードを書き始める前の設計（書）」について話してると思っただけだ

0163仕様書無しさん2016/02/05(金) 14:19:22.92

付け加えるなら

> だからそのコードではない設計書は、完全な設計書（コード）の簡易版でしかなく
> それだけでは設計書として足りない
その通りだが、だからといってその設計(書)が不要というわけではない

0164仕様書無しさん2016/02/05(金) 14:20:09.30

>>162
じゃあお前の勘違いだ。

コード＝設計書という話をしている。
それ以外に設計書がないという話はしていない。

コード以外の設計書は無くてもいいが、必要なところだけ作ればいいもの。

作業依頼書のように、渡してこれをこの通り作れというものじゃない。
どうせ作業依頼書には大したことは書かれていないのだから
大部分はプログラマが設計して設計書（コード）を書いているのだ。

0165仕様書無しさん2016/02/05(金) 14:21:07.84

>>163
> その通りだが、だからといってその設計(書)が不要というわけではない
大部分は不要。概略で十分。今は作りすぎている。
無くても作れるならば当然必要ないもの。

0166仕様書無しさん2016/02/05(金) 14:21:27.97

>>164
だったらageてた一人を除いてお前に反論する奴はいないんじゃ？

0167仕様書無しさん2016/02/05(金) 14:22:29.28

>>165
お前の視野内に作りすぎてる奴がいるってだけでしょ

0168仕様書無しさん2016/02/05(金) 14:27:21.03

>>166
反論ないならば、レスしていないはずだ。

反論してくるから、あぁ、こいつはコードが設計書だって
理解してないんだなと思っただけ。

コード＝設計書に反論しないならレスしなくていいよ。

0169仕様書無しさん2016/02/05(金) 14:32:06.22

>>168
俺の反論ポイントはそこじゃなくて
> コードではない設計書は、設計書ととして足りないって話。
で、足りてないから何？ってことだったんだが、ま、どうでもいいか

0170仕様書無しさん2016/02/05(金) 14:37:23.09

>>169
> で、足りてないから何？
話の流れが逆。

それは理由。答えは最初に書いた。

コードは設計書である。（答え）
本来設計書というものは設計書通りに作れば同じものが出来るものだ。

しかし、コードではない設計書だけみても同じものは出来ない。
だからそのコードではない設計書は、完全な設計書（コード）の簡易版でしかなく
それだけでは設計書として足りないということだ。

と理由を述べたのに、最後だけ抜き出して、
最初に言った答えを聞くな。

0171仕様書無しさん2016/02/05(金) 14:38:20.59

>>170
> 本来設計書というものは設計書通りに作れば同じものが出来るものだ。
という前提が間違ってるんだが

0172仕様書無しさん2016/02/05(金) 14:38:45.50

>>171
間違ってない。

0173仕様書無しさん2016/02/05(金) 14:40:37.81

>>172
じゃ、お前の主張通りのブログでも論文でも良いが紹介してくれよ

0174仕様書無しさん2016/02/05(金) 14:42:30.53

>>173
コードは設計書である。という論文では駄目かね？
本当に言いたいことは、コードは設計書である。ということだ。

54 名前：仕様書無しさん[sage] 投稿日：2016/02/04(木) 15:00:55.72
ググったら、日本語訳あったわ。

ソフトウェア設計とは何か？
http://web.archive.org/web/20080803072849/www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

55 名前：仕様書無しさん[sage] 投稿日：2016/02/04(木) 15:01:31.19
地球が何回回ったときなんだ？

56 自分：仕様書無しさん[sage] 投稿日：2016/02/04(木) 15:04:02.03
>>54
これと一緒かな？
http://knagano.tumblr.com/post/11941519742/

魚拓にもあった
http://megalodon.jp/2008-0719-2309-27/www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

0175仕様書無しさん2016/02/05(金) 14:42:35.94

同じ設計書がインプットなら同じアウトプットができなければならないという前提にまず同意してないから。

0176仕様書無しさん2016/02/05(金) 14:44:04.80

>>174
それのどこに
> 本来設計書というものは設計書通りに作れば同じものが出来るものだ。
と書かれているのか、引用してくれよ

0177仕様書無しさん2016/02/05(金) 14:44:20.17

>>175
そっちに同意していなくても

ソースコードは設計書であるという論文がでたのだから
こっちには同意しておけ。

0178仕様書無しさん2016/02/05(金) 14:45:29.36

>>176
そんなものないぞｗ

ソースコードは設計書であるという証拠は
幾つもある。その中の一つってだけだ。

ソースコードは設計書であると書いてある論文は提示した

0179仕様書無しさん2016/02/05(金) 14:48:01.83

>>178
マジなのか釣りなのかわからんわ

> 本来設計書というものは設計書通りに作れば同じものが出来るものだ。
という前提が間違ってるんだが
↓
間違ってない。
↓
じゃ、お前の主張通りのブログでも論文でも良いが紹介してくれよ
↓
>>174
↓
それのどこに
> 本来設計書というものは設計書通りに作れば同じものが出来るものだ。
と書かれているのか、引用してくれよ
↓
いまここ

理解できた？

0180仕様書無しさん2016/02/05(金) 14:49:07.77

いきなり設計書を書くな。設計してから書け。

01811792016/02/05(金) 14:50:06.05

ちなみに、その記事を紹介したの俺だから

0182仕様書無しさん2016/02/05(金) 14:50:18.82

で、コードが設計書だったらどうなの？今までとなにが変わるの？

0183仕様書無しさん2016/02/05(金) 14:55:02.05

>>158
あるある

0184仕様書無しさん2016/02/05(金) 15:04:07.57

>>141
>>128宛じゃないの？
何でお前が反応してるの？

0185仕様書無しさん2016/02/05(金) 15:13:14.74

まだコード＝設計書くんは勘違いしてるのか。
以下に箇条書きに書いておくぞ。
・コードと一対一対応のコード以外の設計書を書く必要はない。
・コーディングは設計である。
・設計はコーディングではない。
・コーディング以外の設計も必要である。
・設計したのならその結果を残すところまでが仕事。

0186仕様書無しさん2016/02/05(金) 15:13:55.93

コーディング以外の設計がほんの少しでいいということは、
簡単なソフトウェアだということ。

0187仕様書無しさん2016/02/05(金) 15:16:07.71

ageてる奴とかdisって悪かった

>>185
> ・コーディングは設計である。
> ・設計はコーディングではない。
まともだったわ

0188仕様書無しさん2016/02/05(金) 15:16:28.99

少なくとも、顧客とこういうトラブルになったとしても
うまく着地させられなさそうだね

世の中、正解がAかBのどちらかに一意に決まるなんてのは殆どないし
気に入らなくても折れる必要もあれば、下手にでて説得しなくちゃいけないこともある
プログラムだけの世界ならそんなこともないけど、現実との接点はそうじゃないからねぇ

0189仕様書無しさん2016/02/05(金) 15:18:53.04

> ・コーディングは設計である。
> ・設計はコーディングではない。

コード＝設計書くんは↑見て頭こんがらがってる

0190仕様書無しさん2016/02/05(金) 15:23:46.00

等号の使い方がずっとあやふやだったコード＝設計書くんｶﾜﾕｽ

0191仕様書無しさん2016/02/05(金) 15:26:31.70

>>188
人前に出しちゃアカンやつばっかりやな

0192仕様書無しさん2016/02/05(金) 15:27:12.76

2chでは別人格ですよ？

0193仕様書無しさん2016/02/05(金) 15:34:59.61

>>185
最後が意見の分かれるところ。
> ・設計したのならその結果を残すところまでが仕事。

だから・・・
→ 設計「書」として残せ派
→ Wikiとかにまとめとけば良いよ派
→ ソースコードがあるんだから他には何もいらないよ派(RTFC(read the fucking code)派）

0194仕様書無しさん2016/02/05(金) 16:07:53.36

金型があれば同じ製品ができるからといって、金型が設計書というわけではない

0195仕様書無しさん2016/02/05(金) 16:14:39.25

>>185

> ・コーディングは設計である。
> ・設計はコーディングではない。

ワロタｗ
矛盾してるｗ

0196仕様書無しさん2016/02/05(金) 16:16:36.18

まとめ

・コードは設計書である。
・コーディングというのは設計書をコードで書く行為である。

0197仕様書無しさん2016/02/05(金) 16:17:50.71

設計を図で書こうがコードで書こうがどちらでもいいんだよ。

ただコードは絶対に書かなければならないもので、
図は無くてもいいもの。

0198仕様書無しさん2016/02/05(金) 16:21:07.20

>>189
みたいだな>>195

0199仕様書無しさん2016/02/05(金) 16:23:23.59

× コーディングは設計である。
○ コードは設計書である

この違いがわからないんだろうなぁ。

0200仕様書無しさん2016/02/05(金) 16:24:15.00

ソフトウェア開発について語るときに設計書という言葉を使った場合、それがコードを指すことはない。
だから、コードが実質的に設計書であろうとなかろうと、コードと設計書はわけて考えたほうがいい。
そこで無理矢理コードも設計書だと言い張っても、会話が混乱するだけでメリットは**ひとつも**ない。

0201仕様書無しさん2016/02/05(金) 16:25:07.47

コーディングは所詮書くだけの行為だからね。
設計は頭でやるもの。

その設計を図で書くか日本語で書くか
コードで書くかの話。

設計のすべてが書いてあるのはコード以外存在しない。

0202仕様書無しさん2016/02/05(金) 16:27:26.06

>>200
分けて考えているからシステム開発が失敗するんだよ。

コードは設計書であるという事実を受け入れたほうがいい。

0203仕様書無しさん2016/02/05(金) 16:28:29.47

新人「設計書はどうします？ちっちゃいアプリなんでドキュメント残す必要もなさそうですけど」
先輩「は？設計書（コード）がないのにコンピュータはどうやってソフトウェアをビルドすんの？」
新人「（めんどくせえ）」

0204仕様書無しさん2016/02/05(金) 16:30:28.23

>>203
それを言うならこれでいいだろｗ

新人「設計書はどうします？ちっちゃいアプリなんでドキュメント残す必要もなさそうですけど」
先輩「コーはが設計書だから、それ以外の資料は無くていいよ」
新人「了解」

0205仕様書無しさん2016/02/05(金) 16:31:26.97

ミスった

新人「設計書はどうします？ちっちゃいアプリなんでドキュメント残す必要もなさそうですけど」
先輩「コードが設計書だから、それ以外の資料は無くていいよ」
新人「了解」

0206仕様書無しさん2016/02/05(金) 16:34:00.39

コードはコード、設計書は設計書

0207仕様書無しさん2016/02/05(金) 16:35:36.49

設計書という大きな枠組の中に、

コード
クラス図
シーケンス図

などがあるんやな。

0208仕様書無しさん2016/02/05(金) 16:36:19.87

基本設計がしっかりしてれば、それをどうコードに落とすかなんてのは些末な問題。
それをいちいち設計だなんて大袈裟に捉える必要はない。

0209仕様書無しさん2016/02/05(金) 16:36:32.11

>>197
設計図書いてる暇がなかったので、とりあえず作らないといけない家だけ作りました。

0210仕様書無しさん2016/02/05(金) 16:37:13.27

>>209
それがどうかした？ｗ

0211仕様書無しさん2016/02/05(金) 16:38:15.16

ソフトウェアの場合、

家を作る。家を建てる。家をビルドするっていうのは、
コンパイラでビルドするっていう行為になるんだよね。

0212仕様書無しさん2016/02/05(金) 16:43:01.52

>>211
だからどうしたの？

0213仕様書無しさん2016/02/05(金) 16:44:15.55

>>211
まだ、ソフトウェアの製造と既存の工業製品の製造を同じものだと考えてるのか。

0214仕様書無しさん2016/02/05(金) 16:47:02.29

ドカタのお前らが建築士ぶりたいがためにコード＝設計書と言い張ってるのが泣かせる

0215仕様書無しさん2016/02/05(金) 16:48:34.58

>>209
> 設計図書いてる暇がなかったので、とりあえず作らないといけない家だけ作りました。

まだ、ソフトウェアの製造と既存の工業製品の製造を同じものだと考えてるのか。

0216仕様書無しさん2016/02/05(金) 16:49:08.62

>>213
違うものだから、既存の工業製品と同じに考えるのは間違い。

0217仕様書無しさん2016/02/05(金) 16:50:25.48

既存の工業製品と違って、コードが設計書なのですよ。

0218仕様書無しさん2016/02/05(金) 16:50:33.41

>>202
お前以外は「コーディングプロセスも設計作業の一部である」といってるのを受け入れた方がいい。

それ以上は、お前が設計の最終成果物（の一つ）であるソースコードを「設計書」と呼ぼうが、（俺は）かまわん。

0219仕様書無しさん2016/02/05(金) 16:50:52.86

>>216
>>211は明らかに同じように考えてるよね。

0220仕様書無しさん2016/02/05(金) 16:51:46.55

>>217
へぇー
既存の工業製品にもコードがあるんだー

0221仕様書無しさん2016/02/05(金) 16:52:11.91

>>219
同じようにとは？
何と何が同じなんですか？

0222仕様書無しさん2016/02/05(金) 16:53:00.27

>>220
> 既存の工業製品にもコードがあるんだー

無いから、同じではないということだろう？

0223仕様書無しさん2016/02/05(金) 16:55:06.47

ソフトウェアにはコードというものがあってそのコードから
自動的に製品が作られるのですよ。

完全にコード（設計）から製品の生産が
自動化されているわけですね。

これは既存の工業製品とは全く違うことです。

0224仕様書無しさん2016/02/05(金) 16:55:40.14

だからコードを書くことを製造と言ってはいけないんですね。

0225仕様書無しさん2016/02/05(金) 16:57:42.89

>>195

0226仕様書無しさん2016/02/05(金) 16:57:53.27

>>221
結局、君も既存の工業製品の枠から抜け出せていないんだよ。
だから、一生懸命ソフトウェア作成プロセスを既存の工業製品に
当てはめようとして
「設計書をもとに製品を作るのはコンパイラの仕事」
「つまり、コードは設計書なんだ」
と言ってるだけに過ぎない。

0227仕様書無しさん2016/02/05(金) 16:59:58.92

敢えて例えるなら、ソフトウェア開発における最終的な成果物はコードだよ。
今はコンパイラを使わないことも多いしね。

0228仕様書無しさん2016/02/05(金) 17:00:53.03

>>226
それで抜けだしたあなたの意見は？
自分がさも抜けだしたかのようなふりをして、
相手にばっかり抜け出せていないといった所で、

じゃあ、あんたは？って言われて
何も言えないようじゃ、恥ずかしいことですよね？

0229仕様書無しさん2016/02/05(金) 17:02:07.19

いきなり最終成果物を書くな。設計してから書け。

0230仕様書無しさん2016/02/05(金) 17:03:26.22

>>228
「ソフトウェアの作成を既存の工業製品になぞらえてもなんの意味もない」

0231仕様書無しさん2016/02/05(金) 17:05:31.18

ついでに言うと、比較することも意味がない。

0232仕様書無しさん2016/02/05(金) 17:09:26.93

>>230
だからどうしたの？

0233仕様書無しさん2016/02/05(金) 17:09:50.00

まったく、>>54から何年経ってるんだよ。
未だに工業製品の生産方法を持ち出して「コンパイラが製造するんですー」ってアホちゃうか。

0234仕様書無しさん2016/02/05(金) 17:12:24.98

>>217
お前誰にレスしてるの？

0235仕様書無しさん2016/02/05(金) 17:13:13.56

>>233
誰がそんなこと言ったの？

0236仕様書無しさん2016/02/05(金) 17:13:59.86

ビルドしただけで動くんですかと
吉牛風に問い詰めたい

0237仕様書無しさん2016/02/05(金) 17:16:52.99

家が動くわけないじゃん？ｗ
アホ？

0238仕様書無しさん2016/02/05(金) 17:16:58.91

>>233

> まったく、>>54から何年経ってるんだよ。

何年もたっていても、>>54が示した事実（コード＝設計書）という
考え方が普及してないんだよ。仕方ないね。

0239仕様書無しさん2016/02/05(金) 17:19:38.08

>>233
「コンパイラが製造します」の更に前の時代は
「人間が製造します」だっけ？

人間は製造しない。設計しているだけ。

0240仕様書無しさん2016/02/05(金) 17:20:00.74

>>238
未だにコード＝設計書とかわざわざ言ってるのはお前だけ。
もうそんな時代は過ぎたんだよ。

0241仕様書無しさん2016/02/05(金) 17:21:44.31

>>240
コードが設計書だろうがどうでもいい。
必要な成果物を作れ。

0242仕様書無しさん2016/02/05(金) 17:22:04.70

>>239
一番最初は本当に人間がコンパイルしたらしいけどね。

一番最初のコンパイラは、一体どうやって
作られたのか？の答え。

それぐらいだよ。人間が製造したものは

0243仕様書無しさん2016/02/05(金) 17:22:34.54

>>248
過ぎて何になったんだよｗ

0244仕様書無しさん2016/02/05(金) 17:24:39.51

>>241
だから必要な成果物がコードなんだよ
何回も言わせるな

0245仕様書無しさん2016/02/05(金) 17:25:00.78

同じものは一切作らないって時点で
殆どの工業製品とは別物だけどね。

0246仕様書無しさん2016/02/05(金) 17:25:23.04

>>248
どうなんだ？

0247仕様書無しさん2016/02/05(金) 17:25:59.91

>>243
>>246
知るかよ

0248仕様書無しさん2016/02/05(金) 17:26:20.30

>>247
早えよ

0249仕様書無しさん2016/02/05(金) 17:26:39.53

>>238
未だにコード＝設計書とかわざわざ言ってるのはお前だけ。
もうそんな時代は過ぎたんだよ。

0250仕様書無しさん2016/02/05(金) 17:27:07.29

>>249
過ぎて何になったんだよｗ

0251仕様書無しさん2016/02/05(金) 17:28:00.91

過ぎるっていうか、コード＝設計書であることは
今の時代常識だろうって言ってるの

0252仕様書無しさん2016/02/05(金) 17:28:13.38

>>233
7年だよ

0253仕様書無しさん2016/02/05(金) 17:28:40.40

design != documentなんですが

0254仕様書無しさん2016/02/05(金) 17:29:25.19

>>253
それがどうしたんだよ？ｗ

0255仕様書無しさん2016/02/05(金) 17:29:31.37

SI業界以外では、コードが設計書であることは常識

0256仕様書無しさん2016/02/05(金) 17:30:08.16

>>253
設計＝デザイン

デザインパターンのデザインとかだよな。

0257仕様書無しさん2016/02/05(金) 17:30:39.02

>>254
え？
>>54のタイトルはThe Source Code Is The Designなんですが

0258仕様書無しさん2016/02/05(金) 17:31:32.41

あ、>>54そのもののタイトルはWhat Is Software Design?だった

0259仕様書無しさん2016/02/05(金) 17:31:48.39

>>257
んなの読めばわかるよ
だからどうしたんだよ？

0260仕様書無しさん2016/02/05(金) 17:32:26.87

せやな。設計と言ったらデザインパーターンの
どれを適用するか？ってのを考える行為でもある。

例えば、あるオブジェクトの状態の変化を監視したいと
思った時は、ここはオブザーバーパターンを適用します。とか
書くのが本物の技術者の設計っぽいｗ

0261仕様書無しさん2016/02/05(金) 17:34:50.04

>>259
え？
>>54には、コード＝設計書なんていう事実は書かれてないんですが

0262仕様書無しさん2016/02/05(金) 17:36:58.97

>>259

>>54の内容の一部を書いておくわ。今でも色褪せること無く通用することだからさ。

ソースコードがソフトウェア設計であると考えることによって重大な帰結が導き出されます。
この帰結はあまりにも重要かつ自明であるものの，ほとんどのソフトウェア組織において盲点となっているものです。
それは，ソフトウェアの製造（ビルド）が安価なものであるという事実です。あまりにも安いため安価なもの
として見なす必要すらなく，ほとんど無料といっても良いくらいなのです。ソースコードがソフトウェア設計で
あると考えた場合，ソフトウェアの本当の製造はコンパイラとリンカによって行われることになるわけです。
私たち自身もソフトウェア・システム全体のコンパイルとリンクのプロセスを，しばしば「ビルドを行う（"doing a build"）」と
呼んでいます。また，ソフトウェア構築用の機器に対する資本投資も莫大なものとはなりません。実際に必要なものは，
コンピュータ，エディタ，コンパイラ，リンカだけなのです。そして，いったんビルド環境が利用可能になれば，
ソフトウェアの製造にはほんの少しの時間しか必要とならないのです。 50,000行のC++プログラムをコンパイルするには，
かなりの時間が必要となるかもしれませんが，50,000行のC++と同じくらい複雑な設計のハードウェア・システムを
製造することを考えた場合，取るに足らないものとなるはずです。

ソースコードがソフトウェア設計であると考えた場合，ソフトウェア設計は少なくとも機械的な意味合いにおいて，
比較的容易に作成できるという帰結も導き出せます。コードにして50行から100行の一般的なソフトウェア・モジュールを
記述（すなわち設計）するには，たいていの場合，数日しかかかりません（完璧にデバッグを終えるということはまた別の話であり，
それは後ほど考察しています）。同程度の複雑さを有した設計を，ソフトウェア並みの期間で生み出せるような工学分野が
他に存在するかどうか調べたいのは山々ですが，まず最初に行うべきことは，複雑さを測定し比較する方法を見つけ出すことでしょう。
ソフトウェア設計はむしろ迅速に肥大化していくというのが明らかなのですから。

0263仕様書無しさん2016/02/05(金) 17:38:12.64

英語だと、設計書はdesign documentsかspecificationでは？

0264仕様書無しさん2016/02/05(金) 17:38:58.59

>>261
> >>54には、コード＝設計書なんていう事実は書かれてないんですが

書いてあるよ。ほら↓

> その教訓とは，プログラミングがソフトウェアの製造作業ではなく，ソフトウェアの設計作業であるということなのです。

0265仕様書無しさん2016/02/05(金) 17:39:07.29

だから>>253は誰に向けての主張なんだよ？

0266仕様書無しさん2016/02/05(金) 17:40:24.46

>>265
誰って>>238宛てですが

0267仕様書無しさん2016/02/05(金) 17:41:31.19

>>54の内容より

> ソフトウェア開発では，「すべて」が設計プロセスの一部になっているという大きな問題があります。
> コーディングは設計であり，テスティングとデバッギングも設計の一部であり，
> 私たちが一般的にソフトウェア設計と呼んでいるものもやはり設計の一部なのです。

0268仕様書無しさん2016/02/05(金) 17:41:31.64

>>264
設計作業(=design) != 設計書(=design documents or specification)
だといってるんですが

0269仕様書無しさん2016/02/05(金) 17:43:40.83

>>54の内容より

> 構造化チャート，Boochダイアグラム，状態遷移テーブル，PDL（訳注： Program Design Language---いわゆる疑似コードのこと）等---
> それが役に立つのであれば何でも採用することです。しかし，こういったツールや記法がソフトウェア設計ではないということは，
> 常に心に留めておかなければなりません。最終的に，私たちは真のソフトウェア設計を作り出さなければならず，
> それは何らかのプログラミング言語となるためです。したがって，私たちが設計を作り出す際に，コーディングを
> ためらう必要はないのです。私たちは，必要に応じて設計を洗練しなければならないというだけなのです。

0270仕様書無しさん2016/02/05(金) 17:43:57.78

"source code is the design"
約 358,000 件（0.35 秒）

"source code is the design documents"
1 件（0.61 秒）

"source code is the specifications"
1 件（0.62 秒）

ほら、コード=設計書なんていってる人はほとんどいませんよ

0271仕様書無しさん2016/02/05(金) 17:44:43.71

>>268

・設計作業(=design) != 設計書(=design documents or specification)
・コード = 設計書

この2つは矛盾しません。

0272仕様書無しさん2016/02/05(金) 17:44:55.64

>>268
だから
設計作業 = 設計書なんていってる奴がどこにいるんだよ？

0273仕様書無しさん2016/02/05(金) 17:45:22.13

>>268
あったまわりぃなあ

0274仕様書無しさん2016/02/05(金) 17:46:53.24

>>54の内容より

> オブジェクト指向設計は新たな潮流であり，C++はその中心に位置しています。
> では次に，人気を博さなかったものを思い起こしてみましょう。 CASEツール？確かに普及しましたが，
> 普遍的なものにはなっていません。構造化チャート？これも同じでしょう。同様にWarner-Orrダイアグラム，
> Boochダイアグラム，オブジェクト・ダイアグラム等が出てくるかもしれません。それぞれには長所があるものの，
> それぞれは本当のソフトウェア設計ではないという共通した短所を抱えているのです。実際，広範囲に
> 普及しているといえるソフトウェア設計記法はPDLだけであり，それが私たちの目にどのように映っているのかを考えてみる必要があるでしょう。
>
> このことは，プログラミング・テクニック，そしてとりわけ現実世界におけるプログラミング言語の改善が
> ソフトウェア業界において最も重要であるという点を，ソフトウェア業界全体が本能的に理解していることを意味しています。
> またこのことは，プログラマが設計に興味を持っているということも意味しているのです。
> より表現力豊かなプログラミング言語が利用可能になれば，ソフトウェア開発者はそれを採用するのです。

0275仕様書無しさん2016/02/05(金) 17:46:53.46

>>271
>>54がいってるのは、source code is the designであって、
source code is the design documentsでも
source code is the specificationsでもないんですが

0276仕様書無しさん2016/02/05(金) 17:47:32.13

>>275
いつまでも>>54のタイトルにこだわってないで、
内容の話しろよｗ

0277仕様書無しさん2016/02/05(金) 17:48:30.81

>>54の内容より

> さらに，ソフトウェア開発プロセスがどのように変遷してきたのかを考えてみてください。
> 昔々，私たちはウォーターフォール・プロセスを実践していました。そして今では，
> スパイラル開発やラピッド・プロトタイピングについて論じています。
> こういったテクニックの目的として，しばしば「リスクの低減」や「製品出荷の短期化」等が
> 主張されているものの，本当のところはライフ・サイクル中でのコーディング作業を早期に
> 開始するための口実でしかないのです。しかし，これは正しいことです。これによって，
> 設計を早期に検証，洗練するためのビルド/テスト・サイクルが開始できるようになるわけです。

0278仕様書無しさん2016/02/05(金) 17:49:17.48

>>276
は？
>>54をざっくりとまとめたのが、日本語で言えば、コード＝設計であって
コード＝設計書であるなんていってないんですが

0279仕様書無しさん2016/02/05(金) 17:50:24.17

>>54の内容より

> 補助ドキュメントのもう1つの重要な用法とは，設計自身から直接抽出することが難しい，設計上の側面を
> ドキュメント化しておくというものです。こういったものとして，上位レベルおよび下位レベル双方の
> 側面が含まれる可能性もあります。こういった側面の多くは，図表として表現するのが最適なのです。
> このため，ソースコード中のコメントとして記述することが難しくなるわけです。
> しかしこのことは，プログラミング言語の代わりにグラフィカルなソフトウェア設計記法を
> 使用するべきであるという議論「ではありません」。これでは，ハードウェア分野の設計図に文字の
> 説明が必要であるという主張と何ら変わりはありません。

> 真の設計を決定付けるのは，補助ドキュメントではなく，ソースコードであるということを忘れてはいけないのです。

コードじゃない設計書　＝補助ドキュメントにされちゃったｗ

0280仕様書無しさん2016/02/05(金) 17:50:56.17

>>278
だからお前の解釈がおかしいんだよ

0281仕様書無しさん2016/02/05(金) 17:50:59.97

テスト＝設計書
テスト書いてない奴は設計してないのと一緒。
まさかそんな奴はもう生息してないよな？

0282仕様書無しさん2016/02/05(金) 17:51:34.37

つまり、

>>238
> 何年もたっていても、>>54が示した事実（コード＝設計書）という
> 考え方が普及してないんだよ。仕方ないね。

普及してないのは、>>54がコード＝設計書なんていってないからですね

0283仕様書無しさん2016/02/05(金) 17:52:32.68

>>280
解釈なんて不要ですね

書かれているのか
書かれていないのか

事実ベースで誰でも確認できることですね

0284仕様書無しさん2016/02/05(金) 17:52:39.52

>>278
何で成果物と作業がイコールで結ばれるんだよ？
頭おかしいの？

0285仕様書無しさん2016/02/05(金) 17:53:05.17

>>54の内容より

> 将来的には，ソフトウェア・ツールによってソースコードという設計から，補助ドキュメントが
> 生成されることになるのかもしれません。しかし，これはおそらく高望みというものでしょう。

> 要約すると
>
> ・プログラム・リスティングとはソフトウェア設計を表現したドキュメントです。ソフトウェア設計は，コンパイラとリンカによって実際に製造（ビルド）されているのです。
> ・真のソフトウェアをビルドするには，驚くほどコストがかからず，コンピュータの高速化とともに，より安価になってきています。
> ・コーディングは，信じられている以上に意味のある作業です。コードによって設計を描き出すプロセスはしばしば，
> 見逃しや追加設計を行う必要性を暴き出してくれるのです。こういったことを早期に行えば，設計はより優れたものとなるわけです。
> ・テスティングとデバッギングは，設計アクティビティです。これらは，他の工学分野における設計の検証と
> 洗練プロセスと等価なものなのです。優れたソフトウェア設計プロセスはこのことを認識しているため，このステップで手抜きを行おうとはしていません。

> ・多くの様々なソフトウェア設計記法は，有益なものとなる可能性を秘めています。補助ドキュメントやツールも同様に，
> 設計プロセスを円滑にする支援となります。しかし，これらはソフトウェア設計ではありません。

0286仕様書無しさん2016/02/05(金) 17:54:44.54

>>284
> 何で成果物と作業がイコールで結ばれるんだよ？

さあ？
>>54の中の人に質問したらどうですか？
なんでcodeとdesignを"is"でむすぶのかって

0287仕様書無しさん2016/02/05(金) 17:54:57.22

>>54に書いてある内容

コーディング＝設計
コード = 設計書

0288仕様書無しさん2016/02/05(金) 17:56:12.87

>>286
オリジナルの英文では、coding と design を isで結んでいますけど？

0289仕様書無しさん2016/02/05(金) 17:58:00.24

>>286
だからそういう直訳で解釈したアホはおまえだけなんだって

0290仕様書無しさん2016/02/05(金) 17:59:20.84

>>270の結果を見ると、英語圏ではcodeとdesignをisで結んでも違和感ないんじゃないですかね

0291仕様書無しさん2016/02/05(金) 18:01:03.17

これだから自然言語は…

0292仕様書無しさん2016/02/05(金) 18:01:07.88

>>289
「ソース=設計書とは書かれてない」（誰もが確認できる事実）
「俺の解釈では「ソース=設計書」と書かれてるんだ」

さて、どっちが客観的に見て妥当ですかね

0293仕様書無しさん2016/02/05(金) 18:01:30.84

>>290
そのとーり

0294仕様書無しさん2016/02/05(金) 18:03:55.19

>>292
主観を客観的っぽく書かれても困りますね

0295仕様書無しさん2016/02/05(金) 18:05:42.64

ここは中学生の英語教室じゃねえんだよ

0296仕様書無しさん2016/02/05(金) 18:05:54.51

デスマ上等の方たちがなにかいいたいのかなと

0297仕様書無しさん2016/02/05(金) 18:09:23.54

>>294
またまたご冗談を

> >>54が示した事実（コード＝設計書）という考え方
これこそ、主観ですね

だって、そんなこと書かれてないんだから

0298仕様書無しさん2016/02/05(金) 18:11:45.84

まあ>>54が初出なのかどうか知りませんが、今では>>270の通り

"source code is the design"は広まっていて
"source code is the design documents"も"source code is the specifications"も
広まっていないというのが事実

これを「主観」というなら、それこそ主観とは何かという話になりますね

0299仕様書無しさん2016/02/05(金) 18:13:32.01

ついでにこれの検索結果もはっときましょうね

"source code is the documents"

"source code is the documents"との一致はありません。

0300仕様書無しさん2016/02/05(金) 18:26:08.79

コードが完全な設計書とかぬかすやつはプログラム設計書で話が収まる仕事しかしたことがないITドカタだよな

0301仕様書無しさん2016/02/05(金) 18:33:44.55

コード＝設計書君は一体なにをしたいんだろうか

0302仕様書無しさん2016/02/05(金) 18:36:04.31

>>195

0303仕様書無しさん2016/02/05(金) 18:48:01.49

まだ悩んでるのかw

0304仕様書無しさん2016/02/05(金) 19:49:47.24

>>262
> ソースコードがソフトウェア設計であると考えることによって
コードが設計という前提で考えたらこんなことも言えるよと言っているだけで、
コード＝設計書とは言ってない。

0305仕様書無しさん2016/02/05(金) 20:01:49.70

>>300
誰にも賛同されないなんて恥じゅかちいー

0306仕様書無しさん2016/02/05(金) 20:11:14.96

>>185
相変わらずこの程度の文章でも矛盾を潰せない設計書君

0307仕様書無しさん2016/02/05(金) 20:11:17.67

>>295
でもその辺を明確にした方がいいんじゃないか
この場合のthe designって「設計すること」じゃなく「設計の成果」みたいな意味でいいんだよね？

0308仕様書無しさん2016/02/05(金) 20:21:33.21

設計書を記述出来るプログラミング言語を
誰か作れよ
それで、コンピューターが動けば全て解決

0309仕様書無しさん2016/02/05(金) 20:54:30.36

コーダーを拗らせた馬鹿って笑えないレベルで可哀想なやつ多いな
新人の時から既に拗らせてるのまで居るからたちが悪いｗ

0310仕様書無しさん2016/02/05(金) 21:04:50.75

設計屋を拗らせた馬鹿って笑えないレベルで可哀想なやつ多いな
新人の時から既に拗らせてるのまで居るからたちが悪いｗ

0311仕様書無しさん2016/02/05(金) 21:10:51.17

>>310
顔まっかっかw

0312仕様書無しさん2016/02/05(金) 21:46:01.70

設計君はブーメランがホント大好きだな
毎回戻ってきたブーメランが顔にぶつかっても同じことを繰り返す

0313仕様書無しさん2016/02/05(金) 22:19:41.41

>>306
いくらなんでもオブジェクト指向くらいは理解してるよね？

0314仕様書無しさん2016/02/05(金) 22:51:34.84

>>310
常用漢字を知らないやつって自分に教養がないと言っているようなものだぞ。

教養というより義務教育時代から学力が怪しいレベルだが。

0315仕様書無しさん2016/02/05(金) 23:33:39.66

>>314
漢字は日本の害悪であり、教育を阻害するものです。
GHQが必死で排除しようとしたがかないませんでした

漢字の知識を自慢をする奴は
無駄無益なことに時間を費やしたことを自慢しているのだ

0316仕様書無しさん2016/02/05(金) 23:40:20.59

どこの漢字が間違ってるのかわからん

0317仕様書無しさん2016/02/06(土) 00:08:40.29

教わってもいない、プロが書く文章にもない、国が使うなと言っている漢字を使うやつは何を基準に漢字を使ってるのだろうか？

0318仕様書無しさん2016/02/06(土) 00:33:29.60

IME様のご提案です

0319仕様書無しさん2016/02/06(土) 00:38:10.18

>>318
そのIME様は外国人が作っているという事実w

0320仕様書無しさん2016/02/06(土) 06:46:35.10

>>313
>>195

0321仕様書無しさん2016/02/06(土) 07:05:03.73

>>320
意味不明。何も言えないのなら書き込まなくて良い

0322仕様書無しさん2016/02/06(土) 07:08:48.07

>>321
>>195を見ても尚、矛盾に気付かないとかヤバすぎるだろ

0323仕様書無しさん2016/02/06(土) 07:28:08.95

>>322
人間は哺乳類である
哺乳類は人間ではない。

こう言えばわかるだろ？

コーディングは設計であるは正しいが、
設計はコーディングではないんだよ。

で、ここでずっと言われているのは
コーディングは設計であり
コードは設計書であるということ。

0324仕様書無しさん2016/02/06(土) 07:35:02.59

>>323
俺がいなくてもスレがすげえ進んでたんで一連を読んでみたら
>>54がきっかけか。たしかに面白いことが書かれてる。

要するにプログラミング（というよりオブジェクト指向言語）は
設計を円滑に進められる最強ツールだってことだな。
机上でひたすら無駄な時間を費やして信頼性の低い空想設計をして
最後にコード化、ビルドという古代の流れは開発システムの
性能向上（ビルド時間の短縮）とともに既に終わっていると。

オブジェクト指向設計が上手ければドデカい仕様変更や設計変更も
お手軽にできるし、設計変更の準備なんて下手すりゃ１分とかからない。
これが机上設計からやり直してたら時間がどれだけあっても足りない。

プログラミング言語が設計に使われれば、書かれたコード自体が設計書になる。

だから「プログラミングができないSE」が
役に立たない設計書もどきを時間をかけて書いて
仕事をしてるフリができる時代は終わったと。

で、設計書を書けと言ってる連中が爆発したと。

0325仕様書無しさん2016/02/06(土) 07:37:25.71

俺もだいぶ前に書いたっけ
詳細設計はパンチカード時代の遺物だって。

オブジェクト指向言語なら
基本設計から使えるもんな。

0326仕様書無しさん2016/02/06(土) 07:53:49.53

>>323
＞人間は哺乳類である
＞哺乳類は人間ではない。
＞コーディングは設計であるは正しいが、
＞設計はコーディングではないんだよ。
言いたいことはわかるが、どうもしっくりこない
つまり訂正すると

コーディングは設計の一部である
設計の全てがコーディングではない

ってことな。
まあテスト設計とか違うしな。

0327仕様書無しさん2016/02/06(土) 07:58:33.69

俺はカレー

0328仕様書無しさん2016/02/06(土) 08:01:02.88

カレーは俺

注文がテーブルに届いたときに言うね、普通に

0329仕様書無しさん2016/02/06(土) 08:05:05.74

使う場面で、どっちも同じ意味にもなるし
全く違う意味にもなる、日本語は正しく使えってことだな

0330仕様書無しさん2016/02/06(土) 08:08:35.98

おいおいコーダー君が調子に乗るような事言ってんじゃないよ君達
君達が無理なら僕が現実を付きつけてあげるよ
準備はいいかい？ちゃんと耳糞ほじったよね？じゃあいくよ

コーディングは設計ではない

0331仕様書無しさん2016/02/06(土) 08:08:43.22

だけどな。それ揚げ足取りでしかないんだわ。

0332仕様書無しさん2016/02/06(土) 08:09:36.50

>>330
話をループさせるな。>>54を読め
何年も前にお前は論破されてるんだよ。

0333仕様書無しさん2016/02/06(土) 08:13:59.57

>>332
おまえこそちゃんと読め>>54読んでみろ
そこにはコーディングが設計だなんて一言も書いてないぞ

0334仕様書無しさん2016/02/06(土) 08:15:31.73

>>333

>>54に書いてますが？

> ソフトウェア開発では，「すべて」が設計プロセスの一部になっているという大きな問題があります。
> コーディングは設計であり，テスティングとデバッギングも設計の一部であり，
> 私たちが一般的にソフトウェア設計と呼んでいるものもやはり設計の一部なのです。

0335仕様書無しさん2016/02/06(土) 08:17:32.92

コーディングが設計　なんて書いてないも～ん
コーディングは設計　ってかいてあるだけだも～ん

「が」と「は」だから違うも～ん

って子供かｗ

0336仕様書無しさん2016/02/06(土) 08:28:14.77

>>330いわく
コーディングは設計ではない

↓

>>332いわく
54を読め

（54のリンク先）
> コーディングは設計であり，テスティングとデバッギングも設計の一部であり，

↓

>>333いわく
> そこにはコーディングが設計だなんて一言も書いてないぞ

なにこの茶番ｗ

「コーディング "は"」って言ってるのに、
なんで関係ない「コーディング "が" 」の話してるんだ？
日本語は正しく使えよ。

0337仕様書無しさん2016/02/06(土) 08:28:48.19

コードを設計と呼ぶかどうかは別として
どっちみち設計は必要という点では一致だな。

次に少し設計について観点を変えて述べてみたい。
対象はコンピュータでなく、マン子。君たちには手が届かないだろが。
そのマン子を口説けるかなのだ。
それは設計に掛かっているといえるかどうかだ

だがこいういう設計はプログラマには無理だね。
それは設計として高級すぎるからだ

0338仕様書無しさん2016/02/06(土) 08:30:59.93

> どっちみち設計は必要という点では一致だな。
そりゃそうだろｗ

コード書くにしろ、脳内で設計はしている。
必要ないのは、コードではない設計書だよ。

頭の中で設計をし、コード（設計書）を書いている。
これは絶対に行われるプロセスなのでコードが有るならば
（それがどんなにレベルの低い設計であれ）設計は存在する。

0339仕様書無しさん2016/02/06(土) 08:33:47.04

>>337
設計が必要なんて最初から一致してたろ、設計書はいらんが
と同じことを何度書いたか

0340仕様書無しさん2016/02/06(土) 08:34:45.80

>>54の内容からも、コーディングは設計なわけで、
コーディングしてできたコード（設計書）を見るだけで
わかることならば、別の形の設計書は不要なのだよ。

コード以外の形の設計書が必要なのは、
コードだけでは分かりにくいことを補助的にサポートする。
だから必ずしも必要なわけじゃない。

0341仕様書無しさん2016/02/06(土) 08:37:02.17

>>340
コードを読めない奴が理解するために必要かもしれないけど
そんな奴が知る必要はそもそもないしな

0342仕様書無しさん2016/02/06(土) 08:39:01.23

コードは設計書なのだから、
設計書を読めないやつを設計するなんて
ナンセンスなわけでｗ

0343仕様書無しさん2016/02/06(土) 08:39:30.56

訂正

設計書を読めないやつ "が" 設計するなんて

0344仕様書無しさん2016/02/06(土) 08:57:29.34

ガストに行けば

俺は、カレー
カレーは、俺

というやりとりは普通にある

0345仕様書無しさん2016/02/06(土) 10:45:31.65

>>320>>322
>>189

0346仕様書無しさん2016/02/06(土) 12:21:55.58

>>345
よっぽど気に障ったらしいなｗ

コードは設計書だよ。

0347仕様書無しさん2016/02/06(土) 12:46:21.14

コンパイラが作業者
プログラマが設計者

0348仕様書無しさん2016/02/06(土) 12:48:06.49

軽くプログラム書いてから設計書おこすわ、申し訳ない

0349仕様書無しさん2016/02/06(土) 12:53:01.78

>>334
その文はコーディングをしながら同時に設計も行っているという意味だな。
コーディングが設計だと言ってるのではない。

コーダー君には残念な事だがもう一度言おう

コーディングは設計ではない

0350仕様書無しさん2016/02/06(土) 13:19:36.54

コーディングは設計の一部である
設計の全体は、コーディングのみではない

0351仕様書無しさん2016/02/06(土) 13:20:19.17

>>340
コードだけでわかるソフトって、すげー簡単なものに限られるよね。

0352仕様書無しさん2016/02/06(土) 13:21:18.84

言葉の意味の階層を分けるような

0353仕様書無しさん2016/02/06(土) 13:26:05.04

>>332
> 真のソフトウェア設計が最終的なソースコードであると仮定した場合
と書いてあるね。
幽霊が存在すると仮定した場合どうなるかという文章を読んで
「幽霊は存在するんだ」と勘違いしちゃったのかな？

0354仕様書無しさん2016/02/06(土) 13:35:55.29

>>351基準のすげー簡単＝Hello World

0355仕様書無しさん2016/02/06(土) 13:37:32.60

>>346
なんでおまえが釣り針に引っかかるんだよ
おまえじゃねーよ

0356仕様書無しさん2016/02/06(土) 13:43:02.32

>>311
集合とか習ってないのかな？
高校の範囲だっけ？

0357仕様書無しさん2016/02/06(土) 13:55:51.45

>>350
つまりコーディングする前にテスト設計も全て終わらせとけと？

0358仕様書無しさん2016/02/06(土) 13:59:55.81

>>351
英語だけでわかるドキュメントは、すげー簡単なものに限られる？

0359仕様書無しさん2016/02/06(土) 14:03:43.79

>>351
おまえにとってコードを読むのは
神のようなスキルを持った人にしかできないスゴ技なんだな

0360仕様書無しさん2016/02/06(土) 14:11:55.10

>>349
> コーディングが設計だと言ってるのではない。

↓ >>54より

> ソフトウェア開発では，「すべて」が設計プロセスの一部になっているという大きな問題があります。
> コーディングは設計であり，テスティングとデバッギングも設計の一部であり，
> 私たちが一般的にソフトウェア設計と呼んでいるものもやはり設計の一部なのです。

> コーディングは設計であり，テスティングとデバッギングも設計の一部であり，

> コーディングは設計であり，

> コーディングは設計であり，
^^^^^^^^^^^^^^^^^^^^^^

0361仕様書無しさん2016/02/06(土) 14:14:10.58

>>353
真のソフトウェア設計が最終的なソースコードであると仮定した場合
と書いてあるね。

仮定した結果、いろいろな真実が見えてくる。
この仮定は正しいということだよ。

0362仕様書無しさん2016/02/06(土) 14:17:50.17

コーダー君は自我を守るために必死やん

0363仕様書無しさん2016/02/06(土) 14:18:51.32

>>360
その設計ってコードの設計だから。

0364仕様書無しさん2016/02/06(土) 14:19:53.21

>>353

【数学証明】仮定・結論とはいったいなにもの？？
http://benkyo.me/assumption-conclusion/

まとめ：仮定と結論は証明問題には必須！

「仮定」と「結論」は証明問題には必要不可欠なものさ。

なぜなら、証明とは、

与えられた仮定をつかって結論を論理的にみちびくこと

だからね。

0365仕様書無しさん2016/02/06(土) 14:21:30.65

>>363
>>54を読んで曲解するやつってお前の事だったのかｗ

明らかに、コーディングは設計と書いてあります。

>>54の内容はコーディングはソフトウェア設計として解釈すると、
ソフトウェア開発における色々な問題や理由の説明ができることを
述べた文章です。

0366仕様書無しさん2016/02/06(土) 14:26:16.30

コーディングは設計ではない

誰もいない休日のフロアでExcel方眼紙を見つめ、彼は呟いた

0367仕様書無しさん2016/02/06(土) 14:56:26.07

>>364
きみ、数学の証明問題解けなかったでしょw

0368仕様書無しさん2016/02/06(土) 14:58:17.09

>>359
そうだな。
お前が吐いた腐ったスパゲティを読める人間はいないよ。

0369仕様書無しさん2016/02/06(土) 15:15:55.75

>>367
お前がだなｗ

0370仕様書無しさん2016/02/06(土) 15:17:56.35

>>369
お前がだなｗ

0371仕様書無しさん2016/02/06(土) 15:33:28.64

>>367みたいな下らないレスって

0372仕様書無しさん2016/02/06(土) 19:58:41.86

>>368
じゃあ俺のソースコードをスラスラ読める俺は神レベルってことだなｗ

0373仕様書無しさん2016/02/06(土) 20:01:13.82

>>363
「相当な馬鹿」でも理解できるように>>324に簡潔にまとめてやったのに
それでも理解できないのか
>>54なんて曲解や誤解を受ける余地すらないだろうに

0374仕様書無しさん2016/02/06(土) 20:31:53.77

>>373
おまえ本当に仕事したことあんの？

0375仕様書無しさん2016/02/06(土) 20:34:04.33

根拠「本に書いてあった！」

あかんやつや
しかも理解間違ってるしｗ

0376仕様書無しさん2016/02/06(土) 21:29:32.96

設計書って理解力が足りないあなた達のような馬鹿に書くものだよ。

はぁ、一緒のレベルの人と仕事したいわぁ

0377仕様書無しさん2016/02/06(土) 21:45:16.65

前で述べていた人がいた。ソースコードは金型みたいなもんやで
金型にプレスすれば同じものを作りあげる。

このようにみれば金型が応用が利かない代物だとわかる
金型はそれ意外なものが作れない

金型には寸法も材質も何も記載されることは無い。
設計図とは違うからだ。

見本の金型から少し違うものを作りたい場合、
設計図が無い場合は寸法をすべて拾わなくてはならない
そこから設計図を作ってからパクリの金型ができる

0378仕様書無しさん2016/02/06(土) 21:57:04.82

信じられんが、ソースコードと金型の区別もつかんアホがいたという話か。

0379仕様書無しさん2016/02/06(土) 21:57:12.72

>>376
> 設計書って理解力が足りないあなた達のような馬鹿に書くものだよ。

単なる指示書になってるねｗ

本来は、自分のために書くものなのに。

0380仕様書無しさん2016/02/06(土) 22:00:21.38

>>376
類は友を呼ぶ

0381仕様書無しさん2016/02/06(土) 22:18:12.08

>>374
>>373が仕事したことがあるか訊いてどうするの？
なかったら覆るの？

0382仕様書無しさん2016/02/06(土) 22:23:23.42

なかったらプギャーって言うだけの話。
どや？言われたら恥ずかしいやろｗ

0383仕様書無しさん2016/02/06(土) 22:23:59.64

＞明らかに、コーディングは設計と書いてあります。

でも逆はいえないだろ
つまり設計書はコーデングとはいえない

俺はカレーといえても、カレーは俺とはいえないのと同じ。

0384仕様書無しさん2016/02/06(土) 22:25:50.47

>>382
あったらプギャー言えないの？

0385仕様書無しさん2016/02/06(土) 22:27:15.24

>>383
カレーが喋った！

0386仕様書無しさん2016/02/06(土) 22:36:33.36

>>371
>>364と>>353も含めて

0387仕様書無しさん2016/02/06(土) 22:39:58.75

>>377
3Dプリンタが普及しつつある今その例えはピンと来ない

0388仕様書無しさん2016/02/06(土) 23:08:14.82

>>387
ものづくりに興味無いでしょ。

0389仕様書無しさん2016/02/06(土) 23:10:28.46

>>324
プログラマが、設計もせずにコーディングだけすることが推奨されたこともありませんが。

0390仕様書無しさん2016/02/06(土) 23:19:33.66

> 設計もせずにコーディングだけすることが推奨された
誰？そんなこと言ったの

0391仕様書無しさん2016/02/06(土) 23:25:56.60

>>388
ああだからピンとこない

0392仕様書無しさん2016/02/06(土) 23:26:08.80

>>390
コード＝設計書くんはずっとコーディングは設計だからコーディングだけすればいいと言ってますがな。

0393仕様書無しさん2016/02/06(土) 23:27:31.65

そんなレスある？

0394仕様書無しさん2016/02/06(土) 23:27:33.57

>>391
無理やり3Dプリンタとか持ち出すからややこしくなる。
単純に、ものづくりに興味無いからピンとこないと言えばいいのに。

0395仕様書無しさん2016/02/06(土) 23:30:44.58

>>394
それを言うなら>>387に突っ込む前にまず
無理やり金型とか持ち出すからややこしくなる。
って>>377に言って差し上げて。

0396仕様書無しさん2016/02/06(土) 23:35:16.58

ブーメランわろた

0397仕様書無しさん2016/02/06(土) 23:36:28.81

>>384
おまえの勝ち

0398仕様書無しさん2016/02/06(土) 23:39:07.06

>>395
金型という喩えはまっとうなものだと思うぞ。
少なくとも、コンパイラが製造するという喩えよりまとも。

0399仕様書無しさん2016/02/06(土) 23:39:54.38

>>380
それは言ってやるな

0400仕様書無しさん2016/02/07(日) 00:11:50.19

>>383
> つまり設計書はコーデングとはいえない
誰が設計書はコーディングって言ってるの？

コーディングは設計、または
コードは設計書としか言ってないけど。

コードは設計書だからって、
その逆は必ずしも成り立つわけじゃないって知ってる？

0401仕様書無しさん2016/02/07(日) 00:15:19.46

>>392
> コード＝設計書くんはずっとコーディングは設計だからコーディングだけすればいいと言ってますがな。

言ってませんよ？

コード＝設計書だから、特に前段階の資料が必要なければコードだけでも十分、
コードではない設計書は必須のものじゃないと言ってるだけです。

意味わかりますか？必須じゃないということは絶対にいらないという意味ではありません。

0402仕様書無しさん2016/02/07(日) 00:28:23.83

>>401
でも、書かないよね？
書かれたものに対する批判はするけど、書くことに対しての言及はない。
書けない(書く権限を与えられてない)のかな？

0403仕様書無しさん2016/02/07(日) 00:30:14.99

>>401
じゃ、君が今までどんな設計書(コード以外で)を書いてきたのか教えてよ。

0404仕様書無しさん2016/02/07(日) 00:57:13.94

なんか変なこと聞き始めたぞ？

>>374と同じやつかな？
相手に仕事したことあるの？って聞いて
ぷぎゃーって言おうとしているのかな。

0405仕様書無しさん2016/02/07(日) 00:59:05.85

まあいいか。一例として、PlantUMLを使って
クラス図やシーケンス図等を書いてますよって言っておくか

PlantUMLを使うと、図をテキストで書くことができるので
差分が簡単にわかって便利だよ。

エクセルなんか使いません。

0406仕様書無しさん2016/02/07(日) 03:38:10.19

いつも思うけど詳細設計はもう、ユニットレベルのフローチャートだけでいいんでない？つか無駄工程でしょ

0407仕様書無しさん2016/02/07(日) 04:12:26.81

PlantUMLってのがあるのか
astah*(jude)しか知らなかったので、豆知識になった

0408仕様書無しさん2016/02/07(日) 06:37:40.31

>>374
正社員勤めしながら副業で経営者もやっとるぜ

>>389
そんなこと一言も書いてないが
設計書が必要な子は、一体どこの記憶がリライトできなくなってるんだ？
これじゃ人工無能の方がまだ素直で仕事ができそうだな

0409仕様書無しさん2016/02/07(日) 06:39:12.07

>>408
なんだよ妄想かよw

0410仕様書無しさん2016/02/07(日) 07:00:54.39

>>408
個人でちょっとした仕事を請けてる程度で自称経営者だったら笑えるｗ

0411仕様書無しさん2016/02/07(日) 07:39:06.51

>>409-410
お前仕事を何だと思ってるの？

0412仕様書無しさん2016/02/07(日) 07:44:14.94

＞設計書が必要な子は、一体どこの記憶がリライトできなくなってるんだ？

俺の作ったシステムにデバイスのが追加があった。
俺は追加に対応できる？　とそれを引きついだ君に聞いた。
引き継いだ君は、システムは追加ができるように作ってあるという
引き継いだ君に「おめえが作ったんじゃん」といわれた
俺は、覚えていない。
プログラマってそんなもんよ。設計書(システムの図の説明）があるというのは便利

0413仕様書無しさん2016/02/07(日) 07:46:20.19

>>410
請けていた時期もあるので依頼はあるが
平日勤め人で打合せの時間を取れないから基本請けてない。
つきあいの長い人は暗黙にメールだけでOKってのもあるが。
自社製品や輸入品のネット販売がメイン、実作業はパートと家族
俺はたまに商品作ったり海外で珍しいもの探して買い付けて
メッチャ楽しいぞ。

個人事業でも法人でもいいから登録して仕事して売り上げて
たまに外注もして、雇って、帳簿付けて、確定申告して。
小さくても経営は経営、ナメんなガキ。

0414仕様書無しさん2016/02/07(日) 07:48:35.39

>>412
お前がバカだから必要なだけだろ

0415仕様書無しさん2016/02/07(日) 07:58:48.12

>>412
それってさ、引き継いだ方もプログラマじゃん？
引き継いだ方は設計書がなくてもできることを知ってるうえに
作った人間が誰かってことまで正確に憶えてる

一方、作った本人と思われる「設計書が必要なお前」の方が
すべてを忘れてる

そういう話しか

0416仕様書無しさん2016/02/07(日) 08:12:57.27

>お前がバカだから必要なだけだろ

システムの開発では、覚えているいないというのは価値がない
学校の授業では、社会というのがあるが、記憶だけがたよりの科目だな
退屈な時間だ
そんなのより面白いのは数学だ。楽しい時間、考えるのがいい
プログラマの適正は、数学が好きというところにある

といいながら、俺は抜群な記憶力を持っている。
職業柄、きたえられるね

0417仕様書無しさん2016/02/07(日) 09:04:03.65

>>413
なんだその小遣い稼ぎｗｗよくもまあ経営者を自称できるなｗｗ

0418仕様書無しさん2016/02/07(日) 09:46:20.49

>>412
> プログラマってそんなもんよ。設計書(システムの図の説明）があるというのは便利
図があると便利だっていうのは誰も否定していない。

ただし、どんな場合でもあれば便利かというとたいして意味がない場合もある。
その場合は、図は要らないと言い切ってよい。

そうすると「設計書は書かないのか？」と言い出す馬鹿がいる。
コードは設計書なのだ。図はなくてもコードから図で分かる情報を読み取ることが出来る。
わかりやすさの違いはあれど、コードがあるならば設計書がないことなんてありえないのだ。

あってもなくてもいいのなら、あったほうがいいのでは？
という意見は図があることのデメリットがわかっていない。

・図を作成・修正するコストがかかる
・図が間違っていたら・最新ではなかったら混乱を起こす

必要ない図は作る必要はない。コードから読み取ったりツールで図を
出力できるなら省略して構わない。コードは設計書なのだから、それで十分。

0419仕様書無しさん2016/02/07(日) 10:07:31.48

コードより優れたものは、図だな
わかりやすさ、ここが第一義

プログラマがコードを書いているというのはオナニーみたいなもんよ
アルファベットがズラズラなんて、誰が見るの？

１関数の行数が画面をスクロールしないと分からないようなのは
二つに分ける
１関数の行数が１００行なんて素人が作るものだ
それは見難いからだ。

プログラムというのは分かりやすさが、優先

0420仕様書無しさん2016/02/07(日) 10:57:02.62

Linuxには設計書があるよ

0421仕様書無しさん2016/02/07(日) 10:58:50.35

>>419
> コードより優れたものは、図だな

ハノイの塔のアルゴリズムを図に書いてみ。
必ずしも図はわかりやすいとは限らない。

必要ない図は書く必要がない。
コード見ればわかるからね。

0422仕様書無しさん2016/02/07(日) 11:00:20.75

>>>419
> アルファベットがズラズラなんて、誰が見るの？
全員見るでしょ？

> １関数の行数が画面をスクロールしないと分からないようなのは
> 二つに分ける

関数を見るの？何のために？見やすいから？
ということは見るわけだよね？

0423仕様書無しさん2016/02/07(日) 11:01:00.68

>>420
> Linuxには設計書があるよ
コードは設計書だからねｗ

0424仕様書無しさん2016/02/07(日) 11:01:36.25

必要ない図も書くべき

0425仕様書無しさん2016/02/07(日) 11:03:22.70

設計書のないソフトウェアは存在しない

0426仕様書無しさん2016/02/07(日) 11:05:24.32

ドキュメントやコメントには意図を残せって言う奴いるけど、コードから意図を読み取れない時点でゴミプログラマなんだから業界から足を洗え

0427仕様書無しさん2016/02/07(日) 11:28:41.25

>>426
意図を残そうとすると、すべての行にコメントすることになる。
なぜなら、すべての行にはプログラマの意図が込められているから。

0428仕様書無しさん2016/02/07(日) 11:29:39.30

より保守し易い方法があるならそれはなんであれ採用すべきだと思うが。
読み取れればいいってもんでもないでしょう。
より簡単に読み取れる方法があるならその方法を取り入れてみるべきじゃないかね。

0429仕様書無しさん2016/02/07(日) 11:33:41.92

>>428
保守とはどんな活動を想定して言ってる？
より簡単に読み取るためのドキュメントを作ると言っても、より簡単に読み取るべき箇所をどうやって設計段階で特定するんだ？
結局設計したすべての箇所に改修の可能性はあるわけだから、すべての箇所をドキュメント化するのか？

0430仕様書無しさん2016/02/07(日) 11:37:52.42

>>429
保守はバグがでれば直すとか機能追加があれば追加するとかそんなもんでしょ。
別にコードを書く前にすべて各必要はないし、すべての箇所に対してドキュメントが必要な訳でもない。
そうやって杓子定規にやろうとするから問題が生じる訳で。
なんでも必要ないかなんでも必要の２択しかないってのがおかしい。

0431仕様書無しさん2016/02/07(日) 11:57:29.89

>>430
> なんでも必要ないかなんでも必要の２択しかないってのがおかしい。

コードがあれば十分。そもそも改修の入る箇所がわかっていれば拡張しやすいように作ればいいだけで、余計なドキュメントで拡張性のなさをカバーするのは本末転倒だ。

0432仕様書無しさん2016/02/07(日) 12:13:09.84

俺がコード＝設計書だと言っている人間だが、今一度はっきりさせておこう。

俺は図は絶対に要らないとは言っていない。
コメント同様に、コードが分かりにくい場合などに
それを補助するためのものとして、図を入れた方が良い場合もある。

ただコメントをなるべく書かないほうがいいと言われてると同じように
図もメンテナンスが大変になるので出来る限り少ないほうがいい。

日本語による説明文章は、コードの近くにコメントとして書くべきだが
全体に関することなど、コードの近くに書けないものは別に書いた方がいいが
もちろんそれも出来る限り少ないほうがいい。

コードは設計書であるのだから、ソースコードがある以上、設計書が全く
無いなんてことはありえない。だから安心してコード以外の設計書は減らしていい。

コードは設計書なのだから、それ以外の設計書は必要最低限でいいのだ。

0433仕様書無しさん2016/02/07(日) 12:34:15.34

つまり必要最低限は必要な場合もあるわけだ。
たいていの場合、コメントやドキュメントが多すぎて問題なのは理解できるが
まるっきりないのもたいていの場合、問題だけどな。

ほどほどが正解だが正確にそのほどほどを伝えるのはかなり難しい。

0434仕様書無しさん2016/02/07(日) 12:51:02.08

設計書を作業指示書と勘違いしてはいけないのだ。

日本はSEとプログラマとかにわかれていて設計書をもって
プログラマに指示しているからこんな訳のわからないことになる。

設計している人がプログラマであるならば何がコードだけで良くて何が図として必要かがわかる。
一例を上げると（コードではない、例えばエクセルなどの）設計書を読み取ってソースコードや
データベーススキーマを出力するツールがあればなと思ったら、
それは最初からコードで書くべきことだ。

プログラミングが出来ない＝設計能力がないやつが設計書なんか作るから、
無駄な工数がかかって、間違いだらけ、漏れだらけで使いものにならない
（コードではない）設計書が出来上がるんだよ。

0435仕様書無しさん2016/02/07(日) 12:56:17.18

>>434
おまえ自己紹介でお一人様だって言ってなかったか？

0436仕様書無しさん2016/02/07(日) 13:03:51.56

>>435
何をどう勘違いしたのｗｗｗｗ
あなたちょっとマヌケですね。

0437仕様書無しさん2016/02/07(日) 13:42:51.51

>>406
設計書必要論者でもコードレベルの詳細設計書が必要だと言ってるやつはいないだろう。
職場で求められて書かされる場合はあるかもしれないが。

0438仕様書無しさん2016/02/07(日) 13:48:22.23

コードレベルの詳細設計書を書く能力がないからなｗ

0439仕様書無しさん2016/02/07(日) 13:55:37.83

>>431
事前に改修の入る場所がわからなくても、どう改修すれば既存の設計を壊さずに改修できるのかを
素早く判断できるようにしておくのは有用。
コードの解析から始めると引数一ついじるだけの改修に二時間かかったりする。
(元のコードを書いたやつは設計知ってるから数分でやれるんだけど)

0440仕様書無しさん2016/02/07(日) 14:00:49.80

>>439
そういう情報はコードを読める人にしか書けませんね。
コードではない設計書には書くことが不可能な情報です。

0441仕様書無しさん2016/02/07(日) 14:04:41.47

>>434
>一例を上げると（コードではない、例えばエクセルなどの）設計書を読み取ってソースコードや
>データベーススキーマを出力するツールがあればなと思ったら、
>それは最初からコードで書くべきことだ。
めんどくせー
スキーマの元となるデータがエクセルでやってくることはよくあるけど、
いちいちそれを手作業でコードに写すの？
プログラマならめんどくせー、自動化しようぜって思わない？

0442仕様書無しさん2016/02/07(日) 14:06:16.45

>>440
コードは読めるけど、コードじゃない設計書を書く能力がないと言ってるという認識でおk？

0443仕様書無しさん2016/02/07(日) 14:09:51.41

>>440
あ、もしかしてSEがコードじゃない設計書を書いて、
PGがコードを起こすという前時代的なやり方しか知らない？

0444仕様書無しさん2016/02/07(日) 14:26:23.80

>>441
何言ってるんだ？
エクセル作る必要ないだろ。
最初からコードで書けばいいだけの話。

エクセルとコードの二重管理になって、
エクセル修正するのが面倒で仕様と実装が食い違ってる原因は
エクセルから変換しようとするからだぞ。

0445仕様書無しさん2016/02/07(日) 14:30:23.20

>>428
バカを想定したドキュメントなんて作り始めたらキリがない
それよか目の前に成果物そのものがあるんだから読めって話

プログラマがコード読めないって
翻訳家を名乗ってる人間が、通訳たてないと外人と喋れない状況と同じだよな

0446仕様書無しさん2016/02/07(日) 14:35:05.41

>>445
そう言ってコードを抱え込むメンバーが一番いらないんですよ。

あと、成果物って、コンパイラが生成するんじゃないの？
コード＝設計書くんの主張では。

0447仕様書無しさん2016/02/07(日) 14:36:26.13

>>444
客にコード書けということですね。
この際だから、全部書いてもらいましょう。

0448仕様書無しさん2016/02/07(日) 14:41:43.42

>>445
仕事って個人の能力を誇示する場じゃないからねー
たと馬鹿相手だとしても、それを書くことで
プロジェクトがスムーズに進むなら書くべき。

0449仕様書無しさん2016/02/07(日) 14:42:40.52

>>446
設計書君にとっては設計書も成果物なんじゃないの？
誰かここに書いてたけど

0450仕様書無しさん2016/02/07(日) 14:44:47.78

>>448
最低能力に達してない素人がプロになったつもりで
仕事のふりなしてんじゃねえよと

0451仕様書無しさん2016/02/07(日) 14:46:22.78

>>445
プロジェクトにとってみんなが設計を理解するメリットより
俺がコード書けなくなるデメリットの方が大きいというなら、
そう言って認めさせればいいこと。

0452仕様書無しさん2016/02/07(日) 14:53:22.56

>>451
コードを読むってのはプロで食ってるなら最低限の能力
プログラマがますます神に近付いてるな

0453仕様書無しさん2016/02/07(日) 14:58:07.69

>>446
プログラムを読み書きする程度のスキルもないのに
この業界で、このプログラマ板で、いったい何してんのよ？

0454仕様書無しさん2016/02/07(日) 15:00:34.37

４４６
なんちゃって性留守営業

0455仕様書無しさん2016/02/07(日) 15:02:56.31

>>453
ものによるからなあ。hello wold程度なら
コード読めでいいけど、複雑なものになると
概略を示した文書がほしい。非機能要件のために破格なロジック組むこともあるし。

0456仕様書無しさん2016/02/07(日) 15:10:31.82

最近は、プログラムにイラスト書いたりするよね。

0457仕様書無しさん2016/02/07(日) 15:11:03.14

>>453
え？
いつプログラムを読み書きする能力がないって言った？
君、いつも仕様書読み間違ってるでしょ。

0458仕様書無しさん2016/02/07(日) 15:14:16.62

>>447
今は設計書の話をしている。
設計書は客のために作るものではない。

0459仕様書無しさん2016/02/07(日) 15:18:58.70

>>458
オナニーのときのおかず用だよね。

0460仕様書無しさん2016/02/07(日) 15:21:44.73

>>458
客の情シスから項目一覧がくることはよくあるんですよ。
フォーマットはいろいろだけど。
顧客とやりとりしないとわからないだろうけど。

0461仕様書無しさん2016/02/07(日) 15:24:03.79

> 客の情シスから項目一覧が

SQL渡せば終わりだな。

表形式にすると、どうせトリガーなどの情報が抜け落ちるだろうに
なぜ表形式に "整える" だけのことにこだわるのか？
本当に仕事が、幅調整になってるよな。

0462仕様書無しさん2016/02/07(日) 15:25:35.30

>>461
RDBMSじゃない場合も多いんですねー

0463仕様書無しさん2016/02/07(日) 15:27:45.08

RDBMSじゃなくてもスキーマは存在する。

どうせエクセルからデータベース構造を作れるわけがないんだから

0464仕様書無しさん2016/02/07(日) 15:35:48.31

>>463
いずれにせよ、既存のデータから手作業でいきなりコード書くのは馬鹿ですね。
普通は自動化しようと思いますから。
既存DBのスキーマをパースするくらいなら、客にエクセルにでも
まとめてもらって、そっから自動生成した方が楽。

0465仕様書無しさん2016/02/07(日) 16:10:36.86

>>445
ソフトウェアって、規模が大きくなって運用基幹が長くなるほど
コードを書いている時間よりコードを読んでいる時間のほうが多くなるもの。
たとえコードが書かれた時間と同じ時間で読める凄腕のプログラマを揃えたとしても、
10人が読めばコードが書かれた時間とコードが読まれた時間の比は 1:10 になる。
書かれた時間と読まれた時間の合計は11だな。

だから、ソフトウェアを作る上ではいかにコードを読む時間を少なくするかのほうが大事。
コードを書くのと同じ時間だけかけて設計書を書く(でもなんでもいいけど)ことで
コードを読む時間が3/4になるとすると、コードが書かれた時間と設計書が書かれた
時間とコードが読まれた時間の比は1:1:7.5になる。
合計は 9.5 だな。

どちらのプロジェクトがいけてるかは一目瞭然だな。

あ、ここでの設計書はコード以外の設計書ね。
(いちいち注釈入れてあげないといけないのが面倒臭い)

0466仕様書無しさん2016/02/07(日) 16:33:26.80

まあ設計書でもコードでもいいけど読み手の都合を考慮しないで書いてる奴は
SEだろうとプログラマだろうとそのうち仕事なくなるよ。

0467仕様書無しさん2016/02/07(日) 16:47:41.76

設計書が信用できないので結局コードも読む羽目に

0468仕様書無しさん2016/02/07(日) 19:11:02.56

>>464
頭大丈夫？

自動化を手に頑張ってるみたいだけど、
完全な設計書であるソースコード（この場合はスキーマ）から
ドキュメントを生成したほうがいいんですよ。

エクセルではソースコードで出来ること全てを表現することは出来ないのですから、
エクセルで出来ることしかできなくなってしまいます。

例えばRDBで言えば主キーやユニークキーどうするつもり？新たなフィールド追加ですかｗ
外部キー制約とかどうするつもり？これも新たなフィールド追加ですかｗ
制約条件とかどうするつもり？またフィールド追加ですかｗ
トリガーどうするつもり？あ、なんか特殊なセルにコード書くんですかｗ
いろんな機能に対応しないといけないですね。

おやおや、エクセルの見た目がcreate tableの単語をセルに
埋め込んだだけみたいになってますよｗ

エクセルからの完璧な変換ツールでも作るつもり？ｗ

0469仕様書無しさん2016/02/07(日) 19:12:14.93

>>464
> 既存DBのスキーマをパースするくらいなら、客にエクセルにでも

既存のパーサーにやらせれば終わり
情報はコードで簡単に取得できる。

ソースコード書けないSEには無理でしょうけどねｗ

だからぁ、プログラマが設計しろっていうんだよ。

0470仕様書無しさん2016/02/07(日) 19:21:40.55

エクセルから自動化して生成するとかアホだよな。
テキストからならawkでも使って簡単に生成できるのに。
客も項目をメールにでも羅列したほうが楽だろうに。

0471仕様書無しさん2016/02/07(日) 19:35:04.87

初期データをexcelで作るのはいいけど、格納したらDBとかから情報出すよね普通。

0472仕様書無しさん2016/02/07(日) 19:41:39.02

上から下へ流れるだけだと思ってる人は、
後から修正するってことを考慮できないのさ。

客から貰えばそれでOK、
そこから半自動生成でスキーマっぽいものを作って
足りない技術的情報を手作業で埋めてDBに格納
これで終わりだと思ってしまう。

実際には足りないものが合ったり間違いが合ったりするわけだが、
またそれを最初からやり直し、客に修正したものをエクセルでもらって
そこから半自動生成で（略）手作業で足りないものを（略）

修正あるなら修正点だけ聞けばいいだろ。そこからコードを修正して
自動生成でエクセルでもPDFでも作ればいい。それらは閲覧専用だ。

0473仕様書無しさん2016/02/07(日) 21:16:49.49

>>469
既存のパーサーって何？
パーサーってどんなものかわかってる？

0474仕様書無しさん2016/02/07(日) 21:18:58.39

設計書に必要な情報
～の強度を持つ板2枚を～の締め付けトルクで接合する

ソースコードに書かれた情報
3mmの鉄板2枚をネジを30回まわして接合する

こんなのを設計書って言っちゃうコーダーってｗ

0475仕様書無しさん2016/02/07(日) 21:35:52.83

validationデータをテーブルでやスクリプトで管理してるので大丈夫ですよー。

0476仕様書無しさん2016/02/07(日) 21:58:47.20

「テーブルやスクリプト」ってそのレスに必要？ね？

しかも真顔で「ちゃんと30回したかテストするコードがあるので大丈夫です！」とか言っちゃって
どうしようもない理解不足を露呈してしまうなｗ
これがコーダーの実態ですｗｗ

0477仕様書無しさん2016/02/07(日) 22:05:34.89

それ仕様だし

0478仕様書無しさん2016/02/07(日) 22:14:47.35

設計とは仕様を作る事だからな
工程か進むに従ってより詳細になっていくが
どこまでいっても出力が仕様である事に変わりはない

0479仕様書無しさん2016/02/07(日) 23:01:07.04

>ソースコードに書かれた情報
>3mmの鉄板2枚をネジを30回まわして接合する

//三十回まわす
for( int i = 0; i < 30; i++){
　　iron　+= screw;　//ねじを接合
}

こんな感じかな。

0480仕様書無しさん2016/02/07(日) 23:28:22.46

>>473
わかってないのはお前では？ｗ

0481仕様書無しさん2016/02/07(日) 23:29:31.98

>>475
何のために？

0482仕様書無しさん2016/02/08(月) 03:24:33.25

コードどデータがまちがっていたから、どうやって間違いに気付くのでしょうか？

0483仕様書無しさん2016/02/08(月) 05:00:38.47

設計が間違っているのと同じ理由で気付のでは?

0484仕様書無しさん2016/02/08(月) 06:58:14.49

>>474
それ仕様じゃん、しかもそこから固定値のコードは書けないし
「3mmの鉄板2枚を～」ってのは設計書に書くもんだぞ
そのうえ、設計書にそう書かれてたらコメントも何も残らない。
一方、ダイレクトにコード化してれば、必要な理屈はすべてコメントに残すけどな。

0485仕様書無しさん2016/02/08(月) 06:59:18.69

>>455
必要なら後からでもいくらでも書けるじゃん。それも事前作成よりも正確に。
先に書いとけって理屈にはならない。

>>457
>>446のコードを抱え込むって、プログラマにしかコードが読めない
。
つまりおまえにはコードを読むことができないってことだろｗ

>>465
なんのためのオブジェクト設計思考よ？
ぜんぜん活用できてないな。
そんなんじゃ設計書書いても何も変わらねえぞおまえじゃ。

0486仕様書無しさん2016/02/08(月) 07:07:48.10

設計書必要派の思考が、「事前作成の必要性」から
いつの間にか「後で必要だから」に変わってるなｗ

後で必要なら、事前に作成する必要性は無いわけだ。
>>474みたいに書いた本人さえ理由がわからなくなりそうなものは
必ずコメントに残すしな。
設計書から起こしたコードだとそうはならないけど。

0487仕様書無しさん2016/02/08(月) 07:28:16.74

修正時にソースが読めなくて設計書から洗い出す必要があるんじゃ
設計書の情報が古かったり不備があったら即死だな

0488仕様書無しさん2016/02/08(月) 08:07:44.00

>>486
変わってないけど？何の夢見てんだお前ｗ

0489仕様書無しさん2016/02/08(月) 08:18:53.43

>>487
> 修正時にソースが読めなくて設計書から洗い出す必要があるんじゃ

問題は、なんでそうなるのか？だよな。

ソースコード＝設計書だと考えると、めちゃくちゃな
設計書を作ることが問題だと気づくはず。

で、ソースコードの内容全てが（コードではない）設計書に書いてあるならば
たしかにそれから、ソースコードを読む手がかりになるかもしれないが、
実際には書いていない。

重要な事だからもう一度言う。（コードではない）設計書には
ソースコードのに書かれていることの全ては書かれていない。

だからソースコードを読まないといけないし、ソースコードがぐちゃぐちゃだから
どこかの会社がソースコードから（コードではない）設計書を作り出すツールを作っているようだが、
ぐちゃぐちゃなものから綺麗な（コードではない）設計書は作り出せない。

だから最初からやらないといけないことは明らか。
ソースコードを設計書だと考えて、綺麗な設計書（コード）を作ること。

0490仕様書無しさん2016/02/08(月) 08:21:06.33

>>486
本当に頭のなかがお花畑だな

0491仕様書無しさん2016/02/08(月) 09:18:03.14

ソースコードに業務手続き内容まで書くなら設計書だろうがな。
現実はソースにゃ処理内容しか書かんからなぁ
だからその処理がどんな前提で動作する物かも分からんしな。
結局ソースコードが設計書と言うには無理があり過ぎだ。

0492仕様書無しさん2016/02/08(月) 09:37:13.30

>>491
お前バカか？

> ソースコードに業務手続き内容まで書くなら設計書だろうがな。

お前、UML図に業務手続内容まで書かないから、
UML図は設計書じゃないと言うつもりか？

はぁ～ｗお前本当に馬鹿だよｗ

0493仕様書無しさん2016/02/08(月) 09:38:55.28

業務手続き内容は、設計書に書かないよ？

0494仕様書無しさん2016/02/08(月) 09:43:18.37

業務内容は仕様であって設計じゃないな

0495仕様書無しさん2016/02/08(月) 09:45:31.13

どちらにしてもソースは完全な設計書で漏れがないとかいう説をといてるやつはバカ。一応いっとくが前スレにいたやつにいっている。

0496仕様書無しさん2016/02/08(月) 09:49:54.13

そんなやつ居た？

0497仕様書無しさん2016/02/08(月) 09:50:07.52

ソースコードは完全な設計書であってるよ。
ソフトウェアの設計が全て記述されている。

0498仕様書無しさん2016/02/08(月) 09:50:50.00

業務手続き内容は設計書に書いてはいけません。

設計書というものをわかってないようですねｗ

0499仕様書無しさん2016/02/08(月) 09:54:14.99

ソースコードにはソフトウェアの設計が全て書かれている。

だがサーバー構成などの設計は書かれていないのだ！

いや、だからソースコードには「ソフトウェアの」設計が
全て書かれているんだってばｗ

0500仕様書無しさん2016/02/08(月) 09:55:43.00

【IT】日立、COBOLアプリをJavaアプリに変換するサービス開始　COBOL技術者の人材減少避けられず脱却を促す [無断転載禁止]©2ch.net
http://potato.2ch.net/test/read.cgi/bizplus/1454890942/

> プロジェクトの最初に取り組む分析工程において、現行システムの仕様をリバースエンジニアリングする
> 「現行システム資産分析支援」機能を提供する。「ドキュメントが無い、あってもプログラムと乖離しているというのが
> 多くのCOBOL資産の現状」と情報・通信システム社アプリケーションサービス事業部サービスソリューション本部
> サービス統括部の広瀬雄二担当部長は話す。

0501仕様書無しさん2016/02/08(月) 09:56:48.55

最近はインフラ構成管理もコードでやるようになってるけどな。
どんどんコード化が進んでいる。クラウドとかDockerとか知ってる？
今やコードを読めないと設計も読めない。

0502仕様書無しさん2016/02/08(月) 09:56:49.82

要求定義と何１つリンク出来て無い書類なんか何を幾ら積み上げても無意味だからな。

0503仕様書無しさん2016/02/08(月) 09:59:18.23

シェフにおまかせ

0504仕様書無しさん2016/02/08(月) 10:02:25.42

>>499
後付けばっかだな

0505仕様書無しさん2016/02/08(月) 10:54:36.28

なんか長々とどうでもいい議論が続いているが、コードが設計書かどうかなんてどうでもよくて、

>>489
> めちゃくちゃな
> 設計書を作ることが問題
というだけ。

つまり、有用な設計書を作れということ。

0506仕様書無しさん2016/02/08(月) 11:00:13.04

>>489
> 重要な事だからもう一度言う。（コードではない）設計書には
> ソースコードのに書かれていることの全ては書かれていない。
あたりまえだな

> ソースコードを設計書だと考えて、綺麗な設計書（コード）を作ること。
別にソースコードが設計書と考えなくとも、綺麗なコードは書くべきだな

0507仕様書無しさん2016/02/08(月) 11:13:44.53

>>506
> 別にソースコードが設計書と考えなくとも、綺麗なコードは書くべきだな

自称設計者が、綺麗なコードに関してむとんちゃくなんだよ。特にSI業界は。

（コードではない）設計書と一致してない上に
ソースコードめちゃくちゃで解析ツールがーとか本末転倒な
ことやってるのは、設計者がしっかりコードの内容をレビューしてないから。

そりゃ品質も上がるわけないね。設計者が見るべきコード（設計書）を
ないがしろにしているわけだからね。

設計者はコードを見なくていいと思っている奴がいる限り
ソースコードは設計書であると言い続けるよ。

0508仕様書無しさん2016/02/08(月) 11:26:50.37

そもそも、詳細設計者！＝コードを書く人な環境が、現代においては特殊環境だな

0509仕様書無しさん2016/02/08(月) 11:39:12.36

>>486
> 後で必要なら、事前に作成する必要性は無いわけだ。
後で必要というより、後から書いた方がより工数が少なく意味のある物が書ける。

0510仕様書無しさん2016/02/08(月) 11:46:25.85

>>507
コードレビューは第三者がしろよ。
お前の所は、設計者とコーダーの二人しかいないのかよ。

0511仕様書無しさん2016/02/08(月) 11:50:25.04

>>510
第三者に設計者の考えをまとめた資料を作れって話か？ｗ

0512仕様書無しさん2016/02/08(月) 11:51:44.79

人を増やせば増やすほどコミュニケーションのコストが
かかるって知らないんだな。

0513仕様書無しさん2016/02/08(月) 12:19:46.84

>>510
設計者と第三者じゃ観点が違うだろうがアホ

0514仕様書無しさん2016/02/08(月) 12:30:06.84

>>507←風車に立ち向かうドンキホーテｗ

0515仕様書無しさん2016/02/08(月) 12:37:28.98

>コードレビューは第三者がしろよ。
>お前の所は、設計者とコーダーの二人しかいないのかよ。

おれんところは、人材がいない。俺が開発して、あとは高卒がそれを少し手直しする。
おれがこけたら、外注でもつかって開発しろよー、って感じ

0516仕様書無しさん2016/02/08(月) 12:50:50.74

>>513
観点が違う奴がレビューしなくてどうする。

0517仕様書無しさん2016/02/08(月) 12:51:26.41

つか、コードレビューのことすらわかってなかったのか。

0518仕様書無しさん2016/02/08(月) 13:05:30.26

>>511
設計者がコード書く奴に渡した資料見せればいいだろ
アホか

0519仕様書無しさん2016/02/08(月) 13:51:22.21

設計書君は、まず自分のチーム・部署・会社の技術レベルの底上げをすべきだね。

0520仕様書無しさん2016/02/08(月) 13:55:25.77

>>507
> 設計者はコードを見なくていいと思っている奴がいる限り
そんな時代錯誤な奴どこにいるんだろう？？
だいたいどこでもプロジェクトの体制によって設計が主業務になる人はいても、
コード見ないってことはないし、設計通りにコードが書かれているかのレビューは
設計者が確認するのが普通では？

(ここでの設計書はコード以外の設計書という意味ね)

0521仕様書無しさん2016/02/08(月) 13:58:28.89

>>519
大規模SI現場でど底辺PGやっててチーム・部署・会社の技術レベルの底上げなんてやらせてもらえないのでは。

0522仕様書無しさん2016/02/08(月) 14:06:33.01

あり得ないレベルの話（設計者はコードを見なくていいと思っている奴とか）を持ち出しても、
そこから一般論は出てきません。

0523仕様書無しさん2016/02/08(月) 14:56:34.24

主語広すぎ
SI業界はとか言うな

0524仕様書無しさん2016/02/08(月) 15:59:56.43

>>513
> 設計者と第三者じゃ観点が違うだろうがアホ
設計者が詳細設計して、コード書く奴に渡して、コードができたら設計者がレビューして、
指摘事項を修正して・・・みたいなサイクルでやるんなら、設計者がコード書く方が工数も
少なく品質も高いものができるな。

0525仕様書無しさん2016/02/08(月) 17:21:51.19

>>524
それ単に、入社1,2年目のプログラマを育てるメソッドじゃ・・・

0526仕様書無しさん2016/02/08(月) 18:14:46.44

お前ら「設計者」は何人いるんだ？
まさか1人（＋管理役？）じゃないよな？

プログラマに対して、それよりも大幅に少ない設計者じゃ
コードレビューなんて追いつかないだろ。

それは、設計者とプログラマがわかれているからだよ。
コード＝設計であり、コード書くプログラマ＝設計者ならプログラマと
設計者の数は同数、これなら誰にもレビューされないコードは無くなる。

コードレビューではなくて偉い人がOKをだすという考えの
コード監査になってしまっていては、開発効率は上がらない。
全員がお互いのコードをレビューアしあうようにならなくてはいけない。

そういやどこかの企業で上級プログラマが他の人ならばやっているレビューを省いて
作ったプログラムを実行して、単純ミスのバグでデータを消してしまった事件あったよな？
こういうのは技術力が上の人が書いたコードを、低い人がレビューしても見つけられたはず。

レビューは上の人が与える許可じゃない。相互の確認。そして情報の共有が目的だ。

設計者（コード書かない）がプログラマのコードを確認するという考えも間違いなんだよ
設計者＝プログラマが相互にコードを確認しあうというのが正しい。

>>525
指差し確認っていうのは、新人がミスするからやるものではないよ。
誰でもミスするのだから、どんなものでもコードレビューは必要。

0527仕様書無しさん2016/02/08(月) 18:36:06.83

>>526
> 指差し確認っていうのは、新人がミスするからやるものではないよ。
> 誰でもミスするのだから、どんなものでもコードレビューは必要。

「詳細設計をせずコードしか書かない奴」
「詳細設計しかしない奴」
という役割にして、>>524のようなことをするのなら、それは
「入社1,2年目のプログラマを育てるメソッド」
だということだ。

0528仕様書無しさん2016/02/08(月) 18:37:40.60

>>526
> お前ら「設計者」は何人いるんだ？
> まさか1人（＋管理役？）じゃないよな？
あと、一体どこからこんな疑問が出てきたんだ？

0529仕様書無しさん2016/02/08(月) 18:44:21.48

>>528
コード＝設計書くんの職場がそういう体制なのでは。

0530仕様書無しさん2016/02/08(月) 18:45:17.83

重要な点は一人かどうかじゃないよ。
全コードをコードレビューできる人数がいるかどうかだ。

0531仕様書無しさん2016/02/08(月) 18:56:34.64

設計書なんて責任を明確にする為に残されているだけ。本当の意味の設計書なんて見たことないよ。

grepで処理追って、修整が上手くいかなかったら設計書を根拠にそっちが悪いゴラァ！っつって突き返すためだけにあるもの。

0532仕様書無しさん2016/02/08(月) 19:37:21.09

窓際社員だろ。

0533仕様書無しさん2016/02/08(月) 20:53:01.94

>>490
罵声だけのレスは、完璧に論破された証拠だぞｗ

0534仕様書無しさん2016/02/08(月) 21:28:55.00

>>474
仕様書と設計書で書くべきことの区別すらついてない奴が設計書を書いてるのか
そんなグッチャグチャの設計書を渡されるプログラマ、
糞のような資料を残された後釜社員

悲惨だな

0535仕様書無しさん2016/02/08(月) 22:03:08.68

どうせ変わり者で、あまり重要じゃない仕事を渡されて、ドキュメントを書かない

0536仕様書無しさん2016/02/08(月) 22:04:33.71

、テストしない分、暇で定時帰りで、飲食店で働いているんだろうな。

0537仕様書無しさん2016/02/08(月) 22:06:39.71

パッケージソフト屋の腫れ物的存在だろうな。

0538仕様書無しさん2016/02/09(火) 01:23:47.17

>>532 >>535-537
自分が理解できないものへの不安と恐怖がレスに現れている

0539仕様書無しさん2016/02/09(火) 02:07:48.77

>>531
低レベルな環境にいるね。意識を高く持ってるつもりになって、周りより自分のほうがマシだと思ってるかもしれないけど、
受け売りでわかったつもりになっているだけのお前と、よりよい開発を日々求めて実践している俺たちとでは
実力差は広がっていく一方。お前もう詰んでるよ。

0540仕様書無しさん2016/02/09(火) 07:23:49.07

>>535
ソースも、ソースのコメントもドキュメントだぜ
それも処理と１：１という、これ以上ないほど直感的なドキュメント
ソースファイルもクラスも階層表示できるし
ソースはそれ自体がネストされてるし
人もコンパイラも読める一石二鳥、一挙両得

0541仕様書無しさん2016/02/09(火) 07:25:59.89

>>536
残業しないと仕事をしてないと考えるザンネンなタイプかよ
残業は、日中仕事をしてないか、仕事が遅いか、残業代目的か
個人の業務量が見合ってない経営上の問題か、はたまた帰りにくい雰囲気か
いずれにせよプラスではないな

思考が柔軟で経験が豊富、設計も開発もテストも効率的だから
単純に仕事のスピードがおまえさんとは桁違いなだけだよ
この業界、型にはまってる、はまらないと仕事ができない
填めようとしてる人間が一番使えない人間

0542仕様書無しさん2016/02/09(火) 09:24:56.81

朝は部下のメール確認、昼は他案件の営業、夕方は客の問い合わせ対応、コード書くのは夜になるんだよ。

0543仕様書無しさん2016/02/09(火) 09:32:10.90

自転車操業だな

0544仕様書無しさん2016/02/09(火) 09:34:01.62

> 朝は部下のメール確認
と 2ch

0545仕様書無しさん2016/02/09(火) 11:39:30.17

いきなりコード書いて、かたまっているやつがいるなｗ

0546仕様書無しさん2016/02/09(火) 12:49:46.67

設計書いらない派は有用な設計書を見たことないのを恥ずべきで
設計書いる派は有用な設計書の書き方を啓蒙するべき
このスレ見てると設計書いらない派は視野が狭く見えて
設計書いる派はその視野せまいヤツすら騙せない無能な詐欺師に見える

0547仕様書無しさん2016/02/09(火) 13:00:50.65

>>542
ずいぶん小さなシステムなんですね。

この言動からパッケージソフトであることが明確になりました。

パッケージソフトなら設計書を書かないところはあるので、納得しました。

やっぱり一般論ではなかったのですね。

0548仕様書無しさん2016/02/09(火) 13:10:30.69

>>546
お前、なにか言ってるようで何も言ってないよなｗ
ごちゃごちゃ言う前に有用な設計書というのを示せばいいじゃんか。

なお、コードが設計書というのは、別にその他の資料が要らないという意味じゃない。
コードと重複する資料、単なる作業指示しょになってるだけで
コード読めば十分なものは要らないがな。

0549仕様書無しさん2016/02/09(火) 13:11:25.83

>>547
お前の業界が一般的じゃないんだよｗ

0550仕様書無しさん2016/02/09(火) 13:46:31.33

>>546
> 設計書いらない派は有用な設計書を見たことない
という思い込みをまず捨てるべき。

> このスレ見てると設計書いらない派は視野が狭く見えて
> 設計書いる派はその視野せまいヤツすら騙せない無能な詐欺師に見える
設計書いる派の方が視野が狭いと見える。

0551仕様書無しさん2016/02/09(火) 13:47:57.50

コード＝設計書の奴が一番視野が狭いけどな

0552仕様書無しさん2016/02/09(火) 13:57:36.47

>>550
有用な設計書を見たことがあれば、
設計書は役に立つということ、どのような設計書を書けば良いのか
が理解出来ているはずだが。

(ここでの設計書はコード以外の設計書という意味。念のため)

0553仕様書無しさん2016/02/09(火) 14:07:03.27

>>552
> が理解出来ているはずだが。
だから理解できてないという思い込みを捨てろ。

設計書を作るかどうかというのは、単に有用かどうかだけではなく様々な判断が必要。
お前の想像している「設計書」を書かないという選択をしたからといって、有用ではないと
判断しているわけではない。

0554仕様書無しさん2016/02/09(火) 14:15:59.63

つまり、設計書のいらない程度の簡単なソフトを作ってるということですね。

(ここでの設計書はコード以外の設計書という意味。念のため)

0555仕様書無しさん2016/02/09(火) 14:20:47.32

>>554
CookPadでレシピを表示するくらいのことしかしないんでしょ

的な話であれば、それを「簡単」と判断するのはお前次第であり、不毛な議論。

0556仕様書無しさん2016/02/09(火) 14:24:00.07

>>554
amazon.comは1時間に最大1000回デプロイされるんだが、そのコード全てに設計書が存在してると思ってる？
それとも、amazon.comとか簡単なソフトでしょと思ってる？

0557仕様書無しさん2016/02/09(火) 14:26:33.74

>>556
> amazon.comは1時間に最大1000回デプロイされるんだが、そのコード全てに設計書が存在してると思ってる？
必要な設計書は作ってるでしょ。

(ここでの設計書はコード以外の設計書という意味。念のため)

0558仕様書無しさん2016/02/09(火) 14:27:41.27

むしろamazon.comが設計書なしで作られてると考えるほうが現実離れしてるだろ。
(ここでの設計書はコード以外の設計書という意味。念のため)

0559仕様書無しさん2016/02/09(火) 14:29:00.52

設計のアウトプット（設計書とは限らない）の目的は、
・設計そのものを推進するため
・メンバーとの知識の共有のため
・メンテナンスの資料として
・ステークホルダーへの提出資料として
などがある。

開発プロセスや、対象アプリの分野・性質、会社やチームの性質、ドキュメントにすることによる工数、
それらを総合的に判断して、それを「設計書」という形にした方が良いのかどうかが決定される。

今の自分の立ち位置で「設計書を作ること」がベストだとしても、他でもそうだとは限らない。

0560仕様書無しさん2016/02/09(火) 14:30:19.07

>>557
> 必要な設計書は作ってるでしょ。
そういうエクスキューズはやめようぜ。

> むしろamazon.comが設計書なしで作られてると考えるほうが現実離れしてるだろ。
設計書なしで作られるケースもあるということだ。

0561仕様書無しさん2016/02/09(火) 14:30:36.10

>>553
なるほど。
「有用な設計書」を書かないという選択をする理由を教えてくれ。
(ここでの設計書はコード以外の設計書という意味。念のため)

0562仕様書無しさん2016/02/09(火) 14:33:01.20

>>561
ドキュメントという形にせずとも、他の手段でメンバーと知識の共有ができ、コーディングに取りかかれるのなら
別に作る必要はない。

・・・というのが過去10年以上にわたって「アジャイルvsドキュメント」という議論がなされてきたんだが、知らないのか？

0563仕様書無しさん2016/02/09(火) 14:33:10.53

>>559
・設計そのものを推進する必要ない
・メンバーと知識を共有する必要がない
・メンテナンスする必要がない
・ステークホルダーに資料を提出する必要がない
開発って、個人的なものに限られるんじゃね？

0564仕様書無しさん2016/02/09(火) 14:33:30.29

>>557
> > amazon.comは1時間に最大1000回デプロイされるんだが、そのコード全てに設計書が存在してると思ってる？
> 必要な設計書は作ってるでしょ。

つまり、コード全てに設計書は存在していないってことなわけね

0565仕様書無しさん2016/02/09(火) 14:34:17.27

ぶっちゃけ、（コードではない）設計書は作業指示書じゃないんだから、
必要ないならば作らなくていいんだよ。
いきなりコードを書いていい。

0566仕様書無しさん2016/02/09(火) 14:35:15.68

>>563
> 開発って、個人的なものに限られるんじゃね？

全然？

他人と情報を共有するならば、コードを読めばいい。

0567仕様書無しさん2016/02/09(火) 14:35:57.55

>>562
アジャイルはドキュメントを書かない
というのは、よくあるアジャイルに対する勘違いですね。

0568仕様書無しさん2016/02/09(火) 14:36:29.40

俺が作る設計書は全て必要なものであり十分

お前は設計書を作ってるかもしれないが、不十分という決めつけ

だと話はいつまでたっても平行線

0569仕様書無しさん2016/02/09(火) 14:36:33.64

>>564
え？
今更そんな議論やってるの？
９０年代から進歩してないんじゃないの？

0570仕様書無しさん2016/02/09(火) 14:38:11.86

開発するときにコードは必ず読まなくてはいけない。

開発するべき時に読むべきものを減らすならば
絶対に読まなければいけないコードだけで
わかるようにするのが一番コストが少ないんだよ。

どうしてもそれが難しい場合にのみ、その他の資料を
追加すればいいわけで。

どうせ資料作っても実際に動くと一致しているかわからん。とか
なってるじゃん。資料を作れば作るほど。
減らせば減らすほど、開発のコストは減るんだよ。
もちろんコードも減らせば減らすほどいい。

0571仕様書無しさん2016/02/09(火) 14:38:13.90

>>567
誰もアジャイルはドキュメントを書かないとは言ってないけど

0572仕様書無しさん2016/02/09(火) 14:38:28.45

>>568
> 他人と情報を共有するならば、コードを読めばいい。
と言い切っちゃう奴が十分なドキュメントを作ってるとはとうてい思えないんだけどね。

0573仕様書無しさん2016/02/09(火) 14:38:50.28

>>569
SI業界が進歩しないのは今に始まったことじゃない。

0574仕様書無しさん2016/02/09(火) 14:39:41.63

>>572
だからその思い込みを捨てろって。

0575仕様書無しさん2016/02/09(火) 14:39:58.60

>>571
アジャイルは有用な設計書を書かないってレスがあるよ？
(ここでの設計書はコード以外の設計書という意味。念のため)

0576仕様書無しさん2016/02/09(火) 14:40:21.04

>>572
お前の十分と他人の十分が違うとは、どうして想像できないのか

0577仕様書無しさん2016/02/09(火) 14:41:06.64

「コードがドキュメントだ」とうそぶくことは簡単ですが、「ドキュメントであるかのようなコード」
「ドキュメントが不要なコード」を書くのはとても難しいです。
また、コードだけでは「なぜこの設計にしたのか」「なぜ他の設計にしなかったのか」という設計判断の根拠が残せません。
アジャイルプロセスはコードを重視するプロセスではあっても、偏重するプロセスではありません。
コードとドキュメントの間でバランスを取ってこそのアジャイルプロセスなのです。

0578仕様書無しさん2016/02/09(火) 14:41:43.04

>>575
有用な設計書は必ず書くべきという反論はした覚えはあるが、いつでも書かないとは誰も言ってない

0579仕様書無しさん2016/02/09(火) 14:42:42.34

>>577
> また、コードだけでは「なぜこの設計にしたのか」「なぜ他の設計にしなかったのか」という設計判断の根拠が残せません。
> アジャイルプロセスはコードを重視するプロセスではあっても、偏重するプロセスではありません。
それが必要なら後から作ればいいし

0580仕様書無しさん2016/02/09(火) 14:49:48.89

>>576
他人と情報を共有するならば、その都度必要な資料を作ればいい
とかならまだわかるけど「コードに全てが書いてあるのでそれ読めばいいじゃん」
って言ってるやつは信用できないね。

0581仕様書無しさん2016/02/09(火) 14:59:42.65

>>577
> また、コードだけでは「なぜこの設計にしたのか」「なぜ他の設計にしなかったのか」という設計判断の根拠が残せません。

それだけがドキュメントで必要なものですねｗ

しかし、コードを見て「なぜこの設計にしたのか」って思うわけですよね？
コードを見て設計がわかるんですよね？ｗ
そこに設計があるわけですね。

0582仕様書無しさん2016/02/09(火) 15:01:39.55

アジャイルって言いたいだけなのがよくわかったw

0583仕様書無しさん2016/02/09(火) 15:09:25.97

>>581
だからその思い込みを捨てろ

0584仕様書無しさん2016/02/09(火) 15:12:05.91

>>577
> アジャイルプロセスはコードを重視するプロセスではあっても
え？

0585仕様書無しさん2016/02/09(火) 17:01:53.73

>>583
思い込み？俺は>>577に書いてあることを
補足しただけだけど？

0586仕様書無しさん2016/02/09(火) 17:04:18.96

アジャイルはコードを重視するプロセスではなくて
変化を重視するプロセス。

だから必要のないものはなるべく減らすし
最初に入念な計画を立てることもしない。

即動いて即フィードバック
だから必然的に必要最小限のコードに傾くだけ。

0587仕様書無しさん2016/02/09(火) 17:09:34.32

第4回　ドキュメントを大切にする
http://gihyo.jp/dev/serial/01/agile/0004

> ドキュメントとコードは同じぐらい大切
>
> ちなみに図2では「ドキュメント」の四角が「プログラム」の四角に重なっていますが，
> これは作図ミスではありません。アジャイル開発者にとってドキュメントには
> プログラムも含まれます。これについては後述します。

http://gihyo.jp/dev/serial/01/agile/0004?page=2
> そのため，アジャイルな開発では中間成果物のドキュメントを極力減らします。
> 作成・維持コストもできるだけ低減させることを心がけます。
>
> ソースコードやテストコード，自動化スクリプト，口頭やホワイトボードによる直接伝達，
> Wikiページや情報カードなどで代替できるものは，どんどん置き換えていきます。

> 図2に示したようにプログラムは，とりわけソースコードとテストコードはアジャイル開発者にとって重要なドキュメントです。
> 「なぜコードが重要なドキュメントなのかというと，詳細かつ正確なドキュメントはコードしかないから」（注5）です。

> みなさんも経験があると思いますが，既存のコードを保守する際に，設計書とソースコードとで記述が異なっていた場合は，
> ソースコードを優先することが多いのではないでしょうか。潔く「コードはドキュメントである，
> それも最重要ドキュメントである」と認めたほうがプロジェクト全体の効率は高くなります。

http://gihyo.jp/dev/serial/01/agile/0004?page=3
> ソースコードは設計である
> ソースコードが最重要ドキュメントなのは，ソースコードは設計だからです。そして設計はテストによって検証されねばなりません。
> いわゆる「製造」はコンパイラやリンカ，ビルドツールの仕事です。この考えを理解するためには，Jack W. Reevesによる
> 「ソフトウェア設計とは何か？」という15年前に書かれた素晴らしい論文をぜひ読んでください。何度も読み返す価値のある論文です。

0588仕様書無しさん2016/02/09(火) 17:10:52.26

> ドキュメントのようなコード
> 詳細なプログラム設計書やテスト設計書がソースコードやテストコードと情報が重複していくのは，
> ある意味当然といえます。コードはドキュメントなのですから。重複は「繰り返しをなくす」というDRY（Donﾕt Repeat Yourself）原則違反でもあります。
>
> とはいえ，ここで一つ注意を。冒頭に引用した某Ruby設計者のように「ソースコードがドキュメントだ」とうそぶくのは簡単です（注13）。
> しかし，ドキュメントのようなソースコードを書くには技術が必要です。
>
> コードがドキュメントとして役に立たないのは，プログラマがコードのことを真剣にドキュメントとして扱っていないからです。
> スタイルを統一すること，クラスやメソッドに適切な責務を割り当て，よい名前を選ぶこと，意図を明確に表現する単位で
> メソッドを記述すること……まだまだ続きます。プログラムを書く際に「このコードはドキュメントとして通用するか？」を自問することは重要です。

http://gihyo.jp/dev/serial/01/agile/0004?page=4
> 今回は少し目先を変えて，アジャイル開発者にとってのドキュメントに対する考え方を紹介しました。誌面の都合上，
> ごく表面的にしか言及できなかったことが残念ですが，「アジャイル開発はドキュメントを書かない」という根深い誤解を解くきっかけになれば幸いです。
> アジャイル開発ではむしろ「なにもかもがドキュメント」なのです。それでは，また次回お目にかかりましょう。acts_as_agile!

0589仕様書無しさん2016/02/09(火) 17:25:45.07

設計書かけかけって言ってる奴に質問だけど、例えば
・コードの行数 3万行
・クラス数 100
・データベースのテーブル数 50
くらいのシステムで、ドキュメントは何を何ページくらいどれくらいの工数かけて書いてるんだ？
UMLで言えば
・クラス図
・シーケンス図
・ステートチャート
・コラボレーション図
とかは書く？書かない？

0590仕様書無しさん2016/02/09(火) 17:35:29.60

>>550
じゃあ有用な設計書を例示して不要な理由を説明してくれ
例示の無い説明は不要

0591仕様書無しさん2016/02/09(火) 17:36:17.92

その程度の小さなソフトなら
・クラス図: 主要部分のみ記述
・シーケンス図: シーケンスが需要な設計要素なら書く
・ステートチャート: ステートが需要な設計要素なら書く
・コラボレーション図: 書かない

0592仕様書無しさん2016/02/09(火) 17:37:19.02

>>590
不要とは言ってないよ。
君の環境で「設計書」として存在させるのがベストならそうすればいいじゃない。

0593仕様書無しさん2016/02/09(火) 17:39:15.97

>>591
> ・クラス図: 主要部分のみ記述
え？そうなの？
じゃプログラマがコーディングしながら設計するって事でいいのか？

0594仕様書無しさん2016/02/09(火) 17:41:00.87

じゃ、俺（ら？）のスタンスと一緒じゃないのか？
俺（ら？）は、必要最低限の設計をすれば、もうコーディングするよ派なんだけど。

0595仕様書無しさん2016/02/09(火) 17:43:02.52

>>548
俺は有用な設計書教えて欲しい派
出せる情報は何もないので何も言ってなくてもしかたない

>>550
俺にはそもそも設計書いる派が本気で設計書いると思ってないように見える
なので詐欺師にしか見えないし視野とは別の問題と見る

0596仕様書無しさん2016/02/09(火) 17:45:13.24

>>593
当然、設計をした後にコーディングするよ？
何も考えずにコード書くなんて恥ずかしいから。

0597仕様書無しさん2016/02/09(火) 17:46:06.77

>>591
> その程度の小さなソフトなら
Webサービスなら、5人で半年くらいで作ってローンチするくらいのサイズなんだけど、
あなたの分野だとどれくらいの感じなの？

0598仕様書無しさん2016/02/09(火) 17:47:37.47

>>596
何も考えずにコードなんか書けないよ。
俺（ら？）だって、考えてコード書いて考えてコード書いてだし。

設計したものは設計書にしろってスタンスだと思ったんだが違うのか？

0599仕様書無しさん2016/02/09(火) 17:52:45.19

>>589
俺ならER図だけは書く。
それ以外は全部ITSのWikiだな。

0600仕様書無しさん2016/02/09(火) 18:02:55.02

>>592
いらない派だけど不要とは言ってないってこと？

0601仕様書無しさん2016/02/09(火) 18:03:37.55

>>598
コードを書いていく上で、他人にはわかりづらいだろう箇所、
説明が必要だろうという箇所はその都度設計書に落としていく。

0602仕様書無しさん2016/02/09(火) 18:04:00.27

ER図を書く時の注意点だが、書くのはER図のER
実体(entity)と関連(relationship) に注目して書くこと。

たまにER図にフィールド全てを書く人がいるが、
関連に関係ない部分は省略して良い。

また関連がないテーブル（設定とかログ関連）はER図から省略してもいいし
またすべての関連を書く必要もない。

テーブル間の関連を理解できればいいので、実際のテーブル定義の情報を
すべて書く必要はないし、ましてやER図作成ツールからデータベース定義（SQL）を
生成しようと思ってはならない。

ER図は理解しやすくするためのものであって、詳細な定義はSQLを読めばわかるので不要

0603仕様書無しさん2016/02/09(火) 18:04:31.44

コード書くことじゃなくて
キーボード叩くことに苦手意識でもあるとか

0604仕様書無しさん2016/02/09(火) 18:09:49.88

>>593
３万行でクラス100個なら、末端のクラスが多いだろうからな

0605仕様書無しさん2016/02/09(火) 18:12:01.96

>>591
>>589は設計書かけかけ言ってるヤツを名指しだけど>>591は本当にそうなのか？
それじゃあ主要じゃないクラスをいきなりコード書くなってなるぞ

0606仕様書無しさん2016/02/09(火) 18:15:55.55

３万行でクラス100個
1クラス平均300行ならそれくらいじゃね？

0607仕様書無しさん2016/02/09(火) 18:20:34.83

>>604
末端のクラスっていうのがよくわからん。
何が「末端」の定義なんだ？

なんか一つのでかいクラス（ゴットクラスというアンチパターン）に
機能を詰め込んで、それを利用するだけの小さなクラスを末端と読んでる気がするが？

俺に言わせれば、親クラスは共通する部分だけを持つから機能は小さいし
汎用的な部分は（親クラスではなく）役目毎にわかれた小さいユーティリティクラスに分けるし、
どれも小さいクラスになるんだが。

そして、こういうのが「設計」（の一つ）なんだよね。

0608仕様書無しさん2016/02/09(火) 18:22:11.73

>>605
どっかに箇条書きにした記憶があるが、コードと一対一の設計書を書けとは言ってないぞ。

0609仕様書無しさん2016/02/09(火) 18:22:57.18

（コードではない）設計書には概略の設計だけを書いて
残りの設計はコードでいいからね。

0610仕様書無しさん2016/02/09(火) 18:27:09.57

>>607
リーフノード。
クラス図書けばわかるだろ。。
書かなくてもイメージすればわかるだろ。。

0611仕様書無しさん2016/02/09(火) 18:29:58.60

>>608
そこまでは言わんけど
全メソッドのインターフェースも決めないのに設計書いるいるに属してることに違和感

必要派も不要派も一枚岩じゃないのが面倒臭い

0612仕様書無しさん2016/02/09(火) 18:35:25.90

>>610
はぁ？やっぱり俺が予想したどおりじゃん。
普通、（お前の言う）末端のほうがコード多くなるんだぞ。

末端には汎用的じゃないものが書かれる。
クラスの数だけ異なる処理があるってことで、それがメインの処理なわけで
うまく共通部分を抜き取らなければ、末端のクラスはどんどん膨れ上がる。

末端のクラスが多いだけじゃ、平均値は下がらん。
末端のクラスから、役割ごとに共通のコードを抜き出して別のクラスに
移動させることで、多くの小さいクラスに分けることが出来るんだよ。

0613仕様書無しさん2016/02/09(火) 19:19:34.77

>>612
何をそんなに暑くなってるのかわからんが。
末端の方が総量として処理が多いから、
それはつまり１００個のクラスのうち多くは末端クラスに
属するんだろうと予想しただけだが。

0614仕様書無しさん2016/02/09(火) 19:24:43.36

基本設計はいるだろ、DB設計もいるよな。ファイルの入出力があるなら、フォーマット設計いるよね。処理の概要も書かないとダメ。
クラス図:継承は一段まで、とかならいらない。デザインパターンは無視
ステート図:ステートレスでやるならいらない
シーケンス図:リクエスト-レスポンスしかないならいらない

0615仕様書無しさん2016/02/09(火) 19:29:37.16

> 基本設計はいるだろ
基本設計がどの部分なのか全くわからんのでコメントのしようがない。

> DB設計もいるよな
DB設計は必要だが、コードでないDB設計書の殆どはコード（SQL）で記述すれば良い。

> ファイルの入出力があるなら、フォーマット設計いるよね
設計はするが、コードでない設計書は不要。フォーマット設計の殆どはコードだけで十分表現できる。

> 処理の概要も書かないとダメ。
コメントで十分

0616仕様書無しさん2016/02/09(火) 19:30:30.71

ミスった

× DB設計は必要だが、コードでないDB設計書の殆どはコード（SQL）で記述すれば良い。
○ DB設計は必要だが、コードでないDB設計書の殆どは不要。コード（SQL）で記述すれば良い。

0617仕様書無しさん2016/02/09(火) 19:38:49.90

誰も設計が不要とは言ってないんだがなぁ。
コードではない設計書が不要と言っているだけで。

もちりん全く不要ではなくて、コードで書くのが難しいところだけ
最小限度だけ書けばいいって話。

0618仕様書無しさん2016/02/09(火) 19:42:02.98

いきなりコード書くより、設計書書いてからの方が速いんだけど、異論ないよね?

0619仕様書無しさん2016/02/09(火) 19:42:22.14

>> ファイルの入出力があるなら、フォーマット設計いるよね
>設計はするが、コードでない設計書は不要。フォーマット設計の殆どはコードだけで十分表現できる。
出力側のコード＝設計書と、読み込み側のコード＝設計書で食い違いが発生して、
どっちが間違っているかを決めるために責任のなすりつけが行われるわけですね。

0620仕様書無しさん2016/02/09(火) 20:03:13.83

>>619
出力側のコードじゃない設計書と、読み込み側のコードじゃない設計書で食い違いが発生して、

と言ってるのと何も変わらんｗ

ついでに言うとコードじゃない設計書が間違っていたり古かったりしていて
挙動はどちらが正しいのか → コードじゃない設計書が間違っていました
ってことのほうが多い。

だから動作検証が必要になる。

0621仕様書無しさん2016/02/09(火) 20:04:15.39

>>542
部下はなにやってん？

0622仕様書無しさん2016/02/09(火) 20:04:49.08

>>618
>いきなりコード書くより、設計書書いてからの方が速いんだけど、異論ないよね?
コードの一部だけを設計書に書くという行為ならば、
単にコード書く前の計画にすぎない。

そういうものはメモ帳程度のもので十分で
その話をしているんだよね？

0623仕様書無しさん2016/02/09(火) 20:15:06.90

>>551
お前はいつも同じことばっかり言って、視野も思考も狭いよな

0624仕様書無しさん2016/02/09(火) 20:16:10.89

>>552
またお前かｗ

0625仕様書無しさん2016/02/09(火) 20:17:51.02

>>554
ちなみに規模の大きさと難易度は全く関係ないよな
作れない子にはわからないだろうけど

0626仕様書無しさん2016/02/09(火) 20:20:56.46

>>620
ふつう、出力側と入力側で同じ設計書を使うだろ。
なんでそんなバカなことしてるの？
(ここでの設計書はコード以外の設計書という意味。念のため)

0627仕様書無しさん2016/02/09(火) 20:35:02.09

>>626
それなら入力側と出力側で同じライブラリを使えばいいだけの話。

0628仕様書無しさん2016/02/09(火) 20:35:25.79

>>618
賛同者ゼロだね
反対２

0629仕様書無しさん2016/02/09(火) 20:44:40.08

>>619
> 出力側のコード＝設計書と、読み込み側のコード＝設計書で食い違いが発生して、
> どっちが間違っているかを決めるために責任のなすりつけが行われるわけですね。

やばいなぁこれｗ典型的じゃんかよ。

最初はとあるフォーマットを出力するだけでよかった。
だから出力専用の機能を作った。

その後、読み込みの機能も必要になった。
ので、出力専用の機能には全く手を付けずに
新たに読み込み専用の機能を作った。

その結果、書き込みフォーマットと読み込みフォーマットという
同じ（微妙に違うｗ）定義が二箇所に存在することになった。

ある時片方だけ修正して・・・
って流れが目に浮かぶなｗ

仕様が変更になった時に、再設計（リファクタリング）をするという
文化がないからそうなるんだよ。

0630仕様書無しさん2016/02/09(火) 20:48:05.15

>>627
ライブラリw
そもそも出力側、入力側で言語すら違うこともよくあるのに？ライブラリってw
なんでもライブラリ()を使えば簡単ですねw

0631仕様書無しさん2016/02/09(火) 20:53:18.81

>>629

0632仕様書無しさん2016/02/09(火) 20:53:57.21

>>629
>仕様が変更になった時に、再設計（リファクタリング）をするという
>文化がないからそうなるんだよ。
俺が悪いみたいな言い方すんな

0633仕様書無しさん2016/02/09(火) 20:54:46.41

>>630
お前が何をいいたいのかわからん。

一番オリジナルのコードを見ればいいだけじゃないか。

0634仕様書無しさん2016/02/09(火) 21:01:57.72

>>630
出力側と入力側で言語が違うって言うけどさ、そもそも
日本語とプログラミング言語でも言語が違うって気づいてる？

言語が違うことで起きる問題っていうのは、
（コードではない）設計書と実際のコードの動きが違うという
問題ですでに現実のものとなってるんだよ。

プログラム言語とプログラム言語であれば、両方共テストコードを
かけるし、テストコード部分を共通化することだってできるが
（コードではない）設計書ではそれも無理なんだよ。

0635仕様書無しさん2016/02/09(火) 21:04:30.67

>>633
一番オリジナルのコードが正しいという保証は？

0636仕様書無しさん2016/02/09(火) 21:06:14.63

>>635
実際にそれで動いているから。
設計書が間違ってることなんて良くある話だからねｗ
コード見たほうがいいよ。

0637仕様書無しさん2016/02/09(火) 21:12:49.22

>>636
出力側のコード＝設計書と入力側のコード＝設計書で食い違いが発生した場合は、
どちらか先にコーディングした方に合わせると言ってる？
たとえそれが明らかに先にコーディングした方の間違いだろうという場合でも？

0638仕様書無しさん2016/02/09(火) 21:13:54.37

入出力なら、常に設計書側が正だろ

0639仕様書無しさん2016/02/09(火) 21:15:52.77

>>637
だからそれ、コードじゃない設計とコードである設計書でも同じことですよね？
って何度も言ってるだろ。

コードとコードの食い違いの問題っていうのは、
コードじゃない設計とコードである設計書の時点でも発生するから、
一次ソースがコードだけの場合に比べて問題となる点が多いんだよ。

0640仕様書無しさん2016/02/09(火) 21:16:03.47

コードで分かるのは事実だけで、それを正しいとするレベルの低さ

0641仕様書無しさん2016/02/09(火) 21:17:47.04

コードでない設計書で分かるのは事実の一部だけで、それを正しいとするレベルの低さ

コードでない設計書はテスト不可能だから間違いを見逃す可能性も高い。
修正した時に再テストも出来ない。

0642仕様書無しさん2016/02/09(火) 21:19:40.86

コードでない設計書は書いてあることが曖昧で抜けてる点も多く
同じ設計書からでも、違う（でも正しい）実装が出来ることがあるからな。

0643仕様書無しさん2016/02/09(火) 21:24:21.61

普通は、コードではない設計書を正として入出力を作るわな。
コード＝設計書同士で食い違いが発生した場合は、コードではない設計書と
コード＝設計書を実行した結果を突き合わせて、コード＝設計書を実行した結果が
コードではない設計書と食い違いがあれば、自分がわのコード＝設計書を修正。
そうでなければ、相手側に報告。
コードではない設計書が間違ってれば、コードではない設計書を修正した後に
双方のコード＝設計書を修正して単体テスト、結合テストを行う。

0644仕様書無しさん2016/02/09(火) 21:25:24.22

>>643
そうそう。実際にそういう問題がおきてメンテナンスが大変だから
同じものは二度書くな、コードで一元管理しろって言ってるわけ。

0645仕様書無しさん2016/02/09(火) 21:25:46.66

>>642
そんな低品質な設計書しかかけませんという自己紹介ですか？
ちなみに、底辺な現場でなければ設計書を書くのもプログラマですからね。

0646仕様書無しさん2016/02/09(火) 21:27:31.94

>>644
入出力それぞれで言語が違うこともよくあるのに、コードで一元管理ですか。

0647仕様書無しさん2016/02/09(火) 21:28:44.14

小規模開発者の集いですか？

0648仕様書無しさん2016/02/09(火) 21:28:46.33

>>645
品質を上げるには「努力」では駄目なんだよ。
仕組みが必要。

動くコードであれば、自動テストという仕組みで対応できる。
もちろんコードではない設計書の「努力」も動くコードに適用できるがｗ

さて「努力」以外にどうやってコードでない設計書の品質を上げる？
根性論では何も解決できないんだよ。

0649仕様書無しさん2016/02/09(火) 21:29:53.95

>>642
あまり詳細書き込んでも改修あったときに設計書修正する手間が増えるし、
要所をさくっと書いてあればいいかと

0650仕様書無しさん2016/02/09(火) 21:30:21.70

>>646
> 入出力それぞれで言語が違うこともよくあるのに、コードで一元管理ですか。

だからぁ、日本語とプログラム言語で言語が違ってるから、
一元管理できてない問題を先に解決しろってｗ

お前の理屈では、それは言語が異なる場合のみ発生するんだろうが。
言語が同じだと発生しねーよ。

だから、コードでない設計書もプログラム言語で書けって言ってるんだよ。

0651仕様書無しさん2016/02/09(火) 21:31:30.26

まともな設計書なら、コード読むよりはるかに速く読めるんだが。
おまえらまともな設計書かけないんでしょ、

0652仕様書無しさん2016/02/09(火) 21:32:54.38

RFC参照してプロトコルの実装とかしたことないのかね？

0653仕様書無しさん2016/02/09(火) 21:33:14.29

コードと同じ粒度で設計書書くのは俺も違うと思う

0654仕様書無しさん2016/02/09(火) 21:36:13.85

まぁRFCにしても守らない相手のためにいろいろ対応することになるのはよくあることだけど。

0655仕様書無しさん2016/02/09(火) 21:36:34.99

>>651
まともな設計書には、コードの全てが書かれてないからなｗ
どっちみちコードは読まなきゃならん。

いくらコードよりも遥かに早く読めたからって、
それでコードを読まなくて住むなんてことにはならないんだよ。

0656仕様書無しさん2016/02/09(火) 21:37:16.12

少なくともRFCの通りに実装してますは言えるからな。

0657仕様書無しさん2016/02/09(火) 21:37:47.57

>>655
コード読まずに済むようにテストくらい書けよ。

0658仕様書無しさん2016/02/09(火) 21:40:39.28

誰もコード読む必要ないなんて書いてないのに何言ってんだ？

0659仕様書無しさん2016/02/09(火) 21:44:21.26

>>657
テストもコードだよｗ

0660仕様書無しさん2016/02/09(火) 21:44:27.85

>>629
クラスや構造体を使って何をしたら食い違いが起きるのか

0661仕様書無しさん2016/02/09(火) 21:45:50.38

>>658
だから、そういうことだろ？

コードを読むことを省略はできない。
必要最低限っていうのは必要ない所は省いて
省けないところだけってことだ。

コードではない設計書なんて、コード（設計書）を
理解するための予備知識的資料で十分なんだよ

0662仕様書無しさん2016/02/09(火) 21:46:16.99

>>660
俺に聞くなよｗ
なんか言語が違うとか言ってるぜｗｗｗ

0663仕様書無しさん2016/02/09(火) 21:49:31.23

>>661
頭悪すぎ。
最初からコードしかみれるものがない状態と、それ以前のレベルで参照するものがある状態の違いも分からずに論破した気になるとか

0664仕様書無しさん2016/02/09(火) 21:52:54.60

>>653
そういうのは基本設計で十分で、詳細設計とかまったく不要だね

0665仕様書無しさん2016/02/09(火) 21:54:29.85

>>661
へー、全部のコード読んでるんだー

0666仕様書無しさん2016/02/09(火) 21:55:07.16

>>665
へー設計書全部ヨンデルンダー

0667仕様書無しさん2016/02/09(火) 21:55:54.94

>>664
なぜかコードと一対一対応の設計書が必要だと言っている奴がいる前提で熱くなってるんだよなー

0668仕様書無しさん2016/02/09(火) 21:56:59.41

あ、派遣コーダの立場の場合は人から言われたソース部分の修正とか、作業しかやることないから、立場を考えると設計書不要ってやつがいるのも分かる。
割合的にも人数だけなら多いだろうし。

0669仕様書無しさん2016/02/09(火) 22:06:07.58

>>668
メッチャカッコワルイなお前
真っ先に実力ではなく身分で判断する奴は
器もスキルも比較にならず負けを認めてる証拠だぞ

0670仕様書無しさん2016/02/09(火) 22:18:06.98

>>669
そうだね。SEは派遣コーダーより実力がないんだもんね。

0671仕様書無しさん2016/02/09(火) 22:19:09.97

実力なんて見てもらいたいの？
既に示されてると思うけど。

0672仕様書無しさん2016/02/09(火) 22:23:20.99

>>670
コーダーってことは、お前プログラム読み書きは全く問題ないの？

0673仕様書無しさん2016/02/09(火) 22:25:18.14

>>671
実力ってのは肌で感じるもの、恥は自ら語るもの
人の実力を受け入れられない恥曝し

0674仕様書無しさん2016/02/09(火) 22:27:51.17

>>670
奇特な奴だな
いまどきコーダー相手にプログラムコードと１：１の詳細設計書を書いてるのかスゲー

0675仕様書無しさん2016/02/09(火) 22:29:39.68

>>669
必死すぎワロタｗｗｗ

0676仕様書無しさん2016/02/09(火) 22:29:44.80

条件と結果の表が設計書としてあると楽だよ
そのままテストに使える

0677仕様書無しさん2016/02/09(火) 22:31:21.91

>>675
さすが実力のないひと、喰い付きがいいな

0678仕様書無しさん2016/02/09(火) 22:32:39.47

>>676
そのままテストに使えるっつーか、それまんまテストケースな

0679仕様書無しさん2016/02/09(火) 22:34:00.39

言い換える意味あるのかよｗなんだこのスレ

0680仕様書無しさん2016/02/09(火) 22:35:36.23

テスト設計知らんの？

0681仕様書無しさん2016/02/09(火) 23:40:23.49

>>676
> 条件と結果の表が設計書としてあると楽だよ
条件と結果の表がコードになってると楽だよ

0682仕様書無しさん2016/02/09(火) 23:46:06.44

>>678
テストケースと結果＝詳細仕様書な。

0683仕様書無しさん2016/02/09(火) 23:46:25.25

実力がないからその身分なんだろ･･･

0684仕様書無しさん2016/02/09(火) 23:56:41.92

>>681
それができた日がプログラマが地球上から消える日…

その究極のシステムがそのへんに転がってるみたいにいうな

0685仕様書無しさん2016/02/10(水) 00:00:05.59

>>682
仕様書≠設計書な

0686仕様書無しさん2016/02/10(水) 00:22:08.45

>>683
実力があるからこそ尚更というのが今の日本のIT業界の姿。

元々は「必要なときに即戦力になる実力派エンジニアを派遣します」ってのが本筋だったが
人身売買が儲かることを知った連中が、経歴詐称して素人を送り込むようになった。
その結果、「使えない」「いらなくなったらぽい」「使い捨て奴隷」扱いになった。
結果、エンジニアは低い身分、使い捨て、派遣にやらせるものという風潮に。

結果、非エンジニアがIT業界で幅を利かせるようになって
今の日本は世界に恥じる技術後進国に成り下がった。

外国ではエンジニアの給料が最も高いはずだよ。

0687仕様書無しさん2016/02/10(水) 00:30:11.96

エンジニアの身分を見誤ってる奴は
人を見る目が腐ってるか、心が腐ってるってこと

0688仕様書無しさん2016/02/10(水) 00:39:58.45

もっとも、いきなり知らない会社のプロジェクトにポイと入れられて
すぐに順応して実力を発揮しろってのが無茶振りなんだけどな
IT業界のエンジニアの仕事って詰めてみると相当多岐に渡るから
スキルマッチなんてそうそうあるわけがないわけで
そこからいかに必要とされるスキルに合わせられるかが実力の発揮点

0689仕様書無しさん2016/02/10(水) 01:09:31.32

使い捨てにされる程度の実力(笑)

0690仕様書無しさん2016/02/10(水) 01:11:05.11

世間知らずに気持ちよくやってもらうのも上に立つ人間の仕事なわけで。

0691仕様書無しさん2016/02/10(水) 05:20:09.29

なんだコーダー君＝コボラーかよ

0692仕様書無しさん2016/02/10(水) 07:24:43.98

メーカーで派遣はないけど、社内で派遣の悪口を言ってる奴を見ると
人として未成熟な奴が多い、派遣に限らず同僚の悪口も言いまくってたり
常に主観でしか話せず、自分は正しく他人は間違ってるという、自己顕示欲の塊
ここの設計書が必要な連中のようにね

0693仕様書無しさん2016/02/10(水) 07:38:59.88

設計書を書く自信がないから設計書は必要ない方が都合が良い

0694仕様書無しさん2016/02/10(水) 07:51:35.23

>>693
そう思い込みたいんですねｗ

0695仕様書無しさん2016/02/10(水) 07:57:59.36

せめてろくなもん１枚でも書いてからほざけ

0696仕様書無しさん2016/02/10(水) 08:02:32.08

じゃあ言い出しっぺのあなたから

0697仕様書無しさん2016/02/10(水) 08:27:26.28

>>692
見事なブーメランだな

0698仕様書無しさん2016/02/10(水) 09:08:43.16

俺の設計書は一枚数億で取引され、美術館に所蔵される
公開は年に１週間だけだ

0699仕様書無しさん2016/02/10(水) 11:31:15.40

空気に触れると経年劣化が進んでしまうからな

0700仕様書無しさん2016/02/10(水) 11:45:31.04

ソフトウェア開発低迷期の歴史的資料か。

0701仕様書無しさん2016/02/10(水) 12:35:10.41

ここて叫べば叫ぶほど書けないやつということが暴かれていく現実ｗ

0702仕様書無しさん2016/02/10(水) 14:52:42.60

>>701
見事なブーメランだなw

0703仕様書無しさん2016/02/10(水) 18:36:45.55

組み込みだと、デバッガの電気的な問題とか
センサーの出力完了時間2ms待つとかそういう処理の設計が
結構大変

waitいれるか、抜けて割り込みで待つかなんてのは
非同期マルチスレッド制御そのものだから

0704仕様書無しさん2016/02/10(水) 19:53:59.51

事務アプリで設計が必要なところなんてあるの？
仕様をまとめるならわかるけど、
設計なんて要らないでしょ？

0705仕様書無しさん2016/02/10(水) 20:15:52.99

>>693
設計書を書くのにお前は自身が必要だったのか

0706仕様書無しさん2016/02/10(水) 20:16:51.51

自信だわｗ

0707仕様書無しさん2016/02/10(水) 20:19:50.96

>>704
設計はいるが設計書はイラン

0708仕様書無しさん2016/02/10(水) 20:22:38.93

>>707
せやな。コードだけで十分って話。
仕様あれば、事前に考えてまとめるほどの
ものなんかないって話。

0709仕様書無しさん2016/02/10(水) 20:41:42.03

そりゃ決まった仕様貰ってコード書くだけなら設計はいらんな
羨しいわーコーダー羨しいわー

0710仕様書無しさん2016/02/10(水) 20:47:04.98

決まった仕様ならコピーして納品する以外に誰も仕事ねえじゃん

0711仕様書無しさん2016/02/10(水) 20:55:09.16

コーダー用にプログラムコードと１：１の詳細設計書を
わざわざ書いてる>>709のようなバカがまだこの世にいたのか

0712仕様書無しさん2016/02/10(水) 21:25:34.00

設計書ないと何が正しいのかわからなくない？

0713仕様書無しさん2016/02/10(水) 21:26:52.20

>>712
じゃあ設計書は何をもって正しいと判断してるの？

0714仕様書無しさん2016/02/10(水) 21:29:27.47

>>713
客の要求でしょ。設計書書いてこれでいいですか？って聞くよ。

0715仕様書無しさん2016/02/10(水) 21:30:38.47

客でもわかるように重要なところをざっくりとわかりやすく書く技術が必要

0716仕様書無しさん2016/02/10(水) 21:37:17.21

詳細は実際にコード書いてデモやって都度作りこんでいく
お前らが馬鹿にしてるSIerでさえそれくらいやってるぞ

0717仕様書無しさん2016/02/10(水) 21:38:49.77

>>714
それは仕様。

技術的ライブラリの開発ならまだしも
通常の客に設計を見せるとかありえない。

テレビが欲しいという客に回路図がどうとか
言うわけ無いだろ。

0718仕様書無しさん2016/02/10(水) 21:43:28.83

回路図も仕様ですが

0719仕様書無しさん2016/02/10(水) 21:43:57.29

>>717
テレビは例が不適切かな
ITシステムは客と一緒に開発してくっていう性質が
あるものだし、客を巻き込んでこそいい仕事ができる
アジャイルやってないの？
お前らが馬鹿にしてるSIerでさえそれくらいやってるぞ

0720仕様書無しさん2016/02/10(水) 21:45:23.69

>>719
テレビが不適切な理由が書いていない。

こんなテレビを作りました。使い勝手はどうですか？
と聞くが内部はこんな回路になってますと設計図は見せない。

おまえアジャイルやってないだろｗ

0721仕様書無しさん2016/02/10(水) 21:47:58.73

>>718
仕様ならば、それは客がつくるものだ。

0722仕様書無しさん2016/02/10(水) 21:48:22.72

>>720
理由はいわなくてもわかる気がするけどな
設計図は見せないのだろ
じゃあ俺が言ってるのとは状況違うなｗ
ご説明ありがとう

0723仕様書無しさん2016/02/10(水) 21:48:56.72

仕様書と設計書の違いもわからん奴がいるのかｗ

ちょっと、ググってきたほうがいいのでは？ｗ

0724仕様書無しさん2016/02/10(水) 21:50:57.87

>>723
それで君は設計書必要だと思う？

0725仕様書無しさん2016/02/10(水) 21:51:03.05

>>721
その一言でお前が派遣コーダーであることがバレたな。
仕様は開発者が作るもの、客は要望を出すだけだ。

0726仕様書無しさん2016/02/10(水) 21:53:09.49

>>725
ハマったなｗ

じゃあ仕様を作って、客に仕様書を見せれば終わりなのに
なぜ設計書まで見せるんだい？ｗ

0727仕様書無しさん2016/02/10(水) 21:54:58.94

>>724
設計書は開発者のためにあるものと考えれば答えはあきらか
必要な物は作るが必要じゃないものは作る必要はない。
ただしコードだけは絶対に書かなければ動かない。

0728仕様書無しさん2016/02/10(水) 21:57:16.91

>>726
客が見たけりゃどのレベルだろうと見せるぞ。
客に何を隠そうとしてんだよお前？つーかコーダーだったな。

0729仕様書無しさん2016/02/10(水) 21:58:16.39

>>727
大根食べたければ食べればいい、ただし、大根は野菜みたいなクソ意見ですなｗ
中身なさすぎて拍子抜けしたわ、経験が感じられない、ごめんちょっと今日は抜けるわ

0730仕様書無しさん2016/02/10(水) 22:04:37.97

>>728
だね、システム全体のアーキテクチャも示さないと納得してもらえないことあるし
DBの選定とかもとうぜん話し合う、設計書もテスト結果も納品物
テレビ君はITシステムのユーザを秀丸ユーザかなにかと勘違いしてるのかね

0731仕様書無しさん2016/02/10(水) 22:10:11.59

>>717
相手がシステム部だと技術的な説明やるぞ。
概要レベルだけど。

あと組み込みの場合は客もエンジニアだからかなり細かいところまで説明するし
客からの突っ込みもコードにレベルまで入るのが普通。

0732仕様書無しさん2016/02/10(水) 22:12:30.44

>>714
客とは仕様を詰めるもんじゃん？
仕様が確定してるのに、社内で開発に使う設計書を客に見せたってしようがないだろ。
プログラムを書いて現物があるんだったらUIだけ先にこしらえて
使用感を客に試して貰うことはできるだろうけど。

0733仕様書無しさん2016/02/10(水) 22:13:52.15

>>731
それ、客は客でも下請けの関係じゃん

0734仕様書無しさん2016/02/10(水) 22:15:26.12

>>725
よう、プログラムコードと１：１の詳細設計書を書いてるオバカサン！

0735仕様書無しさん2016/02/10(水) 22:19:20.29

>>732
客と認識合わせるのに使う設計書もあるんだよ

0736仕様書無しさん2016/02/10(水) 22:20:26.57

>>733
SIerは常に下請けだけど？
自分たちの作ったソフトウェアを販売しているSIerっているの？

0737仕様書無しさん2016/02/10(水) 22:22:33.94

>>734
よう！派遣コーダーくん！

0738仕様書無しさん2016/02/10(水) 22:22:50.53

>>735
例えば何？
コード作成に関係してる部分で見たい所なんてUI位だと思うけど。

0739仕様書無しさん2016/02/10(水) 22:23:43.55

>>736
元請け仕事しかしないもんで

0740仕様書無しさん2016/02/10(水) 22:26:17.04

悲しいかな真面目すぎる性格の為派遣コーダーである事は否定出来ず「そうか！下請けだったら俺と同じ立場じゃね？」と思い書きこんでしまった>>733の哀愁に乾杯

0741仕様書無しさん2016/02/10(水) 22:26:42.67

>>737
詳細設計書なんて今時見ないからコーダーの仕事なんかねえんだわ
マネージメントからプログラミングまで一貫して関わる仕事はしてるけどな
世間ではプレイングなんたらというんだっけか？

0742仕様書無しさん2016/02/10(水) 22:28:06.77

>>740
一応>>692を書いたメーカーのPMっす

0743仕様書無しさん2016/02/10(水) 22:28:16.89

>>738
データの条件とか処理単位とか処理システムとか言語とか
銀行や省庁は非機能要件にもガンガン口出してくるけどね
独自のロジックで金額チェックしててそれをシステムで置き換えるってことが
ほとんどだからロジックにも突っ込んでくるよ

0744仕様書無しさん2016/02/10(水) 22:28:46.72

プレーングコーダーさんキタｗ

0745仕様書無しさん2016/02/10(水) 22:30:18.79

>>742
よう！プレーングコーダーさん！

0746仕様書無しさん2016/02/10(水) 22:30:33.47

>>743
仕様じゃん、全部

0747仕様書無しさん2016/02/10(水) 22:31:53.31

>>744-745
腹痛が痛いだなそれ

0748仕様書無しさん2016/02/10(水) 22:32:12.85

>>746
いや、設計でしょ
『何を』やるのかが仕様
『どうやって』やるのかが設計

0749仕様書無しさん2016/02/10(水) 22:33:03.61

>>747
ほうコーダーさんがプレーをするものだとでも？ｗ

0750仕様書無しさん2016/02/10(水) 22:33:58.02

>>739
元請けでも普通に客に設計書見せるけど。

0751仕様書無しさん2016/02/10(水) 22:34:13.72

>>748
いや、やることが決まってるんだろ？
だったら設計は不要、仕様だよ。
○○言語使えってのも設計ではなく仕様だろ。

0752仕様書無しさん2016/02/10(水) 22:35:41.53

>>750
どんな内容の設計書よ？

0753仕様書無しさん2016/02/10(水) 22:37:21.39

>>751
設計だよ
『何を』やりますか
これこれの金額を算出します ← これが仕様

『どうやって』やりますか
どこのDBにアクセスして
どれのデータをこういうふうに処理します ← これが設計

0754仕様書無しさん2016/02/10(水) 22:41:20.98

>>753
それを客や客のシステム担当に見せたからどうなるの？
アクセス先のDBが元々あって格納先も全て客の指定なら
説明するまでもなく当たり前のことだしな。

0755仕様書無しさん2016/02/10(水) 22:43:52.63

>>753
「どうやって」ということはつまり「やりかた」だろ？
そのやり方は>>743で客が指示してきてる、ならそれは仕様だ

0756仕様書無しさん2016/02/10(水) 22:44:00.10

>>752
処理のシーケンス図とか。

0757仕様書無しさん2016/02/10(水) 22:44:07.29

また常識指向コーダーか

0758仕様書無しさん2016/02/10(水) 22:46:51.03

納得できるものだったら、うんいいよと言ってもらえる
開発進められる、お金もらえる、美味しいもの食べられる

当たり前に思えることを確認することが認識を合わせるってことなのさ
あとでこんなの聞いてないと言われないようにするためにも
小さな合意を積み重ねていくものなのさ、言質を取るってことなのさ

一生懸命システム作って納品の段階で突っぱねられたくないだろ

0759仕様書無しさん2016/02/10(水) 22:46:57.53

>>757
プログラマとの実力差に相当強いコンプレックスを持ってるんだな

0760仕様書無しさん2016/02/10(水) 22:47:18.64

>>755←そしてこれは派遣コーダー思考

0761仕様書無しさん2016/02/10(水) 22:48:55.86

>>714
あほかwwwww

0762仕様書無しさん2016/02/10(水) 22:49:38.67

>>755
設計書作って確認してもらってるんだよ
『どうやって』を示したものが設計

0763仕様書無しさん2016/02/10(水) 22:50:33.08

>>719
ばかなのかな

検収した側に実装まで責任あるとかいうなら
プロやめちまえよ

0764仕様書無しさん2016/02/10(水) 22:52:44.57

>>743
お前はコーディングは派遣に丸投げしてるんじゃないの？

0765仕様書無しさん2016/02/10(水) 22:52:59.52

>>763
検収した側に実装まで責任あるとか言ってない
馬鹿はお前
人間やめちまえ
群馬のシャブババアにケツから思いっきり小麦粉ぶちこんでもらえ

0766仕様書無しさん2016/02/10(水) 22:53:16.76

>>758
客と設計を共有することでメリットがあるならそうすればいいけどさ。
電子回路なんてわからん客が電子回路図渡されて
コレで良いですか？承認下さい、でどう反応すりゃいいのよ。
客が指示したロジック（つまり仕様）を客に説明してどうするよ。

0767仕様書無しさん2016/02/10(水) 22:53:52.78

>>760
プログラム書けないと辛いよねーｗ

0768仕様書無しさん2016/02/10(水) 22:55:21.50

>>764
丸投げしてるけど、設計書丁寧でわかりやすいって評判いいよｗ
コードの細かいところは全部任せてるし、その辺コーダーが自由にできるようにしてるつもり

0769仕様書無しさん2016/02/10(水) 22:55:33.69

>>758
客がそこまで設計出来るなら
いずれもっと安い会社に変えるか自社で実装までやるんじゃないかな

0770仕様書無しさん2016/02/10(水) 22:56:12.50

>>768
おまえプログラマーじゃないやん
何しにここきてるの？

0771仕様書無しさん2016/02/10(水) 22:57:27.61

>>762
客の指示を起こしただけなら用件定義

0772仕様書無しさん2016/02/10(水) 22:58:55.34

>>768
設計書にないことを書かせてるなら
それコーダーじゃねえし

0773仕様書無しさん2016/02/10(水) 22:59:26.48

>>771
コーダーが無理して上流に口出すなって

0774仕様書無しさん2016/02/10(水) 22:59:48.83

>>766
いいかげん仕様といいはるのやめてもらえないかな？
君、頑固者だって言われない？いいかい、設計だよ、設計だよ、設計だよ、設計だよ、設計だよ
電子回路わからん客を想定してわからない電子回路を渡すから変な話になる
電子回路わかりまくりの客を想定してわかりまくりの電子回路を渡せ
そして客と開発者できゃっきゃうふふで電子回路を見渡すのさ

0775仕様書無しさん2016/02/10(水) 23:00:27.76

>>772
お！コーダーの矜持ですね！

0776仕様書無しさん2016/02/10(水) 23:01:24.24

>>773
不備だらけの設計書でプログラマに苦労をかけてるゴミが上流で廃液流すなよ

0777仕様書無しさん2016/02/10(水) 23:01:51.30

>>770
じゃあお前無職のエジプト人のくせしてなんでスフィンクスじゃないわけ？

0778仕様書無しさん2016/02/10(水) 23:02:40.38

>>775
コーダーは設計書に書かれた通りにしか作らない
俺設計書ないからｗ

0779仕様書無しさん2016/02/10(水) 23:03:58.72

>>778
お前が見てるのそれ設計書だから、仕様書じゃないから

0780仕様書無しさん2016/02/10(水) 23:04:50.70

>>774
だってどこをどう突っついても引っくり返しても仕様じゃん

0781仕様書無しさん2016/02/10(水) 23:05:45.97

>>779
だって客とダベッて仕様まとめて設計してるの俺だし

0782仕様書無しさん2016/02/10(水) 23:05:57.08

>>774
俺は組み込みだし、客も回路解るけど
客は回路に口だしなんてしないよ
品質問題おきたらやるけどさ

俺らだって客側の装置の回路なんて見ない
接続部の電気特性は約束するけど

回路まで指示してくる客の場合は
基板を仕掛かりで供給してもらって
そこにプログラムだけ書いて納品する

0783仕様書無しさん2016/02/10(水) 23:07:13.28

>>781
おかしいな～普通は設計して仕様まとめるものなんだけどな～コーダーは違うのかな～ｗ

0784仕様書無しさん2016/02/10(水) 23:08:06.08

>>783
>>783
>>783
変な奴出現

0785仕様書無しさん2016/02/10(水) 23:08:54.55

>>781
客が了承したから回路が故障したときも
責任折半でとかは、俺のところではないな

0786仕様書無しさん2016/02/10(水) 23:09:16.61

>>783
仕様が決まってないのに何をどう設計すんだよ

0787仕様書無しさん2016/02/10(水) 23:10:11.79

>>785
アンカー間違えてねえ？

0788仕様書無しさん2016/02/10(水) 23:10:48.38

>>786
コーダーさんは知らないだろうな
仕様って設計するものなんだって事
もちろんお前は知ってるよな？

0789仕様書無しさん2016/02/10(水) 23:14:57.40

>>788
つまり仕様書という言葉をなくして全て設計書にしたいわけだ
そうすれば定義が曖昧になって糞適当に作られたお前の設計書も
文句言われずに済むとでもかんがえたか？

0790仕様書無しさん2016/02/10(水) 23:18:33.72

>>789
は？何言ってんのお前？バカじゃね？

0791仕様書無しさん2016/02/10(水) 23:19:20.63

>>788
プログラムを書けないゴミだけど、「設計書」という名前の何かを書いて
設計してる、ものづくりに関わってるという風に見られたいんですね。

で、実際に書いてるのは本当にゴミで、
不備の穴埋めと本設計は全てプログラマに丸投げと。

0792仕様書無しさん2016/02/10(水) 23:19:38.30

>>790
図星だったらしいｗ

0793仕様書無しさん2016/02/10(水) 23:20:29.33

>>791
ゴミを自覚してんならレスすんなゴミｗ

0794仕様書無しさん2016/02/10(水) 23:21:53.62

客が承認したら責任は客が取るのは当たり前。
だからわざと難しくした資料を出す事もある。
でも、資料と違う物を提供してるなら責任は提供者にある。

0795仕様書無しさん2016/02/10(水) 23:22:25.20

>>793
プログラミングができないうえに、文章の読解力も無いときた。
設計書もさぞひどかろう

0796仕様書無しさん2016/02/10(水) 23:24:45.59

>>794
ふつーに難しいよボケと突っ返されるわな
客だって金払ってんのに責任逃れの誓約書になんかサインしたくねえし

0797仕様書無しさん2016/02/10(水) 23:26:22.56

>>795
それを言うならお前の文章力だろ
笑かすなｗプログラムをかけないゴミがｗ

0798仕様書無しさん2016/02/10(水) 23:28:49.77

>>797
俺、設計書いらない側ですけどｗ

0799仕様書無しさん2016/02/10(水) 23:31:52.76

>>794
嫌な下請けだな

絶対検収しねーからな

0800仕様書無しさん2016/02/11(木) 00:09:17.66

実際には顔青くしてすみませんしか言えない下請け

0801仕様書無しさん2016/02/11(木) 06:03:51.05

>>782
うちは口出ししてくるよ。
客としても製品として世に出て行くんだから
下請けがやったことなので詳しくは知りません。
は通用しないだろうし。

0802仕様書無しさん2016/02/11(木) 07:24:52.37

自分ところで作れるスキルがあれば下請けのスキルくらいリサーチできるだろう
それができてない時点で察し

0803仕様書無しさん2016/02/11(木) 07:40:42.85

>>801
面倒臭いから外注に出すのであって
いちいち口出しするくらいなら最初から自分でやればいいのに
その方が期間もコストも信頼性も良いだろうに
面倒臭いからではなく、作れるほどのスキルはなくて
責任の分散が目的だったら一番関わりたくない面倒くさい客だけど

0804仕様書無しさん2016/02/11(木) 09:21:22.01

使い捨て早死に貧困の助長SEは大迷惑
偽装請負の従犯は辞めろ！

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

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

0805仕様書無しさん2016/02/11(木) 11:48:43.03

ソースが一番詳細な設計書っていうのは否定しないけど、目次とか、索引みたいなのはいるでしょ。
その目次が設計書じゃないの。
あと、ソースと1:1の設計書はいらないよ。設計書いるよ派で、1:1がいるっていう人はいないと思うけど

0806仕様書無しさん2016/02/11(木) 11:49:18.72

> その目次が設計書じゃないの。
目次でいいだろw

0807仕様書無しさん2016/02/11(木) 12:05:52.34

>>806
あー、比喩が悪かったか。目次だけじゃなくて、もう少し色々書いておけば便利だろ

0808仕様書無しさん2016/02/11(木) 14:24:23.13

>>803
そりゃおかしいわ

0809仕様書無しさん2016/02/11(木) 15:55:46.69

>>721
コーダーがばれた瞬間w

0810仕様書無しさん2016/02/11(木) 15:56:42.17

age

0811仕様書無しさん2016/02/11(木) 16:07:07.42

>>803
自分で全部やったほうが早いし安全正確だが一人で抱え込める量は上限があるのよ。
いくつものシステムを並行で進めていかない時はヘッポコでも他者の力をかりなきゃならない。
そしてコードの隅々まで確認することができないから設計書などをみて仕様がきちんと伝わってるか確認する。

0812仕様書無しさん2016/02/11(木) 19:21:23.84

ただの要件定義書を書いて設計書を書いたつもりになってる設計もプログラミングもできないアホが
今日も元気いっぱいだな、全然仕事してないから疲れないんだろうな

0813仕様書無しさん2016/02/11(木) 19:24:11.37

そういう　お前が下に見れる人間がいることがお前の精神の助けになってるんだな。
この業界の心の闇は大きい

0814仕様書無しさん2016/02/11(木) 19:52:20.25

>>811
うん。だから簡単な概要のコードではない設計書を渡して
コードである設計書をみんなで書くわけですよね？

0815仕様書無しさん2016/02/11(木) 20:00:16.05

>>814
逆かなー
簡単な概要のコードではない設計書はコードを書く側が作る場合が多い。
設計を理解しているかどうか・十分に設計ができているかどうかを
見るには設計書を書かせるのが一番だからね。
当然外注が書いた設計書に突っ込みも入れるし、コードも見る。

0816仕様書無しさん2016/02/11(木) 20:14:39.30

>>815
まさにそれ。

0817仕様書無しさん2016/02/11(木) 20:19:00.11

SEが仕様をまとめて、プログラマが設計してコードを書くってことか。

0818仕様書無しさん2016/02/11(木) 20:20:09.01

高度なことしてるのに安く買い叩かれてるよな

08198152016/02/11(木) 20:21:21.89

SEとかプログラマとか区別無いけど。

0820仕様書無しさん2016/02/11(木) 20:40:21.50

SI業界ではコード書けないSEがいるのが普通ですよｗ

0821仕様書無しさん2016/02/11(木) 20:42:46.14

>>820
正直そんな無能いらんわな

0822仕様書無しさん2016/02/11(木) 20:53:57.41

>>818
客も何故かプログラマを安く見てくるから困る
ネガティブキャンペーンやってる奴ただじゃおかない

0823仕様書無しさん2016/02/11(木) 21:06:10.47

コードかけないSEも
話ができないPGも
どっちもいらんわ

0824仕様書無しさん2016/02/11(木) 21:43:43.35

高卒専門卒がPGで
大卒新人でPG経験がない奴がSEやってたりするのがこの業界

0825仕様書無しさん2016/02/11(木) 21:52:54.65

それはSI業界だけｗ

0826仕様書無しさん2016/02/11(木) 21:54:59.78

>>818
プログラムなんて誰でも作れるじゃん

0827仕様書無しさん2016/02/11(木) 22:39:06.98

料理だって誰でも作れるし、
野球もサッカーも誰だってできる。

0828仕様書無しさん2016/02/11(木) 23:09:43.46

プログラムの場合はプロでも素人と変わらないから困る

0829仕様書無しさん2016/02/11(木) 23:12:39.65

SI業界はそうなんだよねｗ

0830仕様書無しさん2016/02/12(金) 00:27:05.12

>>826
Helloworldで出来る気になられても

0831仕様書無しさん2016/02/12(金) 03:14:09.590680

>>826
じゃあ、あとはよろしく

0832仕様書無しさん2016/02/12(金) 06:42:49.284895

>>831
時給８００円ぐらいでワーカー探してくる

0833仕様書無しさん2016/02/12(金) 08:34:14.753542

昔からそのうちコーダーはいなくなるって言われてるけどなかなかそうはうまくいかないよね。

0834仕様書無しさん2016/02/12(金) 12:25:49.87

むしろプログラマー気取りのコーダーばかり増えている

0835仕様書無しさん2016/02/12(金) 12:42:35.72

勉強しないやつ多いよね。

0836仕様書無しさん2016/02/12(金) 14:41:06.35

>>801
> 下請けがやったことなので詳しくは知りません。
> は通用しないだろうし。

大抵の場合は知らなくて問題ない。
つか、しらなく良い仕組みにしないといけない。

5人月くらいならすみずみまで一人で確認可能だろうが、
50人月出してもそれ全部確認するのか？

詳細設計書1000ページ
コード5万行
テスト仕様書500ページ

とかになったら、確認するだけでもかなりな工数になるのだが

0837仕様書無しさん2016/02/12(金) 14:46:45.24

今や確認するのに人件費がかかるからって、テスト項目減らされて
結局不具合内包したまま出荷して市場で大量の不具合見つかって回収騒ぎが日常です。

0838仕様書無しさん2016/02/12(金) 14:51:00.50

>>837
そんなニュース聞いたことないが、お前の所がそういう日常だとしたらご愁傷様

0839仕様書無しさん2016/02/12(金) 14:57:12.79

>>836
なんのために存在するの？

0840仕様書無しさん2016/02/12(金) 15:03:45.39

>>839
何が？

0841仕様書無しさん2016/02/12(金) 15:13:44.27

>>837
どんなソフトも不具合を内包したまま出荷されます。

0842仕様書無しさん2016/02/12(金) 16:02:34.39

組み込みでソフトウェアの不具合→リコール
って話じゃないの？

0843仕様書無しさん2016/02/12(金) 18:54:18.17

>>840
存在価値あるの？

0844仕様書無しさん2016/02/12(金) 19:12:53.42

設計書君たちは自分の居場所を奪われまいと
設計から開発まで全部やれちゃうプログラマを
情けなくコーダー呼ばわりしちゃって
そこまで必死になるほど追い詰められてるのか

0845仕様書無しさん2016/02/12(金) 19:46:20.43

>>844
よう！コーダー君

0846仕様書無しさん2016/02/12(金) 19:51:45.24

>>834
ついに君ら素人では、プログラマーが気取らないとなれない
高貴でハイレベルな職業に認定されましたな

これからもプログラマーにコーダーをやらせるよう
プログラマが何一つ考えなくて良いように
頑張ってコードと１：１の詳細設計書を書いて下さい

0847仕様書無しさん2016/02/12(金) 19:53:30.96

真の意味で、コードと１：１の詳細設計書が書けるのはプログラマだけだな
コードが設計書だから

0848仕様書無しさん2016/02/12(金) 19:56:39.51

お前らよくこんなどうでもいいことで

0849仕様書無しさん2016/02/12(金) 19:56:52.98

プログラマなんて頭不要だからな

0850仕様書無しさん2016/02/12(金) 20:00:05.40

>>849
あれれ？コーダーって呼ばないのぉ？

0851仕様書無しさん2016/02/12(金) 20:02:33.50

なんだこいつ。
コーダー呼ばわりで逆上しちゃったおっさんか？

0852仕様書無しさん2016/02/12(金) 20:09:40.42

>>851
すぐ文面に気持ちが表れる無能SEって
良く言えば素直、悪くいえば単純
単純すぎて詰めが甘い
詰めが甘い奴に設計は無理

繋がりましたな

0853仕様書無しさん2016/02/12(金) 21:11:06.99

>>852
くっさ

0854仕様書無しさん2016/02/12(金) 22:20:06.73

コーダーをばかにするな
手が早い奴はそれだけで生半可なプログラマーを圧倒する

いいようにむしられてポイされることが多いけど。

0855仕様書無しさん2016/02/12(金) 23:10:37.71

作れない人が必死ですな

0856仕様書無しさん2016/02/12(金) 23:13:16.91

どうにかしてプログラマとコーダーの地位を下げようと
むちゃくちゃ必死な文系の姿が、見事に浮き彫りになってきました

0857仕様書無しさん2016/02/12(金) 23:14:49.97

おいおいコーダーの地位が今より下がる余地がある思っているのか？

0858仕様書無しさん2016/02/12(金) 23:23:54.57

>>857
コーダーはよくしらねえけど、文系がコーダーに気を取られてる間に
プログラマの位を勝手に上げてくれたからな
指摘したら慌てて下げに走り始めたけどｗ

0859仕様書無しさん2016/02/12(金) 23:26:42.37

開発できない文系の自称設計者が書いてるのって
結局、精々よくて要件定義書ってところだろ
つまり客の要望書を社内のフォーマットに書き写しただけのコーダー

0860仕様書無しさん2016/02/12(金) 23:27:06.78

>>858
お前ラリってるのか？
意味不明すぎてこわいは

0861仕様書無しさん2016/02/13(土) 00:10:45.63

言いぐさがちょっと統合失調ぽいなｗ

0862仕様書無しさん2016/02/13(土) 01:37:27.68

コードは設計書だと言い張ってる奴らって、自分の仕事は設計だと認めてもらおうとしてるコーダーでしょ
本当に設計もプログラミングもできる奴は、自分の書いたコードがコードと呼ばれようと設計書と呼ばれようとそんなのはどうでもいい
どちらにしろやることは変わらないんだから

0863仕様書無しさん2016/02/13(土) 06:07:13.89

>>860
流れを書いてるだけでラリ扱いの過剰反応
自分らの不都合は見えない、都合の良いフィルターをお持ちですなｗ

0864仕様書無しさん2016/02/13(土) 06:11:17.68

>>862
ラリってますか？

＞本当に設計もプログラミングもできる奴は、自分の書いたコードがコードと呼ばれようと設計書と呼ばれようとそんなのはどうでもいい
＞どちらにしろやることは変わらないんだから

コーディングも設計も、やることが変わらないなら
コード＝設計書ってことですね？

0865仕様書無しさん2016/02/13(土) 12:52:20.72

コーダがこれじゃデスマもなくならないな

0866仕様書無しさん2016/02/13(土) 13:58:20.22

コーダーとSEが分かれている所では
すべての責任は上位であるSEにあるのですよｗ

0867仕様書無しさん2016/02/13(土) 14:00:18.98

>>859
わかる

コーダー呼ばわりするなら
クラス設計、クラスのコール方法
マルチスレッド設計、エラー時の処理方法くらい
全部指示してほしい
その通りかいてソース納品するから
テストはやっといてくれよな

0868仕様書無しさん2016/02/13(土) 14:23:37.22

意識高い系のコーダーｗ

0869仕様書無しさん2016/02/13(土) 14:25:44.24

>>867
> クラス設計、クラスのコール方法
> マルチスレッド設計、エラー時の処理方法くらい

それ全部設計の範疇じゃん。
なんでコード＝設計になってるの？

0870仕様書無しさん2016/02/13(土) 14:40:23.14

>>867
クラスのコール方法ってなに？ｗ

0871仕様書無しさん2016/02/13(土) 14:47:31.30

コーダーが設計者を名乗るための詭弁
それがコード=設計書ｗｗ

0872仕様書無しさん2016/02/13(土) 14:48:12.51

お前らコーダーを馬鹿にするけど、実際のところお前らだってコーダーに毛が生えた程度じゃん？

0873仕様書無しさん2016/02/13(土) 14:56:59.37

>>867
背伸びしすぎやで

0874仕様書無しさん2016/02/13(土) 14:58:38.44

おまいらがSEで、仕事投げるとしたら
束縛を苦にせず、喜々として厳密な規約に従い、スケジュールを分刻みでこなすコーダーと
意識高くて自己主張強いプログラマー（笑）と
どっちほしい？ｗ

0875仕様書無しさん2016/02/13(土) 15:00:14.65

>>872
安心してください、パイパンですよ。

0876仕様書無しさん2016/02/13(土) 15:01:36.44

>>874
淡々と作業こなすコーダーの方がありがたい

0877仕様書無しさん2016/02/13(土) 15:17:00.93

>>836
確認していないことによるリスクのほうがはるかに大きいからね。
金銭的にも社会的にも。

0878仕様書無しさん2016/02/13(土) 15:22:38.03

文系文系いってるけど、プログラマーはそもそも文系にも理系にもなりそこねた専門学校卒が多いという事実。

0879仕様書無しさん2016/02/13(土) 15:26:18.52

>>878
いや、専門卒の人なんて殆どいないんだが
もしかして、そういう職場なの？

0880仕様書無しさん2016/02/13(土) 15:29:42.98

>>874
意識高くて自己主張強いプログラマー
コーダーて詳細設計レベルまで落とさないと仕事してくれないんだろ？
コーダーに仕事を渡す頃には、詳細設計できるプログラマがプログラムを完成させてる

0881仕様書無しさん2016/02/13(土) 15:53:55.56

>>879
専門学校にすら行ってない素人ばかりだからな。

0882仕様書無しさん2016/02/13(土) 16:01:05.64

>>880
必死乙

0883仕様書無しさん2016/02/13(土) 16:04:17.00

>>869
その設計すら出来ないSEが用件分析レベルで
発注してるからさ

0884仕様書無しさん2016/02/13(土) 16:55:12.37

>>882
コーダー乙

0885仕様書無しさん2016/02/13(土) 19:02:01.01

>>874
俺より賢ければどっちでもいい

0886仕様書無しさん2016/02/13(土) 19:17:07.90

実態派遣SEの知的財産と契約料金の搾取対策

相場下がって迷惑だから報酬増やすか作業減らせ！

[推定平均生涯収入]
100万/月 3億5,000万円以上(大卒サラリーマン上位レベル)
90万/月 3億円以上(大卒サラリーマン平均レベル)
80万/月 2億5,000万円以上(大卒サラリーマン下位レベル・高卒サラリーマン上位レベル)
70万/月 2億円以上(高卒サラリーマン平均レベル)
60万/月 1億5,000万円以上(高卒サラリーマン下位レベル)
50万/月 1億円以上(フリーターレベル)
40万/月 5,000万円以上(パートレベル)

http://labaq.com/archives/51497438.html

0887仕様書無しさん2016/02/13(土) 19:38:56.15

スレも３スレ目になると、肥溜め感が増すなw

0888仕様書無しさん2016/02/13(土) 19:56:02.04

コード＝設計という定義は昔から言われてることだけどね。

0889仕様書無しさん2016/02/13(土) 20:17:59.06

>>79
設計書通りに作ったら穴だらけな罠
設計者からコードに落とし込むのに更に時間かかるしな
要点だけさっさと書き上げて、詳細な設計書はいらんよ
どうせ詳細になりきれてないんだから

0890仕様書無しさん2016/02/13(土) 20:22:02.49

結局コードじゃない設計書は単なる要点の確認にすぎないということ。
完全な設計書はコードにある。

0891仕様書無しさん2016/02/13(土) 20:23:25.36

コード＝設計て成果物＝過程てことやろ？
コーダーて馬鹿しかなれないんか？

0892仕様書無しさん2016/02/13(土) 20:27:12.75

>>891
お客さんはコードもらってもどうしようもないよｗ
動くバイナリコードを作らないといけない。
動くバイナリが成果物だよ。

コードという設計書からバイナリを作る行為が製造。
一番最初のコンパイラは人がコンパイラの気持ちになって
実行ファイルにコンパイルしたそうだ。それが製造工程だよ。

0893仕様書無しさん2016/02/13(土) 20:31:43.05

>>892
なんで意味も分からんとレスするん？やっぱり馬鹿なん？

0894仕様書無しさん2016/02/13(土) 20:33:11.37

>>893
何か意味があることを言おうねｗ

0895仕様書無しさん2016/02/13(土) 20:34:49.98

ダメやこいつ
もすこし賢いコーダーはおらんのか？

0896仕様書無しさん2016/02/13(土) 20:39:41.31

ますます切羽詰まってんなー、設計書君

0897仕様書無しさん2016/02/13(土) 20:40:17.81

なｗこういうレスしか出来なくなってしまったんだよｗ

0898仕様書無しさん2016/02/13(土) 20:42:38.54

この書き込みがスレの流れを決定的にしたよね。
もう何年も前から言われてきたこと

54 名前：仕様書無しさん[sage] 投稿日：2016/02/04(木) 15:00:55.72
ググったら、日本語訳あったわ。

ソフトウェア設計とは何か？
http://web.archive.org/web/20080803072849/www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

56 自分：仕様書無しさん[sage] 投稿日：2016/02/04(木) 15:04:02.03
>>54
これと一緒かな？
http://knagano.tumblr.com/post/11941519742/

魚拓にもあった
http://megalodon.jp/2008-0719-2309-27/www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

> ソースコードがソフトウェア設計であると考えることによって重大な帰結が導き出されます。
本当に重大なことだった。

0899仕様書無しさん2016/02/13(土) 20:42:38.86

>>891
なんでいつまでたっても「書」をつけないの？
コード＝設計書であって、コードは設計ツールであり成果物だと散々言ってるのに
記憶力死ぬほど悪いね

0900仕様書無しさん2016/02/13(土) 20:44:20.93

>>897
ほんと、まともに反論もできず
ただひたすら子供のように反対してる設計書君

0901仕様書無しさん2016/02/13(土) 20:44:50.01

>>899
設計ツールはテキストエディタとかIDEだろ？

頭の中で考えた設計をUMLエディタやエクセル（笑）で
図やドキュメントにするのも、テキストエディタでコードにするのも
同じ設計作業なんやで。

0902仕様書無しさん2016/02/13(土) 20:45:12.51

>>900

あんたは>>898になんか反論した？

0903仕様書無しさん2016/02/13(土) 20:47:46.30

>>901
バカな君でもわかるように設計書で説明してあげると
UMLは設計ツール、UMLエディタはUMLを書くツール
コードは設計ツール、テキストエディタはコードを書くツール

0904仕様書無しさん2016/02/13(土) 20:49:04.31

>>902
反対してない、全面的な賛成派

0905仕様書無しさん2016/02/13(土) 20:50:23.53

前スレの>>54は決定的だったな
http://knagano.tumblr.com/post/11941519742/

0906仕様書無しさん2016/02/13(土) 20:58:10.39

>>903
> UMLは設計ツール

LはランゲージのLだよね？
つまり言語が設計ツールに相当するわけか。

そして頭の中で設計したものを、その言語で書いたものが
設計書になるわけですね。

0907仕様書無しさん2016/02/13(土) 21:11:41.64

>>892
インタプリタのばあいを考慮できない程度のアホがまともなコード＝設計書をかけるとは思えないなw

0908仕様書無しさん2016/02/13(土) 21:13:48.20

インタプリタの場合でも書いたコードが直接動いているわけじゃないよｗ
技術知らない似非技術者は困るねｗ

0909仕様書無しさん2016/02/13(土) 21:16:37.65

>>908
そんなことはまったく言ってないけど？
思い込みによる仕様書の読み間違えも多いんだろうなぁ。

0910仕様書無しさん2016/02/13(土) 21:28:19.90

http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q14155852909

0911仕様書無しさん2016/02/13(土) 21:28:42.98

あはは。インタプリタの場合
その命令を解釈して動くもの（動いてるのはこっち）が
いるのさ。知らないだろうけどね。

0912仕様書無しさん2016/02/13(土) 21:32:38.65

いつまでも馬鹿のふりしてないでもっと本気でぶつかってこいよコーダー

0913仕様書無しさん2016/02/13(土) 21:43:03.20

徹底的に追いつめられて対抗手段もなくなった壊れかけてる子は
最後に同じ言葉を繰り返すようになる
レス毎に必ず付ける「コーダー」とかねｗ

0914仕様書無しさん2016/02/13(土) 21:47:39.93

>>906
そう、だからUMLで設計するのも、コードで設計するのも変わらない
中には図の方が分かり易いって人もいるけど
UMLとか設計書から追わないとプログラムの目的の場所に辿り着けない子は
英語の微妙な発音が聞き取れない耳と、似た状態かもね
プログラムコードにそれだけ触れてない証拠

0915仕様書無しさん2016/02/13(土) 21:48:50.92

>>892
は？

ビルドくらい自分でやれや無能

0916仕様書無しさん2016/02/13(土) 21:50:29.66

プログラムコードは、たしかに文字だけど、構造化されてるし
プログラムコード自体が図形のように直感的に読めるから
コードを直に見た方が効率的かつ正確に把握できるんだよね

設計書が必要な子は、そんなバカな話があるかと思うだろうけど
日本語の漫画や小説はスラスラ読めるだろ？
これが一般的な職業プログラマの段階

上級プログラマはスラスラを超えた更にその上の段階
文字が図形として頭に入ってくる速読状態
そして図形を描くように手早く書き起こせる速記状態

ちなみに、外国の小説は読むのに時間がかかるだろ？
これが、設計書が必要な、君ら似非SEの状態

いきなりコードを書くな。設計してから書け。 その3 [無断転載禁止]©2ch.netYouTube動画>1本 ->画像>2枚

いきなりコードを書くな。設計してから書け。その3 [無断転載禁止]©2ch.netYouTube動画>1本 ->画像>2枚