まつもとゆきひろ「コードとは設計である」

「ソフトウェアは工業製品ではない」、Rubyのまつもと氏が講演
http://www.atmarkit.co.jp/news/200904/10/matz.html

コードとは設計である

　「ビューティフルコード」と題した基調講演を行ったまつもと氏は、
2007年に共著者の1人として出版した同名の書籍に書いたエッセイに
込めた思いを、次のように語る。

　「世界に冠たる日本の製造業のノウハウを適用することで生産性を
上げることができるに違いないという発想がありますが、
ソフトウェアは工業製品ではない。そうした誤解を正していきたい」。

　コード（ソフトウェア）を書くというのは、組み立てのことではなく
製造業でいう「設計」に相当するという。

　「クルマを作るときに、まず形や強度の設計をしますよね。
それこそがソフトウェア作りです。ソフトウェア作りは、
最初から最後まで工業製品でいう設計に当たるんです」。

馬鹿には無理

【衆院選】声優の平野綾さんが千葉４区から出馬へ
http://ikura.2ch.net/test/read.cgi/nissin/1285228112/

>>1
コーディングが設計ｗｗｗ
Web屋さんって全体の構成とか設計してから作らないの？

>>4
うわぁwww

さすがにコードが設計というのは無理あるだろ

the source code is a design document and that the construction phase is actually the use of the compiler and linker.

世界的には「コードが設計」というのは常識。

日本のヒト売りSIerだけが、人月計算でライン工のように誤解してるだけ。
そういう「製造工程」は、コンパイラやリンカなど、コンピュータ自身がやってくれる。
単純な「製造」ライン工は不要。

コーディングが設計じゃないなら、
必要な全てが記述された設計書が存在して、
コーディングはその設計書を翻訳してるだけなんだよね？

素朴な疑問なんだけど、なんでその設計書を直接コンパイルしないの？

SIer(笑)
上流工程専門(笑)

こいつらには理解出来ないよ。
理解する頭がない。
すぐに無くなる会社だから気にしなくていい。

>>9
> 素朴な疑問なんだけど、なんでその設計書を直接コンパイルしないの？
人間使った方が安いから。

>>11
わざわざ翻訳するくらいなら、最初からコンパイル出来る言語で書いた方が安いよ。

え？プログラミング言語で書けない無能はどうすればいいって？
仕事辞めたら良いんじゃないかな。

わざわざコーディングしてる時間なんて無いんだよ。
人件費の無駄遣いだしね。

無能を雇ってる方が人件費の無駄遣いだし、
事実、無能を抱えたSIerは死に体になってる

SIerはそういう商売なんだから仕方ない。
「技術力に自信があるんなら、SI業界じゃなくてGoogleなどにいけ」
ってSI業界のトップも言ってるしね。
とうぜん、SIerの下請けPGなんて論外だからね。

まず、ソフトウェアにコストがかかっている部分のことを

製造と呼ぶのか？ と考えてみればいい。

Windowsの”製造”工程といったら開発終了したWindowsを
DVDに焼いてパッケージングする工程のことだよな。

だから少なくともそれまでの作業は製造ではないな。

DVDは知らんが、CDをプレスするコストなんて小ロットですら1枚当たり2,3円だったな。

日本のSIerなんて、(自称)上流工程に逝く程、技術力が無い。
SE=プログラミングの出来ないPG
コン猿=フローチャートすら書けないパワポ紙芝居師

お前のことだよ! >>ミカカDATA

>>18
だから、技術力無くて問題ないんだって。
技術力が無いのが嫌だっていうんなら、SIなんかやめろよ。

なにそれ？下書きってことか？

>>19
SI業界まるごと傾いてるんだから、問題あったってことだろ > 技術力無し

Matzもプログラマに媚売るためにこんなこと言ってるだけ

>>21
もしかして、技術力があれば傾かなかったと思ってる？

不況になって仕事が減っても、元請けに技術がないから
下請けをバッサリ切り捨てられない
下請けがやってる行程を元請け側では行えないから

もう下請けへの単価も限界まで減ってるし、あとは
余りまくってる単価の高い上流行程専門のリストラしかない

変化に強い会社の設計も出来ないのだから、技術力はないだろうな。

うぇぶ（笑）っていつも偉そうだよなｗ
社会の底辺らしく負け犬の遠吠えってかｗ

負け犬の遠吠えの例 ↑

SI業界の下請が、元請けより技術力があるとか言ってても虚しいだけだろ。
技術力あるんなら、自分で製品なりサービスなり作って売ればいいのに。

> SI業界の下請が、元請けより技術力があるとか言ってても虚しいだけだろ。
意味分かんないｗ

だいたい下請ってのは、自分よりも技術力があるから仕事を発注するんだよ？

たとえば、俺が印刷会社に仕事発注すること考えてみ。
確実に印刷会社のほうが俺より印刷技術がある。

むしろ、印刷会社よりも俺のほうが技術あるとか思ってるほうが
無知のうぬぼれってやつだろう。

>>28
世の中の下請け構造の問題を知らんのか
大手が仕事を請けて下に丸投げしてんだろ
最上流はどうかしらんが、中間業者はアホばっかりだぞ

最近、上流行程できます(笑)な人達が
Web業界に押し寄せて来てるけど、みな門前払い

そのせいか、最近>>26系の書き込みをよく見るようになった

Web 系が偉そうってのは良くわからない。
誰でも簡単に覚えられる仕事で、一山いくらのドカタが安い賃金で黒々と働かされている業界だろう？

GoogleがWeb系といえば理解できるか？

Web系って自分たちがGoogleの仲間だと思ってたのかw
どんな論文出してるのか言ってみてよ。

言い出しっぺが先にだしな

>>34ってなんのために匿名掲示板使ってると思ってるんだろｗ
個人を特定されないようにしてるのに
個人が特定されるようなことするわけないだろ。
そんな簡単なこともわからないのか。馬鹿だなー。やっぱり馬鹿だなーｗ

ここはGoogleがハード設計からやってることを知らない底辺Webの巣窟
ハードも知らないWeb屋＝メーカー以下のど底辺
それなのにGoogle様と自分を同一視してる虚しい生き物、それがうぇぶ（笑）

↑こんなスレで自己紹介している哀れな人

なんで俺がWeb屋だってばれたんだ…

何屋かでレベルを見分けられるなんて、よっぽど能力高いんだろうな。
俺には出来ないや。

単価で大体分かるでしょ。

ただ単価書いてないけどねｗ

オレの目には普通の見えないモノが見えるんだ！
（中二病患者）

お前のことなんか誰も気にしてないから。

なるへそ。
技術力が高いからではなく、単価が安いから下請に丸投げピンハネしてるだけか。

無差別にroot奪取を推奨するのはやめろよ

SKEのまつりなも語るべきだ

ttps://twitter.com/yukihiro_matz/status/279802518341550080
右傾化してる自民党だけには投票できない。与党のうちはそれでも安定運営してるように見えたのに、下野したら極端化した。

ttps://twitter.com/yukihiro_matz/status/279802899121455104
外交上の不利益を無視して隣国をシナって呼ぶところもなあ。

売国プログラマーならRubyだな

宗教上の理由でモルモン教徒の言うことは一切聞かないことにしてます

>49
斉藤由貴も駄目なのか？

>>47
chinaはシナと呼ぶべきだと前から思っていたけどなあ。

中国だと、岡山や広島を思い浮かべてしまう。

Rubyでネトウヨサービス作ってMatzに見せてみようぜ

立候補すれば島根知事になれるだろうな
売国政策やりまくるんだろうか

まぁ、コンパイルを製造というならコーディングは設計なのかもしれない。

Rubyのばあいは製造しないんだな。

実行時に製造してるよ。

中共が支那と呼ぶことに抗議したなんて話はきいたことがない
どんだけ自虐史観に洗脳されてんだこいつは

>>56
つまり、プログラマは製造機を製造してるわけだ。

>>58
してないよ。

製造機はすでにできていて、
プログラマは設計を作る。設計を入れたら
そしたら製造機（インタプリタ）が実行時に製造してくれる。

インタプリタくらい理解して使ってくれよな。

ソースコード =　設計書
インタプリタ・コンパイラ ＝ 製造機
ってことか。

インタプリタは何を製造するんだ？

そりゃ実行コードだろｗ

メモリの中にネイティブの実行コードが
生成されているからこそ
ソースコードは実行できるわけで

繰り返すけど、インタプリタぐらい理解してくれよ。

インタプリタ作ったこともない奴 >>63

>>64
えと、Rubyの話だよな？

インタプリタだって言ったのは誰だっけ？

Rubyはインタプリタだぞ

Rubyはスクリプトだが？

スクリプトでインタプリタだろ。こいつ馬鹿か？

どっちみち「コードは設計」とかいっちゃう馬鹿とは仕事したくないわな

【死刑】馬鹿にプログラムを書かせるな！　その１【処刑】
名前： 仕様書無しさん
E-mail： sage
内容：
デバッグ・派生開発などまわりの全てが不幸になる
馬鹿プログラマのコーディング業務を禁止する法律を作るべき！

スレ立てられなかった
だれか建ててくれ

>>51
国語辞典でも、中国とはまず中国地方のことだと書いてあるよね

>>70
> どっちみち「コードは設計」とかいっちゃう馬鹿とは仕事したくないわな

正確に言えば、コードは設計書。
プログラミングが設計。
コーディングは、code＋ing というスペルの通り
設計書を書く行為のことですね。

こんなC#, C♯, C＃ライブラリ無いですか？
http://toro.2ch.net/test/read.cgi/tech/1342672311/

javaみたいに名前空間とファイルシステムが連動してればお目当てのソースを
見つけやすいが、rubyを含め1つのファイルにアレもこれも入れれる言語だと
お目当てのソースを見つけるだけでも疲れる。
javaの1ファイル1クラスは窮屈だけど、見つけやすい。javadocみたいなのも
標準で入ってるのは強みだし。

ソースは設計書とか言う割にはそういう部分が弱すぎるんだよな　＞　ruby

おjava様は馬鹿を言う

設計じゃなくて証明じゃなかった？

>>75
まず、RubyにはRDocという(javadocに相当する)自動文書化ツールが「標準」で入ってるから、
あるクラスがどこで定義されているかを探す目的くらいであれば、まったく問題無いはず

あるいは、RDoc(あるいはjavadoc)では不十分で、コード全体の名前空間やクラス継承の構造を
俯瞰したい(=大まかに理解したい)というのであれば、以下のようなツールも利用できる

