1仕様書無しさん2016/09/26(月) 22:56:23.89
これって普通なん？
2仕様書無しさん2016/09/26(月) 23:08:52.90
それは設計書じゃなくて、
ソースを変換しただけじゃないの？
簡潔でわかりやすい詳細設計書というのは、
ソースを作るよりずっと時間がかかるんだよ。
3仕様書無しさん2016/09/26(月) 23:09:49.20
おれの経験では、
詳細設計書に３日かけたところは、
ソースを打ち込むのは１時間とか、
そんな感じ。
4仕様書無しさん2016/09/27(火) 00:58:24.41
詳細設計という紙が大事なんじゃなくて
そこに詰め込まれているアイデアや予想、下調べの積み重ねが大事なんだよ
いきなりコーディングをはじめるやつは、ソースをいじりながら設計してるだけ
紙とエクセルとコードのどれで設計するかは個性の問題だろう
結局はアウトプットで勝負するしかないのだから
5仕様書無しさん2016/09/27(火) 01:11:11.68
設計が悪ければ、いくらコードを書いてもやり直しだ。
6仕様書無しさん2016/09/27(火) 02:59:17.95
設計書書くよりコード書いてる方が実際の動きが読めるんだけど
設計書じゃ矛盾ないように書かれてるけど、実際コード書くと矛盾が見えてきたり
コード書く前に完璧な設計書ってできてるの見たことないわ
7仕様書無しさん2016/09/27(火) 03:12:17.41
設計が悪いとは、そもそもの実装の方向性から間違ってるという意味で、
コードで矛盾を修正したところで設計は良くならない。
適切な設計ならコード量が1/10になったりする。
8仕様書無しさん2016/09/27(火) 06:57:03.99
詳細設計書とかいらねえから適切な要件定義書を残しておいてください(小声)
9仕様書無しさん2016/09/27(火) 08:22:42.08
要件曖昧ズブズブなお仕事
楽しいです(^q^)
10仕様書無しさん2016/09/28(水) 00:03:56.17
>>6
考えてから書けって言ってるだけだよ
紙やエクセルシートが大事だとは言ってない
コードを書きながら考えるという手法も間違ってないよ
もちろん、削除して書き直しだけどね（失敗した設計図の紙を丸めて捨てるように）
ある程度の経験を積めば、コードを書かないとわからないってことは
ほとんどなくなるんだろうね
毎回同じようなものを書いてると特にね 11仕様書無しさん2016/09/28(水) 21:27:17.82
12仕様書無しさん2016/09/28(水) 23:41:28.66
考えてからコーディングしないと飽きるよ
13仕様書無しさん2016/10/01(土) 23:01:25.39
で、詳細設計書には結局なに書けばいいの？
14仕様書無しさん2016/10/01(土) 23:03:14.59
疑似コードとコメント書いてますよw
15仕様書無しさん2016/10/02(日) 19:27:50.93
16仕様書無しさん2016/10/02(日) 19:31:22.28
>>13
コードを見なくても作りがわかるドキュメント 17仕様書無しさん2016/10/02(日) 21:49:15.46
結局コード読めない人でもレビューできるようにするための文書でしょ。
実装の上では全く不要な代物。
18仕様書無しさん2016/10/02(日) 21:54:09.27
>>13
そこには処理を箇条書きにして、何を入力にして何を出力するのか書くんじゃね？ 19仕様書無しさん2016/10/02(日) 22:22:23.48
それは構成仕様
20仕様書無しさん2016/10/02(日) 22:35:13.82
改修作業請け負ったものの設計書が影も形も存在せず
とりあえずの体裁としてVB和翻訳設計書を書かされる羽目になった思い出
コード自体当時の担当者を（自主規制）したくなるほどのクオリティだったが
それはまた別の話
21仕様書無しさん2016/10/03(月) 06:00:33.83
>>17
実装なら設計書ありきの話だろ。
プロは設計に時間をかけて、コーディングは超短時間で終わる。 22仕様書無しさん2016/10/03(月) 08:14:36.61
設計を頭の中でするっていう人はいるかもしれないけど
設計せずに実装する人はいないよね？
コーディングしながら書き換えていくっていうのは
経験のない初心者なら仕方ないけど・・・
23仕様書無しさん2016/10/03(月) 10:15:14.88
どんなに、きちんとした日本語だとしても解釈問題って永久に消えない。
だから、ユーザー現場で開発するアジャイルが一番なんだよ。
24仕様書無しさん2016/10/03(月) 20:09:06.04
>>23
アジャイルというよりスパイラルだけどな。
アジャイルは技術的検証が必要な小さなものになら向いているが、そうでなければうまくいかない。
もともと欧米人は文章だけの資料を作りたがるから、認識がなかなか合わない。
だからアジャイルなんてものが出てくるw 25仕様書無しさん2016/10/03(月) 21:14:02.87
改修だったら事前に絶対ソース見る訳だから
コーディングせずに設計するって
直し方分かってるのにその場は我慢してまず紙に書いておいて
改めてもう一度ソースに戻るってだけだよな
特にオリジナルのソースが汚い場合にはこの方法はキツイ
26仕様書無しさん2016/10/04(火) 00:08:34.26
改修の一番最初の段階（現場レベル）ってのは
既存バグの修正やリファクタリングだろ？
27仕様書無しさん2016/10/04(火) 01:53:26.74
>>26
リファクタリングはありえない。
いきなり仕様が勝手に変わる、障害がおきる可能性もあるし。
リファクタリングは何か改修のついでにやる程度。
もう本番が動いているものに対してはリスクが大きすぎる。 28仕様書無しさん2016/10/04(火) 06:49:43.47
>>26
リファクタリングはありえる
リファクタ無き強引な改修はさらなるバグを誘発、将来の改修が更に困難になることも 29仕様書無しさん2016/10/04(火) 08:31:14.51
動いてるもん弄るな。
30仕様書無しさん2016/10/04(火) 22:43:38.16
これから弄るんだからリファクタリングしたっていいんだよ
どうせ最終的にはテストするんだからな
31仕様書無しさん2016/10/05(水) 01:52:02.65
>>28
それはリファクタリングではなく作り替え。 32仕様書無しさん2016/10/05(水) 05:03:20.48
リファクタリングができない是即ち動いてるのが奇跡だからで候
33仕様書無しさん2016/10/05(水) 05:52:26.15
>>6
＞ コード書く前に完璧な設計書ってできてるの見たことないわ
それはお前が若いからだ。
おそらく30代ぐらいまでで、簡易言語やWeb系やってる人のなかには
見たことないってのも沢山いると思う。
それは時代の流れで
しかたのないことかもしれない。
みんながドキュメント書けない（書かない）馬鹿プログラマに
なってゆくんだよ。 34仕様書無しさん2016/10/05(水) 06:57:33.71
>>31
リファクタリング＝作り替えｗ
脳みそ動いてますか？ 35仕様書無しさん2016/10/05(水) 06:59:49.68
>>33
＞みんながドキュメント書けない（書かない）馬鹿プログラマに
なってゆくんだよ。
ここまでくると宗教のような洗脳ですね
ドキュメント教ｗ 36仕様書無しさん2016/10/05(水) 08:35:04.22
必要に応じて必要な粒度で作りゃいいだけのことじゃないかね
俺の職場では納品物として形だけ作る文化だぜ、アプリ作った後にな
37仕様書無しさん2016/10/05(水) 19:18:07.82
いまはもうないがプログラム設計書のことを詳細設計書というやつがいるけど、それがソースコードを言葉で書いたようなものなんだよな。
38仕様書無しさん2016/10/05(水) 19:25:09.17
ソースコードをただ日本語訳したようなものは設計書ではない。
そんな設計書があるなら、それは設計自体がおかしい。
39仕様書無しさん2016/10/05(水) 20:25:04.94
>>21
設計に時間かけるのは分かるけど、ソースの日本語訳レベルの設計書が必要って言ってるならあなたはかなりハイレベルだと思う。 40仕様書無しさん2016/10/05(水) 20:47:07.99
41仕様書無しさん2016/10/05(水) 21:11:10.68
NASAなんかでは、プログラマは余計なことを考えず仕様書をただひたすらプログラムコードに変換するだけの存在らしい
仕様書の品質についてどうやって保ってるのかは知らないが
42仕様書無しさん2016/10/05(水) 21:26:15.96
>>39
そんなコードそのままみたいな設計書はいらないけど、プログラマでも低レベルのコーダーにやらせるとなると、サンプルプログラムがないとひどいものにはなる。
だからいまは詳細設計とコーディングは同じひとがやるのが普通だけど、汎用機の世界のひとや年配は、いまだにプログラム設計書レベルの設計書を作るよな。 43仕様書無しさん2016/10/05(水) 21:27:58.17
>>41
それは一部の人間だろw
どうせインド人だろうな。 44仕様書無しさん2016/10/05(水) 21:30:24.52
それと仕様書と設計書の違いが分からない人間がいるのは万国共通らしい。
45仕様書無しさん2016/10/05(水) 22:41:28.78
紙→鉄に変わる機械の製造のと違って
記号→記号だからな
変数とか関数とかエディタ介した方が見やすいし
46仕様書無しさん2016/10/05(水) 23:08:37.12
モジュールなりクラスの入出力を「厳格に」決めればいいだけだろ。
使用したアルゴリズムをコメント2,3行で書いとけばいい。
47仕様書無しさん2016/10/05(水) 23:10:32.15
>>41
なんだNASAの真似をすれば良いわけか。
簡単そうだな。 48仕様書無しさん2016/10/05(水) 23:11:49.93
いきなりエクセル使って設計すんな。
なんどもエクセル書き直して
恥ずかしいと思わんのか？
49仕様書無しさん2016/10/06(木) 00:54:47.95
>>44
テスト仕様書とテスト設計署の違いを説明できる人をまだ見たことがない 50仕様書無しさん2016/10/06(木) 06:36:58.98
51仕様書無しさん2016/10/07(金) 02:01:14.74
52仕様書無しさん2016/10/07(金) 10:24:41.69
誤字のせいで台無しだなw
53仕様書無しさん2016/10/07(金) 19:57:35.81
54仕様書無しさん2016/10/07(金) 22:01:28.44
しょーもない
55仕様書無しさん2016/10/07(金) 23:30:25.83
>>54
おまえのところは署もないのか？
ああ、刑務所に入っているから分からないのか。 56仕様書無しさん2016/10/07(金) 23:36:17.48
57仕様書無しさん2016/10/07(金) 23:40:56.65
58仕様書無しさん2016/10/07(金) 23:43:24.61
私は1日署長をやったことあります！
59仕様書無しさん2016/10/07(金) 23:46:22.19
詳細設計書つくるんならソースでもきれいにして桶
60仕様書無しさん2016/10/08(土) 00:40:35.30
>>42
いや、サンプルプログラムはあった方がそりゃいいよ。それはまさに設計じゃん。
ここで言ってるのは個別の業務ロジックそれぞれに対する日本語訳レベルの設計書が必要なのかって話でしょ。 61仕様書無しさん2016/10/08(土) 02:22:30.08
詳細設計があれば修正しやすいでしょ
だっておまえら実装すぐ間違えるから、仕様の推理にノイズが入るし
62仕様書無しさん2016/10/08(土) 14:41:09.62
詳細設計にノイズが入っているのが100%だからな
63仕様書無しさん2016/10/15(土) 23:52:42.24
どいつもこいつもだめだな
詳細設計ってものは言語は何であれ同じ業務ロジックが記述できるように作るものなんだよ
お前ら何十年後とかにシステムのリプレースとかやったことないんだろ
そのときに基本設計、詳細設計のありがたみが分かるよ
入社5年目の俺が言う
しっかりした思想とロジックが入っていればあとはどうとでもなる
糞コードができるのは、プログラマの力量不足でもあり、設計思想が貧弱だった所為でもある
効率の悪いコードとコメントアウト(コメントではない)の嵐
同じコードを2度書くなと何度言えばわかるのか
適切なデータ構造もアルゴリズムも選べないやつは必要ない
ああ、すっきり
怖かった～
64仕様書無しさん2016/10/16(日) 04:17:06.11
> お前ら何十年後とかにシステムのリプレースとかやったことないんだろ
> そのときに基本設計、詳細設計のありがたみが分かるよ
せやな。だから
http://cloud.watch.impress.co.jp/docs/news/597350.html
> 長期にわたって運用されるシステムの保守開発現場では、保守運用のために
> ソースコードの修正・変更が発生するが、そうした変更は設計書に反映されるのが前提になっている。
> しかし、度重なるシステム改修や技術者不足などの理由により、修正・変更内容の
> 反映漏れによるソースコードと設計書の隔たりといった不備や、ソースコード内容が
> 記載されていないなど、設計書自体の不足がしばしば発生する。
こんなことにならないように、基本設計、詳細設計を修正があるたびに
バグや矛盾や曖昧なところがないようにに書き換えような。
そしてちゃんとテストもしような。基本設計、詳細設計の段階で。
ソースコードではできてることを、基本設計、詳細設計になると
怠けるやつは誰だろうな。 65仕様書無しさん2016/10/18(火) 07:59:09.85
初期段階の設計書があるだけでも
保守は楽
66仕様書無しさん2016/10/20(木) 22:27:01.18
仕様書と設計書は普通
詳細設計書はあほ
67仕様書無しさん2016/11/06(日) 16:42:56.87
詳細設計書とソースコードが漏れなく一致していればいいけど
過去の担当者がそれをおざなりにしてるせいでえらい苦労したわ
なんで過去の担当者の責任をこっちが被らないといけないんだよ・・・
68仕様書無しさん2016/11/06(日) 16:54:31.75
まぁそういうドブ仕事させるためにお前に金払ってるわけだから
69KAC2016/12/03(土) 13:00:42.19
詳細設計書がなぜあるのか考えたほうがいい
詳細設計書は三十年前にもあった概念だろ？
三十年前といえば、コンピュータなんてほとんどない時代。
設計は全て机上(紙)で行われていた。PCなんて使わない。
限られたマシン時間の中で如何に早く入力するかというのが
コーディングに求められる唯一の事。
コーディング指示書レベルの詳細設計書がなければ、
入力時間がもったいない。(マシンの時間は人件費よりも高かった)
詳細設計書というのは、そういう時代の名残。
いまでは作業者全員がPC持ってるだろうし、PCがターゲットだったり、
ターゲットとの接続はネットワーク化されて共有化されていたり・・・
とにかく、入力と設計を同時に行っても他人に迷惑のかからない
環境になった今では、詳細設計書にそこまで時間を書ける必要はない。
詳細設計のアウトプットはソースコードで十分だろう。
70仕様書無しさん2016/12/03(土) 13:21:29.95
そういう雑な設計で作ると設計やコードが重複するし保守方法も機能ごとにバラバラになるしアスペクトの追加やアーキテクチャの変更も難しくなる
機械には迷惑かけないかもしれないけど人間にとっては完全に迷惑行為だよ
71仕様書無しさん2016/12/03(土) 13:46:07.12
>>70
どんなに完璧な詳細設計書を作っても、いきなり、数人で
コーディング開始すると、コードは滅茶苦茶になったりするんですけど
優秀精鋭(1,2人程度)でコーディングを開始し、
共通のコードや、お手本となるプログラムを作成し、
その後、徐々に人数を増やしていくやり方なら、失敗しにくいと思うわ
開発初期の頃のコードの作りがかなり重要だと思ってる 72仕様書無しさん2016/12/03(土) 13:47:25.57
優秀精鋭なんて言葉はおかしいな
文章書きなおしてたらそうなた
73仕様書無しさん2016/12/03(土) 14:28:06.13
>>71
そういう状況なら最初から設計パターンを設計書に書けばいい
適切なモデル図と適度な説明はコードよりも正確に早く理解出来る
後は設計書に書かれたパターンに従いコードを書くだけ
コードからパターンを再発見する手間とリスクがないので生産性が高くなる 74仕様書無しさん2016/12/03(土) 14:32:02.45
要するに完璧な設計書と思っていたものが間違っているだけで
優秀なプログラマが書いたコードのエッセンスを設計書に書くべきだった
使えない設計書を完璧な設計書と言って納めてきたクズを否定するのは正しい
しかし設計書の利点を否定する理由にはならない
75仕様書無しさん2016/12/03(土) 15:04:48.32
>>73
> 後は設計書に書かれたパターンに従いコードを書くだけ
それやってみたいわｗ
で、コードに書くだけでいいという
「設計書に書かれたパターン」の一例を見せてくれ。
そんなの見たことないんでなｗ 76仕様書無しさん2016/12/03(土) 15:10:27.70
>>75
一例はあなたがもう知ってるでしょ
優秀精鋭が書いたコードを解析すれば後続も書けるって自分で言ってるじゃない
それを設計書に図と文章で書くだけだよ 77仕様書無しさん2016/12/03(土) 15:17:52.50
> 優秀精鋭が書いたコードを解析すれば後続も書けるって自分で言ってるじゃない
> それを設計書に図と文章で書くだけだよ
それってコードと何が違うの？ｗ
内容的に同じものを2回書く理由は？
ないよね。じゃあどちらか一つにしましょう。
78仕様書無しさん2016/12/03(土) 15:24:32.91
じゃあどちらか一つにしましょう。
と言われた時、設計書だけ書いてコードは書かない。
自動生成しましょう。ってならないのはなぜか？
まあ分かるよねｗ
設計書にはコードに書いてある情報の一部しかない。
それみてもコードは書けないということ。
79仕様書無しさん2016/12/03(土) 15:25:42.97
>>77
レス読んでよ
図と文章で説明するってレスしたでしょ
コードに画像組み込むわけにはいかないだろう
そんなんで設計書が悪いなんて言っても説得力ゼロだよ
マトモに読んでないだけだろ 80仕様書無しさん2016/12/03(土) 15:34:49.42
>>78
なんでこの手の人ってすぐに自動生成に持って行きたがるんだろう
設計書はコード生成のソースではなくコードを書く人間にとって読みやすく理解しやすい形で情報をまとめたものだ
新人研修で教わるような基本的なことでしょこれ 81仕様書無しさん2016/12/03(土) 15:36:06.52
>>79
だから、で、コードに書くだけでいいという
「設計書に書かれたパターン」の一例を見せてくれ。
って言ってるんだが？
設計書にはコードに書いてある情報の一部しか書かれていない。
設計書を見てもコンポーネントの構成がわかるだけだ。
コードを読むことの助けになるだけであって、
設計書から誰もが同じコードをかけるわけがない。
優秀精鋭が書いたコードを解析すれば後続も書けるのは
そこに、設計書の内容＋コード の情報があるから
だけどコードがない設計書は、明らかに情報が足りてないんだよ。
足りてるというのなら・・・話は最初に戻るな
コードに書くだけでいいという
「設計書に書かれたパターン」の一例を見せてくれ。 82仕様書無しさん2016/12/03(土) 15:39:45.52
>>80
> なんでこの手の人ってすぐに自動生成に持って行きたがるんだろう
> 設計書はコード生成のソースではなくコードを書く人間にとって読みやすく理解しやすい形で情報をまとめたものだ
なんでこの手の人ってコードが読みにくくて理解できないと思い込んでるんだろ？
技術力がないから？ｗ
自動生成っていうのは、すべての情報が曖昧ではなく
揃っているのであれば、自動生成が可能だからだ。
自動生成ができないのであれば「読みやすく理解しやすい形で情報をまとめたもの」には
情報が曖昧で欠けているということの証明になる。
だから自動生成できない＝設計書には情報がかけている＝そこからコードを作り出すことは出来ない。
これが成り立つ。 83仕様書無しさん2016/12/03(土) 15:44:35.05
で、設計書を詳細にすればするほど、それをコードに落としやすくはなるが、
現実にある設計書は、ほとんどコードに落とせないものばかりだ。
コンポーネントの構成を理解する程度が関の山だろう。
コードに落とせるレベルまでの設計書を書いたらコストが膨大になってしまうからだ。
自然言語という曖昧な言語で、動くわけでもないからテストも不可能だしな。
84仕様書無しさん2016/12/03(土) 15:45:09.43
仕様変更があると設計書とソースのリンクが取れなっていくって
単純に仕様書担当のSEなりプログラマなりの怠慢でしかないよな
85仕様書無しさん2016/12/03(土) 15:47:35.68
>>84
怠慢をやめるのはいいが、リンクを取るための作業をするなら
単にコストがかかるだけだぞw
仕様変更があったとき一箇所を変えるだけで良くしておくと、
コストはかからなくなる。
怠慢というのは、同じ情報を複数箇所に分散させる行為だろう。
だから、どちらか一箇所にしましょう。 86仕様書無しさん2016/12/03(土) 15:57:29.68
アンチ設計書くんは設計書はプログラマ以外の利害関係者も読むし口を挟むって前提をどこかに置き忘れてるよな
コード読めない利害関係者とコードでコミュニケーションをとるなんて凄まじいコストになるぞ
87仕様書無しさん2016/12/03(土) 16:01:17.00
>>86
だったら「うちでは利害関係のために設計書は書くものです」って
言えばいいだけでは？
ソフトウェアを作る上では必要ないと言ってることに対して
矛盾はしないだろう？ｗ 88仕様書無しさん2016/12/03(土) 16:07:09.92
>>83
逆だよ
詳細まで煮詰めすぎるとコード化しにくくなる
自動生成できるほど詳細な設計書から自動生成したコードは整合性が取れないから動かないことがほぼ保証される
コードの生成ができるほどの濃密な設計書は役立たずってことだ
だから完全性は無いが殆ど正確でコードを書く人が理解しやすい図と文章という構成で設計書を作らなければならない
完全なコードに置き換える作業は人間が手で行う必要がある
最初から完全なコードを書くことは完全な設計書を書くことができないように不可能だから必ず設計書からスタートしなければならない 89仕様書無しさん2016/12/03(土) 16:09:12.11
>>87
必須ではないが有用だよ
もちろん使いこなせないバカにとっては有害になりうる
君や君の同僚にとっては有害だった
それだけの話なんだよね
これ以上は不毛な議論になってしまうな 90仕様書無しさん2016/12/03(土) 16:09:23.64
設計書なんて客から金をむしり取るためのものなのに、
そこに技術的価値があると言い張るからいけない。
91仕様書無しさん2016/12/03(土) 16:12:08.14
>>88
> 自動生成できるほど詳細な設計書から自動生成したコードは整合性が取れないから動かないことがほぼ保証される
なんで自動生成したコードを書き換えるんｗ
自動生成できるなら書き換える必要が無いはずだ。
自動生成できずに、手動で書き換えるから
整合性が取れなくなってんだろｗ
いい加減設計書からコードは自動生成できないって認めてしまえよ。
そしてその理由が、設計書には情報が足りてないからだって理解しろ。
自動生成が悪なんじゃないんだよ。（例えばソースコードからバイナリの生成は自動化できてる）
その元となる設計書の存在が悪なんだよ。 92KAC2016/12/03(土) 16:15:08.11
>>88
> 詳細まで煮詰めすぎるとコード化しにくくなる
はぁ？
いくら何でもそりゃただの馬鹿だ。
なんのために設計するのか理解してから設計しろ。 93仕様書無しさん2016/12/03(土) 16:18:29.26
>>89
> 必須ではないが有用だよ
俺は有用かどうかの話なんかしてない。
コードに書くだけでいいという
「設計書に書かれたパターン」
というものは存在しないと言ってる。
設計書なんてコンポーネントの構成を理解するため物でしかない。
そこからコードは作れない。理由は何度も言うが設計書には必要な情報がかけているから。
コストを無視するならば、有用なものであるのは確かだよ？
設計書を読んでそこから理解するのと、何もない状態から理解するのでは設計書を読むほうが早いだろう。
だけどそこには「設計書を作るというコスト」と「設計書を読むというコスト」がかかっている。
そして有用なのは0（設計書もコードもない）場合との比較だ。
設計書を作るコストを、優秀精鋭がコードを作るコストに転用してしまえば、
もっとコストを抑えられる。そういう意味で無用なものとなる。
あんたが言ってるのは「0に比べれば有用」と言ってるだけで
コードに比べれば有用ではないしコストを無視している。
まあ、コストを釣り上げるために設計書を作っているというのであるならば
わざとコストがかかる方法を選んでいるんだろうけどなｗ 94仕様書無しさん2016/12/03(土) 16:21:52.54
どうせコードを書くことは省略できないのだから
設計書なんてものは、必要最小限であればあるほど良い。
そうすれば、設計書を書くコストは抑えられるし、
設計書を読むコストも抑えられる。
（コードはどうせ読まなければならない。
ただしコードの量を減らして読まなければならない量を減らすことは重要。）
95仕様書無しさん2016/12/03(土) 16:24:08.33
一人のプログラマで最初から最後まで開発して、システムが死ぬまでずっと面倒みるなら
詳細設計書なしでもなんとかなるとは思うが、そんなもん理想論だからなあ
96仕様書無しさん2016/12/03(土) 16:25:41.42
97KAC2016/12/03(土) 16:26:26.41
>>93
話が変な方向に飛躍しているな。
本来の詳細設計書とは、
「コードに書くだけでいい」というレベルの記載がされているものをさす。
設計書からコードが起こせないというのはお前の勝手な思いこみ。 98仕様書無しさん2016/12/03(土) 16:27:41.30
詳細設計書があるからバッチリです！
システム修正できます！
ってコード読まないで言うやつはいないだろうね。
詳細設計書あった所でそこからコードを推察出来ないことの証拠な。
いや、コードを推察できるレベルの詳細設計書というものを
見せてくれることができれば、俺も納得するんだよ？ｗ
99仕様書無しさん2016/12/03(土) 16:27:52.00
プログラマだけでコードで設計とかありえないだろ
コードは正確だけどモデルがそもそも間違ってるから矛盾が発生して製造が滞るなんて現場じゃよくあることじゃん
そういう時にコードしか設計資料がなかったらステークホルダーとどうコミュニケーションとるんだよ
コード原理主義者の理想論はビジネスじゃ全く通用しないぞ
学生のお遊びじゃないんだから責任感持ってしっかりしてよ
100仕様書無しさん2016/12/03(土) 16:29:14.68
>>97
> 本来の詳細設計書とは、
> 「コードに書くだけでいい」というレベルの記載がされているものをさす。
だからそいうのを見せてくれって言ってるんだが。
神がいれば、どんな問題でも解決できる。
といった所で、実際には神いねーだろ？って話
いくら偶像つくってこれが神だぞーと言った所で
それ神じゃねーしｗｗｗ 101仕様書無しさん2016/12/03(土) 16:32:01.64
>>99
> ステークホルダーとどうコミュニケーションとるんだよ
やっぱりそこにたどりつくんだよなｗ
開発するために必要なものじゃなくて、
非技術者とのコミュニケーション用だって言えばいいじゃん。
俺だって、投資家に出資してもらうための
派手なデモは必要だって思うよ？ 102仕様書無しさん2016/12/03(土) 16:35:06.13
>>96
自分が一切開発に携わってないプロジェクトでも、何してるかはコード見ればギリギリわかるが
なぜしてるのかはより上位ドキュメントがないと無理。時間制限もあるのに解読なんてしてられん 103仕様書無しさん2016/12/03(土) 16:37:06.10
>>93
コストの話だしたら余計にコードベース設計の方が不利だぞ
設計とは無縁のコーダーにはわからないだろうけど設計するには対象となるドメインを理解しなければならない
そしてドメインを理解するには残念ながら顧客と真剣に議論し合うしかないのが現実だ
もちろん顧客はコードなど読めないからこのプロセスにはコード以外の資料が絶対に必要になる
その資料を整理して体裁を整えると設計書になるんだよ
コードだけで顧客と議論してもなんの進展もしないで時間ばかりが過ぎていく
この業界では時間ってのは最も重いコストだ 104KAC2016/12/03(土) 16:38:38.32
>>100
なんだ。ただの無知か。
SPDとかYACとか見ればどういうものかわかるだろ。
詳細設計書見たこと無いならさっと言えよ。。。 105仕様書無しさん2016/12/03(土) 16:46:02.97
>>101
前提から噛み合ってないんだから話し合っても無駄だよね
顧客を含めたプロジェクトメンバーとのコミュニケーションを設計プロセスに含めるか含めないか
そこからズレてるんだからどこまでいっても平行線だよ 106KAC2016/12/03(土) 16:46:05.97
>>103
話をややこしくすんな。
「その資料を整理して体裁を整えると設計書になるんだよ」
それは仕様書でやるべき話。
少なくとも、このスレの議題である"詳細設計書"はそこには使わない。 107仕様書無しさん2016/12/03(土) 16:48:27.76
>>103
基本設計書までは客とレビューするけど
詳細設計書はいちいち客とレビューとかする？ 108仕様書無しさん2016/12/03(土) 16:53:29.39
>>106
モデル設計は仕様じゃなくて文字通り設計でしょ
金額と消費税率を入力してボタンを押すと税込価格が表示される
これは仕様
税込価格とは金額と消費税率+1の積である
これはモデル設計 109KAC2016/12/03(土) 17:02:31.65
>>108
モデル設計と詳細設計を混同すんな。
つか、モデル設計を顧客の合意とんなよ・・・
モデル設計の内容にミスがあって仕様を満たせなくても
この内容は「顧客と合意済みだ」とか言いはるのか？
客と合意をとるのはあくまでも「仕様」の範囲にしとけ。 110仕様書無しさん2016/12/03(土) 17:09:28.02
>>109
合意の有る無しの話じゃねぇよ
顧客の協力なしに正しくモデリングできるわけないだろ
妄想の世界を相手にシステム開発してるんじゃねえんだよ 111KAC2016/12/03(土) 17:11:47.08
>>110
で、その仕様を詰めるための「モデリング」と
今回話題になってる「詳細設計書」に何の関係が？ 112仕様書無しさん2016/12/03(土) 17:13:39.06
何かバグが見つかった
調べてみるとコードに誤りはなさそうだ
どいやら詳細設計書のこのモデルのページに間違いがあるようだ
お客さんに設計書を見せて正しいモデルになるよう議論しよう
これがまっとうな対応な
113仕様書無しさん2016/12/03(土) 17:17:49.76
>>112
ちゃんとした仕様書を作って客と合意してから作業しましょう。
これが普通の対応な？
詳細設計書にしか客との合意事項が現れない時点で異常だと気づけ。 114仕様書無しさん2016/12/03(土) 17:28:29.67
>>113
顧客とコミュニケーションを取れる、かつ、仕様書から容易にソースに反映できる形式であること
バグがあっても良いが、随時、修正を施さなければならない
顧客との同意書ではなく、顧客の業務知識をより正確にコードに反映させるためのツール
詳細設計書ってのはそういうものだ
何を作るかの同意は別の文書でやるべきことであってその文書の話はしていない 115KAC2016/12/03(土) 19:00:12.33
>>114
>詳細設計書ってのはそういうものだ
はぁ？
詳細設計書とはなにか調べてから出直してこい 116仕様書無しさん2016/12/03(土) 20:46:05.65
さあ盛り上がってきまたし！
117仕様書無しさん2016/12/03(土) 21:12:56.24
さあ盛り下がってしまいました↓
118仕様書無しさん2016/12/04(日) 01:14:49.64
>>114
ん？
＞顧客の業務知識をより正確にコードに反映させる
これはちょっと違うな。
業務知識とコード（具体的な実装）の間には、最低限もう1枚挟まないといけないと思うよ。 119仕様書無しさん2016/12/04(日) 01:16:31.62
というか、そもそもプログラマとSEでは必要なスキルセットが違うので、
無理して顧客とか業務とか要件とか解ったふりして語らなくていいと思う。
「知りません」「できません」で問題ないんじゃない？
120仕様書無しさん2016/12/04(日) 01:21:19.62
>>35
普通は、要件定義書と基本設計書は同じレベルの人が作って、
詳細設計とコーディングは、これまた同じレベルの人が作る。
なので、通常はコードが欠ける人は詳細設計がかけるレベルであると思ってよい。
基本設計と詳細設計のほうに大きな溝があるんだよ。
ドキュメント教うんぬんよりも、スキルとしてくっついてるんだよ。
だからかけないこともないと思うが、書かない習慣もどうかと思う。 121仕様書無しさん2016/12/04(日) 02:01:34.56
>>114
> 顧客との同意書ではなく、顧客の業務知識をより正確にコードに反映させるためのツール
> 詳細設計書ってのはそういうものだ
実際には伝言ゲームで間に一人増えただけだけどなｗ
業務知識を正確に反映させるためには、顧客が直接プログラミングするのがいい。
当たり前だろ？コミュニケーションの数は少なければ少ないほどより正確なる。
それができないなら、顧客とプログラマが直接やり取りする。
その時に使うコミュニケーションツールは両者がわかるものでなければ意味がない。
これも当たり前だろ？
じゃあ詳細設計書は顧客が理解できるのか？って話。顧客は詳細設計書を理解できない。
つまり詳細設計書では顧客の業務知識を正確にコードに反映させることは出来ない。
詳細設計書でできることは詳細設計書を書いたやつと、それを見るやつの
コミュニケーションツールだよ。けっして顧客の業務知識を伝えられるもの
なんて思ってはいけない。 122仕様書無しさん2016/12/04(日) 03:30:11.21
皆さんの詳細設計書に対する思い入れは凄いですね～
はっきり言ってバカです
123仕様書無しさん2016/12/04(日) 04:48:05.42
ここいらでバーンと詳細設計書を公開すれば
流れは変わるんだけどな。
オープンソースはできるのだから詳細設計書を公開することが
できないわけがない。
124仕様書無しさん2016/12/04(日) 08:38:13.24
>>123
フェイスブックやツイッターを公開してるのだから、
源泉徴収票や健康診断結果を公開することができないわけがない。 125仕様書無しさん2016/12/04(日) 08:51:52.62
そもそも詳細設計書ってひとくくりにして議論するのが間違いですよね
唯一普遍の詳細設計書など存在しないのだから、うちの会社ではこうしてます、へえそうなんですか、以上の議論はできません
以上をもちまして、このディスカッションは閉じさせて頂きます
以後、書き込みは控えてください
126仕様書無しさん2016/12/04(日) 10:13:39.38
127KAC2016/12/04(日) 17:32:58.25
>>123
公開もなにも・・・
フローチャートとか見た事ないか? 128仕様書無しさん2016/12/04(日) 20:21:27.86
時間がないときはソースコードの日本語訳どころか
ソースコードそのものをコピペしたものを納品したりしてるわ
129仕様書無しさん2016/12/04(日) 20:29:35.18
>>128
いや、流石にDoxygenくらいかけようぜ・・・ 130仕様書無しさん2016/12/04(日) 20:50:17.11
>>127
> フローチャートとか見た事ないか?
何のソフトウェアの？ 131仕様書無しさん2016/12/04(日) 20:55:31.95
132仕様書無しさん2016/12/04(日) 21:01:42.91
>>131
いや質問しているだけだが？
別にフローチャートじゃなくてもいいよ
話を戻すぞ。
ソースコード公開できるんだから
その詳細設計だって公開できるはずだろ。
それを公開しているソフトウェアを教えてくれ 133仕様書無しさん2016/12/04(日) 21:04:54.23
>>132
話が戻ってないぞ。
素人は黙ってたほうがいいよ 134仕様書無しさん2016/12/04(日) 21:15:08.62
戻ってるよな？
意味は同じだからまんま前の話を持ってきてもいいんだぜ？
123 自分：仕様書無しさん[sage] 投稿日：2016/12/04(日) 04:48:05.42
ここいらでバーンと詳細設計書を公開すれば
流れは変わるんだけどな。
オープンソースはできるのだから詳細設計書を公開することが
できないわけがない。
135仕様書無しさん2016/12/04(日) 21:20:15.57
136仕様書無しさん2016/12/04(日) 21:43:05.60
図や表ってソースコードでどう書くんだ？
アスキーアート？
137仕様書無しさん2016/12/04(日) 22:13:55.25
>>135
それでソースコードとともに公開されている
詳細設計書はどこにあるの？ 138仕様書無しさん2016/12/04(日) 22:14:10.04
139仕様書無しさん2016/12/04(日) 22:15:04.40
>>136
文章で説明するんじゃないか？
20cmの線分ABの中点Pに直行する10cm線分PDがあり・・・・とか 140仕様書無しさん2016/12/04(日) 22:21:18.74
>>139
そんな文章書くぐらいならコードでよくね？ 141仕様書無しさん2016/12/04(日) 22:22:40.53
うむ、COBOL以外の言語は
自然言語を直接翻訳したような文法ではなくて
数学的な式に近いから曖昧さがなくて簡潔に記述できるんだよな。
結局コードで書くのが一番という結論
142仕様書無しさん2016/12/05(月) 13:17:18.51
うん。
これから仕様書や設計書は図も含めて全てプログラムで書こう。
143仕様書無しさん2016/12/05(月) 18:51:06.23
微積分とか数学記号はどう書くの？
TeXコード埋め込むの？
144仕様書無しさん2016/12/06(火) 00:54:35.45
アスキーアート並みに苦心して書くんだ。
145仕様書無しさん2016/12/06(火) 18:57:22.33
黒塗りの四角と白抜きの四角でドット絵でどうだ
フォントを小さくすれば滑らかで美しいグラフィックになる
146仕様書無しさん2016/12/06(火) 19:11:47.87
コボルの文法って曖昧さがあるのか？
147仕様書無しさん2016/12/06(火) 23:06:58.25
ない。
一切ない。
絶対にない！
あったらびっくりだろうな。
148仕様書無しさん2016/12/06(火) 23:57:54.99
じゃあCOBOLは曖昧さがないのに
自然言語に近づける意味あるのか？
149仕様書無しさん2016/12/07(水) 00:50:15.82
昔は簡潔な記述よりも、自然言語に近い方が
可読性が高いって考えられていた時代があったんだよ。
だってみんなプログラミング言語を知らなかったわけだからね。
今のようにプログラミング言語をスラスラとみんな読めるように
なるとは考えていなかった。
150仕様書無しさん2016/12/15(木) 23:07:36.59
基本設計書は「こう作ります」ってのを書いて
詳細設計書はどこの会社でも書くところはもうソース貼り付けろよってレベルのもんを
深夜残業して書かされたな
ぶっちゃけ詳細設計書はソース書いてから作ったほうが早い気がする
そもそもこの粒度で詳細設計書を書くことは絶対見積りに入ってないし
おそらく詳細設計書は作るだけで検討などしてる時間はないのではないか?
という経験から詳細設計書は基本設計書とソースのつなぎをする程度の内容でいいのではないかと思う
クラス図→絶対役に立たない
シーケンス図→何も表現できない
処理フロー→ソース見たほうが早い
詳細設計書によくある項目って全部役に立たない
151仕様書無しさん2016/12/15(木) 23:14:34.50
コードだと複数ファイルを開き処理を追わなければ関連やシーケンスが見えてこない
絵に書いておけば紙一枚眺めるだけで一瞬で内容を理解できる
コードが設計として役に立つのはメソッドまでだよ
メソッド程度のサイズならコードの方が早く理解できて正確である事が多いことを認めよう
152仕様書無しさん2016/12/16(金) 00:38:15.25
>>151
関連っていらなくね?
大事なのはどの機能がどのクラスやメソッドで実現されているかであって
関連は別にいらねぇ 153仕様書無しさん2016/12/16(金) 03:08:34.87
>>151
設計なんてディレクトリツリーを見ればわかることだよ 154仕様書無しさん2016/12/16(金) 03:08:52.28
ディレクトリツリーとファイル名な
155仕様書無しさん2016/12/16(金) 05:59:58.16
変なおじさん「道路の写真が何枚かあれば道路網がどうなってるかわかるよ」
常識人「地図って知ってる？」
156仕様書無しさん2016/12/16(金) 08:15:43.33
仕様を固めないで行き当たりばったりのプロジェクトに参加させられた時が一番きついわ
何回仕様変更して何回ソース書き直せばいいんだよ
157仕様書無しさん2016/12/16(金) 08:19:20.92
R&D部門だとよくあるけど
158仕様書無しさん2016/12/16(金) 09:06:10.87
変なおじさん「青写真が何枚かあれば設計がどうなってるかわかるよ」
常識人「ソースコードって知ってる？」
159仕様書無しさん2016/12/16(金) 09:13:59.75
>>156
問題は仕様変更した時に再見積りしない空気
ケツそのままで走るのを作業をボイコットしてでもやめさせないと
でもその辺は状況に応じてって感じだと思う 160仕様書無しさん2016/12/16(金) 09:17:18.93
基本設計書にやることが書いてあって
詳細設計書に基本設計書とソースのつなぎが書いてあれば情報は十分だよ
大手の求める詳細設計書はソースの逆変換に他ならない
161仕様書無しさん2016/12/16(金) 18:53:20.64
みたいなこと言ってる子って仕事で設計書書いたことないんだろうな
162仕様書無しさん2016/12/16(金) 19:29:49.14
いい年したオッサンに向かって子とかいうオッサンwキモwww
163仕様書無しさん2016/12/16(金) 19:34:19.72
ここは社会人が来るスレだよ
君みたいな坊やにはまだ早いんじゃないかな
164仕様書無しさん2016/12/16(金) 19:43:04.48
>>163
いや俺もオッサンなんだがwお前ほどキモくないけどwww 165仕様書無しさん2016/12/16(金) 20:21:22.32
166仕様書無しさん2016/12/16(金) 20:37:46.81
なにこいつ常軌を逸したキモさだなw
167仕様書無しさん2016/12/17(土) 08:41:53.92
顧客・ユーザーと直接話をして仕様書等々を作成したことないやつは、語る資格なし
168仕様書無しさん2016/12/17(土) 09:27:08.99
>>167
そもそも、プログラム組めないバカはそれすら語る資格ないわけで・・・ 169仕様書無しさん2016/12/17(土) 15:55:31.43
プログラム組めるのは前提条件です
そのうえで>>167をやってないやつは語る資格なし 170仕様書無しさん2016/12/17(土) 22:14:16.88
細かすぎる設計書でもあるだけマシだろ
現実世界の詳細設計書は細かすぎるどころかスカスカのゴミじゃねえか
上流が悉く仕事をしていないからな
細かすぎるなんて贅沢な不満なら言ってみたいわ
171仕様書無しさん2016/12/17(土) 22:35:49.80
> 現実世界の詳細設計書は細かすぎるどころかスカスカのゴミじゃねえか
だからいらんって言ってるの。
そもそも当たり前だろ。
細かいことを考えるレベルじゃないのに、
細かいことなんてかけるわけない。
できもしないことをすんなって言ってんの
172仕様書無しさん2016/12/17(土) 23:01:44.71
詳細設計書を書く上流って…そういう世界もあるのか……
173仕様書無しさん2016/12/17(土) 23:55:55.66
>>172
そういう現場はもちろんソース書いてから設計書書くよ
担当者もそうするであろうことを見越してスケジュールをする
厄介なのは精度はソースレベルを要求するくせに期間がそれに伴っていないとき 174仕様書無しさん2016/12/18(日) 01:26:39.62
175仕様書無しさん2016/12/18(日) 08:36:22.98
コボルは知らんがコボルには固定長フィールドの読み込みAPIしかないってんならフィールド長を設計書に書くべきだろ
自分がデリミタだと思ってたカンマは実はデータの一部で正しくはフィールド長を根拠に読み込む必要があるってことも当然あり得るわけだ
フィールド長を設計書から省略していいのはファイル形式が明確にCSVでありCSVを読み込むAPIがサポートされてる時だけだ
176仕様書無しさん2016/12/18(日) 09:10:04.98
>>175
いまはいろんな読み方できるけど、
コボルは固定長が基本、で設計書にフィールド情報は絶対にのせる
ほぼそれがメインと言っていい。 177仕様書無しさん2016/12/18(日) 22:48:17.40
ミﾐ ヽヽヽヽﾘﾘﾉﾉノノ
ミ ,,､,､,､,､,､,､,､､ 彡 ／￣`Y ￣ヽ
l i''" i彡/ / / l | | lヽヽ
.| 」 ⌒' '⌒ |/ // ⌒ ⌒ヽ
,ｒ-/ -･=-, ､-･=- ||/ （●） （●）
l ﾉ( ､_, )ヽ || | ⌒ ･ｨ ヽ
ｰ' ノ､＿_!!＿,. || ﾄ-＝-ｧ ﾉ
|. ヽニﾆｿ l | |-ｒ ､/ /|
ヽ /.|| | ＼＿｀ﾆ'_／ ||
/⌒＼〆⌒ヽ"ーー" ⌒ヽ／⌒ヽ ＿ﾉ
../ ﾉつ＼ ・ ・ ／＿人. ヽ /
ｸﾞｯﾎﾟ o0○/ /( 3 ＼ ∩ ／ `-と ) ○0o
( ` /､＿ﾉヽ (:::)(:::) /＿ﾉ' '! )゜
＼＿) | : : : __ : : :｜ ノ(＿ノ
ｸﾞｯﾎﾟ (( ヽ＿＿ | | ＿＿ノ ／ ))
／ ⌒ (:::)(:::) ⌒ー―、
( ⌒￣￣ 人 ヽ
＼ ＼__＿＿＿＿ノ ヽ＿＿＿＿.／ ) .＿_/￣/ /二二二/_ /'''７ /￣ ￣/ /￣/ /'''７
. ＼ ＼ ／ ／ /___. ￣./ / ＿＿ / / / ___ / ￣ ￣/ ￣ / ./
＼ ＼ ／ ／ ノ / /i￣!.￣ __,ノ / / /_ノ / ~/ /二,.´ ＿___.ノ ./
ε( ￣￣) (￣￣ )3 /_,./__./ ヽ､_> /____,／ /＿____,.ノ i＿＿__/ /＿_____.／
178仕様書無しさん2016/12/20(火) 02:08:55.37
無いよりは合った方が断然良いけど
ちゃんとメンテできないならいらない
179仕様書無しさん2016/12/20(火) 14:00:40.43
>>178
ちゃんとメンテできる書き方ってのもあるじゃない? 180仕様書無しさん2016/12/20(火) 19:50:01.21
メンテはまず不可能だから要点をうまく捉えた抽象的な内容にせざるをえない
だから作図が有効なんだね
181仕様書無しさん2016/12/22(木) 23:42:11.82
文芸的プログラミング
182仕様書無しさん2016/12/23(金) 09:51:30.66
設計書はアート
183仕様書無しさん2016/12/23(金) 22:22:31.43
アートは引越しセンター
184仕様書無しさん2017/01/11(水) 19:44:30.96
詳細設計のお仕事が回ってきて憂鬱だ
コーディングより高難度の詳細設計を書かされて
コーディングは低品質な外注にぶん投げ
マネジメントと受け入れテストも押し付けられた
もうやだ一人で仕事したい
185仕様書無しさん2017/01/11(水) 22:19:47.34
>>184
意味が解らん。
一人で仕事すりゃいいじゃねーか。
誰かいないと仕事できないのか？ 186仕様書無しさん2017/01/11(水) 22:50:27.40
営業とか居ないと困るな
187仕様書無しさん2017/01/13(金) 21:52:22.32
詳細設計として価値のあるコンテンツって何だ？
188仕様書無しさん2017/01/13(金) 22:01:41.06
>>187
APIマニュアル、テストコード、サンプル 189仕様書無しさん2017/01/13(金) 22:21:29.51
>>187
状態遷移図・表
プロセス・タスク構成/関連図 190仕様書無しさん2017/01/13(金) 22:39:01.15
>>189
それ結構欲しいけど、図とか表ってアップデートするのめんどくセーんだよなぁ
なんとかならんかねぇ 191仕様書無しさん2017/01/13(金) 22:55:41.70
192仕様書無しさん2017/01/13(金) 23:00:09.08
193仕様書無しさん2017/01/13(金) 23:01:38.61
図を生成するコードとデータを書く
なお製品コードより複雑な模様
194仕様書無しさん2017/01/14(土) 06:21:23.08
195仕様書無しさん2017/01/14(土) 08:55:37.67
>>194
画像から変換する奴じゃなくて？
urlくださいな 196仕様書無しさん2017/01/16(月) 19:54:37.73
複雑なSQLの詳細設計をどう書くべきかいつも悩む
SQLは頭の中に出来てるけど日本語で説明って難しいんだよな
設計して外注するよりその場でコード書いた方が時間かからない……
営利企業としてなんか見失ってる
197仕様書無しさん2017/01/16(月) 20:52:02.80
>>196
手書きで書いた図をスマホで撮って貼り付けしたらいいんじゃないか？ 198KAC2017/01/17(火) 21:12:11.38
>>196
詳細設計終わってから外注する事自体が間違いだろ
詳細設計から外注するか、試験から外注すべきだと思うが 199仕様書無しさん2017/01/21(土) 12:54:40.92
>>196
マジレス
別シートとかに生のSQL文を書いて、管理番号で参照する
結果取得 (SELECT-1-1)
DB更新 (UPDATE-2-1)
もしくは、SQLを詳細設計書に記述する独自記法を決めて、それで記述すればおｋ
テーブルセルの背景色とかフォントを工夫する
構造的な見た目はSQLと殆ど同じｗ
Fとかでは、そうだった
あまりにも馬鹿らしいな・・・
もうそういうのに関わる仕事はしなくなったけど 200仕様書無しさん2017/01/21(土) 12:57:15.88
>>196
引数を渡す時は
SELECT-1-1に
SELECT * FROM USERS WHERE ID = :ID
とか引数を記述して
SELECT-1-1 (ID: 画面[ユーザID])
みたいな感じ
ああ、思い出してもあほらしいわ 201仕様書無しさん2017/02/07(火) 18:42:00.46
なぜかSQLをベタ書きするところはいまだにあるんだよな。あれ謎だわ。
202仕様書無しさん2017/02/07(火) 22:05:13.69
のちのちのメンテで役に立つのは
・コーディングの元となった詳細設計書
・コーディングが終わってから書いた詳細設計書
さて、どっちかな？...
203仕様書無しさん2017/02/07(火) 23:31:08.05
204仕様書無しさん2017/02/07(火) 23:35:38.65
>>201
引当に使うキーは別として
フィールドの粒度で細かく説明しないとだめな時点で設計が失敗してるとは思うが
世の中結構そうやって作っちゃうやつが多い 205仕様書無しさん2017/02/08(水) 07:37:52.27
何もしていない普通の一般人の自宅に隠しカメラを取り付け
それをネットでリアルタイム配信
仲間という人間に対する盗聴盗撮生ネット配信の会
しかけたカメラの映像
乗っ取っているＰＣの画像をリアルタイムで生配信中
集団で仲間の私生活を覗いて楽しんでいる
そんなことが今この国では行われています
206仕様書無しさん2017/02/08(水) 12:10:19.96
207仕様書無しさん2017/02/09(木) 01:29:54.76
208仕様書無しさん2017/02/09(木) 01:58:13.18
209仕様書無しさん2017/02/11(土) 14:26:18.48
詳細設計書って後から見ても、殆ど役にたたない
メンテされずにコードと乖離してたり、嘘や間違いだらけ
そもそも、ドキュメントって、簡単に馬鹿でもメンテできる概要レベルしか残しちゃダメだわ
210仕様書無しさん2017/02/11(土) 15:29:03.41
>>202
> のちのちのメンテで役に立つのは
コードだろ？
既存システムのソースコード解析および設計書作成を自動化「設計書リカバリーサービス」を提供開始
http://www.nttdata.com/jp/ja/news/release/2013/042402.html
> 長期にわたって運用されるシステムでは人手のかかる設計書整備の不備・不足による保守開発の
> 困難さや有識者依存の業務が問題となっています。また、システム更改を行う場合も仕様が
> 不明確で問題化するケースもあります。システムを正しく理解するために設計書の
> 不備・不足を解消するには、既存システムのソースコードを解析する必要があるため、
> 多大な時間を要していました。
> 背景
> システムの保守開発現場では保守運用の為、ソースコードの修正・変更が随時発生し、
> その対応内容を設計書へ反映させます。しかし度重なるシステム改修や技術者不足などの理由により、
> 修正・変更内容の反映漏れによるソースコードと設計書の乖離といった不備や、ソースコード内容が
> 記載されていないという設計書自体の不足がしばしば発生していることがあります。
> 特に長期にわたって運用されているシステムではこの傾向が顕著で、システム改修などの保守開発が
> 困難となる問題が発生しています。その一方で保守開発の現場では、変更要求発生時などに迅速かつ
> 正確な対応が求められており、設計書の不備・不足はシステム改修内容の決定判断や、
> 正確なシステム改修の妨げになるため大きな問題となっています。 211仕様書無しさん2017/02/11(土) 18:14:44.30
212仕様書無しさん2017/02/11(土) 20:47:34.99
>>210
お前、自分で貼った文章の内容すら理解できないのか？ 213仕様書無しさん2017/02/11(土) 21:10:15.59
>>210
各設計書のマークがExcelであることに不安を感じた 214仕様書無しさん2017/02/12(日) 10:34:50.93
詳細設計の粒度はプログラミングをする人間のレベルに合わせるのが現実的。
215仕様書無しさん2017/02/12(日) 10:47:29.03
pseudo code
216仕様書無しさん2017/02/12(日) 11:06:18.89
>>214
おい、なんで新卒様に俺らが合わせないといかんのだ？ 217仕様書無しさん2017/02/12(日) 11:12:24.44
>>216
出来上がってきたプログラムを書き直すのが面倒だから。 218仕様書無しさん2017/02/12(日) 13:46:18.65
>>216
修正するのも将来の新卒や質や経緯のわからない借りてきた派遣の仕事になるんだろうから、意味のある詳細設計なら新卒にあわせないと。
形だけ納品して後は知らない、なら適当に書いておけばいいさ。後で呼び出される心配なければね。
その前に読めんわからんとクレーム上がってくるかもしれないけど。 219仕様書無しさん2017/02/12(日) 13:53:53.83
入社したばかりの新卒が作ったシステムです
高いのは仕方ないでしょう？
とか言うつもりかｗｗｗ
220仕様書無しさん2017/02/12(日) 14:06:44.26
>>218
役に立つなら良いんだけど、放置されてるのたくさん見てるからなあ。
ドキュメントが殆ど無いような案件でリフォームするような仕事したことあるけど作業も半ばまできて、たまたま雑談してる時に別の案件で終了した奴の中に今作業しているのと殆ど同じものがあることを聞いた。
こっちはドキュメントがかなり詳細に残っていて作りもしっかりしてるし、DBで言えばフィールドを少し増やせばそのまま使えるような奴だったけど結局使われなかったな。
詳細なドキュメントが残ってても詳細を知ってる奴が残っていないと放置されたままゴミ箱行きになることも多い。 221仕様書無しさん2017/02/12(日) 15:06:44.85
結局SI業界っていうのは、素人がシステム作ってるんだよ
222仕様書無しさん2017/02/12(日) 15:14:34.47
そもそもpseudo codeというれっきとした名前が有るんだからそれを使ってくれ。
223仕様書無しさん2017/02/12(日) 16:37:39.05
pseudo codeってなんだ擬似コードのことか。
日本語で言えよ。わかりづらい
224仕様書無しさん2017/02/12(日) 18:15:43.41
225仕様書無しさん2017/02/12(日) 18:24:28.39
常識レベルの低い奴に限って
それ常識だよ、とか言うんだよな。
根性がひんまがってる低知能に多い現象。
これ常識ｗｗｗ
226仕様書無しさん2017/02/12(日) 18:41:12.30
時々仕事できないくせにカッコつけた言葉使いたがる奴には「それって何なの?」と圧力的に聞くことがあるな。
で、説明受けた後で「なんだ、～のことかあ」って返す。
勿論、こちらが上司+自他共に技術レベルが上と認められてる場合だけどね。
227仕様書無しさん2017/02/12(日) 18:45:37.14
カッコつけた言葉って？
「ちょ待てよ」とか？
228仕様書無しさん2017/02/12(日) 18:50:15.97
229仕様書無しさん2017/02/12(日) 20:28:33.39
Pseudocode程度でカッコ付けって、どんだけレベル低いんだよ。
230仕様書無しさん2017/02/12(日) 20:33:17.46
日本語で通るもので且つ日本語の方が分かりやすい場合は全部カッコつけてると判断するな。
但し、既に日本で浸透している場合は除く。
けれど、知らない奴に"常識"とか言うような奴ならカッコつけてるという判断をするさ。
231仕様書無しさん2017/02/12(日) 20:49:31.15
成長しないな、それじや
232仕様書無しさん2017/02/12(日) 20:57:10.28
(常識)
233仕様書無しさん2017/02/12(日) 21:08:12.08
プログラム歴1年未満の兵隊をたくさんかき集めて、
無駄に時間をかけて開発するのが
SI業界の常識だろ
234仕様書無しさん2017/02/12(日) 21:57:56.11
>>230
お前が分かりやすいから皆が分かりやすいという訳でもない
同様に日本語の約語より外来のカタカナ語の方が浸透してる例はいくらでもある 235仕様書無しさん2017/02/12(日) 22:03:32.68
漢字が読めない人のために
全部カタカナ or ひらがなで書くべきだ。
可読性重視な
236仕様書無しさん2017/02/12(日) 22:07:40.88
プ…pseudo codeってなんだ？
237仕様書無しさん2017/02/12(日) 23:31:54.67
>>235
可読性を上げるために漢字が使われているんたか？ 238仕様書無しさん2017/02/12(日) 23:58:47.94
たか？
239仕様書無しさん2017/02/13(月) 02:03:49.84
>>234
何言ってんの?
浸透してたら除くって日本語分からんのか?
それに当然分かりやすいなら何の問題も無い。
しかし少なくともPseudocodeが分からなかった奴も擬似コードは分かってたわけだよな。
つまりその時点では意志疎通という意味では擬似コードの方が優秀だったわけだ。
にもかかわらず"常識"とか言うから言われちゃうんじゃ無いの?俺みたいな奴に。
あとやたらプロジェクトって言葉を使う奴も地雷臭がするな。
お前1人でチマチマやってるのの何がプロジェクトだよって言いたくなる。
当然、それなりの規模ならプロジェクトで問題ないけど。
自分を大きく見せようとする奴は要注意。 240仕様書無しさん2017/02/13(月) 07:41:50.50
>>239
fizzbuzzでもプロジェクトだけど？
訳のわからんオレオレ定義振りかざして何言っちゃってんのお前ｗ 241仕様書無しさん2017/02/13(月) 07:48:28.12
242仕様書無しさん2017/02/13(月) 08:08:11.23
>>239
お前が言葉を知らなさすぎるだけですので 243仕様書無しさん2017/02/13(月) 10:24:56.76
定義の話じゃない。
そりゃ、分類すればプロジェクトだろうよ。
でも、しょうもなくて自分からはプロジェクトなんて恥ずかしくて言えないような案件もあるだろ。
244仕様書無しさん2017/02/13(月) 10:44:50.75
英語の文章を日常的に読むんだから、日本語より先に英語が出てくるのは自然だと思うが
245仕様書無しさん2017/02/13(月) 12:00:18.47
246仕様書無しさん2017/02/13(月) 12:08:24.85
既存アプリの劣化クローン作ってひとりプロジェクトとか言ってる奴いるよな
なにかっこつけてんだハゲって周りから思われてることも知らずに
247仕様書無しさん2017/02/13(月) 12:09:24.87
>>245
日本語が理解出来ないなら反論しなくて良いぞ。 248仕様書無しさん2017/02/13(月) 12:25:44.88
>>243
いや恥ずかしいとかそういう問題じゃないからｗ
どんなプロジェクトでもプロジェクトはプロジェクト
てかお前の方がなんか勘違いしてんじゃね？ｗ 249仕様書無しさん2017/02/13(月) 12:30:02.19
不要なコメントを削除するプロジェクト
250仕様書無しさん2017/02/13(月) 13:22:00.65
>>248
だから日本語分からんのなら反論しなくって良いって。
どんなプロジェクトだろうとプロジェクトはプロジェクトだよ。
これでも分からんか? 251仕様書無しさん2017/02/13(月) 18:34:47.12
プロジェクトひとり
252仕様書無しさん2017/02/13(月) 19:21:40.29
あ～あ、ムキになっちゃったw
253仕様書無しさん2017/02/13(月) 19:57:25.76
ムキムキー
(･∀･ )
/⌒"ー ― ⌒ヽ
｜ (_ (＿_人 )
(三0∧ﾐキ)彡ﾉヽ )
￣ ﾉー―-ｲ 0三)
／ ヽﾚ′ヽ ￣
/＿_／ヽ ＼
＼ ヽ ＼＿ )
Lノ ｜ /
ﾋ二)
254仕様書無しさん2017/02/13(月) 20:06:32.63
一般人が思うプロジェクトのイメージで言われたら普通あきれるよ。
255仕様書無しさん2017/02/13(月) 22:07:56.29
詳細設計って、C言語設計の名残だろ
OOP対応言語で作ってたら
爆笑しちゃう
256KAC2017/02/13(月) 22:19:51.95
>>255
Rational Roseとか知らない世代なんだろうな 257仕様書無しさん2017/02/13(月) 22:25:22.08
Roseでもmember functionの処理をPseudocodesで書く。
258仕様書無しさん2017/02/13(月) 22:30:15.73
259仕様書無しさん2017/02/14(火) 00:26:19.05
詳細設計だな
260仕様書無しさん2017/02/14(火) 01:34:15.79
>255の爆笑はまだなの？
261仕様書無しさん2017/02/14(火) 03:50:10.85
262仕様書無しさん2017/02/14(火) 08:18:23.62
コードにdocかけよ
そこからドキュメントを起こすツールがあるんだから
263仕様書無しさん2017/02/14(火) 08:31:35.41
264仕様書無しさん2017/02/14(火) 10:31:21.03
>>263
ソースが文字で見づらいってこと？
コメントなんだから邪魔なら畳めばええやん 265仕様書無しさん2017/02/14(火) 12:06:47.60
図が書けないじゃんってことじゃね
266仕様書無しさん2017/02/14(火) 12:50:40.13
あ～確かにめんどいな
htmlには出来るけどわざわざタグ書くのめんどいんだよね
267仕様書無しさん2017/02/14(火) 13:10:08.48
そこで罫線ですよ
268仕様書無しさん2017/02/14(火) 15:53:13.62
そこでAAですよ
269仕様書無しさん2017/02/14(火) 18:14:08.03
>>268
なるほどaaジェネレータ的なので生成しpreで囲めば行けるかもしれんな… 270仕様書無しさん2017/02/14(火) 23:42:43.96
使い捨てのソフトは設計書いらないけど、長期的に使用する
ソフトは設計書いるよと思う。
設計書の粒度は製品（ソフト）の特性に依ると思う。
271仕様書無しさん2017/02/20(月) 13:29:24.39
設計書（仕様書）無かったら、3000行程度で混乱する
むしろ500行超えた辺りから頭パンクしそうだし、
用途によるけど、（GUIを除いた）
純粋な処理コードだけなら、200行有れば十分だと思うんだが？
[（基本80*200=16000文字）空白除く]
272仕様書無しさん2017/02/21(火) 00:01:55.94
>>271
1クラス3000行？
1メソッド3000行? 273仕様書無しさん2017/02/21(火) 00:37:01.04
274仕様書無しさん2017/02/21(火) 12:32:27.27
お前らって現実に起きている問題には近視眼的なくせに
ソースコードに対峙したとたん全てを把握する神になろうとするよな
要領のいい人とは真逆だよそれ
275仕様書無しさん2017/02/21(火) 12:48:37.61
>>274
あるある
ソース書いてる時点なんて問題の殆どが解決してなきゃいけない状態なのにね 276仕様書無しさん2017/02/21(火) 14:44:14.71
>>274
> お前らって現実に起きている問題には近視眼的なくせに
え？なに？アフリカの飢餓問題とかそういう話？ｗ 277仕様書無しさん2017/02/21(火) 18:29:00.58
278仕様書無しさん2017/02/21(火) 18:58:43.00
279仕様書無しさん2017/02/21(火) 19:23:27.29
オウム返しがやっとか
280仕様書無しさん2017/02/21(火) 19:40:24.62
281仕様書無しさん2017/03/02(木) 17:26:47.07
わっかんねー
何もかもがわっかんねー
282仕様書無しさん2017/05/21(日) 21:01:50.52
詳細設計書に動くサンプルコード添付したら協力会社さんに喜んでもらえた
いい仕事をした後は気分がいいな
283仕様書無しさん2017/05/22(月) 10:37:40.63
概念とそれに対する処理を明確に定義し、全体のアーキテクチャを記述する
これが設計書であり、あとはフォーマットの違いだけだ
284仕様書無しさん2017/05/22(月) 12:28:09.70
どうやら「僕が考えた最強の設計書」のようだけど残念ながら意味不明
285仕様書無しさん2017/05/22(月) 14:37:25.74
意味わからんだろ？
所詮その程度の頭ってことだ
286仕様書無しさん2017/05/22(月) 15:03:24.89
287仕様書無しさん2017/05/22(月) 22:56:07.53
>>282
同じ様な事あって、配列の添え字にまた配列とか配列使いまくりだったから、
思いっきりポインタにしてやった事あるなぁ～。
今思えば無駄な自己主張だったなぁ～。 288仕様書無しさん2017/05/25(木) 10:05:53.17
>>282
まさに重要なのは動くサンプルコードであって
詳細設計書なんていらないって話だなｗ 289仕様書無しさん2017/05/28(日) 21:39:22.86
ウチの会社は部署によってやり方が全然違うんだけど
今度のところはソースをExcelに張っつけたのが詳細設計書
以前のところも少ない人数で我流でやってて色々問題を感じていたけど
今回はさすがにちょっと驚いた
でもまー古い既存システムの改修がメインだから
どうやれば正解と言えるのかは実際には難しいんだけどね・・・
290仕様書無しさん2017/05/28(日) 21:42:44.76
あともう１つ驚いたのが
ソースにコメントをロクに書かないという慣習
なんかそれに美学でも持ってるようだｗｗｗ
僅かに書いてあるコメントも奇妙な言葉使いでほとんど暗号
職人の世界のようでもあるが、とてもアホらしいｗｗｗ
291仕様書無しさん2017/05/29(月) 00:26:54.09
設計書だってフローチャートだってあるのに、
なんでコメント書かなきゃならないんだ？
292仕様書無しさん2017/05/29(月) 00:34:51.62
設計書だってフローチャートにかかれている情報は
概要でしかないから。ほんの一部でしかないし
概要からは省くような詳細な情報がコメントとして必要
293仕様書無しさん2017/05/29(月) 01:25:01.30
未だにウォーターフォールモデルで開発やってんのか
294仕様書無しさん2017/05/29(月) 03:16:11.02
>>291
あるのに？
なかったらどーすんの？
あっても間違ってたり古い仕様だったらどーすんの？
ソースを読めばいいとでも？
flagという変数を使うクソ野郎もたくさんいるぞ。
せめて何のフラグかコメントしとけば読みやすくなる。
なぜかコメントを邪魔なものだと思ってる人も多いが、
実際は逆なんだよ。
百利あって一害なしだ。 295仕様書無しさん2017/05/29(月) 05:43:38.85
296仕様書無しさん2017/05/29(月) 07:33:21.71
>>294
仕事でコード書いたことないんだろうな
コメントはコードと同期しないし
コメントを書き換えるのが面倒だからと変な修正をする奴も居る
プライベートのリポジトリ以外ではコメントを禁止した方が良いぞ 297仕様書無しさん2017/05/29(月) 09:41:38.70
>>296
カスしかいない職場で働いてるんだな
かわいそうに 298仕様書無しさん2017/05/29(月) 10:49:21.36
基本、自分も含めてカスだと思う事が不具合を出さない工夫だと思うけどな。
コメントとコードが一致しないなんてのは普通にあるから、むしろコメントを書かないって選択も有効
299仕様書無しさん2017/05/29(月) 11:21:21.91
一致してないなら直してやれよ
と思うんだけどなぁ
まぁめんどくさいのはわかるけどさぁ
300仕様書無しさん2017/05/29(月) 13:25:50.85
>>299
一応言っとくが、コメント直しても試験やり直せよ？ 301仕様書無しさん2017/05/29(月) 13:48:23.46
>>300
やり直すわけないだろ
バカか？
コメント消したらなぜか動かないとかいつの時代だよ
ていうかビルドと自動テストで十分なレベルだろ 302仕様書無しさん2017/05/29(月) 14:14:10.84
いまどきは修正したコードが通るパターンを通すだけだからなぁ～。
303仕様書無しさん2017/05/29(月) 16:25:07.47
てか、IDE使ってるならコメント行非表示にする機能あるだろ？
邪魔だと思ったら表示しなければいいだけ。
なんかさ、一部の勘違い野郎は自分が基準で周りも自分に合わせてくれると
思ってるみたいだが、そんな考え方してると仕事できないだろ。
周りを自分に合わせようとするのはやめれ。
自分が周りに合わせなよ。
304仕様書無しさん2017/05/29(月) 16:43:03.00
>>303
> 周りを自分に合わせようとするのはやめれ。
> 自分が周りに合わせなよ。
両方バランス良くあるべきだと思うよ
クソな環境は可能なら正すべきだし、微妙なラインは妥協すべきだろうし 305仕様書無しさん2017/05/29(月) 20:18:00.65
ドキュメントコメントからXMLを生成する
そのXMLにはデータやスクリプトが埋め込まれてる
それらがないとまともに動かない
そんなクソシステムを保守させられて以来コメントを見ると吐き気や頭痛に襲われるようになってしまった
306仕様書無しさん2017/05/29(月) 23:18:59.39
>>301
あほか
ソースファイル更新したら試験は必須
お前、働いたことすら無いだろ？ 307仕様書無しさん2017/05/29(月) 23:39:30.13
>>306
よっぽど暇と人がある部署でダラダラと働いてるんだね 308仕様書無しさん2017/05/29(月) 23:44:13.82
>>307
いまどきテストじゃなくて試験(笑)って言ってるアレな人だから、あんまり刺激するなよ 309仕様書無しさん2017/05/30(火) 00:28:18.23
phpunitとかjunitに通すってことじゃない？
310仕様書無しさん2017/05/30(火) 00:41:09.87
311仕様書無しさん2017/05/30(火) 00:41:48.68
312仕様書無しさん2017/05/30(火) 01:09:20.53
>>305
俺はPL/SQLで頭痛がする（1関数5000行の衝撃）
>>309
「試験」と言ってる人はおそらく業務系かつ基幹系で、年期入ってる人のようだから
「テスト仕様書記載の項目を手作業でチェックし直し」のことだろう
diff取ってコメント欄しか変わってないならテスト不要だろうが
版管理使ってない所なら誤爆タイプ（ソースを探してるときになんか a とか誤タイプしちゃうアレ）の
チェックって意味でやってもいいかも
俺だったらgitかsvnでローカルに保存しといてdiff取ると思うが
現場によっては勝手にアプリ入れるな、申告しても「そんなツールはダメ」の場合がある
diffっつかWinMergeの類すらもダメ（だからフォルダ別保存でdiffも取れない）
まぁそんな環境ならコメント直しただけでもテストやり直しってのはあるかも
その手の現場で「試験とは不具合を見つけるのが目的、検査表が一回目で全部〇になるのはおかしい」
とか言われたの思い出したことあるな
事前にテスト用コード書いて流して直したりしたんでエラーないのわかってたんだが
以後無作為に1～2コ×にして、二回目欄に〇にするとかやったな 313仕様書無しさん2017/05/30(火) 01:45:08.77
> その手の現場で「試験とは不具合を見つけるのが目的、検査表が一回目で全部〇になるのはおかしい」
理屈はわからなくはないけど、じゃあ検査表が全部○になるのは
だいたい何回目ぐらいですか？って聞きたくなるな。
試験が不具合を見つけるものであるならば、
試験より前に不具合を見つけるのはやったらいけないのか？
試験より前に不具合を見つけなければ、
それは何十回も試験しなければ全部○になることはないだろう。
どうせその工数入れてないくせに
314仕様書無しさん2017/05/30(火) 02:25:20.86
>>313
なんかよくわからんが、そこの検査表は確か5回目まで欄があったから
あの会社では5回までミスることがあったんだろう
xxxxxをドコソコに入れると何とかと表示されること | × | 2009/3/23 | 〇 | 2009/3/24
yyyyをドコソコに入れるとホゲホゲの値が入ること | 〇 | 2009/3/23 |
みたいなフォーマットだったかな、たしか
まぁ一発書きして適当に手入力で値入れて、そっからテスト仕様書見て動かしてたんじゃないか？ 知らんけど…… 315仕様書無しさん2017/05/30(火) 02:29:49.56
だいぶ昔か、俺も年食ったな……なんかハンコつくだけでカネがすげぇ入ってくる仕事ない？
あったらカネもらって万札握りしめてサーバラックとか買いに行っちゃうよ
316仕様書無しさん2017/05/30(火) 08:19:37.84
せめてコメントちゃんと書いてくれれば
開発の能率がだいぶ上がることはみんな分かっているはずだと思うが
どうやら「ソースで読む」ことを楽しんでいるようだｗ
317仕様書無しさん2017/05/30(火) 08:56:21.61
コメント不要って言ってる人たちは、コメントがいらないということを主張したいんじゃなくて、
コメントいらないくらい綺麗なコードを書いてる自分アピールなんだよ
そりゃ自分で実装したコードなら、無茶苦茶な英語で関数や変数の命名してても、コメントなしで読めるよねっていうw
318仕様書無しさん2017/05/30(火) 08:57:31.63
>>310
じゃぁ試験って英語の単語はなんですか？
>>314
NE○だろ
そこの子会社に派遣されてた頃、本部から押し付けられたてたっぽい
かれこれ数年前の話だな 319仕様書無しさん2017/05/30(火) 09:38:20.77
コメント修正くらいじゃコンパイル結果の比較くらいしかしないなぁ。
で、なぜか一致しないんだよなw
320仕様書無しさん2017/05/30(火) 19:19:02.02
>>318
英語と日本語が一対一だと思ってるのか？
鱒は英語でなんて言うか知ってる？ 321仕様書無しさん2017/05/30(火) 21:32:52.48
>>320
めんどくさいやつだな
プログラミング系なんて英語圏から来ている文化なんだから、
独自文化でもない限り英語で定義されてるだろうに
英語わからないなら、日本語でいいから違いを説明して見てよ 322仕様書無しさん2017/05/31(水) 00:47:15.70
>>321
日本の品質管理は英語圏とは全く違うんだが。。。 323仕様書無しさん2017/05/31(水) 07:27:11.26
「僕ちゃんは絶対正しいの！白いカラスはいるの！！」
プログラマーってこんなんばっか
324仕様書無しさん2017/05/31(水) 07:32:05.79
325仕様書無しさん2017/05/31(水) 07:57:05.70
326仕様書無しさん2017/05/31(水) 09:28:55.22
アルビノからすか。
327仕様書無しさん2017/05/31(水) 09:33:17.25
ソースコードと同等レベルに詳細な設計書だって何の意味があるのか分からない
それソースコードで良くね
328仕様書無しさん2017/05/31(水) 09:39:10.74
>>327
客からすればなんの意味もない
提供する側としては余分に金をもらえるチャンス
同じ金額でそのドキュメント作らされるならふざけんな 329仕様書無しさん2017/05/31(水) 09:47:05.57
ググッたら、白いカラスかわええなw
330仕様書無しさん2017/05/31(水) 10:13:27.98
自然界でも変わり者はイジメ頃されるんだなぁ
331仕様書無しさん2017/05/31(水) 19:14:35.54
>>323みたいな思い込み激しいやつが居るとプロジェクトは苦労する 332仕様書無しさん2017/05/31(水) 19:17:48.31
ソースコードを日本語に変換するツールを作れば儲かるね
333仕様書無しさん2017/05/31(水) 19:39:32.81
334仕様書無しさん2017/05/31(水) 21:30:54.62
自然言語からコードは難しいけどコードから自然言語への変換はそうでもないんじゃないかな
構文木からコードを生成するのと同程度の手間で自然言語を生成できるはず
めちゃくちゃ機械的で読みにくいドキュメントになるだろうけど
設計書原理主義者の言うコードと一対一で対応する設計書を作る唯一の手段だと思う
335仕様書無しさん2017/05/31(水) 21:39:22.05
>>334
設計書原理主義者ってなんだ？
コードと一対一で対応する設計書ってのも初めて聞いた
設計書が書けなすぎて仮想敵を作りだしてしまったんじゃないかお前？ 336仕様書無しさん2017/05/31(水) 21:47:51.25
>>335
過去ログを読めばわかるけど
時々いるんだよそういうのがね 337仕様書無しさん2017/05/31(水) 22:39:50.63
日本のSI系は無駄にドキュメント量が多い。
昔から疑問だったのだが、皆それが合理的だと思っているの?
因みにUSのエンタープライズなプロジェクトを数年やっていたのだが文化が全然違う。
フローを説明すると、初期の詳細設計フェーズでのドキュメントは説明用のパワポ数枚程度で、
アーキテクトと呼ばれる人達が直接コードを書き始める。
設計の説明に関係ない所はモックかインターフェース定義のみになっていて、
データ構造の定義も含まれる。プロジェクトが本格稼働しエンジニアが増え始めると、
アーキテクトはコードを書かなくなりコードレビューに回るという流れ。
ドキュメント類(データ構造仕様書、API仕様書,etc.)は基本ソースコードから出力される。
日本的な人月換算で言うと1000人月位のプロジェクト規模かな。
(それ以上に大きくても小さくても基本的には同じフロー)
日本のSIerが上記の様な開発ができないのは何が問題?
338仕様書無しさん2017/05/31(水) 22:48:48.61
>>337
日本ではコードを書けないクズが指揮をとるからね 339仕様書無しさん2017/05/31(水) 22:53:47.11
いきなり詳細設計から始められる程度に単純な仕事しか経験がなかったら
そら「設計書いらねー」ってなるわな
無理もない
340仕様書無しさん2017/05/31(水) 22:57:56.15
小さい規模の案件でもいきなり詳細設計は無理だろ
コードを書きながらリファクタリングしながらドキュメントを書かないと整合性取れん
341仕様書無しさん2017/05/31(水) 22:59:14.33
まだお前らウォーターフォールモデルで開発してんのか
342仕様書無しさん2017/05/31(水) 23:06:55.84
>>339
じゃあその「単純じゃない仕事」と類似したUSの事例を調べてみてくれ。
それともUSには「単純な仕事」しか無いとでも主張するのかな?
因みにコミュニケーションコストが日本の方が高いという事もない。
何故なら向こうでは人種も宗教も多様なので、
日本的な"常識"を元にしたコミュニケーションが通用しない。 343仕様書無しさん2017/05/31(水) 23:11:05.28
>>337
コード書いた経験がないか極端に少ない人間が上に立つからだよ。
彼らは自分でコード書いたことある人なら誰でも分かってることを理解していない。
だから、客から聞き取った要件をどうコードに落とすか想像できない。
設計書というのは要件をどう実現するかという書類なのに、
コード書いた経験がないから意味不明なものになってしまう。
俺は必ず彼らが書いた設計書をリライトするようにしている。
そうしないと、俺の下で働いてる若手が設計書と何時間もにらめっこすることになるからね。
日本もエンジニアがもっと認められて出世しないとダメだと思ってるよ。
そのためにはコードだけ書いてちゃダメで、経営のことも勉強しなきゃならないけど。
大変やね。 344仕様書無しさん2017/05/31(水) 23:23:38.88
自分は日本のSI系はまだ競争が穏やかだった為、合理化圧力が緩かったと考えている。
ただ昨今の人手不足や労働時間規制で合理化圧力が高まっているので、今後健全化する方向に進む可能性も有るかな。
345仕様書無しさん2017/05/31(水) 23:24:18.01
>>332
富士通のいんでぶとか、あるっちゃあるよ
仕様書と辞書（単語をコードに変換する規則集）を突き合わせてコードをゲロるの
内容に関しては、みずほの件でお察しください
>>337
極端に言ってしまえば日本では「仕様書」にこそ価値があると考えられているから
あるいはコードそのものは単なるパンチカードの紙切れと同じものだ、とでも言うべきか
まあ実際のところそこまで極端な表現をしやしないし、コードもある程度は大事ってのはわかってるんだが
すんげー強調した言い方だと「仕様書のほうが価値が高い」と判断する人は発注元には多いんじゃないだろうか
仕様書をパンチャーに渡せば同一品質あるいは同一内容のコードが出てくるはず、と
メインフレーム時代からそういう価値観を育んできたわけ
日本は世界一速くメインフレーム時代に突入して、世界一長くメインフレーム・オフコン時代過ごしたんで
どうしても昔流の文化ってか「机上の設計が大事」の文化が抜けきらないし
たぶんあと100年くらい「設計書が大事」主義からの脱却はムリじゃねえかな 346仕様書無しさん2017/05/31(水) 23:31:17.50
いつまでもグズグズ言ってないで少しはSEの人を納得させられる設計書書く努力したら？
所詮お前らはコードを書いて設計書でっちあげるだけの派遣コーダーなんだから
人間、身の程を知るって大事な事だぜ
347仕様書無しさん2017/05/31(水) 23:33:41.74
今の国内SIerの競争力の無さを考えると100年とか待ってたら
他業種の競争力を支えるはずのSIerが逆に足を引っ張って日本ごと沈没しそう
348仕様書無しさん2017/05/31(水) 23:36:45.57
3493452017/05/31(水) 23:45:48.95
時折「マなんかバイトで十分、SEは設計だけするべき」論の人がいるのは
設計書さえあればSEが想定した品質のコードが上がってきて当然（＝コードには価値がない）
って論調が一定数存在する証拠でもある
問題は、アセンブラがもっと高級な言語に切り替わってしまった時点で
設計書（まあ日本語とかフローチャートのアレ）とコードが1対1で対応しなくなってしまい
設計書が単なる「意識合わせの書類」に化けてしまったことだが……
350仕様書無しさん2017/05/31(水) 23:52:41.09
大した実力もないPGが、SEさえいなければうまく回るって声を大にして主張してんの笑えるな
なんかの受け売りで熱くなってるんだろうけど、身の丈に合った発言しろやw
3513452017/05/31(水) 23:56:20.31
>>350
俺のことか？
業務系のドキュメント書きタスクの負荷が重い理由を
説明しようとしているだけだが 352仕様書無しさん2017/06/01(木) 00:12:03.95
>>350
冷静に非合理的なフローに対する分析もできない頭とは可哀想。
所で、日本のSIerに勤めた事が無いせいかPG/SEという区分にも違和感を感じる。
System Engineerって本来保守サポート要員の事なので、
日本以外でSEと名乗るとかなり軽く見られるので注意。 3533452017/06/01(木) 00:41:55.96
まぁ日本には「仕様書に価値がある」ということで
Σプロジェクト（コードジェネレータ + 専用OS・ハード開発）を試みてオオゴケしたとか
日本は世界に先駆けて積極的に業務でコードジェネレータ使ったとか(主に金融とか自治体のフレームワーク用）
そういう独特の文化がある
日本のSIにおけるドキュメント重い問題の解決策は今のところ
「仕様書からコードを生成する超高速開発ツールの使用」以外ないと思う
まぁ「超高速開発」のアレはAccessのアレ程度の機能しかないんで
規模が大きくなるとみずほになるが
354仕様書無しさん2017/06/01(木) 00:43:47.52
んだよフレームワーク用て……メインフレームだろ……ワロス……orz
355仕様書無しさん2017/06/01(木) 00:44:37.29
356仕様書無しさん2017/06/01(木) 00:47:45.59
>>353
仕様書からコードを生成するには
仕様書が機械可読で曖昧性が全くない状態でなければならない
そこまで行くともう生成するまでもなくコードだよね 357仕様書無しさん2017/06/01(木) 00:58:39.56
自然言語からプログラミング言語を出力するという発想がなー
そもそもステートマシンを記述するための形式言語ではない物で記述しようとすると
機能が大幅に限られるか、記述量が膨大になるかの何方かだからな
形式言語にすると実質プログラミング言語になるし
要件を入力してコードを出力するAIが登場すると変わるだろうけど
そんな物が登場したら、そもそもその過程で社会の有り様が変わるので
SI業界がとかそういった問題では無くなるなw
358仕様書無しさん2017/06/01(木) 00:59:37.79
>>356
実際のところ、特定の単語とクラス定義をセットにして
コードゲロったりCREATE TABLEったりして、Insertしてデータ中出しする程度の話
ちょっと変なことするなら独自のスクリプトを書く
仕様書でイジるのは文字数とかその辺
たとえば、仕様書に「給与」って単語が出たら、給与テーブルおよびそれをCRUDするクラスとメソッドが
データ辞書からコピペされる
あとはAccessのあの図よろしく主キーとか引っ付ければできるよねってハナシ
よくある詳細設計書のフォーマットで書けばそれっぽいのができるって感じかな
機械可読とか曖昧性がないって計算機工学の話じゃなくって力業やで
……曖昧性については、確かデータ辞書に定義突っ込むときに類義語をハネる機能があったと思うが 359仕様書無しさん2017/06/01(木) 01:03:56.56
>>357
「限られる」のほうやね
例えば「あなたへのオススメ: ドラッガーを読んでも勝てないと悟った女子マネージャーが肉体を駆使したら」
みたいなレコメンドエンジンつけようとしたら死ぬと思う 360仕様書無しさん2017/06/01(木) 01:15:45.21
自然言語からのコード生成は昔から研究されていて
限界を示すある程度の証明が成された論文があった気がするのだが
どうしてそんな方向性に進もうと考えたのだろうか?よく分かってない人達を騙す用?
361仕様書無しさん2017/06/01(木) 01:24:23.02
>>360
だますというより……たぶん、相手方のエラい人にITの素養がある人がおらず
（こっちからしたら）常識のことが（相手には）理解できないので
レベルを下げに下げて下げまくって日本語でわかるように説明しなければ
カネが出てこないせいかもしれない
あるいは、日本語でそれっぽい文章がないと（相手からしたら不満点の指摘ができず）怖いのかもしれない
俺の個人的な意見だけど
一番やっかいなのは、相手の企業さんが自社の業務フローを説明できないことか
個人的にはこっちのほうが問題だと思うんだが、まぁこっちは100年どころか1000年無理かもな 362仕様書無しさん2017/06/01(木) 01:25:54.19
あー、酔っ払ってどうでもいい話を長々と済まん
……ノートPCの修理が雨で中断（傷埋めてパテ埋めまでしたが）、ここで酒を飲んだのがいけない
363仕様書無しさん2017/06/01(木) 01:26:06.80
開発者「限界は有るが少しは役に立ちそうなので作ってみた」
分かってない上司「これで全て行けるんじゃね?」
分かってない営業「これで全て解決ですよ」
分かってない顧客「じゃそれで行こう」
開発者「...」
みたいな感じ?
364仕様書無しさん2017/06/01(木) 01:30:10.20
>>363
開発者が主導ってことはたぶんないかも
あるとしたらパッケージソフトの外販だけ
内製であったとしても各部署からのご連絡が先
外からの仕事ならまず相手企業から営業にそういう連絡がある感じ 365仕様書無しさん2017/06/01(木) 02:02:28.17
めちゃくちゃな設計から目をそらしてコード生成でなんとかしようとするのって典型的なアンチパターンだよね
コード生成があるから大丈夫つって当たり前のように非正規系で大量の列がある制約がぶっ壊れたマジキチテーブルを量産するバカSEは死んでくれ
366仕様書無しさん2017/06/01(木) 06:52:05.73
367仕様書無しさん2017/06/01(木) 10:39:03.31
この問題はPG側の要因も大きい。
実際の話、いくら設計書が大切と言っても、顧客が本当に欲しいのは動くシステムなんだ。
エクセルだかワードのクソ設計書じゃない。
設計書じゃ金儲けできないからね。
「ドキュメントはいいからシステム作ってよ」
とPGに言うと、
「仕様がわからないと無理ですぅ」
となるわけだ。
つまり、俺らが顧客の要件をまとめて形にできるところまで一括してできれば、
クソ設計書の量を減らせるってわけだ。
マジでコードだけ書いてちゃダメなんだよ。
技術という殻に閉じこもって営業批判するだけじゃ、俺らの評価は低いままだ。
368仕様書無しさん2017/06/01(木) 11:40:25.95
>>367
そもそもAgile的なフローじゃ駄目なの?
日本では大規模なAgile回した経験者が居なくて厳しい感じ? 369仕様書無しさん2017/06/01(木) 11:43:30.15
ここでは一人前ぶってるけど職場ではSEの言いなりだからな
だって、できるプログラマの受け売りしてるだけだから、「そこまで言うなら責任与えるからやって成果出してみろ」って言われたらなにもできないもんねw
370仕様書無しさん2017/06/01(木) 12:03:59.15
そもそも日本的なSE/PGというroleの分けられ方がイマイチ分からないのだが意味有るのそれ?
世界から不合理とディスられまくってる日本のSIer固有文化じゃん。
今後、日本のSIerでも合理化圧力が高まるだろうから、
俺はSE/PGだからと謎のroleで自らの役割を制限しているエンジニアはそのうち困ると思うよ。
371仕様書無しさん2017/06/01(木) 12:21:36.77
>>370
自らの役割を制限しないと、なんでもやらないといけなくなるじゃんw
ただのサラリーマンなんだし、それなりに食っていけるぐらいの給料さえもらえてれば、やることは少ないに越したことはない 372仕様書無しさん2017/06/01(木) 12:24:41.40
>>370
お前が無能だからカゴに入れて飼われてるんやでコーダー君
能力があるやつはそれでも自分でカゴから出てくんねん 373仕様書無しさん2017/06/01(木) 12:43:35.50
>>371
その合理性の無いrole分けに疑問を抱かないのか?という話。
無限の役割を求める訳じゃない。
>>372
お前も日本のSIerというカゴから出てみたら? 374仕様書無しさん2017/06/01(木) 12:48:23.22
>>373
やること増やしたくない人にとっては合理的 375仕様書無しさん2017/06/01(木) 12:57:40.44
>>373
君の相談にのってあげとんのやで無能コーダー君
話をそらして自分の問題から目をそむけてたらいつまでたってもなんも解決出来んで 376仕様書無しさん2017/06/01(木) 13:11:23.38
>>368
最近はそうでもないんじゃない？
ソーシャルゲームなんかはユーザ百万人規模のシステムを延々とアジャイルで回してるからね。
俺もソーシャルゲームに関わったことあるけど、完全にアジャイルでやってると
必然的にミスが多くなるんだよ。
ゲームだったら謝罪文とアイテムばら撒いて終わりだけど、他の業種はそうもいかない。
金融機関は特にそうだよね。
いくら設計書は少ない方がいいと言っても、アジャイルはリスクが高すぎる。 3773372017/06/01(木) 13:21:04.52
>>375
無能はH1-Bとれないんやで？万が一取れても無能さらすと即クビになるしな。
まあお前には縁の無い話かもしれんけど。
しっかしまともに自らの業務の効率化の話ができる人が少ないな。
顧客の業務を効率化する事が大きなミッションのはずなのに。 378仕様書無しさん2017/06/01(木) 13:26:44.07
>>376
業務系こそAgileやで。元々エンタープライズな所から出てきた考え方だし。
分かりやすい事例も海外だと多いよ。 379仕様書無しさん2017/06/01(木) 13:44:34.58
>>378
だから案件によるとしか・・・。
小規模で責任がない案件ならいいんだけどね。
アジャイルのデメリットは品質を担保する機能が小さいかまったく無いってとこなんだよ。
だからそのシステムを知ってる人間を業務に縛りつけてしまう。
俺なんか1月1日に女房子供置いて実家から東京に始発の新幹線で戻ったこともあるよ。
しんどいぞアレは。 380仕様書無しさん2017/06/01(木) 14:35:18.31
MSやGoogleが未だに完全なウォーターフォール型で作ってるとか
そんな事はなかろう
381仕様書無しさん2017/06/01(木) 15:10:37.22
なんでお前らってゼロサム的な考え方しかできないの？
382仕様書無しさん2017/06/01(木) 16:24:24.99
完全にウォーターフォールなんて所まだ存在してんの？
ウォーターフォールって数ヶ月や数年先の事を考えて計画するんでしょ？
数年先の事まで完全に予想するなんて神でもなきゃ無理じゃね
一度作ったら作り直しが難しい建築業界はそれで良くても
ソフトウェアでそれやったら他社に置いていかれるじゃん
383仕様書無しさん2017/06/01(木) 16:24:58.23
384仕様書無しさん2017/06/01(木) 16:28:07.71
>小規模で責任がない案件ならいいんだけどね。
>アジャイルのデメリットは品質を担保する機能が小さいかまったく無いってとこなんだよ。
Agileのフレームワークってスプリント毎に見直しが入って、
プロジェクトが進行する過程で起きる様々な問題点に対応しやすい事がメリットだと思うのだが、
それによって品質に対する責任問題が起きるのって全然別問題じゃね?
っていうかフレームワーク的に問題が起きたのであれば見直しが入り是正されないといけない。
だた、日本は規模が大きく外注/派遣が多い開発では、
開発者が品質責任を主体的に果たしにくいってのは聞いたこと有る。
その様な問題の事を指している?
385仕様書無しさん2017/06/01(木) 16:49:50.76
アジャイルは日本でそれほど浸透している訳ではないので
まだまだ定義自体、人に依って違う
386仕様書無しさん2017/06/01(木) 17:08:18.13
387仕様書無しさん2017/06/01(木) 17:10:58.28
NECでさえアジャイル開発始めてきてるのにお前等ときたら
388仕様書無しさん2017/06/01(木) 17:38:43.48
アジャイルならその辺のサラリーマンPGでもいいシステムを作れるようになる
389仕様書無しさん2017/06/01(木) 17:58:46.55
>アジャイルならその辺のサラリーマンPGでもいいシステムを作れるようになる
それはどうだろう?
Agileな仕組みで回そうとしたら開発者に求められるスキルもそれなりに必要。
ただ全員高いスキルが必要なわけでもないし、ナレッジシェアもしやすいけどね。
390仕様書無しさん2017/06/01(木) 18:48:22.18
アジャイルというかプログラミングの基本である分割統治を徹底するだけだろ
丸ごと設計して丸ごと実装っていう流れがいかにアホなことか
サービスをコンテキストで分割してそれぞれアジャイルで回して行けばいいんだよ
391仕様書無しさん2017/06/01(木) 18:59:39.84
偉い人にはそれがわからんのです
392仕様書無しさん2017/06/01(木) 19:03:13.85
お前ら本当にアジャイル好きだよなwうけるw
393仕様書無しさん2017/06/01(木) 20:57:41.44
>>392
下っ端PGがなw
じゃあお前やってみろよって言われたらできないんだぜw
ま、野球見て監督の采配批判するのに野球経験はいらないからな 394仕様書無しさん2017/06/01(木) 21:34:11.77
アジャイルなんてただのプロセスだからね
導入したからってお前らの能力が上がるわけでもない
395仕様書無しさん2017/06/01(木) 22:09:26.80
電卓なんてただの道具だからね
導入したってお前らの能力が上がるわけでもない
こうですかね？
396仕様書無しさん2017/06/01(木) 22:28:13.82
むしろ今時アジャイルベースの開発を検討してない所ってヤバない?
金融系でさえアジャイル言い始めているのに
SIのレベルが著しく低い日本で上手く行くかは知らんけど
397仕様書無しさん2017/06/01(木) 23:21:08.13
うちに会社（メーカー）はウォーターフォールで開発。
アジャイルにしたらもっと良い製品作れるかな？
398仕様書無しさん2017/06/01(木) 23:28:35.01
>>397
普通にええんじゃないの?
Teslaとか車をアジャイルで作ってて上手く行ってるらしいし 399仕様書無しさん2017/06/02(金) 00:04:59.52
今日は酒入ってねえぞっと……ヤケ酒はいかん orz
>>370
SEとプログラマーは「設計者」と「パンチャー」の関係
今だと「パンチャー」ではなく「コード奴隷」とでも言うべきか
少なくとも、1次受けとかユーザーに近ければ近いほどそういう発想が優勢 400仕様書無しさん2017/06/02(金) 00:30:52.92
日本は
・顧客自身が要求仕様を書けない(業務のマニュアル化ができなさすぎるし、できる人材を雇ったり教育することはない）
・要件変更の柔軟性要求・瑕疵担保の要求がキツい
っておっそろしい状況があるので一応SE/PGの区分には合理性がある
SEは「客との折衝」と「瑕疵担保責任」を負担する
特に大規模プロジェクトではメー子か大手しか受けられない、瑕疵担保っつか遅延損害金支払い能力の有無で
PGはまぁ一応、瑕疵担保は限定的
そのプロジェクトがｇｄｇｄ過ぎたら親請けがカネよこせってことはあり得るにせよ
その代わり、親請けが書いた設計書に近いことしかできない
（「仕様書の通り」は95%くらいの確率でありえない、特にエラー処理）
設計書の文言にそう書いてるっぽいこと以外のコトをやったらこっちが瑕疵担保責任取ることになるんで
401仕様書無しさん2017/06/02(金) 00:32:54.26
ベンダー企業がウダウダやってる内に
愛想を尽かしたユーザ企業は内製化に舵をきるのであった
多分近々発表される内製化に関する話がやばば
現場のエンジニアの人にとっては悪い話ではないかも知れないけど
402仕様書無しさん2017/06/02(金) 00:36:37.00
どういやいいのかな、要件は決まってないけど品質や納期は製造業グレードの要求、が日本ではデフォルトだから
日本のSI仕事は（おそらく）海外に比べてリスクがでかい
昔だったら（銀行様がメインフレーム入れてたような時代）だったらそのリスクがペイする程度のカネにはなったが
ダウンサイジングだとかオープンがどうとかそういうので単価下がりまくってしまったので
まぁビジネスとしてはアレだわね
そりゃ介護並みの重労働・低賃金な見られ方をするわな
403仕様書無しさん2017/06/02(金) 00:57:00.98
アジャイル・コング
404仕様書無しさん2017/06/02(金) 03:04:29.18
「アジャイルはイイ！」とみんなが言うと、お前らも「イイ！」と言う
馬鹿ですか？
405仕様書無しさん2017/06/02(金) 03:55:44.20
>>404
イイというつもりはない、どっちかってとあきらめかなぁ
手戻りなしのウォーターフォールですべてが一発で動くなんてあり得ない
ずっとそうあるべきだと信じて努力したけど俺にはわからんことのほうが多かった
だから最速で結合までもっていって早期にミスを狩りだして直すしかない
その程度だと思う 406仕様書無しさん2017/06/02(金) 05:50:48.76
設計する
製造する
試験する
販売する
ウォーターフォールってこういうことだろ
基本的に不具合修正以外は試験のフィードバックなし
つまり試験で判明した不足機能の追加や品質改善はしないわけだ
対象がシステムだから誤魔化せてるけど
これが普通の製造業だったらそんなことあり得るのか？
製造業って最初に作ったプロトタイプをそのまま商品にするものなの？
普通は何度か試作品を作って検討するんじゃないの？
それってアジャイルじゃないのか？
407仕様書無しさん2017/06/02(金) 06:11:18.48
プロトタイプは上流で作成、検討されてるだけでお前らの仕事ではないというだけのこと
無理だろお前らにはwやさしい世界なんやでw
408仕様書無しさん2017/06/02(金) 09:28:18.08
>>404
自分で馬鹿な話考えて
自分の話が馬鹿だなって言ってんの？ 409仕様書無しさん2017/06/02(金) 11:49:46.87
俺らの一番悪いとこは自分は優れてる、自分が正しいと思ってることだよね。
410仕様書無しさん2017/06/02(金) 12:21:14.88
>>409
誰しもそんなもんさ
上司の悪口言ってるサラリーマンなんてごまんといるが、そいつらがその上司のポジションに就いたとき何ができるかというと、
無能呼ばわりしてた上司と似たり寄ったりw 411仕様書無しさん2017/06/02(金) 12:27:03.89
民主党の悪口はそこまでだ
412仕様書無しさん2017/06/02(金) 12:34:20.55
そういう教育を受けてきたのだから仕方ない
お前らが悪いんじゃないよ
お前らのアタマは悪いけど
413仕様書無しさん2017/06/02(金) 20:11:25.18
>上司の悪口言ってるサラリーマンなんてごまんといるが、そいつらがその上司のポジションに就いたとき何ができるかというと、
>無能呼ばわりしてた上司と似たり寄ったりw
ピータの法則ってのがあってだな...
http://ja.wikipedia.org/wiki/ピーターの法則
要するに、例えばエンジニアとして優秀であっても管理職として優秀とは限らないだろ?
しかし、優秀なエンジニアであったが為、組織の中で"出世"してしまい無能な管理職になってしまう(可能性が高い)。
そこら辺を分かっている企業であればキャリアパスとして、職位(給料)とroleを分けていて、
PMより給料が高いエンジニアとかも割と居たりする。
因みにそういったキャリアパスがある企業は日本だと、
エンジニアの質が競争力に直結する自社サービスで食べている様な企業が多いかなー。あと外資系全般。 414仕様書無しさん2017/06/02(金) 20:43:04.08
>・顧客自身が要求仕様を書けない(業務のマニュアル化ができなさすぎるし、できる人材を雇ったり教育することはない）
>・要件変更の柔軟性要求・瑕疵担保の要求がキツい
USでも基本顧客は要求仕様を書けない。ただ昨今は内製化が進んで有る意味変わってきたが。
仕様変更が多いのも同じかな、だた瑕疵担保は違う。
瑕疵担保に対するリスク負担の割合が所謂SE/PGを分けているという事であれば、
SEと呼ばれるroleは元請け企業を頂点に受託報酬が少なくなっていく順で
少なくなって行くはずだが、そんな感じの構造だっけ?
415仕様書無しさん2017/06/02(金) 20:50:37.65
>>413
うわ、知ってることぐだぐだ説明されちゃったよ 416仕様書無しさん2017/06/02(金) 21:03:31.39
>>406
Agileと言っても最近は色んなフレームワークが有って、製造業向けの物はソフトウェア開発向けの物とは違う。
ただ、Teslaとかは製造ラインも柔軟に組み替えられる仕組みがあって、ソフトウェアの開発プロセスに近い。
因みにAgileの重要要素の1つとして、メンバー全員のタスクやvelocityの可視化、
プロジェクトの問題点の改善プロセスがあったりするのだが、
その過程で無能やサボりが明らかになるという副次効果がある。
自分は評価の厳しいUS企業で体験したのだが、無能には割とドラスティックな対応が入ってて色々凄かった。
日本であれを適用するとSE/PG問わず阿鼻叫喚になりそうw(雇用規制が邪魔してできないだろうけど) 417仕様書無しさん2017/06/02(金) 21:10:14.23
ベロは関係ないだろ！
ふざけんな！
418仕様書無しさん2017/06/02(金) 21:23:46.11
>ベロは関係ないだろ！
velocityは個人の能力に関係がないと言いたいのであれば、基本的にそれは正しいのだけど、
同じチームで相対的に著しく低い場合はやはり関係有る。
もちろん改善プロセスや可視化されたその他諸々との総合評価だけど。
419仕様書無しさん2017/06/03(土) 00:06:06.58
舌がなんだって？
420仕様書無しさん2017/06/03(土) 01:02:35.18
無能を排除しない
有能を評価しない
ジャップランドのなにがダメかってこういう基本的なところだよな
ウォーターフォールとかアジャイルとか実は大して関係ないんだわ
421仕様書無しさん2017/06/03(土) 01:47:48.30
422仕様書無しさん2017/06/03(土) 09:20:06.26
解雇規制なんか撤廃されて
みんなクビになっちゃえ！
423仕様書無しさん2017/06/04(日) 05:11:47.17
>>414
自治体案件だとそんな感じ、大手SIerが高値で契約を結び、
それっぽいキックオフをやり、
その後下請けか孫請けが安値で臨時に招喚される 424仕様書無しさん2017/08/25(金) 07:00:59.17
設計書要らないってヤツに聞きたい
テストの基準は何？
納品物に指定されていたらソースの後で作るの？
レシピなしで料理したり
設計書なしでビルを建てたり
まともなものが早く作れるんですか？
新人ＰＧってどの程度のスキルの人を指しますか？
結局書けない書きたくない得意じゃないいわゆる苦手なヤツが
もっともらしい理由付けてやろうとしないだけなんじゃないの？
425仕様書無しさん2017/08/25(金) 11:26:48.75
>>424
一口に設計書と言われましても、それが指す範囲が広すぎてなんとも 426KAC2017/09/14(木) 00:58:23.04
>>424
プロジェクトによる。当然仕様の決定は必須だが、
たとえばスーバープログラマが概要作って
周りのプログラマが肉付けしていくような開発なら、
「設計書」という体裁の文章は残らないこともあるだろう。
(企画書や仕様書は当然インプットとして残すだろうが)
設計書が本当に必要かどうかはプロジェクト依存。
「設計をメンバーに周知させる手段の一つ」と考えるのが無難だろ。
少なくとも、コンシューマ向けのプログラムで
客から設計書の開示を求められることはありえないんだから。 427仕様書無しさん2017/09/29(金) 15:50:24.32
スレタイレベルの設計書が本気で開発に必要だと考えてる会社なら、残業ハンパないのは容易に想像できる。
428仕様書無しさん2017/09/29(金) 16:37:22.56
>>427
そういう設計書を作るの込みで見積もってスケジューリングしてるから、残業が多いかどうかはまた別の話。想像力足りないんじゃないの？ 429仕様書無しさん2017/10/06(金) 04:12:43.40
>>1みたいな設計書嫌いじゃないぜ。
ちゃんと解読すればテスト項目が完璧に書けるのだからな。 430仕様書無しさん2017/10/06(金) 08:10:53.72
>>429
設計書ってテスト項目が完璧に書けるのが当然じゃね？ 431仕様書無しさん2017/10/06(金) 12:01:35.06
今時そんな非効率なことやってる所あんの？
432仕様書無しさん2017/10/06(金) 12:19:33.54
>>431
ないよ。詳細設計書という用語自体もはや死語だし。 433仕様書無しさん2017/10/06(金) 12:22:05.78
>>429
i++; //iに1を加算
この粒度の項目でもいいのか？ 434仕様書無しさん2017/10/06(金) 15:19:02.92
詳細設計書がいるところでは先にコード書いてデバグ済んでから設計書作るんだろ？
435仕様書無しさん2017/10/06(金) 19:43:03.83
まあコード説明書だよね
436仕様書無しさん2017/10/06(金) 21:58:14.26
コード説明書がコードと同じ細かさだったらコード説明書説明書が要るだろ
437仕様書無しさん2017/10/07(土) 21:59:27.76
コード説明書があったら読むの楽だからいいなぁ
438仕様書無しさん2017/10/07(土) 22:28:42.78
細かく日本語に訳しても間違った設計は間違ってるんだよな
ユーザーインターフェースの設計書にデータアクセスの仕様が細かく書いてあったらどんなに丁寧に書いたってもう台無しだ
プログラムを書けない上流はそこを理解してない
439仕様書無しさん2017/10/08(日) 00:57:19.16
書く場所さえ正しければコード日本語訳仕様書もおkってことでつね
440仕様書無しさん2017/10/08(日) 01:16:43.32
でつね（笑）
441仕様書無しさん2017/10/08(日) 02:18:55.25
>>433
i = 1 # watirはスクレイピングをキメたtableのインデックスを1から始めるので殺してやりたい
今はどうか知らんけど 442仕様書無しさん2017/10/08(日) 02:36:17.02
詳細設計でどんだけ細かく書いてもエラー出るかどうかは結合やるまでわかんね
細かく書いて書いて書きまくって読み手がシクることは超ザラ
シクってたらこっちの説明の仕方が悪かったってことになるんで再連絡だろうが、遅れるとご愁傷
V字のアレなら主義まげて早期の結合テスト
アジャイルだろうがDevOpsだろうが早期に一気通貫できてるかどうかのテスト
そうでないとミスが判明しない
で、可能な限り早期に自動化しないと死ぬ
443仕様書無しさん2017/10/08(日) 07:33:58.94
>>442みたく書き手（設計書書く人）と読み手（コード書く人）が別人だとコードレベルの詳細設計書はだめだろうなｗ 444仕様書無しさん2017/10/08(日) 08:10:04.22
設計書でもDRYとかSOLIDを守らないとダメなんだよね
コーディングのスキルがない文系SEはそういうの知らないからもうめちゃくちゃ
コードをコピペで書く人は設計書もコピペだらけ
445仕様書無しさん2017/10/08(日) 12:06:05.61
>>444
SOLIDなドキュメントってどういうこと？
例えばSOLIDのDはドキュメントだとどうなるの？ 446仕様書無しさん2017/10/08(日) 12:20:30.21
447仕様書無しさん2017/10/08(日) 12:51:34.17
448仕様書無しさん2017/10/08(日) 19:26:56.93
>>442
自動化考えるプロジェクトがソースコードレベルの機能仕様書作るだろうか？作るのかな。わかんないが。 449仕様書無しさん2017/10/08(日) 21:50:34.15
コードレベルの仕様書って意味あんのか？
客が見てもわからんだろ
コードを書いてバグを取り除いてから仕様書に移した方がいい
450仕様書無しさん2017/10/08(日) 22:32:42.50
そもそもコードレベルの仕様書って客に見せるもんじゃないだろアホ
451仕様書無しさん2017/10/09(月) 07:55:17.42
客に見せないならコードレベルの設計なんかいらん
最初からコードを書けばいい
452仕様書無しさん2017/10/09(月) 08:41:42.96
ある言語で完成されたシステムを他言語に移植する仕事で、元の言語のコードをそのまま張り付けた詳細設計書は見たことあるｗ
453仕様書無しさん2017/10/09(月) 09:10:24.65
>>452
貼り付けた後に日本語訳なら弊社でよくやってるよ
アホくさ 454仕様書無しさん2017/10/09(月) 17:30:44.97
>>452のようにプログラム言語で書かれているものがあるならそのソースコードを詳細設計書にするのはありだろうな。 455仕様書無しさん2017/10/09(月) 17:54:18.38
レガシーシステムが業務に対応しきれてないからモダンな環境に移行して保守性を獲得しようって案件だと完全に失敗なんだけどそれ
456仕様書無しさん2017/10/09(月) 20:23:12.39
Excelスクショと同等のIT業界の悪夢
457仕様書無しさん2017/10/09(月) 20:26:08.87
スクショ地獄は自動化フレームワークのおかげでだいぶ楽になったよ
あんなの手作業でやるのは日本企業だけだろうね
458仕様書無しさん2017/10/09(月) 20:32:50.11
459仕様書無しさん2017/10/09(月) 20:35:13.03
>>458
金になるならいくらでも撮りますよ
損するのは日本企業だけだし 460仕様書無しさん2017/10/09(月) 21:09:33.75
Excelスクショってなに
461仕様書無しさん2017/10/09(月) 22:44:21.43
優れたスクールショーツじゃね？多分？
462仕様書無しさん2017/10/10(火) 07:59:27.92
設計書なんかどうでもいいんだよ。早く動くの出せよIT土方ども
463仕様書無しさん2017/10/10(火) 19:22:02.95
「設計書通り」を真面目に実現しようとするとコード並みに詳細な設計書が必要
どう考えたって時間の無駄だわ
464仕様書無しさん2017/10/10(火) 19:24:17.39
設計書並みにアバウトなコードを書けばいいだけやんか
465仕様書無しさん2017/10/10(火) 19:28:10.99
ザル設計をそのままコードにしてバグが出ると設計書通りに書けって文句言われっからなぁ
設計書をコメントでコピーして1行1行翻訳していけばいいのか？
466仕様書無しさん2017/10/10(火) 20:30:28.37
そりゃお前のコードにアバウトさが足りんのと違うか？
ちゃんと設計書通りのアバウトさにしないから叱られるんや
467仕様書無しさん2017/10/10(火) 20:36:50.85
仕様書の通りを厳守してエクセルをプロジェクトに追加して納品
468仕様書無しさん2017/10/11(水) 00:49:35.68
>>410
陰口叩かれる順番が順当に回ってくるだけだよなw 469仕様書無しさん2017/10/11(水) 07:40:17.11
上司が無能の原因の7割は部下が無能で動かす手足がないからだもんな
無能集団じゃ誰がリーダーやったって変わらんよ
日本の政治を見ればわかるだろ
470仕様書無しさん2017/10/11(水) 16:37:43.20
仕様書通りにコード書いてテスト部隊に回したらいっぱい指摘されて泣きそう。てか泣いた。
471仕様書無しさん2017/10/11(水) 19:37:39.32
仕様書通りなのにいっぱい何を指摘する事があるんだその無能テスト部隊は
472仕様書無しさん2017/10/11(水) 20:37:30.16
なんか気に入らない使いにくい気がする程度の事でも障害にされる
品質管理部門とかいうお荷物
473仕様書無しさん2017/10/11(水) 20:59:43.21
なんという狂ったプロジェクトなんだw今すぐやめるべきだろそんなとこw
474仕様書無しさん2017/10/11(水) 21:14:41.34
コーダーどもは品質管理の言うことを黙って聞いていればいいんだよ
475仕様書無しさん2017/10/11(水) 21:33:30.54
満を持して品質管理気どりのテスター登場w
476仕様書無しさん2017/10/11(水) 22:32:36.04
で、出たー手動テストしかやる事ないやつ
477仕様書無しさん2017/10/11(水) 23:22:01.07
外部発注された品質管理のためのコードレビューってのがあって
大量のプログラム未経験者と一緒にぞろぞろと参加した
何十人もいたけど
Insertメソッドが一度に一行しか登録できないことに誰も気が付かず
くっつけたらまったく動かなかったらしい
478仕様書無しさん2017/10/11(水) 23:28:12.87
上は上で規約を提示してしつこく言っときながら
フォーマットの誤りをツールで洗い出して全部指摘した会社があったんだけど
ありがとうございますすごいですねーとか言いながらそこが真っ先に切られた
結果レビューで規約を気にするものは誰もいなくなりましたとさ
がんばって一杯指摘はしたが、一体何の仕事をしたのか今もってわからない
479仕様書無しさん2017/10/11(水) 23:33:05.02
お前がそのツール作ったのかｗ徒労だったなｗ
480仕様書無しさん2017/10/11(水) 23:58:43.09
うちでも似たようなツール作ったけどリーダーが空気読んで
先にお伺いたてて指摘にはのせなかった
その会社はきっちりやってたように見えた、
ただ欠点といえばそこのリーダーの顔が今でいうコミュ障っぽくてたよりなさそうだったんだ
そのときに世界の不条理を学んだ
481仕様書無しさん2017/10/12(木) 00:10:40.14
482仕様書無しさん2017/10/12(木) 00:15:29.56
そうか
規約はチェックされないのか
いいことを聞いた
483仕様書無しさん2017/10/12(木) 07:25:59.27
アホな規約作って紙出しして一人で必死に規約レビューやってるバカもまだこの世には存在するから気をつけろよw
484仕様書無しさん2017/10/12(木) 08:13:50.51
>>472
それは仕様バクだから仕様書変更しろよ？ 485仕様書無しさん2017/10/12(木) 15:20:39.23
夢でも食ってろ
486仕様書無しさん2017/10/12(木) 19:30:41.97
>>484
もちろん派遣のプログラマが直すよ
俺らはチェックして可否を出すだけ 487仕様書無しさん2017/10/12(木) 19:47:01.50
レビュアーが詳細設計書を基準に指摘する気力がなくなるぐらい
仕様書ガン無視して要件定義から実装
488仕様書無しさん2017/10/12(木) 19:54:18.07
>>487
そういうのは読まずにNG出していいルールにしておくと捗るよ
誰にでもわかるコードはレビュアーにもわかるコードでなければならない 489仕様書無しさん2017/10/13(金) 16:36:13.56
スレタイ通りの詳細設計書があるなら>>487みたいなのが許されるはずがない。 490仕様書無しさん2017/10/13(金) 19:58:12.45
必殺知らんぷり
491仕様書無しさん2017/10/13(金) 22:20:07.98
インタプリタに与えると動く仕様書
ビルドすると実行可能ファイルができる仕様書
ビルドすると特定の言語のソースコードができる仕様書
ソースコードを日本語化した設計書と認められるのはこの三種類のみ
もちろん自然言語の日本語で書かれてる前提ね
492仕様書無しさん2017/10/14(土) 16:16:25.00
どんなに詳細設計書を書いても動かすたびにおかしい動きが見つかる。
493仕様書無しさん2017/10/14(土) 16:40:29.89
バグ報告
プログラムを使いデバッグ
プログラムの修正箇所を特定する
仕様書の1対1に対応する箇所を修正する
プログラムの1対1で対応する箇所を修正
(あくまで仕様書の変更を元にプログラムを修正するので、デバッグで得た知識が無くても修正できなければならない)
プログラムをテスト
仕様書とプログラムを同時にマージ
アホくさ
494仕様書無しさん2017/10/14(土) 17:32:57.07
>>493
お前は今二つの嘘をついたな
すぐにわかっちゃうんだそういうの
嘘1：仕様書
真1：プログラム設計書
嘘2：アホくさ
真2：ボクは無能だからバグが多すぎて設計書まで直す時間がないよぅ～ 495仕様書無しさん2017/10/14(土) 17:41:28.75
仕様書は広義に設計書の事も含む
アホくさ、が正しい
496仕様書無しさん2017/10/14(土) 17:52:55.75
有能な人がこんなネタスレに書き込むわけがない。
497仕様書無しさん2017/10/14(土) 17:59:48.58
回帰テストめんどくさいから詳細設計書で完璧にバグ出さないようにしろよな
498仕様書無しさん2017/10/14(土) 18:00:59.65
白紙の設計書と空のプロジェクトを同期させる
あとは変更を二重に適用管理するだけ
ん？これもう片方だけでいいんじゃないの？
499仕様書無しさん2017/10/14(土) 18:16:25.86
>>498
なんかうまい事言ってるつもりらしいけどどうしてそうなるのさサッパリ理解できんwすまんなw 500仕様書無しさん2017/10/14(土) 18:34:30.53
501仕様書無しさん2017/10/14(土) 19:03:42.97
>>499
設計書とプログラムは1対1
なので設計書に加える変更とプログラムに加える変更は等価
最初に白紙の設計書と空のプログラムを用意したので設計書とプログラムは常に等価
等価ならどちらか片方だけであればおk 502仕様書無しさん2017/10/15(日) 05:10:28.01
>>1のいう設計書ってどんなの？
1～nまでの和を出す要求だとどんな風に書くのかしら？ 503仕様書無しさん2017/10/15(日) 09:12:17.25
>>502
nを引数として受け取って総和を返却する関数
1.変数「ループカウンタ」を1で初期化する
2.変数「総和」を0で初期化する
3.変数「ループカウンタ」が引数「n」以下である間以下を繰り返す
3-1.変数「総和」に変数「ループカウンタ」を加える
3-2.変数「ループカウンタ」をインクリメントする
4.変数「総和」を返却する 504仕様書無しさん2017/10/15(日) 09:29:17.65
>>503
パッケージ
クラス
メソッド名
引数名
型
設計書なんだからもっと正確に書けよ 505仕様書無しさん2017/10/15(日) 09:49:02.88
506仕様書無しさん2017/10/15(日) 10:02:41.51
>>505
は？じゃないよ
書けよ
設計書なんだろ？
なんで必要な情報が書かれてねえんだよハゲ
お前はメソッドの中身だけコーディングしてコンパイル通ると思ってんのか？
冗談じゃないよまったく 507仕様書無しさん2017/10/15(日) 10:05:00.66
>>503
その現場で
return Enumerable.Range(1, p).Sum();
なんて書いたらレビューで揉めるなｗ 508仕様書無しさん2017/10/15(日) 10:09:58.68
>>507
コードレビューにて
バカ「そのコードはダメだ」
天才「何がダメなんでしょうか？」
バカ「読めない人がいる」
天才「今はコードのレビューでしたよね？」
バカ「どういうことだ？」
天才「読めない"人"がいるわけですよね？」
バカ「だから何だ？」
天才「コードに問題が有るのではなく、人に問題が有るということですよね？」
バカ「！？」
天才「コードのレビューをしましょうや？その能力がないのですか？」 509仕様書無しさん2017/10/15(日) 10:10:49.24
おっと p じゃなくて n か。すんまそ。
510仕様書無しさん2017/10/15(日) 10:18:34.95
>>508
おれ天才じゃないけどその言い返ししてみたいｗ 511仕様書無しさん2017/10/15(日) 10:37:59.11
>>507
うちの上司だったら設計書との対比が取れていないので分かりにくいって絶対に受け入れないだろうね
設計書そのものがすでに分かりにくいのは見て見ぬ振りだ 512仕様書無しさん2017/10/15(日) 10:39:27.16
>>507を読めない人ってアスペだろw
見たまんまじゃん 513仕様書無しさん2017/10/15(日) 10:52:05.07
いや対比の例としてだされたお題からずれてしまってる>>507がガチアスペw 514仕様書無しさん2017/10/15(日) 11:04:08.71
515仕様書無しさん2017/10/15(日) 13:27:59.55
今時の言語に沿ったコードレベルの日本語詳細設計書書ける人材が必要だなw
516仕様書無しさん2017/10/15(日) 14:11:30.15
sum = sum + 1;
これををパースして
assign(
var("sum"),
add(
var("sum"),
const(1)
)
)
こんな構文木を作る
辞書に{ "sum": "合計" }を登録する
構文木を文字列に変換する
const(1) -> 「1」
var("sum") -> 「合計」
add(a, b) -> 「aとbの和」
assign(a, b) -> 「aにbを代入する。」
つまり
「「合計」に「「合計」と「1」の和」を代入する。」
という文字列に変換する
同じ考え方で変換規則を作り込んで行けばソースから日本語の仕様書を生成することができる
誰か作ってくれ
517仕様書無しさん2017/10/15(日) 17:20:46.45
エクセル設計書って大量の小さいクラスと相性悪いよなぁ
クラスをシートで分けるとシート数大杉だし
ファイルで分けると開くのめんどくさすぎ
518仕様書無しさん2017/10/15(日) 17:24:18.00
>>517
Excelかどうかじゃなくて、大量の小さいクラスをいちいち設計書に起こしてるのがバカすぎw 519仕様書無しさん2017/10/15(日) 17:28:00.24
>>518
設計書とコードが同期してないとレビューで袋叩きのズタボロにされる 520仕様書無しさん2017/10/15(日) 17:30:28.42
大量の小さいクラスに向いた設計の表現方法はないの？
521仕様書無しさん2017/10/15(日) 18:02:58.66
522仕様書無しさん2017/10/15(日) 19:13:18.63
523仕様書無しさん2017/10/15(日) 19:40:32.07
524仕様書無しさん2017/10/15(日) 21:35:51.18
525仕様書無しさん2017/10/15(日) 22:15:06.32
規約にはしないけどレビューで指摘したら直せよ
526仕様書無しさん2017/10/15(日) 22:59:35.81
もちろんですとも現作業終了後ただちに直します
（テストさえ通ってしまえばこっちのもの）
527仕様書無しさん2017/10/15(日) 23:04:05.31
レビュアーがマージするからレビュー指摘クリアしないといつまでたっても終わらんぞ
528仕様書無しさん2017/10/15(日) 23:08:03.74
そこまでヒマなレビュアーはあんまり見たことない
529仕様書無しさん2017/10/16(月) 09:53:25.70
>>526
ソースコードレビュー完了より先にテストっておかしくないかい？ 530仕様書無しさん2017/10/16(月) 15:53:23.86
>>525
わかりました。レビュアーを修正します。 531仕様書無しさん2017/10/16(月) 17:50:25.89
532仕様書無しさん2017/10/16(月) 23:35:25.61
ウォンリーを探せ！
533仕様書無しさん2017/10/17(火) 03:50:36.05
>>524
バカが読めないコードはダメって規約ができるのかよw 534仕様書無しさん2017/10/17(火) 18:58:21.45
あれ使うなこれ使うなって使用禁止令が
535仕様書無しさん2017/10/17(火) 21:22:01.43
>>534
バカが読めないコードが全部使用禁止になるのか 536仕様書無しさん2017/10/17(火) 21:28:48.45
規約とはトレードオフでどちらかに割れるようなお題を片方に寄せるためのものだと思ってた
でも現実には誰もがその判断は間違ってると思っていても逆らえないただの足枷になってしまっている
537仕様書無しさん2017/10/17(火) 21:59:56.23
半年間くらいずっとExcelとWordで似たようなコピペ設計書を作る日々を繰り返したことがあるが、
結局その設計書が使われることは無かったな
基本クラスの仕様が少し変わる度に数千あるファイル全て手直ししないといけなくなったので
538仕様書無しさん2017/10/17(火) 22:12:19.00
シート[受注]
継承元: 無し
状態変数:
受注番号(文字列(20))
受注日(年月日)
明細(受注明細のリスト)
処理:
受注額取得:
入力:無し
出力:受注額(金額)
処理内容:
明細から(単価*数量)を選択して合計して返す
設計書ってこんな感じでいいんじゃないかな？
みんなどう書いてるの？
5395382017/10/17(火) 22:14:43.14
これに加えて綺麗に罫線を引くと見栄えも完璧
540仕様書無しさん2017/10/17(火) 22:36:19.54
>>538
1行を10行にするつもりで書いてたわ
おっさん連中は文字が沢山あると嬉しいらしいです
処理内容：
① 合計値を格納する変数totalを宣言する
② ①で宣言した変数totalに0を代入する
③ 明細リストをループする処理に入る
④ 明細から単価と数量を乗算し、①で宣言した変数totalに加算する
⑤ ③明細リストのループが終了
⑥ 変数totalを戻り値に代入する
⑦ 関数を終了する 541仕様書無しさん2017/10/17(火) 22:55:53.66
ちょっと聞かせてもらいたいのだけど、商用製品で仕様書や設計書無しで他人に製品評価させるってありなのか？
遅れているじゃ無くて作る予定が無い
5425382017/10/17(火) 22:57:14.62
5435402017/10/17(火) 23:48:17.35
>>542
分かりづらいだろ？
更にソースに連番で①～⑦まで処理別に書くんやで
// ① 合計値（ｒｙ
int total;
// ② ①で宣言（ｒｙ
total = 0;
以降続く・・・
半年後、大炎上した 544仕様書無しさん2017/10/17(火) 23:49:02.61
あ、なんかトラウマで吐き気が・・・寝よう
545仕様書無しさん2017/10/17(火) 23:53:02.74
インターフェースって設計書に書くと拒否されるから別の言い回しないかな
546仕様書無しさん2017/10/17(火) 23:54:26.00
入出力
547仕様書無しさん2017/10/17(火) 23:55:24.61
548仕様書無しさん2017/10/18(水) 00:24:39.20
機能
549KAC2017/10/18(水) 00:40:25.31
>>538
それは設計書じゃない。
設計書ってのは、「設計した」結果が記載されるものだ。 550仕様書無しさん2017/10/18(水) 06:22:38.28
551仕様書無しさん2017/10/18(水) 07:55:46.69
設計書は標準的なコーダーが施工すれば同じコードが仕上がるようになっていなければならない。
したがって>>1以外の設計書はありえない。 552仕様書無しさん2017/10/18(水) 08:04:25.46
パンチカード時代の話ですか？
553KAC2017/10/18(水) 12:50:50.21
>>550
そうなら、「設計ができていない」と判断するしか無い。 554仕様書無しさん2017/10/18(水) 19:11:48.14
「やろうと思えば機械的にソースコードに変換可能」が設計書の定義だろうね
機械的にソースコードに変換できないということは曖昧さが残っているということだ
曖昧な設計は設計ではなくただの妄想
555仕様書無しさん2017/10/18(水) 19:31:20.64
どうせコードが設計書とか言いたいだけでしょw
556仕様書無しさん2017/10/18(水) 19:32:03.08
つまりスレタイみたいな詳細設計書は無駄ということたな
557仕様書無しさん2017/10/18(水) 19:37:20.06
設計書自体は無駄でもそれを書かされてるお前らの苦労を見る事が上流の人達の娯楽になり
結果上流の人達のパフォーマンス向上に貢献する事になる
やっぱりソースコードを日本語訳したレベルの詳細設計書は必要悪なんだよ
558仕様書無しさん2017/10/18(水) 19:46:58.40
抜け毛が増えてきた
いやだ
ハゲたくない
だれか助けてくれ
559仕様書無しさん2017/10/18(水) 20:20:39.17
>>557
設計書は生成してるんだなぁ
工数なしで費用だけ頂いてすいやせんね 560仕様書無しさん2017/10/18(水) 20:21:08.73
そうやっていつも他力本願だからハゲるんだよ
561仕様書無しさん2017/10/18(水) 20:28:17.33
562仕様書無しさん2017/10/18(水) 20:33:14.70
切っても剃ってもハゲはハゲ
563仕様書無しさん2017/10/18(水) 21:03:09.78
ハゲないためにDNAというソースコードを修正せねばなるまい
564仕様書無しさん2017/10/18(水) 21:13:13.44
DNAは設計書
その証拠に欠陥だらけだ
565仕様書無しさん2017/10/18(水) 21:19:09.87
DNAにどれだけ無数の欠陥があろうともハゲだけは受け入れる事はできない
566仕様書無しさん2017/10/18(水) 21:32:33.27
ハゲに人権なし
567仕様書無しさん2017/10/18(水) 22:09:53.46
>>558
ハゲはどうせ帰っても抜け毛を数えるぐらいしかやることないだろうから、毎日終電までサビ残して経済に貢献しろ 568仕様書無しさん2017/10/18(水) 22:15:06.16
ハゲだが帰宅したら楽しいクッキングタイムだ
抜け毛を数えてる暇はない
569仕様書無しさん2017/10/18(水) 22:18:13.06
570仕様書無しさん2017/10/18(水) 22:25:01.41
ポジティブなクッキングハゲｗ
571仕様書無しさん2017/10/18(水) 23:19:22.43
料理に毛が入ってそう
572仕様書無しさん2017/10/19(木) 06:13:58.68
ハゲをいじめるのはよくない
573仕様書無しさん2017/10/19(木) 07:17:31.60
ソースと対の詳細設計書はもちろんソースコード一行一行にもコメント書くんやで
574仕様書無しさん2017/10/19(木) 07:46:09.81
シェルスクリプトを書けるようにならないといけなくなって、本を一冊買った
サンプルコードの一行一行に、これはなにをしているというのがコメントで書かれていた
ありがたかった
575仕様書無しさん2017/10/19(木) 07:52:27.42
>>573
メソッドドキュメントコメントにも詳細な処理内容を書かなきゃ 576仕様書無しさん2017/10/19(木) 22:29:58.97
>>574
マジレスすると、それはコードの意味がわからない人に
一行一行「説明してくれる」のがありがたいのであって
一行一行「コメントしてくれる」のがありがたいわけじゃない
コードが読める人＝例えば英語が読める人
に対して、一単語ずつ意味を説明されてもうざいだけ 577仕様書無しさん2017/10/19(木) 22:49:51.85
別にうざくないけど
578仕様書無しさん2017/10/19(木) 22:59:47.22
>>576
お前のようなできるプログラマでも、そんなダサいコメントだらけのコードに関わることがあるのか？ 579仕様書無しさん2017/10/19(木) 23:10:30.51
>>578
そりゃあるだろ？
一人でプログラミングしてるわけじゃないんだ。
十数年前の学生の頃に、そんなコード書いていたやつがいたんだよ 580仕様書無しさん2017/10/19(木) 23:22:58.36
すべての行にコメントがついてるアセンブラコードとかあったな
581仕様書無しさん2017/10/19(木) 23:48:15.07
>>579
十数年前のことをよくもまぁ飽きずに何度も語れるもんだw 582KAC2017/10/19(木) 23:51:23.83
583KAC2017/10/19(木) 23:53:57.26
詳細設計書がしっかりしてるならコメントは不要。
少なくとも、このスレでコメント云々語るのはすれ違い。
584仕様書無しさん2017/10/20(金) 00:35:57.93
>>581
一回しか語ってないが、何度も語ると、何か問題が有るの？ 585仕様書無しさん2017/10/20(金) 06:02:18.22
コードがしっかりしてれば詳細設計書は不要
586仕様書無しさん2017/10/20(金) 12:25:31.97
だがしっかりしたコードはこの世に存在しないので詳細設計書は必要
587仕様書無しさん2017/10/20(金) 22:16:28.54
設計書はさらにしっかりしていない
588仕様書無しさん2017/10/21(土) 00:14:32.04
しっかりしろよ？な？
589仕様書無しさん2017/10/21(土) 00:56:33.91
詳細設計って何を指しているんだろう？
機能仕様の下位に位置するドキュメントかな？
どんなにコードがしっかりしていても、プログラム全体を把握するドキュメントは必要と思う。
ブロック図、シーケンス図、状態遷移図等。
590KAC2017/10/21(土) 02:25:10.36
>>589
詳細設計という概念が考えられた時代を考慮に入れるとおのずと解る 591仕様書無しさん2017/10/21(土) 06:33:38.80
ビルドコストランコストが高すぎたんだ
だから設計書を書くしかなかった
つまり現代では不要
592仕様書無しさん2017/10/21(土) 06:41:36.35
>>589
殆どのシステムはコンテキストマップがあればあとはコードとドキュメントコメントで十分
概念が複雑なものはUMLに頼らずそれを表現する的確なモデルを作る
例えば剛体シミュレータを作るのにUMLは最適解じゃないだろ
まず必要なものは物理数学モデルだ 593名無しさん＠そうだ選挙に行こう！ Go to vote!2017/10/22(日) 13:39:16.26
ValueObjectを使うようになると設計書は要らなくなるな
というか同期するの大変だからむしろ設計書が邪魔になる
594仕様書無しさん2017/10/22(日) 23:03:17.29
訳のわからない言い訳ばかり言ってないで設計書書け底辺共
595仕様書無しさん2017/10/22(日) 23:22:59.85
今時になって設計書なんか書いてる底辺がなんか言ってる
596仕様書無しさん2017/10/22(日) 23:44:41.58
>>593
じゃあ今まではValueObjectを使ってなかったがために設計書が必要になってたのか
意味わからんなw
どういう設計書を書いてたんだよw 597仕様書無しさん2017/10/22(日) 23:54:55.54
>>596
そうだよ
ValueObjectを使っていなかったから基本的な型のロジックがあちこちに分散して制御不能になってた
それを設計書でどうにかして誤魔化そうとしていた 598仕様書無しさん2017/10/23(月) 02:32:58.82
Value Objectって言いたかっただけだろ。
はやくフローチャートを書く仕事に戻れよw
599仕様書無しさん2017/10/23(月) 18:51:21.76
誰も読まない設計書をサビ残で仕上げてこそ底辺プログラマ
苦痛を与えることに意味がある
600仕様書無しさん2017/10/23(月) 18:56:13.87
詳細設計書は誤字脱字なく書け
コード一行にコメントを書け
メソッドドキュメントコメントには処理フローを書け
だから、みなし残業60時間用意しとるんやからな
601仕様書無しさん2017/10/23(月) 19:34:04.93
>>600
自動生成できるものに数倍の工数を使えて嬉しいね
楽して稼げるから下請けとしては助かりますわ
え？手書き？またまたご冗談を… 602仕様書無しさん2017/10/23(月) 19:37:42.65
自動生成遅っwwww
ゼンマイ式コンピューターでも使ってんのか>>601の会社はw 603仕様書無しさん2017/10/23(月) 20:07:51.34
せ、セロリン？ってやつ使ってます
604仕様書無しさん2017/10/28(土) 15:27:16.31
機械的にソースコードに変換可能
か
ならばそれをコンパイルすれば？
と笑ってしまうww
605仕様書無しさん2017/10/28(土) 15:56:25.70
某社の製品でエクセル設計書をプログラムに変換可能とか宣伝してたから文書読んだら
形式固定の表データからコード生成&ビルドするだけで笑わせてもらった
エクセルVBAと大差ない
606仕様書無しさん2017/10/28(土) 16:09:33.89
笑うポイントがおかしい人ってキモいよねw
607仕様書無しさん2017/10/28(土) 16:13:58.69
>>606
笑うというか苦笑したってところかな
君に対してね 608仕様書無しさん2017/10/28(土) 19:01:43.26
笑うポイントがおかしい自覚がある人にアンカされとるwキモw
609仕様書無しさん2017/10/28(土) 21:12:15.38
まあ便利な｢言葉｣ではある
610仕様書無しさん2017/10/29(日) 01:43:34.94
「神掛かりのパフォーマンスを出すモノを見た」が
「どうやってそれを実現したのか私にはわからない」から
「形式を模倣」することに徹する
に陥るのはこの世の常じゃあないのか？
で、最終的には見た目バンザイと
611仕様書無しさん2017/10/29(日) 01:47:57.16
個人的にコードジェネレータを勧めたいひとは
「ぶっちゃけあなた同じ事やってるんでしょ」かつ
「それでメシ食えてるから今後もずっとそれをやっていきたいんでしょ」のうえ
「相手がいうことは正しいか間違ってるかを知りたいんじゃなくて、個人的にキモチイイ見え方かどうかだけが価値判断基準の人」かなぁ
つまり、プログラミングとか好きじゃないのね、でも立場上ブログラマとかSEの類なんス
そういう条件そろってる人割と多いからコードジェネレータ勧めることよくある
612仕様書無しさん2017/10/29(日) 08:47:24.23
設計書の通りにプログラムを書けと言って上流から渡される細かすぎる(その割に誤算だらけの)設計書に対する皮肉として
設計書の通りで本当に動くならコードジェネレーターでも作ればいいんじゃね？と皮肉で返したのが始まり
本当に設計書からコードを生成しようとは別に誰も考えていない
613仕様書無しさん2017/10/29(日) 08:52:34.70
そもそも設計書の通りにコード書けるならコード要らなくね？
設計書からマシン語作れば解決
614仕様書無しさん2017/10/29(日) 08:54:41.76
コードを読めない人の為に設計書を書く
なら解らんでもない
615仕様書無しさん2017/10/29(日) 09:01:24.46
設計には業務知識だけでなくプログラミングの領域の要素も入ってこざるを得ない
プログラミングの素人がリポジトリとかサービスとかインターフェースとかパッケージとかイベントとかインフラストラクチャーとかコントローラーとかビューとか言われたとして果たして正しく理解できるだろうか
プログラムを読めない人は設計書も正しく読めない
そんな人は最初から相手にするだけ時間の無駄だ
616仕様書無しさん2017/10/29(日) 09:07:17.81
バカ上司「プログラムをそのまま日本語したものが設計書だ。
お客様はプログラムは読めないが日本語化したものなら読める」
僕「識別子を日本語化してキーワードをマクロで日本語化すれば素人でも読めるってこと？」
バカ上司「うるさい。設計書は納品物なんだから文句言わず作れ」
617仕様書無しさん2017/10/29(日) 12:13:22.80
なんだ、ただの「上司に意見しちゃう俺」アピールじゃん
618仕様書無しさん2017/10/29(日) 18:53:08.50
>>616
おまえの意見は正しい
問題はこのあたり
・プログラム言語固有の識別子や型宣言、演算子
・複雑な末端アルゴリズム
・ローカル変数
このへんをクリアすれば本当に読めるはず 619KAC2017/10/29(日) 20:26:44.28
>>616
それはお前が詳細設計書というものを全く理解できていないだけ。 620仕様書無しさん2017/10/29(日) 20:33:14.49
>>619
詳細設計書はゴミ
こんなゴミをありがたがる連中はプログラミングを理解してない 621仕様書無しさん2017/10/29(日) 20:48:28.20
詳細設計なら
変数の型を端折れるし
XXを取得するってかいたらローカル変数とGetXXで二回XXを書かないでもすむし
定数の名前とか逆に具体値とかその場で決める必要ないし
先に詳細設計書いたほうが楽じゃないの？
622仕様書無しさん2017/10/29(日) 20:53:34.47
>>621
曖昧になってあっという間に破綻する
まさにゴミ 623仕様書無しさん2017/10/29(日) 21:12:47.66
名前と動詞を統一しとけばそんなに破綻しないよ
経験上だけど
破綻はおもに必要な情報の不足から起こる
設計書はXXを作成するとかって結果から書いていって順々に中と必要な情報詰めていくかんじ
コード上だと最初から必要な情報洗い出されたうえで引数決めて書く必要があるから
下位でこれたりねーってなったら、上位メソッドまで全部変えなきゃいけなくなる
破綻を見つける能力はコードに劣るけど破綻を回復する能力は詳細設計のほうが全然上だ
624仕様書無しさん2017/10/29(日) 21:14:12.39
おまえら簡単に破綻しすぎw
625仕様書無しさん2017/10/29(日) 21:33:50.23
俺が破綻するのか
626仕様書無しさん2017/10/29(日) 21:37:02.89
何が面倒って名詞に英語の名前つけるのが一番面倒
アルゴリズム考えながら全体見通して無理のない統一された英名考えるとか
俺には無理だ
外人はこんな苦労しなんだろうな
627仕様書無しさん2017/10/29(日) 21:51:33.31
>>623
ほらな
やっぱりわかってない
OOPはボトムアップだよ
必要なものがなければその場で作ればいいだけ
疎結合だから他への影響も心配ない
トップダウンで機能分割していく手続き型じゃこうはいかない
一個破綻したら全部持っていかれる
そして世の中の殆どの設計書は手続き型の方法論を踏襲して書かれるものだ
だから簡単に破綻する
ゴミなんだよ 628仕様書無しさん2017/10/29(日) 21:55:06.47
必要な情報が欠けてても開発を進められるのがオブジェクト指向の最大の利点
いわゆる決定の遅延って奴だな
これがあるからアジャイルが成立する
全部決めてから着手なんて頭の悪いやり方はオブジェクト指向ではやらない
そういうのはCOBOLとかでやればいい
設計書も同じこと
そういうのはCOBOLでやってくれ
629仕様書無しさん2017/10/29(日) 21:55:39.82
>>627
OOPがインターフェースの情報不足をどう解決してくれるのかさっぱり見当がつかない
そもそもボトムアップでコード作れるのは先にトップダウンで設計書き下してるからこそじゃないの？ 630仕様書無しさん2017/10/29(日) 22:04:31.71
>>629
インターフェースが変わるなら修正すればいい
なんのためにリファクタリングツールが発展したと思ってるんだ
一度書いたら直さないなんて腐った発想が全てを台無しにする
そんなのは一筆書き戻りなしの制約をつけて巨大迷路をクリアするようなものだ
>>629
OOPでも全体を俯瞰するときにはトップダウンで考える
例えばそれはコンテキストの境界を考える場合だ
しかし手続き型のアホどものようにコード全てをトップダウンで解析するようなバカな真似はしない 631仕様書無しさん2017/10/29(日) 22:13:59.08
インターフェースのリファクタって
一番自動でできないとこじゃんかー！
嫌だやっぱ先に詳細設計かく
632仕様書無しさん2017/10/29(日) 22:18:01.99
>>631
アホか
お前の使ってる開発環境は静的解析もできない欠陥品かよ 633仕様書無しさん2017/10/29(日) 22:24:13.57
インターフェースは実装と切り離されてるからむしろリファクタリングは非常にやりやすい
これからレガシーシステムのリファクタリングやりますってなったらまず真っ先にインターフェースで実装の結合を分離して手を出せる状態を作り出す
リファクタリングとインターフェースはサイモンとガーファンクルのデュエットのように相性バツグンなんだよ
やったことない奴には一生わからんかもしれんがそういう奴らは一生スパゲティCOBOLでも啜ってればいい
634仕様書無しさん2017/10/29(日) 22:25:53.80
インターフェースの中身を挿げ替えるのはそりゃ簡単ですよ
635仕様書無しさん2017/10/29(日) 22:30:09.23
>>634
インターフェースは責務が明確で余裕があるからコントラクトを変えるのも簡単
コントラクトを変えなくてもアダプティブに変更できる場合も多い
インターフェースを使わないと中身の変更も大変だし
コントラクトと中身が結合してしまうからコントラクトを変えることも難しくなる 636仕様書無しさん2017/10/29(日) 22:46:58.15
コントラクトってなに
OOPに幻想もちすぎじゃないの
責務の範囲を区切ったって結局実装するメソッドは手続きの中で考えないと
責務を全うするためにいらんメソッドまでいっぱい実装する羽目になって余計工数かかるし
インターフェース自体を変えなきゃいけないってなったら影響範囲半端ないし
作り終わったあとのリファクタはやりやすいかもしれんが、
作りながら破綻がみつかりしだい改修とか作る片手間にやれるこっちゃない
OOPだと余計詳細設計重要なイメージしかないんですが
637仕様書無しさん2017/10/29(日) 22:55:29.29
>>636
要するに君が下手くそなんだよ
実装が手続き汚染されるのは手続き脳から離れられないから(頭が硬い)
責務を全うするのにいらんメソッドなんかない
インターフェースがあるから影響範囲を最小化できる
ダメージが軽微なうちから修正しながら進めるから修正コストが最小化される
OOPに必要なドキュメントは詳細設計書ではなくストーリー 638仕様書無しさん2017/10/29(日) 22:57:41.13
要らないメソッドってむしろ手続き型の方が多いだろ
トップダウンで分析するから細部まで手が回らず似たようなメソッドを何度も何度も作る
あっそうか手続き型の連中はメソッド書くんじゃなくてコピペするのか
そりゃメソッドが増えないわけだよ
639仕様書無しさん2017/10/29(日) 23:05:23.45
全てを結合するまで破綻していたことに気が付かない
それがトップダウン手続き型の開発手法だ
ノコギリで素材を直感に頼り切り分けてそのまま雑にくっつけて家具を作るようなものだ
しっかりしたもの作るならそうじゃない
ヤスリがけなどで加工して寸法チェック強度チェックなど部品単体としての欠陥がないか確かめながら無理のないように組み上げるだろ
それがOOPによるコーディング設計術の心得な
640仕様書無しさん2017/10/29(日) 23:05:28.05
なんか掛け声は威勢いいけど
言ってることに具体性なさすぎて何言ってんかわからん
641仕様書無しさん2017/10/29(日) 23:07:24.37
>>640
抽象的な思考力がないのはOOPやる上で致命傷 642仕様書無しさん2017/10/29(日) 23:08:36.00
酒でもくらいながら書いてんじゃないよな
643仕様書無しさん2017/10/29(日) 23:31:58.27
どうせOOP言いたいだけだろ。
644仕様書無しさん2017/10/29(日) 23:33:11.29
負け惜しみの捨て台詞頂いたんでここらで終了ですかね
645仕様書無しさん2017/10/30(月) 08:28:43.81
>>644
おまえは二度と来るな。
ここは手続き型言語で（誤った意味での）ウォーターフォールをやるとこ限定なんだよ。 646仕様書無しさん2017/10/30(月) 18:41:37.51
スレタイ通りの詳細設計は不要かな。
障害対応時の報告資料や変更点説明資料としては有りだけど。
647仕様書無しさん2017/10/30(月) 21:55:28.13
雑に書いた基本設計の体裁を綺麗に整えて文章も畏まったふうにして詳細設計書とする
648仕様書無しさん2017/10/31(火) 07:45:41.76
かりこまりぃ～
649仕様書無しさん2017/11/02(木) 01:39:07.49
OOPは凝りだすとオーバーエンジニアリングになるきらいがあるからなぁ
650仕様書無しさん2017/11/03(金) 01:29:31.10
>>623
「コード書く前に完璧なシーケンス図書いて見せるまでコード書くな」
という詳細設計って話じゃないならいいんだけどね
元請けの要求を満たすために、「本当にそうなのか」をチェックするためにコード書いて
書類書くってこともあるので、午前3時に
APIリファレンス眺めてこれでいいのかっつってテキトーな図書いても絶対そうならないんで……という奴 651仕様書無しさん2017/11/03(金) 10:39:25.81
きっちりレビューした詳細設計書が降りてくるのならいいのだが、
作ったもの動かしてもらって「XXの場合の処理がおかしい」などという指摘が飛んでくるとレビュアー百回死ねと思う。
652仕様書無しさん2017/11/03(金) 11:26:54.71
>>651
それは製作中に問い合わせて言質とっとかないと。 653仕様書無しさん2017/11/04(土) 01:07:17.67
最初から完璧な指摘ができるレビュアーなどいない
瑕疵が発覚したあとに責任を誰になすりつけるかの問題
654仕様書無しさん2017/11/06(月) 16:29:08.92
コーダー含めて関係者全員をレビューに集めて合議で決めればレビュー漏れはみんなの責任となる。
レビュー漏れで一番ひどい目に合うのはコーダーなんだけどな
655仕様書無しさん2017/11/16(木) 19:45:16.19
日本語ソースコードみたいな詳細設計書はコストを増やす原因
基本設計書ともソースコードとも合ってないドキュメントは悪臭放つゴミ
効率化だのなんだののたまうならまずメンテナンスのコストを下げる努力をしろ老いぼれ脳みそ
656仕様書無しさん2017/11/16(木) 21:08:57.41
>>655
お前みたいな下請けはコストのことなんて気にしなくてよろしい
ゴミを作るのにかけたコストはどうせ元請けが支払ってくれるんだから 657仕様書無しさん2017/11/18(土) 13:42:35.15
>>618
よめねーよ
素人は2重ループから理解できないわ 658仕様書無しさん2017/11/18(土) 19:13:30.65
>>657
2重ループ書いちゃうような素人がいきがんなよ 659仕様書無しさん2017/11/19(日) 16:51:00.88
>>658
書く書かないの話はしてないってことを理解できないなら素人以下だな
日本語読めないレベル 660仕様書無しさん2017/11/19(日) 19:00:46.00
>>659
読解力のない素人だなあ
あのね？キミが何を言いたいかなんて問題にしてないの？わかる？
ボクがそれなりの根拠にもとづいてキミは2重ループを書いちゃうような素人だと判断したって事よ？
日本語ってムズカシイよね素人クンw 661仕様書無しさん2017/11/19(日) 19:15:44.41
わかったけど関係ないし邪魔だから帰れｗ
662仕様書無しさん2017/11/19(日) 19:20:54.90
>>660
つまり「煽りたいだけ」ってことか
中身のないやつは俺にレス付けんなくず 663仕様書無しさん2017/11/19(日) 20:49:32.68
設計書どうでもいいからさっさと手を動かしてコード書けよ。
664仕様書無しさん2017/11/19(日) 21:36:09.13
>>662
素人認定されたから中身のない煽りって事にしたいんだろうけど
世の中そんなにキミの都合に合わせて動くわけじゃないからねえ
というかキミ只の素人というより頭の悪い素人だよね？w 665仕様書無しさん2017/11/19(日) 21:40:35.24
ないようがないよう
666仕様書無しさん2017/11/19(日) 21:43:38.69
こういうガイジは無視して
667仕様書無しさん2017/12/29(金) 18:24:36.23
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
43A84H5OM5
ブックマークへ