1：仕様書無しさん2015/11/27(金) 20:07:51.16 .net
っていうけどさ、そんなレベルの人が設計を書いても設計が
正しいかどうかなんて判定できないと思うんだが？
だって実装した時に書き直しが必要ない完璧な設計を作らないと
いけないわけでしょ？それって実際に実装できる力がないと無理でしょ？
初心者が設計したとしても、ダメな設計しかできず、
どっちみ書き直しが必要になると思うんだ。
正しいかどうかなんて判定できないと思うんだが？
だって実装した時に書き直しが必要ない完璧な設計を作らないと
いけないわけでしょ？それって実際に実装できる力がないと無理でしょ？
初心者が設計したとしても、ダメな設計しかできず、
どっちみ書き直しが必要になると思うんだ。
2：仕様書無しさん2015/11/27(金) 20:11:39.89 .net
それにさ、設計って言うけど、やってることって設計じゃなくて計画でしょ？
○○と○○と○○を作りますって。
以前作ったものと同じようなものは、
設計は要らず計画だけ立てればいい。
以前作ったことがないものは、頭の中で設計しても完璧なものとならず、
仮実装を経て検証して、やっとその設計が正しいことが実証される。
何か間違ってるかな？
○○と○○と○○を作りますって。
以前作ったものと同じようなものは、
設計は要らず計画だけ立てればいい。
以前作ったことがないものは、頭の中で設計しても完璧なものとならず、
仮実装を経て検証して、やっとその設計が正しいことが実証される。
何か間違ってるかな？
3：仕様書無しさん2015/11/27(金) 20:42:59.17 .net
頭のメモリからはみ出るような仕組みを考えるときは
紙と鉛筆使うだろ。
紙と鉛筆使うだろ。
4：仕様書無しさん2015/11/27(金) 20:46:08.52 .net
>>3
最初の一回だけね。
最初の一回だけね。
5：仕様書無しさん2015/11/27(金) 20:50:26.39 .net
で、頭のメモリからはみ出るような仕組みは考えただけじゃダメで、
実際に実装してみないと正しいかはわからない。
実際に実装してみないと正しいかはわからない。
6：仕様書無しさん2015/11/27(金) 23:25:27.38 .net
>>1
うるせー要求仕様書貰ってこいバカ
うるせー要求仕様書貰ってこいバカ
7：仕様書無しさん2015/11/27(金) 23:53:44.91 .net
>>1
設計レビューって知らないの？
設計レビューって知らないの？
8：仕様書無しさん2015/11/28(土) 01:04:17.13 .net
設計のレビューしたって、曖昧な日本語の文章だろう？
コードと違って正確なレビューができるわけないじゃないか。
コードと違って正確なレビューができるわけないじゃないか。
11：仕様書無しさん2015/11/28(土) 02:13:37.87 .net
>>8
間違った方向に走り出す馬鹿は止めることができる。
間違った方向に走り出す馬鹿は止めることができる。
9：仕様書無しさん2015/11/28(土) 01:05:26.21 .net
その設計のレビューに、作成する関数の名前一覧とか
その関数の中身の実装方法まで書いてあるって
いうのなら別ですけどねぇ。
その関数の中身の実装方法まで書いてあるって
いうのなら別ですけどねぇ。
10：仕様書無しさん2015/11/28(土) 01:11:20.75 .net
設計レビューで、使用するフレームワークやデータベース、
サーバーの構成とかならできると思うんだけどね。
アプリの画面構成は、どちらかと言ったら要求仕様だろう。
やれるにしてもデータベース設計までかな。
コーディングに関する部分は、設計したとしても
書きなおさなくてすむレベルまでの設計はしないでしょ？
サーバーの構成とかならできると思うんだけどね。
アプリの画面構成は、どちらかと言ったら要求仕様だろう。
やれるにしてもデータベース設計までかな。
コーディングに関する部分は、設計したとしても
書きなおさなくてすむレベルまでの設計はしないでしょ？
12：仕様書無しさん2015/11/28(土) 02:19:26.81 .net
でもそれは、コードが書きなおさなくていいものになるわけじゃないよね？
13：仕様書無しさん2015/11/28(土) 05:14:39.69 .net
そもそも、コードを書き直さなくていいものにすることが目的じゃ無いから。
何甘えたこと言ってるんだって話だな。
完璧なものがでい無いんならやる意味無いじゃんってw
ガキか
何甘えたこと言ってるんだって話だな。
完璧なものがでい無いんならやる意味無いじゃんってw
ガキか
14：仕様書無しさん2015/11/28(土) 09:11:11.19 .net
大規模なプログラムなら
「こういうクラス作って依存関係はこう」
みたいな設計はするわ。
1か月前の自分のソースが読めないたちでね。
「こういうクラス作って依存関係はこう」
みたいな設計はするわ。
1か月前の自分のソースが読めないたちでね。
15：仕様書無しさん2015/11/28(土) 09:34:52.59 .net
とりあえずコード書いて、後で詳細設計した方が良い
16：仕様書無しさん2015/11/28(土) 11:00:27.94 .net
コンソールに "Hello, World!" を表示するプログラムを設計せよ。
いきなりコードを書くのは禁止とする。
いきなりコードを書くのは禁止とする。
17：仕様書無しさん2015/11/28(土) 13:17:38.34 .net
1. とりあえず仕様をキメて、
2. 素早くコードを書いて動作させて、
3. 仕様を練りなおして、
4. 今度はちゃんとコード書いて、
って流れが俺は好き
2. 素早くコードを書いて動作させて、
3. 仕様を練りなおして、
4. 今度はちゃんとコード書いて、
って流れが俺は好き
18：仕様書無しさん2015/11/28(土) 13:55:37.58 .net
よほど大規模じゃないかぎり脳内設計でコード書いてそっからレビュー用の資料を作るな
19：仕様書無しさん2015/11/28(土) 13:58:41.92 .net
＞仕様を練りなおして、
コードをざーと書いて、その後リファクタリングするわけだが
Model View Controller モデルに持っていく時間が取れるかだな
Viewクラスに持っていく関数になるのは
Disp＊＊＊というように命名しているが
もとのやつをクラス分けしても出来栄えは？ となる
なんか、判断基準がない。
大きいクラスを小さくしたぐらいなもんさ
コードをざーと書いて、その後リファクタリングするわけだが
Model View Controller モデルに持っていく時間が取れるかだな
Viewクラスに持っていく関数になるのは
Disp＊＊＊というように命名しているが
もとのやつをクラス分けしても出来栄えは？ となる
なんか、判断基準がない。
大きいクラスを小さくしたぐらいなもんさ
21：仕様書無しさん2015/11/28(土) 14:21:16.19 .net
>>19
Disp ｗ
Viewなのにdispって馬鹿みたい
Disp ｗ
Viewなのにdispって馬鹿みたい
20：仕様書無しさん2015/11/28(土) 14:05:58.11 .net
試作につかったコードは捨てるがコツ
22：仕様書無しさん2015/11/28(土) 14:31:56.96 .net
上級者 ・・・ 頭の中でコードを書けるから、書かなくても設計できる。
初心者 ・・・ 頭の中でコードが書けないから、実際に書かないと設計できない。
初心者に、いきなりコードを書くなって言うのは酷ではないのか？
初心者 ・・・ 頭の中でコードが書けないから、実際に書かないと設計できない。
初心者に、いきなりコードを書くなって言うのは酷ではないのか？
23：仕様書無しさん2015/11/28(土) 21:09:59.97 .net
おまえらいい加減コーダー卒業したら？
24：仕様書無しさん2015/11/28(土) 21:25:11.89 .net
別にコード書いてるだけで、コーダーじゃないよ。
25：仕様書無しさん2015/11/28(土) 21:40:11.66 .net
でも設計できないだろ？だったらコーダーだよ。
26：仕様書無しさん2015/11/28(土) 22:02:54.49 .net
いや、設計できるが？っていうかそれくらいできないで
自分一人でオープンソースアプリ作れないって。
自分一人でオープンソースアプリ作れないって。
27：仕様書無しさん2015/11/28(土) 22:37:32.51 .net
アプリ作るのに設計は必要条件じゃないって。
29：仕様書無しさん2015/11/28(土) 23:07:25.42 .net
「コードを読み込んで、仕様書を勝手に。そして的確に作成してくれる優秀な
ソフト」が欲しいよな。もしそれが、デバッグソフト並の解析力があれば
最高なのだが。
ソフト」が欲しいよな。もしそれが、デバッグソフト並の解析力があれば
最高なのだが。
33：仕様書無しさん2015/11/29(日) 00:49:45.16 .net
コードなんて日々変化していくから
詳細設計書なんてきっちり作りこむ必要ないと思うな
機能設計書レベルで後は設計メモ程度が楽
詳細設計書なんてきっちり作りこむ必要ないと思うな
機能設計書レベルで後は設計メモ程度が楽
34：仕様書無しさん2015/11/29(日) 02:07:52.31 .net
OSSのソフトって設計書ってあんの？
あんまみたことないんだが
それなのに完成度が高いんだから、設計書なんていらんのやろ
あんまみたことないんだが
それなのに完成度が高いんだから、設計書なんていらんのやろ
38：仕様書無しさん2015/11/29(日) 11:59:39.74 .net
>>34
んなこたない
「設計書」としては存在しなくても、
フォーラムで議論したり、コミットコメントをきちんと書いたり。
誰でも見れる場所に適切な資料は残してある。
んなこたない
「設計書」としては存在しなくても、
フォーラムで議論したり、コミットコメントをきちんと書いたり。
誰でも見れる場所に適切な資料は残してある。
41：仕様書無しさん2015/11/29(日) 16:26:13.55 .net
>>38
その適切な資料で十分ってことでしょ？
その資料っていうのは、全体のごく一部の
重要な部分、複雑な部分に対してのみしか存在しない。
言わなくてもわかるような部分まで含めたソフトウェアの
全部の資料を予め自然言語で書くなんて無駄が多すぎる。
で、その資料（設計書？）通りに作ります。これ以上のものは作りません。
って確約になってるから、後から問題が出た時直すことも出来ないし
生産性を上げるサポートライブラリ的な顧客に直接関係ない機能が省かれる。
その適切な資料で十分ってことでしょ？
その資料っていうのは、全体のごく一部の
重要な部分、複雑な部分に対してのみしか存在しない。
言わなくてもわかるような部分まで含めたソフトウェアの
全部の資料を予め自然言語で書くなんて無駄が多すぎる。
で、その資料（設計書？）通りに作ります。これ以上のものは作りません。
って確約になってるから、後から問題が出た時直すことも出来ないし
生産性を上げるサポートライブラリ的な顧客に直接関係ない機能が省かれる。
35：仕様書無しさん2015/11/29(日) 02:41:35.19 .net
UIに関して言えば、ありきたりなUIは
決まりきったものになるだけ。
ありきたりでないUIは作って触ってみないとわからない。
決まりきったものになるだけ。
ありきたりでないUIは作って触ってみないとわからない。
36：仕様書無しさん2015/11/29(日) 02:49:29.89 .net
データベースの設計といいながら、
SQLのcreate table文と同じ内容をエクセルに書くだけ。
カラム名、型、制約、インデックス
こういうのは最初からSQLで書いたほうがいい。
ER図ぐらいなら書いてもいいけど、
そこに書くのは関連があるカラムだけでいい。
例えばアドレス帳テーブルがあったとして、
電話番号とかFAX番号とか、ER図に書く必要ないだろう。
分かりきっている上にそれが設計を左右することはない。
SQLのcreate table文と同じ内容をエクセルに書くだけ。
カラム名、型、制約、インデックス
こういうのは最初からSQLで書いたほうがいい。
ER図ぐらいなら書いてもいいけど、
そこに書くのは関連があるカラムだけでいい。
例えばアドレス帳テーブルがあったとして、
電話番号とかFAX番号とか、ER図に書く必要ないだろう。
分かりきっている上にそれが設計を左右することはない。
37：仕様書無しさん2015/11/29(日) 07:37:14.88 .net
概略のクラス図とシーケンス図は書くべき
詳細になると逆に一気に形骸化するからどうでもいいけど
詳細になると逆に一気に形骸化するからどうでもいいけど
39：仕様書無しさん2015/11/29(日) 12:05:12.48 .net
そもそも、設計書のアカンところは、
それに至った経緯が分からん部分だな。
最新の状態を知りたいだけなら、ソースが一番正しいのだし、
クラス図くらいならソースから自動生成すりゃいい。
それに至った経緯が分からん部分だな。
最新の状態を知りたいだけなら、ソースが一番正しいのだし、
クラス図くらいならソースから自動生成すりゃいい。
42：仕様書無しさん2015/11/29(日) 16:28:48.96 .net
>>39
> そもそも、設計書のアカンところは、
> それに至った経緯が分からん部分だな。
それはあるね。「こうこう作ります」っていう結論になっていて
なぜその設計にしたのか？という重要な情報が省かれてる。
設計書見ても、なぜこうしたのかがわからない。
そして設計書見て作る人は、なんでこんなクソな設計なんだ？って
思いながら開発することになるわけさｗ
正当な理由がある場合でも、それがわからないし、
間違った理由であった場合でも、こっちのほうが良いという提案もできない。
> そもそも、設計書のアカンところは、
> それに至った経緯が分からん部分だな。
それはあるね。「こうこう作ります」っていう結論になっていて
なぜその設計にしたのか？という重要な情報が省かれてる。
設計書見ても、なぜこうしたのかがわからない。
そして設計書見て作る人は、なんでこんなクソな設計なんだ？って
思いながら開発することになるわけさｗ
正当な理由がある場合でも、それがわからないし、
間違った理由であった場合でも、こっちのほうが良いという提案もできない。
via http://nozomi.2ch.sc/test/read.cgi/prog/1448622471/