・TmDoc - Rubyソフトウェアの保守ドキュメントを作成
　http://www.h6.dion.ne.jp/~machan/tmdoc/index-ja.html

出力文書のサンプルもあるので、目を通してみてくれ

>>78
> まず、RubyにはRDocという(javadocに相当する)自動文書化ツールが「標準」で入ってるから、
> あるクラスがどこで定義されているかを探す目的くらいであれば、まったく問題無いはず

それはRDocが用意されているものに限るな。

RDocが用意されてないライブラリなんてあるのかよ？と思うのであれば
実践経験に乏しいとしか思えない。

RDocが用意されてないのは昔自社の誰かが作ったコードだよ。
もちろん自分が作ったコードの場合もあるが。

工学として考えるとプログラミングは設計そのものなんだけど
商習慣としてはプログラミングが製造工程なんだよな。

我らがSE様がおっしゃられました。
「さっさとソース製造しろよクソPGどもめ」

>>79
RDocは(javadocとは違って)簡素なRubyの構文解析処理をしているから、
たとえパッケージ化されずRDoc向けコメント化すらされていない
過去の「自社の誰かが作ったコード」や「自分が作ったコード」であっても、
コードが配置されているディレクトリへ移動(cd)してrdocコマンドを実行すれば、
モジュール/クラス(名前空間)やメソッドの一覧を自動抽出してHTML文書を生成できる

だから、>>75の「rubyを含め1つのファイルにアレもこれも入れれる言語だと
お目当てのソースを見つけるだけでも疲れる」という指摘は意味不明というのが>>78の主旨

結論として、プログラマに1ファイルに1クラスしか書けないという制約を負わせ、
しかも「標準」では(javadocのような)貧弱な文書化ツールしか提供されていない言語と
比較すれば、Rubyは「ソースは設計書」と言うにふさわしい適性があるのではないかと....

もしもRubyをdisりたいのであれば、別の視点で攻めるのがいいと思われ

>>82
べつにRubyはやったことないけど、ソースはあくまで結果（最終はもちろん実行ファイルだが存在としてはイコール）
であるとも考えられるじゃない。
設計とは結果を導くための道標と位置づけであるからして、別物である、と
いうこともできる。

結局、個人の位置づけでいかようにも捉えられるのではないだろうか。



あ、あけましておめでとうございます。

>>82
例えばjavaだと「net.2ch.kohada.prog.スレ名」というクラスがあったとしたら、
「net/2ch/kohada/prog/スレ名.java」というファイルにプログラムが記述
されているという言語的な制約とそういう名前を付けるという習慣がある。
どこか別のソース、例えば「net.2ch.toro.tech.スレ名」というソースで
使っていて、探そうとした場合に自社ソースだったら割りと簡単に追える。
別にjavadocで出力してなくてもだ。 まあ、rubyに限らずjava以外の言語で
こういう制約を付けている言語はなかったとは思うけどね。 そもそもRDocで
出力しなければ分からないという時点ですでに劣っている。 構文解析云々と
いうなら、javadocもコメント無しのやつは出力されるし。

少人数の開発ならjavaのああいう制約は鬱陶しくて面倒だけど、ある程度以上の
規模の開発や人の入れ替わりが激しい開発なんかだと便利なんだよね。

Railsでも言ってるでしょ、設定より規約ってね。

Javaはディレクトリ深すぎ。

じゃばばんばぁだからね

>>1
こりゃダメだわ。バカだったのか。

実装手段によらない部分を設計っつーんじゃなかったのか

>>88
たとえばアルゴリズムを考えれば設計がなにかわかると思う。
名前の無い新しい検索アルゴリズム。
その手順を日本語で書く。
まさにアルゴリズム＝実装手段によらない部分＝設計だね。

その手順を日本語ではないプログラム言語で書いたからって
やっぱりアルゴリズム自体は設計なんだ。

実装手段によらない設計を頭で考える。考えただけでは形にならない。
その設計を曖昧な日本語で書くか、曖昧さのないプログラム言語で書くかそれだけの違い。
考えたもの＝設計、それを書いたコード＝設計書なんだよ。

だから行き当たりばったりのコードが量産されるのか。

コードを書くという行為が設計書を書く行為だと知らずに、簡単なものだと考え、
下っ端にやらせるから、行き当たりばったりのコード（設計書）ができあがる。

優秀なアーキテクトを雇うなりして、そのアーキテクトの設計書（コード）を
手本として、みんなで設計力をつけていけば、まともなコードを書けるようになる。

コードが設計書だと理解していないところは、たいがいエクセルかなんかで書いた
曖昧な日本語を元（それを設計書だと言いはって）に、各自ばらばらかってに
実装（実際は設計）してくれなんてやるからめちゃくちゃになる。
各自ばらばらに設計して統一されたものが出来るわけがない。

> 優秀なアーキテクトを雇うなりして、そのアーキテクトの設計書（コード）を
> 手本として、みんなで設計力をつけていけば、まともなコードを書けるようになる。
うちはそれやって、自発的に設計書を書くようになりました。

はい、設計書＝コードなので当然ですね。

言葉遊びをしたいんなら一人でやっててね。

スレタイ読んでね。

コード以外に曖昧さのない
設計書は存在しないから。

コードは結果（体現）であり設計は結果を導くために考案した式、故にコードを設計とみてもおかしかないが
それだと「なぜそのその手法を選択したのか？」という問いに答えることはできない

結果だけでは伝える能力は半減するのだ

定石ならまだしも、専門的なものについてはコードだけでは足りないものがある、故に俺はコード＝設計には
異論の側面はあるとみる

あと、別の観点では顧客に説明するときにコード見せるなんてことはまずあり得ない（Javadocの類でさえも）

そも、特定の言語や環境を挙げて議論するならその旨を前提条件として設けるべきだな

例えばWeb屋ならどうだ、とかね（業界でもいいけど）

>>96
> それだと「なぜそのその手法を選択したのか？」という問いに答えることはできない
それはコメントに書くんだよ。

COBOLではソースコードと実際に走ってるモノは違うのが当たり前だったりしなかったけか？
提出されたコードは全て水増しされたダミー

>>98
それは確実性に乏しい（正しいことが書いてあるかどうかが人だよりで不明瞭だ）から、あまり賢い選択ではないかも
知れないね
Javadocみたいなもので生成するような環境なら、しっかり書く癖もみについてるだろうけど

あと、顧客に説明するときって観点ではどう？

そんなの書かなくていいからそのぶん割引してよ。

せやなｗ

>>89
じゃあperlで「設計」してもいいよね。
rubyは設計に剥いてないと思う。

>>100
> それは確実性に乏しい（正しいことが書いてあるかどうかが人だよりで不明瞭だ）から、あまり賢い選択ではないかも

コード以外は全て動かない。
だからコード意外は全て確実性に乏しいよ。

エクセルなんかの仕様書があてにならないのはよく知られた話。
だからできるだけコードで書いた方がいいということになる。
これはコードから自動生成するドキュメントも含まれる。


> あと、顧客に説明するときって観点ではどう？
顧客に説明して、その説明が正しいとしてコードがその通りの動いているという確実性はない。
作ったものの動きを100%完璧に説明するならばコードを見せるしか無い。
そしてそれが現実的でないのは言うまでもないこと。

結局の所、顧客への説明は設計から見れば一部分だけしか伝えられない。
そういうものなんだ。

顧客にはその一部分を説明すればいいだけではないだろうか？

ただし開発者側として理解しておかないといけないのは、顧客に説明したものは一部でしかないということ。
顧客に説明した。顧客が納得した。これで設計完了だ！ではない。なぜなら一部でしか無いんだから。

>>103
> じゃあperlで「設計」してもいいよね。
いいですよ。

実際にそういう開発も行われています。

http://dev.ariel-networks.com/Members/inoue/spdy/
> ちなみに、mod_spdyの実装はC++です。Cで書かないとApache本家に取り込めない、と指摘があったら以下のような回答でした。
>
> 「C++でプロトタイピングして、後でCで書き直します」

>> 96
コードに付随するドキュメントがあればいいんじゃね？

確実性という意味では、どんなドキュメントも確実性は担保しない。
よって、テストやデバッグという検証作業を行う必要がある。

顧客には、より上位の設計書または、
コードに付随するドキュメントをベースに説明すると良いのでは無かろうか。

ちなみに「コードは設計」という考えは１９９２年時点で既に存在している。
http://web.archive.org/web/20080803072849/www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

ダメじゃん。今までなにも進展がない手法ってことだし。

>>107
内容そのものは素晴らしいね。

それはそれとして、その人のサイトどうなったんだろう？
web.archiveじゃなくて、復活させたいな。

>>108
手法じゃなくて本質的なとらえ方だよ。

コーディングが製造だとすると色んな矛盾があって
例えば
・プログラマの技量によって製造されるコードが異なる
・人数と開発期間が比例しない
・設計の検証するために製造工程が必要
・etc..

コーディングとテストが設計の一環だと考えるとしっくり来るわけ。
個人的にはメディアへの複製が製造だと思う。

>>110
＞・プログラマの技量によって製造されるコードが異なる
＞・人数と開発期間が比例しない
＞・設計の検証するために製造工程が必要
＞・etc..

だからといって、コード＝設計としたところで人が介在するものである以上は設計
と考えたとしてもそれで上記は避けられないものではないか？という考えだね、俺は

>>104
設計書（それがExcelなのかどうかは置いておくとして）があてにならないのだとすると、それは工程の無駄
だね
だが、大元は「ないがしろでまかり通る状況」が問題なのであって確実性に乏しい件とはちと違うような気が
するかなぁ

あと、一部分というのは処理の動きとして、だよね？ここが解釈違ってると話がややこしくなるので
確認したい
それなら同意。
顧客は「なにができるのか？（どんな機能？）」を説明すればよく、どういう処理によってそれを実現
しているかまでは説明するごっちゃない（してもいいけど）

なので、一部分というのは処理としてみた場合の考えとしては同意

>>106
まったくもって同意、俺も基本はその考えです

ただ、コードに付随というニュアンスのとこだけ「設計書が先で、そこからコードを生成する」という
考えなのです
まず、機能仕様（なにがこのシステムでできるのか）があって、そこから詳細仕様（その機能をどんな
処理…アルゴリズム含む…で実現するのか）が生まれ、もちろんレビューとかはあるよ、んでそれらを
経てコード、バイナリができる

という感じで捉えてるのね、俺は
それぞれの工程を着実にやらない、または短縮して、満足なものができたためしがないかな、関わった
プロジェクトの総括としては


※本音は開発にかける期間の短縮とか糞マネージ氏ねってことです

>>110
その流れで言うならウォーターフォール最強伝説再び始まるんだが

ウォーターフォール以外に最強を名乗れる開発プロセスなどない！

うん、とどのつまりウォーターフォールなんだけど、これの問題点を語る前に、日本の現場はなんだか
いろいろ足りない気がするんだよね

十分に吟味できたのか？とかさ、ぶっちゃけ前提にすら及んでないままにこの工法の問題点がどーした
こーしたって話しても意味がないかなぁ、と

いや、ウォーターフォール開発が最強なのは異論無いよ
手法というか、コード＝設計 ってのが頭おかしいやろ ってだけで。

なるほど
俺は後学のために色々実践してる人に聞いてみたい心持ち

>>1
４年近くも前のソースでスレを立てた意図がわからね。
ひょっとしてご本人でつか？

>>117
理論的には別にコードじゃなくても設計書はかけるけど、
コードじゃない＝日本語や図で設計書を書くのは難しい。
書くのが難しいと何が起きるかというと大幅に省略された設計書が出来る。

例えばさ、家でも車でもいいけど、設計書を作ってから家や車を作るでしょ？
その時、リバースエンジニアリングのように、作られてる家や車を解析して設計書を作るとするじゃん。
そうすると最初の設計書とほとんど同じ物が出来ると思うよ。
これは設計書に家や車を製造するのに必要な情報が全て含まれている証拠。

でもソフトウェアの場合、ソースコードを解析して設計書を作ったら、
手書きの設計書より大幅に多くなるでしょ？
クラスが足りない、メソッドが足りない、変数が足りない、etc
それは、手書きの設計書が大幅に省略された設計の一部でしかないから。

いくらでも時間をかけていいというのなら、日本語で設計して、
そこから人間が日本語読んで機械的に変換する作業をスレばいいよ。
「if(a > 100) ・・・」というコードが、「aが100以上の場合は・・・」という風に
冗長な日本語をになって、それを解釈を間違えないように書き換える無駄な作業ができるだけだろうけどね。

>>114
> その流れで言うならウォーターフォール最強伝説再び始まるんだが

ウォーターフォールは最強で間違いない。
だけど「ただし」がつく。

ただし、
・十分な開発期間が取れる。
・仕様の変更が発生しない。
・人間が間違いを起こさない。

今は競争のせいで十分な開発期間が取れない。
開発時間を短くすると、仕様検討の時間も減るから変更も起きやすい
間違いも起きやすい。だからウォーターフォールが使えなくなってる。

コードが設計だと、設計がまずかった時にどうやってフォローするんだ？

設計に最適なのは自然言語だけど、わざわざRubyで書く必要もないんじゃねーの？

フォローってなんだ？ コードレビューの話か？
設計がまずいなら直すしか無いし直せばいいだろう？
コードじゃなくてもそれは同じだろ。

>>121
人増やせばいいんじゃね？

>>111
それは同意。

「コード＝設計」だとこれらの問題が解決するという訳じゃなくて
設計であるからこういったことが起こる。
という考え方であって手法とか解決策という意味じゃないんだ。

>>122
設計が不味い場合のフォローは、コード＝設計であるかどうかに
関わらず、上流からやり直すべきだと思う。

「コード＝設計」論者は
「プログラマ＝土方」ではなくて、設計なんだから「建築士」だ！
という思想がベースにありそう。

下っ端建築士は半端ないレベルでブラック労働環境なので
PG = 建築士で問題無い

>>126
ということにしたいって思想？ｗ

論理的に考えなよ。
他の業界における設計と比べた結果
コードは設計書そのものと考えたほうが
極めて性質が近いって話だよ。

それは多くの技術者が語ってることだろ。

ごたく並べずにマ板民らしくさっさとコード書けよ

コードが設計って頭おかしいわ・・・
回路図引かずにいきなりアートワークおこすようなもんだろ

>>121
>今は競争のせいで十分な開発期間が取れない。
っていうけど、どれだけ開発期間をとったら十分なわけ？

>>128
「設計」したときの言語ではニガテとしているものがあって
それがほかの言語では容易に解決するものだとしたら、
「再設計」するの？

>>130
スレの流れとは関係ないけどアートワークってなんぞや？

詳細設計をそのまま書いたらコーディングになるくらい詰めて設計しないとダメ
机上でその詳細設計（コーディングそのもの）に
バグがないかどうかまでしっかりチェックしないとね

あいまいで、大雑把な話って技術いらないじゃん
ここの書き込みもそうだけどさ。
プログラマーをドカタ呼ばわりするんならそのくらいの事が出来ないとダメだよ
そこまで詰まった設計書をコーディングするだけの作業だったら
ドカタ呼ばわりされても仕方ないと思う

コード⊆設計

>>133
ttp://3.bp.blogspot.com/_s3r8cyoSFek/R9zJw-y9OpI/AAAAAAAAAGk/DQuLhvAgRY0/s1600-h/all.jpg
適当にググってきた

下が回路図（設計に相当）、上がアートワーク図（コードに相当）

>>128
おれはコード＝設計だと思ってるよ。

ただ、商習慣ではコード＝製造なので
こういう事を声高らかに主張する人は
商習慣に対して苦言を言いたいんじゃないかな？
と思っただけ。

>>130
アートワークってプリント基板の設計でしょ。

>>136
さんくすだ。
でもなんでアートワーク図ってのが必要なんだろう？
回路図の通りに部品配置して結線すりゃいいんでないの？

アートワークってコードっつーより、コンパイル後のアセンブリって感じじゃね？

>>134
VB6で動いてるのをC#に移行する用の詳細設計書ですごいの見たことある。

If XXデータ>=30 Then
　YYデータ配列(13) = 75
Else
　YYデータ配列(15) = 50
End If

みたいなの。VB6のコードで変数が日本語にかわっただけ。
詳細設計を名乗るならこのレベルでないとな。

それコードほぼ丸写ししただけじゃね？
たしかVBとかC#って、日本語変数おｋでしょ

ただ動きゃいいってことじゃなくて
ぱっと見ただけで何やってるかわかるコードを書くことを要求されるだろ？
詳細設計＝コーディングの意識を持つことは大切なんだよ

>>140
それは部品の実装の方だな
アートワークはまず自分でいじることのほうが多いだろ
自動配線は信用ならんて

>>139
そうそう、専門外だとそう見えるよねｗｗｗ
「プログラムなんて仕様書どおりに書いてコンパイルすりゃいいんじゃないの？」
みたいなことを言っているわけよ

「アートワーク＝設計」であるから
「アートワーク＝コードに相当」ならば
「コード＝設計」とならんかね？

>>146
アートワークは設計を実装に落とす処理だと思うがどうか
あれはコーディングだよ

設計図をもとに実際のものを作るのが製造だ
プログラミングの場合、製造はコンパイラが担当する
設計図を作るのはプログラマの役割

>>141
日本語変数…ねぇ
俺はじめてVBで見たとき、頭が混乱したわ（日本語で書くメリットが分からんかった）

>>147
例えばアートワークに落とす作業中に設計書でどの部品使うか何も書いてない
場合とかどうする？そんなことあるわけ無いと普通は思うだろ？　設計書から
コードを起こす場合はそんなの当たり前過ぎて誰もおかしいと思わない状態だぞ。

プログラミングはただの作業だと言う人には雑なコード納品してやればいいんだよ。
「この方が製造コストが安くすみますよ、やったね」って言ってやればいい。

>>141の設計書を書いたら
コードより長くなるだろ？

理想的な設計書とはコードと同等のものなんだから
それならコードで書いたほうが楽。
コードはアートワークだ。
コードから生成したモジュールの関連図なんか、
プリント基板と同じようなものだろ。

>>132
> 「設計」したときの言語ではニガテとしているものがあって
> それがほかの言語では容易に解決するものだとしたら、
> 「再設計」するの？

"再"設計ではない。その場合は本当に別の言語で書けばいいだけ。（＝設計）
別にJavaとJavaScriptを組み合わせて開発したらダメなんてルールはないし、
実際の開発では幾つかの言語を組み合わせてるのがほとんど
C#使っていても、データベースのアクセスはSQLを使うとかよくある話
DSLという考え方はまさに、ある言語で書くのは苦手だから別の言語で書くということだよ。


それから自分で言った言葉をよく見なおしてみ。

「設計」したときの言語（例 日本語）で苦手としているものを
容易に解決できるプログラム言語で書く

これを「再設計」するの？ と君は聞いたんだよ。
つまり、君はプログラム言語で書くことを（再）設計といったんだよ。

しかし、大規模開発では迷惑な手法だわ。
設計を人に説明する時は、ソースを渡すのかよ。

>>154
ソースコードからドキュメントを生成して渡すんだよ。
そんなこともわからないの？

大規模開発で「あるある」

・ドキュメントが無い。
・ドキュメントがあるけど、所々、抜けてる、古い、バグがある。
・ドキュメントが多すぎる。多いだけで役に立たない。

>>154
どのレベルのドキュメントが欲しいんだ？
プログラムレベルなら、コードから生成したクラス図とAPIリファレンスあれば十分じゃないか？

…正しく設計、命名されてることが前提だけど。

ローマ字化した日本語と英語もどきをちゃんぽんにするのが正義。

>>157
実装元になった仕様書がほしい

>>159
実装と大きくかけ離れた代物を説明に使うのか？

>>160
仕様と大きくかけ離れた実装なんかするなボケ。市ね。

>>161
お前の書いた仕様には、実装のことについて全く書いてない。

せめて実装するのに必要なすべての関数のとその引数と戻り値ぐらい、仕様に書け。
それが書いてないから、勝手ににやるしかないのは当たり前の話だ。

>>159
プログラムの設計を言ったんかみに書いてからプログラムしろって事？それは自動生成したクラス図やなんかと何が違うの？

てか、その後の話の流れ
まさかプログラムレベルの仕様書が必要なの…？
そんな仕事させられたら頭おかしくならない？

>>163
頭の中にしかないとの、それをドキュメントとして明らかにされたもの、どちらも前者には違いはないかもだけど
周りからすると雲泥の差があるね

いろいろな気づきは「触れるから発生するもの」だから、あとで生成したものではまさしく後の祭りということに
なっちゃうよ

どこまでやるかは別として、ね

結局のところ、ソースコード以外に
実装の設計が書かれているものがないならば
ソースコードが設計書になってるんだよな。

コードしか設計書に相当するものがないプロジェクトにいると改修時に泣きそうになるよ。

>>164
その設計書をミス無く書くとするとすごい労力。
そのうえ、変更時のつじつま合わせが大変。
そして、その分の金はもらえる可能性が低い。

そういう現場があることは知ってる。
が、よほど高い金をくれなければやる気にはならない。
設計の意図なら、コードの中にも書ける。

（Excelかなんかで書いた）設計書には
動作するシステムを作るための情報が全て書かれているわけじゃない。

理論的には書くことは可能だけど、現実にはまずない。

バグは存在し放置されているが問題視されない。
その状態で”完成”とされている。

それに対してコードには動作する情報のすべてが書かれている。
明らかなバグは直さないといけない。

まつもと先生は設計はコーディングだけで行う、とは言ってないんだよね？
日本語の設計書がいらないってわけじゃなくてコーディングも設計の一部だよって言うだけで。
なんでここでこんなにモメてるのかわからない。

>>169
言葉だけが先行してる部分はあるね
だけど、まぁいいじゃないか

>>169
ここにいるほとんどの人も、コードが設計であるといってるだけで、
コード以外は設計じゃない。とは言ってないよ。

揉めてるのは、コードが設計であることを認めたくない人だけさ。
なんでだろうね。論理的に否定出来ないくせに

「バカやえた・ひにんの作業であるコーディングが高尚な設計の一部とはふざけるな」と公言している
ＩＴ産業のピラミッドの頂点付近に位置づけている大企業のプロジェクトマネージャ・システムエンジニアが
このスレに来ているのでしょうｗ

大手の会社から請け負ってる仕事だったりする事が多いから
全部どこぞの馬の骨と言っても過言ではないだろう請負の人に
設計から全部丸投げしてる事を認めるわけにはいかないんだよ
設計は社内でやっていて彼らはドカタでありますと対外的には言わざるを得ない
ピラミッドの頂点の人達のプライドもなくはないだろうとは思うけど

大手に発注している人が可哀想だな。
ただの名前貸しの取次会社ってわかってない。
取次がいなければ、もっと安くいいものが作れる。

客のために、ソースコードが設計だと一般の人にも
伝える必要がある。

車検は大手のディーラーに持っていくのをやめよう
大手のディーラーでも、内情はどこぞの町工場に丸投げしてるから
車検は直接、そのどこぞの町工場に持っていきましょう

さすがに車そのものは丸投げだけでは作らないだろうけど、そんな感じ

>>174
大手は債務保証だけに徹してくれりゃいいんだけどな。

それはそうだけど、実情がいろんな人にバレて問題になっちゃったら
俺たちみたいな請負のどこぞの馬の骨の人は仕事が貰えなくなっちゃう
ピラミッドの上の人からはバカにされるけど、仕事がもらえる分今のままの方がいいんだよ

ソースコードが設計だというのは本当のことだけど
それがわからない人にはわからないままでいい。本当の事は教えなくてもいい。
本当に価値のあるものは、わかる人だけにわかればいいんだ

>>177
お前の都合なんかどうでもいい。

知られたくない事実は
知らせるべきだ。

>>178

「知られたくない」なら知らせないだろう。
知らせるメリットがない。

知らせるメリットは、大手がやってる無駄とマイナス作業をなくすため。
大手がいなくなったら、顧客と開発者両方にとって幸せになれる。

ピンハネは悪習だよな
もしピンハネを完全になくすことができたら
それはそれで失業率があがらないだろうか
まあそんな事まで俺が考えることでもないかもしれないが

顧客はどこぞの馬の骨に直接頼むことになるのだろうか
大手は開発環境そのものは持ってるだろうから全く存在意義がないということもないのでは
コピペでプログラム作ることが出来なくなるからできなくはないが大変だろう
ピンハネされるお金については開発環境を貸してもらえるのだから仕方がないのでは

環境整備から、全くのゼロからの開発を請け負うのなら開発者が直受けもありだと思う
それならそれで、いっぱいお金欲しくならないだろうか

どうだろう

ゼネコン通さなきゃパワーショベル使えないでしょう
そんなもの個人で用意できない
道具を用意できなきゃ何も出来ないよ

ゼネコンにピンハネされるのはしようがないのでは
長くなっちゃったけどそういうことが言いたい

パワーショベルってなんだ？

ソフトウェア開発で使う道具なんて
無料がほとんどなんで、個人でも
パワーショベルが使えるんだが。

開発者が使うパワーショベルて何だろうか。
オラクル？VisualStudio？
オープンソースなり個人用なりで何とかなるよね。
仕事取ってくる部分はどうにもならんけど。

オラクルやVisualStudioであっても
自社で普通に買うものだしな。

デカいサーバとか、いらないかな
汎用機のホストとか

何十万人が使用する事を想定して、
トラフィックはどのくらいまで耐えられるかとか
そういうテストを個人のパソコンで、できるのかな

>>186
はい。今はAmazon AWSなどを使って
個人であっても短時間で
何十台、何百台のマシンを調達出来ます。

そうかもしれないけど分散の仕組みとかを１から設計しないといけないし
稼動実績がないとやっぱり仕事もらうの難しいと思いますよ

個人の信用で仕事とるのは本当にたいへん
起業しようという気概は凄いと思います

実際に運用していて障害があったりして
かなりの損害が出てしまったりしたら大変ですし

若さと荒削りな技術を評価してくれて仕事をくれる人は居なくはないでしょう
起業がうまくいくことを願います

ファーストサーバの例を見るに、稼動実績とか重視してる奴ってそんなにいなくね。
とりあえず値段で決めてるようにしか見えない。

>>188
なんか話ずれてるぞｗ

ソフトウェア開発には
ゼネコンみたいなのは無いって話だろ。

結局パワーショベルってなんなんだよ。

信用ってより、何かあった時の瑕疵保証やら賠償やらで中小だと金を取る前に
潰れちゃうとかの方が大きいからな。ここらへんは土木建築でもそうなんだけど、
国や地方自治体の方針で公共事業なんかは地元の中小使えって通達があるから
バブル以降は大手ゼネコンしかできないもの以外はなるべく中小が受注出来る
ようになっている。

それならそれでそういう会社だって言えばいいだけじゃね。
何かあったら保証する会社。

保険かければよくね

保険会社はシステム復旧してくれないぞ。

大手はシステム復旧しないのかｗ
技術力無いからな。

仕様書の力でシステム復旧とかやってんのかな？ｗ

しょせん、javaScriptをパクったRubyですから。

>>195
保険会社って、損保や生保だろ？　SIerとは別。

いや、話の流れからSIerは役立たずなんだから
保険会社やってればいいってことだろ。

大手はマジで技術力ないよ
けっこう昔だけどみずほ銀行の普通預金のバグ酷すぎ
あそこまで騒がれないにしろ、他にもいろいろ障害出てるシステムはあるでしょう
ひでえ仕事だよ俺にやらせろよと思ってる人いっぱい居るよ

Rubyの開発はドキュメントがないんだよな。
機能追加でもドキュメントがない。

誰も中身わからなくて、最初から作ったことが何度かあってさ。

設計はいいけど、その前と次の工程は資料が必要。

開発言語とドキュメントの有無は関係なくね？

いや、必要なのは言語のドキュメントって話だよ？
わかってる？

リファレンスのこと？

どういうポリシーで、どう作ったかの資料でしょ、多分。
API仕様とかではなく。

>>171
> ここにいるほとんどの人も、コードが設計であるといってるだけで、
> コード以外は設計じゃない。とは言ってないよ。

どうだろうか。>>154とか見ると
既存の設計書の代わりにソースコードを設計書とする手法である
と勘違いしている人が居そうだが

誤解釈防ぐには、しっかりした作りのものを渡すという手もある。
相手がそれを理解できるかどうかは知らんけどね。

>>205
勘違いしている人は
「ソースコード＝設計書」を
否定している人だけだよｗ

今でもコードを書く部門のことを「製造」と呼ぶ会社は結構あるんでないかい？

誰がやっても同じことが出来ると勘違いしてるところでしょ、製造って言ってるのは

なんと呼ばれようがやることは変わらんのだけどな。
いわゆる「カイゼン」をコード書く現場に持ち込まれると泣きそうになる。

カイゼン
を誤読してる老害経営者がいるんじゃね

>>210
ソースコードの修正＝改善だよ。
ライブラリの作成＝改善
リファクタリング＝改善
コードをシンプルに書き換える＝改善

袋詰程度の作業と思ってんじゃね、プログラムを

というか、コードを書く段階で「設計」してるようじゃ
いつまでたっても職人気取りで終わるぞ

いい設計書があがってくりゃコードを書くのに設計なんていらんよな

要求分析もできんのにコード書けるわけねえじゃん

要求分析を担当されている大手SIerへのご批判でつか？

無能自慢してる人たちがいっぱいのところ？

>>214
意味不明。頭で考えた設計は
文書化しないといかんだろ？
ソースコードという形で文書化するんだよ。

>>219
たぶんね、>>214が言いたいのは頭の中の考えをコード化する場合、まとまった状態の方がスッキリとして
コードにするだけだよってことがいいたいんじゃないかな

頭の中の考えをいきなりコードとして書く場合、それはどんなにスッキリしてるつもりでもやれ考えてない
ところが出て来て手が止まるとか、外向けのIFをどうするか気してなかったりするもんだ
そもそも、コーディングしているときって手が意外に止まってたりするよなんてな研究結果もあるわけで、
それってつまり「その時点で考えてる」っつーことなんだよね

あと、一人で作ってるのかグループでやってんのか

この辺の環境の違いもこうした意見の違いに表れるんじゃないかな？とも感じる
そりゃ一人とか少人数とかある程度まとまった機能を開発するんなら外的要因なんて気にならんわな
とも思うし

>>220
> 頭の中の考えをいきなりコードとして書く場合、それはどんなにスッキリしてるつもりでもやれ考えてない
> ところが出て来て手が止まるとか、外向けのIFをどうするか気してなかったりするもんだ

当たり前だろ？ それはソースコードじゃなくて
WordやExcelに書いたって同じだろ？

一旦書き出し、修正しながら、煮詰めていく。
WordやExcelでそれをやってるのに
ソースコードで試行錯誤してはいけないのはなぜ？

コンピュータで出来ること（内部動作）を、人の感覚で細かく語ることはとても難しい

> そもそも、コーディングしているときって手が意外に止まってたりするよなんてな研究結果もあるわけで、
当然。
設計しているんだから、手が止まるのは当たり前。
それこそコーディングが単なる製造ではないということの証だ。


小説に例えればわかりやすい？
他人が書いたものを写経するなら手は止まらんさ。何も考えてないんだから。
執筆作業ってのは考えて書いてるんだから、手は止まる。

この業界のこと知ってる立ち回りの上手い人は、写経みたいな動作が出来るんだよね

>>225
で、そいつが書いたコードは写経なみにほとんど無駄もなければtypoもないの？

いやどんなに無駄がなくても、それは最初の話で
仕様が変わるのは必然なんだから
結局リファクタリングが必要だろ。

>>226
時間で働いてる人が効率化とか考えてやってると思うの？

>>224
頭の回転が遅いだけ。

>>229
なぜそう言い切れる？
お前は考えることをしないのか？

コードが仕様書とか言ってる奴いるけど
フレームワークを使ってるだけのようなのはそりゃコード読んだ方がいいけど
複雑な数値計算してるようなのはドキュメントないと無理でしょ。

>>231
し〜。そんなシステム組んだ事ないんだよ、ここの奴らは。

> 複雑な数値計算してるようなのはドキュメントないと無理でしょ。
無理じゃないでしょ
流れが読みにくいような書き方をしてるだけじゃあ

>>231
複雑な数値計算のドキュメント例見せて。一部でいいからさ。

>>234
コメントで書くよりたとえばTeX書きされた数式の方が、ってことなんじゃね？

数式以外の部分は、設計要らないの？

>>231
>>233
「コードとは設計である」という議論が
「コードがあればドキュメントは不要である」という議論にすり替わってるよな。

ドキュメントが不要って話じゃないから。
ドキュメントの有無にかかわらずコードは設計による成果物なんだよ。

数式に関してはプログラム言語と
同質のものだからなぁ。

ようは自然言語による設計は
冗長で曖昧さが多いため
設計には向かないという話。

あ、もちろん設計には向かなくても
設計の補助には使えるよ。

>>238
いや、WebシステムとかRubyが活躍してる所では自然言語の方がいいよ。
ビッグデータや画像処理をやると、数式の硬さは希に感心する。そして、その数式を使ってすら正しく伝えられない人もいる。

Web系だけど三角関数と外積内積使って衝突判定の処理作ってるわ。
IE6だからCanvasのクリック判定が効かないからやるしかねえんだわ。
Javascriptだからコメントもあんま入れれねえし
ドキュメント無しでこんなんわかるとおもえんわ

>>239
> いや、WebシステムとかRubyが活躍してる所では自然言語の方がいいよ。

いいよという理由が書いてないので却下な。
設計書の話であることを前提に
自然言語の方がいいという理由は？

>>240
> Javascriptだからコメントもあんま入れれねえし

え？なんで？ まさかMinifyとかしてないの？

jQueryとか一般的なオープンソースのJavaScriptライブラリでは
普通に複数のファイルで作って連結してMinifyしてるから、
やるのが普通だと思ってるんだけど？

おまえらどんだけボロいマシン使ってんだよ

http://mormon.org/jpn/yukihiro/
ま　さ　に　布　教

でもこれ系の人でMac使ってないのって珍しいな…そこだけは好印象
もっといいマシン使えばいいと思うけど

>>243
いきなりどうした？ｗ
関係ない話しだしたなｗ

>>240
> IE6だからCanvasのクリック判定が

IE6では存在しないCanvasを使うってことは、ExplorerCanvasというライブラリを
使ってるということだと思うけど、このライブラリにバグが有るの？
報告はされてる？

>>241
設計段階で要件定義まで差し戻すだろ？
お前レベルなら。

>>248
あの、質問もう一回書きましょうか？

> いや、WebシステムとかRubyが活躍してる所では自然言語の方がいいよ。
いいよという理由が書いてないので却下な。
設計書の話であることを前提に
自然言語の方がいいという理由は？

答え：温かみがあるからです。

言語は変わるかもしれないからなぁ

>>250
大事やね

俺、数式嫌いなんだよ。

なんていうかさ、温かみがないだろ？

小学生でもわかるような
説明をしてくれよ。

>>249
お前さ〜、設計の手法を勉強したことないだろ？

コードって二次元なんだよな。配列とか、特にRubyはさ。
まあ実装上の逃げ道はあるだろうけど、そんなの使ったら設計とは言えない。

良い設計は、要求されている情報や能動的な流れを、余すことなく、減らさず、変に増やさず、実現するために行うわけでさ。
そこには二次元的な縛りはないのよ。

コードで設計すれば、そりゃ実装だわ。
多次元に弱いRubyなら特に。

Rubyは可読性が悪い。
Ruby コンソールが便利、とかいうけど、
それ、可読性が悪くてツールに逃げてるだけですから。

何言ってんだこのアホは

>>254
それで肝心の説明は？

それをいわないと「設計の手法を勉強してない人」に
お前が負けてることになるぞ。

ちなみに「コードは設計」という考えは１９９２年時点で既に存在している。
http://web.archive.org/web/20080803072849/www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

古典を引っ張り出してきてどうする？

>>258
ならないんだな、これが。

>>261
で、説明は？ｗ

設計と実装を対で考えるのはソフトウェア独自だよな。
普通の工学分野なら設計と製造なんだよね。

実装というのは実際に取り付けたりする作業だったり
特定の機能を実現化することだったりする。

ソフトウェア工学というくらいだから、普通の工学分野に当てはめると
製造とはビルドであり、コーディングは設計なんだよ。

>>263
思考停止馬鹿

上流工程とか威張ってる連中の言う「設計」って、
建築で言えば「完成予想図」とか「完成模型」のレベル

いやいや。上流って馬鹿にしちゃいけないよ。変数名まで決まってる設計書が下りてくることもあるんだから。

>>266
決めるのは簡単。その根拠が正しいなら
それは設計書だと認めるが。

×「コードのみが設計である」

コード以外にドキュメントがあっても主張と齟齬はないでしょう。

俺が！俺こそが設計だ！！

>>269
みたいな奴、Rubyやってる奴に多いよな。
チーム組んだプロジェクトだと、悪影響がデカイので左遷させてるわ。

>>262
ほとんどの手法が設計を細分化して幾つかのターンに分けるけど、
ソースで設計した時は、そんなこと出来ないだろ。
設計の再評価は集約されたソースからは無理。ターン毎の資料を再評価するのが正しい。

より良い設計を行うためにさ、色々な設計方法があるのに
ソースで設計すると、なにが良くなるのやら。

何が良くなるって、そりゃ曖昧さがなくなるし
実際に動作するいう実証が得られるし、
良くなることはあっても悪くなることはないよ。

>>273
でも、>>291のようなこと等をやるに最悪なんだが。

単にコストを自分だけから他人に移してるだけじゃね？
チームワークには向かないわ。引きこもり向けか。

>>265
完成予想図を見ただけで、いきなり鉄骨を組みはじめるやつは恥ずかしい。
挙げ句の果てに「建築物は設計である」とか言い出しちゃうのw

>>275
だからコードという設計図を書くわけでしょｗ

設計に段階があることを受け入れられない人達

設計のアウトプットは設計図面だよね
そして図面を元に家を建てる。
家がコード、プログラムなんだよ。

現場の判断で勝手に図面書き換えられちゃ困るわけよ

図面があまりにも拙いのなら設計やりなおせって差し戻すことになるけど
それ以外はちゃんと図面通りつくらないとな。

要求通りに動くものが家でしょ、例えるなら
コードって、なんのこと言ってるんだか

>>280
そんなオレオレ定義を振りかざされても困る

プログラムの設計図なんか書いてどうすんだよwバカかよwww

他の業界と同一視してる奴はただの馬鹿か、実際にコード書いたこと無いやつだろ。
設計書通りに書いてまともにバグ無しで動くのなら誰も設計書に文句言わんっての。

相変わらず「コード＝設計」が新たな手法だと勘違いしているのがいて話が噛合わないね。

>>278
> 現場の判断で勝手に図面書き換えられちゃ困るわけよ

たとえば、コードにはクラスや関数が書かれている。
ならば図面にもクラスや関数が書かれているはずだ。

ちゃんと書いてあればそのとおりに書くが
書いてないものは、書き換えどころか、作り出さないといけない。

勝手に書き換えなくてもいいような図面とは
クラス名、関数名、その引数、変数名
当然プライベートなクラスなども含めて
全て書いていないといけない。

書くのが面倒というのは言い訳でしか無い、
実際コードで書いているのだから書けないことはない。

>>278
> 現場の判断で勝手に図面書き換えられちゃ困るわけよ

図面なんて、現場の判断で普通に書き換えられるよ。
正しくは書き換えるのではなく、
図面通りに作らない（作れない）という話だが。

むしろ 100% 図面どおりに作られた建物の方がマレだろ。

図面には作るのに必要なことが全て書いてあるからなぁ。
書いてないのは作るときに使う道具の使い方だけ。

ソフトウェアも本来は設計書に書いてないのは
コードを書くときのエディタ・IDEの使い方だけ。
作るのに必要なことは全て書いていないといけないんだよ。

ま、それができない（効率が悪い）からコード＝設計書というわけさ。

何も良いことがないのに、コードが設計とかさ、
頭おかしい。

コードが設計と考えると
さまざまな矛盾が解決するんだよ。

ソフトウェアを建築と比較してもしっくり来ないな。
比較対象には工場の方が良くないかな。

比較するにしても個人の技量が上がることを前提にしないと使い捨てカイロみたいになるような

例えば製造は体を使う物
設計は頭を使う物という定義にしたとしても

ショートカットを体が覚えることでエディタを使いこなす作業が製造であり、
内容を考えているのであれば、頭を使う＝設計ということになる。

こんな簡単ことからもコードが設計であることを
導き出すことが出来る。

なんでエディタ使いこなす作業が製造なんだよ
建築でも製造業でもCAD操作を製造とか呼ぶか？
そこらへん含めて設計だろ

さっさとコードを製造しろ

実際、あるプログラミング言語で作成するソフトウェアの構造を
一番的確に表すことができるのは、そのプログラミング言語で書いたコードだからな

事あるごとに「まずフローチャートを書け」とかいうアホは一刻も早く死に絶えろ

設計する能力がないから、コーディングしながらやります。

ってだけだよな。

素人かよ。

僕って、かっこいい？

>>296
いえ、コードじゃないと設計を正しく記述できないからです。
コード以外で関数の引数などまで
しっかり設計された例を見たことがありませねん。

コードは設計だという見方より
コードは絵画だという見方のほうが
まだしっくりくる

>>298
それは君のまわりではそうだというだけで、ないこともない

コードは設計とぬかしてるバカは
品質を何で担保するつもりなんだよ

as is
の世界

>>301
品質の担保なら
○○の機能を○○までに作りますって
書いておけばOKだよｗ

ほんとうの意味で品質の担保をしたいのなら、
まずは品質の計測ができるようにならないといけない。
計測するためには実際に動くものが必要。

動くものがあれば、それに対してテストしたり
メトリクス計測したりして、品質を調べることが出来る。
あとは、その品質が〜以上って定めればいい。

こことか読んでみたら？
http://gihyo.jp/news/report/01/agilecon2010/0004

>>303
コードが設計どおりに動くかどうかを測定することが品質の担保になる
言ってることわかる？ コード≠設計ってことだよ？

詳細設計書作っておくと「ちゃんと考えて作ってある」ように思われるんだよ
要するに、バカを納得させるための必要悪

良品質なプログラム作るのに、大まかなモジュール構成とか全体シーケンスの設計などは必要だが
メソッドごとのアクティビティ図全部用意するとか、キチガイの所業

プログラミング言語のソースコードで、ドキュメントベースの設計書よりも
分かりやすいソフトウェア構造が記述できない人間はPG辞めた方がいいよ
才能がない

英語の小説書くのに、直接英語で考えてそのまま表現していくのと
日本語で文章作り終わってから、それを元に英訳したものでは
どっちの方が自然で英語圏の人間が読みやすいものになるか聞くまでもない

>>304
俺はな、設計そのものが間違ってたり、設計に動きが書いていなかったりするから、
最終的に客が望んでいるものの品質を測定しようと言ってるんだよ。

お前の話だと、設計の品質をどうやって担保するかに
話が摩り替わってるだけじゃないか。

要求に対する理解力がない人が間に入るからでしょ

コードの品質を何で担保するか？
↓
コードが設計通りに動かを測定する
↓
あれ？じゃあ設計が正しいのをどうやって担保するのか？
↓
クソSE「設計という名前でそれらしいものを適当に作って客がはんこを押せばそれが正しいんだよｗ」
↓
客「設計？ 意味がよくわからんけどプロが変なものを作るわけがないか」
↓
開発終了後
↓
客「こんなの作ってなんて一言も言ってない！」
↓
クソSE「でも判子押しましたよね？ｗｗｗ 契約書に書いてますよｗｗｗ」

>>308
そもそも、客自身も、自分の要求が何であるかを
完全に理解していないということを知るべき。

実際に出来てから、思っていたものと違うとか
使ってみたら使いづらかったということが起きる原因はこれ

もちろん100%完成品である必要はないが、ある程度動くものを作らないと
客は判断できないわけで、要求も仕様も固まらない。

案を出して、動くものを開発して、試用して、問題点を修正するという工程を
繰り返すのが設計なのだから、そこからプログラミング工程を省けないのは当然のこと

誰が書いて（やって）も、同じ物は出来ると思ってる人がいるってことじゃあ

品質と保守性と拡張性と開発時間まで一緒じゃないと
「同じ物」とはいえないからなぁ。

まあ、コードが理解できない客に、Officeで作った設計書見せても理解できるわきゃないわな

以前、四半世紀前くらいはソフトかじってたとかいう爺の客に、文章ベースで機能説明書いてやったら
「文章だけでは処理が分からん、フローチャート書け！」とほざき
今のソフトウェアは非同期で動作しているのでフローチャートでは表せないと何度言っても聞かず
仕方が無いから概要レベルどころか概念レベルのフローチャートでっち上げてやったら
いたく満足された
当然起こしたコードは、そんなフローチャートとは100%別物

ソフトウェア製品納める際の設計書の価値なんて、こんなもん

>>311
誰がやっても一定のクオリティを保つために、開発手法を色々と考えてるんですけど？

>>313
作ったモノが別物、って、ダメだろそれ。
粗悪技術者だなお前。

>>314
素人でも出来る建築方法のたぐい？

>>313
実装手段は枝葉末節だろ
心配ならそれこそコード＝詳細設計書と言い張っとけ

全体として、設計書（概念レベルのフローチャート）どおりに
動作するなら、それでいい。
その代わりそのとおりに動かなかったら死刑だ

>>314
ソフトウェアで同じ物作るなんて誰でも出来るよ。copyコマンド使えばいいだけだから。
建築物やら工業生産品なんかはそんなコマンドないから、人の手やらロボットやら
必要になるんだけどね。 一品物を同じクオリティとかどう図るの？

そりゃプログラミング言語の開発者にとってはコード＝設計でしょうｗ
業務アプリの開発者にとっては、せいぜいコードは設計に含まれるくらいにしかならん。

>>318
テスト項目を作って、テスト項目をクリアすることだろ

>>314
コードは設計と考えると、
誰がやっても同じクオリティになる設計方法を
いろいろ考えてるということになるけど、

誰がやっても同じクオリティになる設計方法って
存在するのか？

FizzBuzzみたいに単純なものであっても
同じクオリティにならないんだよな。

「1 から順に数を数えていく。ただしその数が 3 で割り切れるならば数字の代わりに Fizz と5 で割り切れるなら Buzz と言う」

これは仕様であって設計ではないということだ。

これに対してコードが同じクオリティになる設計というのを見てみたいね。

>>322
「一定」は無理だが、「一定以上」ならいくらでもある

まず、クソ事例を挙げて意見をいうのやめーや

各工程を本来の姿（意義や目的）で語ってある程度コンセンサスを得てからじゃないと話が分散してて
まったく有意義じゃないな

>>323
いや、いくらでもあるという
言葉だけでは、いくらでもあるという証明にはならない。

>>324
細かいことはどうでもいいよ。

ちなみに「コードは設計」という考えは１９９２年時点で既に存在している。
http://web.archive.org/web/20080803072849/www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html


これが正しい考え方だねってこと。

>>326
「天動説は紀元前からあった。だから正しい。」
みたいな感じ？

>>327
いいえ、むしろ「コードは設計ではないという考えは、昔からあったが間違い」ということです。
正しいか間違いかは、論理的に検証して判断することです。

コードが設計だと仮定すると
他業界の設計との、さまざまな矛盾が
解決するのです。

コードは設計である。
しかし、自然言語で書かれた設計書もまた設計書である。

CPUに向けた設計書か、人間に向けた設計書か。
その違いだけで、どちらも設計書である事に変わりはない。

>>329
これが落としどころだね

>>326
92年から存在してることがなんなのかイマイチ君は説明できてないけど、読む限り手法の一つではあっても
主流にはなりきれてないよね

利点がないよな。
粗悪技術者にはいろいろな矛盾を無くせて良いのかもしれんけど。

普通の技術者にはそんなのいらんわ。

>>332
普通の技術者さん、さようならｗ

優秀な技術者は大概
コード＝設計派だよな。

自然言語で設計書を書くメリットがないと思うんだ
そもそもどうやってその設計書を元にビルドするの？
プログラミング言語で設計書書いたらビルドボタン押すだけで楽なのに
どうして自然言語で設計書を書くの？

自然言語は、設計（＝コード）の
補助として使うのが一番だな。

コードには設計のすべてが書かれているが
詳細すぎて把握しづらい時に、
概略をしるために使う。

メリットはある。つーか、前から散々出てるんだが。
ソースが設計って宗教か？
バカバカしい。

本質じゃあ

中身読めない人が自然言語の虎の巻？欲しがってるような

>>337
何いってんのお前？

俺らは、ソースは設計書、
自然言語も設計書、
両方設計書って言ってるのに、

お前だけだよ。自然言語で
書けば十分って言ってるのは。

自然言語じゃソースコードの全てを
記述できないのはさんざん出ている話。

・基本設計書は自然言語で書くこと
・詳細設計書はコードで書いても構わない

基本設計は自然言語でやる。
そこからプログラミングができる程度までの設計を、これまた自然言語や図(UMLやER図など）を使ってやる。
そして最後にコードを書く。

これだけでしょ。

設計ってどうやって機能を実現するかってことだよね
それがソースより解りやすく書かれた資料なんてみたことない
そんなのよりどんな機能を実現したいのか書いてある完成予想図のほうが重要

状態遷移すらまともに組んだ事ないのか？
簡単な仕事ばかりでちゅねぇ。

>>343
誰も状態遷移図の話なんかしてないけど、
何を見てそう思ったの？

>>344
たとえ話だよ。

無理に例えなくていいよｗ
たとえ話は所詮たとえ
例えたもの以外、何も批判できてないから。

設計と製造の境目はどこか？という議論なのに
新しい「手法」の話だと思ってる人が多いな。

コードが設計だとして自然言語の設計や図表が
無くなる訳じゃないのにそう思い込んでるんだな。

単なる先行開発か？

>>348
先行開発＝コード書くことではないから
関係ない。

概念設計→詳細設計→実装という流れの中の詳細設計以降の話なだけじゃん。

適当に実装から入って結果的にできたもんなのに自称設計とかいう馬鹿が多いから
こういう話題で荒れるんだな。

仕事ではきっちり設計書を書いていようが、趣味でプログラミングするときに設計書書く奴なんて一人もいない
オープンソースプロジェクトも、仕様決めはやるだろうが「コーディングの前に設計書をアップしましょう」とか聞いたことがない
つまり、プログラマは全員、本心では設計書なんて不要だと思ってる

>>「コーディングの前に設計書をアップしましょう」とか聞いたことがない
自分しか使わないような趣味のソフトとか、しょぼいツールならともかく、
商品開発でそれはやばいだろｗ

>>352
たとえばLinuxだって設計書なんてない。

というかコードに全て書かれているから
別途設計書は不要。

理解をサポートするために追加でつけるのが
コード以外の設計書だよ。

既に出来上がったものを使わせる分には当然設計書なんて不要だが、
複数人でソフト書く場合にどうやって進めてるの？
誰かがメインのコード書き終わるのを周りは待ってるの？

>>354
おはなしあい

>>354
それと設計書が何の関係があるのかわからんのだが？

やるべきことと、やるべき人を決めれば
終わりでしょ。設計書にやるべき人を書くの？

> 誰かがメインのコード書き終わるのを周りは待ってるの？
誰かが設計書を書き終わるのを周りは待ってるの？

オープンソースの開発なんか誰かがコード書いて
それをレビューして、マージするでしょ。

設計書を誰かが作って、この通りに開発してください。
なんてやってるオープンソースプロジェクトなんて無いよ。

>>355
話し合いで設計方針決めるのは良いとして、その記録が落ちるのが
設計書じゃないの？

>>356
>>やるべきことと、やるべき人を決めれば
>>終わりでしょ。設計書にやるべき人を書くの？
そのやるべきことはどこに書かれるの？設計書にやるべき人を書くとか
聞いてきてるのも意味不明。

>>誰かが設計書を書き終わるのを周りは待ってるの？
質問に質問で返すなよ。まず回答してくれ。

オープンソースの開発はしたことないから分からんが、
何の共通認識もなしにいきなり皆で好きに組み始めるのか？

オープンソースは基本的にどこかの誰かが最初は一人で始める
とりあえず動くようになったら公開する
あとはそのプロジェクトを気に入った連中がいればパッチをなげてくるようになる
最初は一人だから共通認識なんて要らないし、数名増えたところでみんなコードは読めるから
最初の一人のやり方が特にまずくなければ、それに合わせるだけ

オープンソースは、出来がどうであれ、まず実際にコンパイルできて動かせるものが
存在するところからスタートするんだよ

そんなだから、喧嘩ばかりなんだよ。
仕事場では使えねぇ手法だわ。
ソフトウェア工場で使えない手法は糞。

>>350
たぶん、コード＝設計で両者が語らずして一番の認識の違いはここだな

ところで「実装」は設計？製造？

>>361
製造

>>361
犬小屋を設計図なしで作るのと同じほう

ソフトウェア開発において実装とか
頭のなかにあるコードを
テキストエディタで入力すること

考えることがあるのなら、それは設計。

頭の中でコードを組み立てることも実装のうち

>>364
建築で建材を組んだり釘打ったりするのも設計になっちゃう

>>366
建材を組む場所を決めたり
釘を組む場所を決めるのは
設計でしょう？

>>367
そう、それが仕様書だ

仕様書、釘はこの箇所に○cmごとに打つこと。

仕様書は客との話し合いで決めること
設計は客抜きで決めること。

要件定義と仕様の区別のつかない馬鹿

そうやって細かく分けるから
プロジェクトが失敗する原因になるんだと思う。

伝言ゲームみたいなもんだよ。
間で違うものに変換されるたびに
どんどん情報が劣化していく。

あと何十年たったら、ソフトウェア開発を建築になぞらえて考える風習がなくなるんだろうな
作り上げる仕組みが全く違うのに、あたかも建築物のように、設計して施工するのが当然という考えがあるから
「まず設計書をきっちり作れ」みたいなイカれた考えがなくならないんだろうな

ソフトウェア業界の設計図なんて
建築物で言えば、

ここらへん居間、キッチン、ダイニング、寝室
それぞれは廊下でつながっている。

程度のものだからな。

共通認識無しで進める仕事なんかないだろ。
起案〜実装まで同じ奴がやるならともかく、そんな商品ほとんどない。

>>375
起案と実装の間は何だ？

他の商品では同じ工程を二つに分けたりしない。

起案と実装が同じ工程って言いたいのか？ｗ

>>377
いや？
起案は設計じゃないと言いたいだけ。

で最終的にはコードは設計という結論に持っていく。

それは無理。
今まで、すべて論破されてるのにまだやるのか。

釘を打つ場所を設計とか言っちゃうわけ？

論破されようが何だろうが「俺が思った通りにしろ」ってことだろ。
もしくはプログラム＝製品と思っててよほど視野が狭いか。

>>381
そう怒んなよ
プログラム＝製品 ってのは法律で決まってんだし

ちなみに「コードは設計」という考えは１９９２年時点で既に存在している。
http://web.archive.org/web/20080803072849/www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

誰かこの内容に論理的に反論できた人いたっけ？

「こんな内容信じないニダ！」って言ってる人なら
いた気がするけどｗ

そっか、普通、製品はお客様に納品するのが当たり前なのだが
ソースコードの納品に特別な契約が必要で
その契約がなければ、ソースコードの権利が開発側にあるのは
ソースコードが製品ではなく設計書だからなのか。

誰か、>>384を論破してみて。

>>383
今は存在してるだけでは正しいとはいえない

ていうか、存在している＝正しい っていえるなら
今そのサイト存在してないんだから
今となっては正しくない という証左になっちゃうよね

>>385
別に小説でもなんでも同じことがいえるよね

>>386
いや、正しいといえるかどうかではなくて、

内容に反論してみてって話なんだが。

>>387
たしかに。
中古販売していいけど、
文章自体は著作権とかで守られてるしな。

馬鹿。

まー世のプログラマが設計書作る一番の理由なんて「納品物に含まれているから」だよな
本来コーディングだけで済む作業に「設計書作成」という作業を加えることで
工数を上乗せして客から金引き出せるわけだ

しかも、「ソフトウェアだって品質の高い製品を作るためには、きちっとした設計書を作る必要がある」
という馬鹿げた考えが世の中に根付いてるおかげで、誰も「設計書なんて作らなくていいから安くしろ」
とは言ってこない

だからプログラマはみんな、コーディングが終わったあとに適当な設計書をでっち上げるのさ

そんな仕事をRubyでやってるやつなんかいるわけないだろ？
だからルビ椅子豚は馬鹿ばかり。

>>391
自分のとこがそうだから他もそうって？
マジでこの業界から消えろ、迷惑も甚だしいわ

>>391
プログラムを自分で組むとわかるようになるんだけど、
やっぱり仕様書がカッチリしてるプロジェクトは
仕事がスムーズに進むんだよね

なにかあったら前工程に差し戻せばいいし
責任分解点が明確だと担当者同士でのいがみ合いも減る

>>383
それは、ソースコードがソフトウェア設計を表出したものであると言っているだけなんだけど、
結果として文書として出力される設計工程や、脳内での設計作業を否定する物では無いよ。

＞ソフトウェア設計は，コンパイラとリンカによって実際に製造（ビルド）されているのです。

ここが茶番ポイントその２
スクリプト言語は無視かよ気持ち悪い

>>C++は正しい方向に向けての一歩である
こんなたわごと書いてる文章を論拠にするとか
コード＝設計派 は追い詰められているの？

>>396
スクリプト言語は実行時に製造してるってだけ。

>>397
いいから論理的に反論しろよｗ
一度も反論してないよな。

仕様書と設計書は別のものです。
仕様書がきちんと存在するなら、設計書はあってもなくてもコードでもいい

一億総プログラマとか真剣に言ってた時代の文章を引っ張り出すとか、
よっぽどだなｗ

>>395で反論するような内容じゃないし、馬鹿が都合よく解釈して
「反論してみろよｗ」とかｗｗｗ

ほらまた反論できない

話がループだな。

最後の砦がそこしかないから、何言われても壊れたテープレコーダーみたいになるしかないんだろ、、

ソフトウェア開発に、自然言語で書かれた設計書なんてものが必要だとほざいてる奴は
ソフトウェア石器時代からの生き残りなんじゃないの？

可読性が高いソースコードを記述するという概念が存在せず
機能や目的が推測できない変数名、関数名を付けて、ひと目で流れが分からないような
巨大なブロック、深すぎるネスト、ちりばめられたreturn等々
とても人間が読むに値しないウンコすぎるコードしか書けないから
処理説明のために人間の言葉で書いた設計書が必須だと考えている

この手の輩は、ソースはコメントが多いほど丁寧に作られていると考えるタイプと同種

> とても人間が読むに値しないウンコすぎるコードしか書けないから
> 処理説明のために人間の言葉で書いた設計書が必須だと考えている

いやいや、ウンコすぎるコードすら書けないSEが、
自然言語で書いた設計書に価値があると信じたいだけでしょ

コードを書けない、読めない人がいっぱい？

どっちもどっちを論破してるようには見えない

そりゃお前が盲だから

こうして、延々とループするのであった

まあコーディング前に仕様書さえちゃんと書いてくれれば
こっちも文句は言わんよ

人間の言葉で書いたものは
設計書というよりコメントというべきもの。

クラス図とかE-R図とかそんなのは
コードから生成できる。
ならば二重に作る必要はない。

だから、設計書がプログラミング言語だろうとどうだっていいよ
仕様書をきちんと日本語で書いてくれればそれでいい

>>413
仕様書の話なら、スレ違いだから
お前がよそにいけ

開発言語にJavaはもう古い！次の主流は「関数型」言語★２
http://uni.2ch.net/test/read.cgi/newsplus/1360017468/
同社が採用したのは、業務系システムの開発で主流になっているJavaでも、
Webシステムで人気を博すRubyやPythonでもない。「関数型プログラミング言語」と
呼ばれるオープンソースの開発言語の一つ、「Scala（スカラ）」だ。

>>415
だがJava上で動作する…ってこれ何かの上級者向けの冗談なのか？

>>412
その程度では話にならん。

コードが設計とか、どうでもいい
設計が実装なら、実装方法なんてどうでもいい
そんな枝葉

次の主流は「関数型」言語 じゃまだだめだな。
今の主流は「関数型」言語 にならんとな

>>417
え？ 言い返さないの？
泣き寝入りで終わりなの？

ソースコード　⇒　コンパイラおよびプロジェクトメンバー向けに作る。
S/W仕様書　⇒　元請け、会社の上司、プロジェクト新規参入者向け、
および自分が真面目に考えて仕事たことの証拠のために作る。

目的が違うが、内容は被る部分が多いから俺は並行して作る。
ソースコードはS/W仕様書と同じで実質設計だが、商慣習的には製造だから、
TPOに応じて使い分けたらいいと思うね。

喩え話だと思えばいいよ。

例えば車を製造しているのと似ている。
製造する機械を二倍にすれば、二倍多く生産できるし、
どれから製造しても、全く同じ物が出来る。
考える作業はほとんどなく、全く同じ物を何個も作る。

これが何の喩え話かを考えてみれば
自ずと、プログラミングじゃないなってわかるはず。

問題はそこなんだよ
作ってる最中に「あーでもないこーでもない」とその場で対処する
ここが、高い品質を出せない最大最悪の原因になってる

この「品質のブレ」を出来る限り早い段階で潰したい
そのために求められるのは作ってる時に考えるのではなく
設計図を書いてる段階で実作業もできるだけ規定すること

今は無理でも、そこに向かって一歩ずつ前進することが大事
「コードが設計」なんて欺瞞で思考停止していてはいけない

ソースコードはウイルス
ttp://i.imgur.com/vCCQrOL.jpg

>>425
ワロタ

>>423
> 作ってる最中に「あーでもないこーでもない」とその場で対処する
> ここが、高い品質を出せない最大最悪の原因になってる

それのどこがいけないの？
その場で対処できてないのが問題でしょ？
その場で対処できるようになればいいんだよ。

その場で「対処できたつもり」になってるのが現状だよ・・・

道はね。間違っているとわかった時に
正しい道に修正すればいいんだよ。

最初っから100％正しい道を進むなんて無理。
その方法は、後からの仕様変更はできませんと言ってるようなもの。

正しい道がわからない、正しい道は変わる。という前提があるのだから
最初から作りこむなんて不可能なんだよ。

だから道が変わった時、どれだけ素早く正しい道に修正するかの
技術を磨いたほうがいい。

クラウドの考え方ともにてるよ。

ハードウェアが壊れないという前提で作ると
ハードウェアが壊れた時に対処できない。
だからハードウェアを壊れないように二重化していくが
そうするとコストが跳ね上がっていく。

ではなくハードウェアは壊れるという前提のもと
壊れても自動でリカバリできるように作っておく。

どっちみち仕様は後から変わったり追加される。
「その場で対処しないといけない」というのは絶対になくならない。
だからその場で対処できるように設計していくんだよ。

>>430
それはそれ、これはこれだ

アドホックな対応をせざるをえない可能性はゼロにならないかもしれない
が、しなくていいように全力を尽くすんだよ
その２つの道は矛盾しない

>>421に書いた通り、実質的にコードは設計書の一つでもあると思うんだが、
設計書書くときにあーでもないこーでもないと考えないならいつ考えるんだ。

まあ、プログラム書いた事無いアホが考えそうな妄想だよね

>>433
そうなんだよね
仕事で集団でコードを書く機会があれば、「現場での対応」がいかに困るものか
わかってもらえるんだけど

現場で対応せざるをえない設計書に泣いたことは幾度もあるなあ

>>435
どう「対応」したのか、設計書にきちんと反映しておけよ
次に類似案件取ったときにまた泣きたくないだろ

「現場での対応」ってなんじゃい
製品の設置場所でコード書いてんのか？
それともプログラマの知らない会議室で設計やら問題解決してくれる人がいるのか？

はっきり言うが設計しないでよいプログラマなどいない。
コードも「一つの」設計書だ。
そして一番誤解してほしくないところ、設計書は一つだけではない。

うーん。同意する人が少ないんだから、
いい加減、空気読めよ。

馬鹿言うな、過疎るよりは荒れてた方がマシだろ

もっと荒れてほしいのでage

>>437
プログラム書いた事無い奴には
日本語ドキュメントとソースコードの間のギャップの大きさなんて
分かるワケ無いって。ギャップを埋めたこと無いんだから。

もしギャップが無いというなら、日本語ドキュメントを直接コンパイルできるはずだしな。

ギャップを埋めるのはマの責任だな

>>425
もうなんかバカは記事書くなよって感じだな

バグだらけのソースはウイルスよりたちが悪いよ。

人間を破壊してしまうからな

スパゲティコードの山を見慣れてるから「コードとは設計」と言われても信じられない

設計した結果がスパゲッティだったというだけのこと

>>483
むしろ君に同意する人が少ないのでは？
このスレでは意図はそれぞれ違えど、コードは設計と考える人の方が若干多い。

>>441
もちろん埋められないギャップがある。
それが「設計書は一つだけではない」という理由だ。
コードが欲しいか別の設計書が欲しいかは立場によって違うし、大抵は両方必要だ。
だからコードとは別に仕様書を書く。
コードと仕様書を同じ人が書くなら、その作業は並行しても構わないだろう。

まあ君が他人の設計を教えてもらってコードだけを書く係りの人なら、
君の困っている理由は痛々しいほどよくわかる。

SIからの受託でもweb系の内製でも、コード書くときに最初にやることは決まってて
インターフェースを定義して、仕様書のメンタルモデルをコード表現に落としこむ
この部分は設計に近いところがありつつも実装寄りのコードになるし、非エンジニア向けには別の説明が必要になるのも否定できない

web系は抽象化能力が高い言語を使うケースが多いので、設計がコーディングと分離されてない
ネットワークIO(~200ms)の前にDB以外の最適化が意味をなさないので、ほとんどのケースで速度より綺麗な設計を採用する

設計とコーディングが分離されてないとはいっても、大枠決めるのはプロトタイピングした、
殆どの場合チームで一番プログラマとして優秀な人だが、明確に設計フェーズだと定義されてはいない

それとは別に、ひたすら検証コード書いて、泥臭い実装を続ける部分で、単純にコーディング力の不足が設計を破綻させるケースがある
ぶっちゃけ設計になりきれてないコードは、プロトタイピング不足と、コーディングの地力の問題に起因してるといってもいい

防衛省、『サイバー空間防衛隊』新設へ検討委員会を設置
http://anago.2ch.net/test/read.cgi/bizplus/1360979117/

こいつさあ、Twitterで堂々とroot奪取の話してるけど
社会的責任を取れるのかと

プロトタイプ作成を設計とかわらえ？

うんこJava言語のコードと比べれば、
Rubyのコードは設計と言えるレベルの抽象度を持ってるな

ハァ？動的型付けじゃむしろ設計が見えなくなる

長文を書くときに、事前に構成を紙に書きだしたりするでしょ？
そして並んでいる項目の粒度がそろっているか、
カテゴリーミスマッチがないか、確認したりする。

みんなも大きなコードを書く前にも同じようなことするでしょ？
それがコーディングにおける設計じゃないの？

>>455
それも設計、コードも設計
いい加減理解しろよｗ

文章における製造とは
印刷工程だな。

>>454
それはね、君がゴミ言語に慣らされたゴミだからだよ

元コンシューマ系ゲームプログラマと一緒に仕事してるけど
破綻することに慣れてしまったC++書いてた人は設計的な視点でやばいってのはある
C++が悪い言語という訳じゃなくて、ゲーム業界由来のやばさを感じる　うまく言葉にできないけど

ウェブ業界も似たようなもんだよ。
コンパイルせずに動くからと
特定のファイルにパッチ当てる感覚で場当たりの修正していく。
設計感がないからどんどんカオスになっていく。

まあ、下見ればどっちもクソはたくさんいるし
ウェブもSIもお互いの下をみて罵倒してる感じはある

>>453
オブジェクト志向しか勉強してないだろ。
なんて視野が狭い奴だ。

でもHaskellとかClojureの関数型連中は名前空間ぶつけまくるよね　やつらは設計って観点はあんまりない
属人性が薄い最近の巨大プロダクトで、OO以外のアーキテクチャってあんま見ない
新しい言語の傾向として、継承を使わずにDCIやインターフェースがモダンって風潮にはなってる(GoのstructやHaskellの型クラス)
ただ、それが主流に使われるにはプログラミング言語の流行が一周した頃になるだし、C++/Java/.NETが主流なうちはパラダイムは変わらん

OO言語ってオブジェクト指向という側面の他に
多人数で開発しやすいように
小さくモジュールを分割できるって
側面もあるんだよ。

モジュールを分割するなら
適当なモジュール機構があればよくって
クラスベースOOPは不要

やっぱ、オブジェクト志向だけやって設計してる奴は視野が狭い。

指向と変換できない奴に言われてもなぁ

「動くだけ」じゃなくて、大丈夫か？まで考えろと。
設計が先に出来てるとは思うなと。

20年ずっと一つのRubyというシステムをこねくり回している人だから言える言葉なんじゃないか？
奴隷になってあっちこっちでこき使われているPGには無理な話。

>>460
俺はゲーム・Web・組み込みを経験してる変り種だが、459の言ってることは分かるよ
ゲームPGは閉鎖的な業界で自己流なやり方で極めてしまって矯正もできないようになってしまっている
仕様、実装、テストというプロセスを分ける概念がないんだよね。すべてごっちゃになってしまっている
もっと簡単に言えばやり方が属人的すぎるということだけど
webはそうまでひどくは無い、ひどいとしてもその状況を是とはしていない。ゲームPGはそれを当たり前、是としてしまっている

> 仕様、実装、テストというプロセスを分ける概念がないんだよね

ウェブで流行りのアジャイルもそうだよ？

そういう風にプロセスを分けるのはウォーターフォールっていうんだ。

ゲームは絵や音のリソースを早い段階で大量に揃える必要があるので
ウォーターフォールにならざるを得ないんだよ

ゲームは絵や音のリソースを揃えてから
プログラミングしていると思ってるのか？

>>473
全部は揃わないよな
大抵1モデルだけ揃えてもらって あとはごまかしごまかし

>>1
10年早いぜ

東芝、日立が進めたソフトウェア工場って概念は今や見る影もないな
工場内でノウハウを蓄積できた90年代まではそれで良かったが、Linuxやandroidといったオープンソースの上に各社のソフトを乗せる現代の開発工程には合わなくなった

>>1
命令・コマンドの羅列に夢想している松本かw

>>477
文字と記号の羅列と何が違うの？

>> 476
A Japan that can Fail 1992 by David Thielen
http://dave.thielen.com/articles/J-FAIL.DOC

>>341
基本設計とかいう言葉を使う奴はもれなく馬鹿

>>386
原文は残ってるよ。
http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm
もともとは1992年のC++ジャーナルの紙面に掲載されたエッセイだな。

>>480
オマエよりは賢いぞw

新概念ルビンゲリオン

>>483 糞スレあげんじゃねぇよ。

Lisperらしい意見だと思う

設計書
http://livedoor.4.blogimg.jp/himasoku123/imgs/4/c/4cc6ab00.jpg

http://engawa.2ch.net/test/read.cgi/poverty/1383923697/399

コード作成は設計作業の一部だよ。
品質管理、バージョン管理をしてない所ではそうでも無いらしいが。

エクセル方眼紙でドット絵の穴埋めを設計と呼んで、肝心のプログラミング実装は
誰でもできる製造ライン工の流れ作業…そう思い込んでるPMの多いこと。
先日も脳味噌お花畑なblog書いて炎上してたな。

で？

最近はコードが設計と言う人もだいぶ減ってきたね
一時期はどうなることかと思ったけど

設計でもいいし、書捨てでもいいじゃない
どうして一つにしたいの

>>1
オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
http://toro.2ch.net/test/read.cgi/tech/1393660194/73