07/01/25 23:27:12
概要設計書、外部設計書、詳細設計書
クラス図、シーケンス図、状態遷移図、アクティビティ図
リファレンスマニュアル、レビュー管理記録、成果物リスト、・・・・・・・
アホか、、
外設した後はさっさとコーディングした方が
設計書なんかで妄想してるより何倍も多くのことが分かるっての。
で、実装とテストが終わったあとに
改めて補足のドキュメントまとめた方が明らかにソースと食い違いのないものができる。。
だいたい「ソフトウェア 設計書」でググったら
現状懐疑論ばっかじゃねーか。
2:仕様書無しさん
07/01/25 23:31:57
設計書よりも
デバッグ期間とか、発生数／対応数のグラフだけ毎日書くひとじゃねえの？
3:仕様書無しさん
07/01/25 23:37:05
>>2
そういう単純作業は派遣社員にでもやらせるのが勝ち組
4:仕様書無しさん
07/01/25 23:44:06
後から作るから問題なし。
つーか今時
＞概要設計書、外部設計書、詳細設計書
こりゃねーだろｗ
5:仕様書無しさん
07/01/25 23:50:54
製作を外注するならともかく意思疎通しやすい距離で作業するんなら、
全くもっていらないんじゃない？
6:仕様書無しさん
07/01/26 00:07:02
>1の会社はいまだにステップ数で見積もってるんだろうな…
7:仕様書無しさん
07/01/26 02:07:12
1は形式的手法も知らないDQN工員
8:仕様書無しさん
07/01/26 10:28:10
今は短納期が基本だから設計書なんて書かない。
仕様書はデータベースの定義だけあればいい
9:仕様書無しさん
07/01/26 10:34:13
1.概要設計書をでっちあげる
2.概要設計書をコピーして少し書き足す→外部設計書
3.外部設計書をコピーして少し書き足す→詳細設計書
4.1～3の成果物を大切に保管
5.DB定義書と機能メモをもとに実装
なんてことを、ここ数年続けてる。
10:仕様書無しさん
07/01/26 20:29:26
実際には外部に発注する以外作った設計書の使い道がない。
ただ、ISO9001の審査を通すために毎回作ってる。
11:仕様書無しさん
07/01/27 01:18:56
ドキュメントは重要だが、たいていは客に提出するドキュメントを作った時点で
力尽きてしまい、開発用のドキュメントがおざなりになってしまう・・・
12:仕様書無しさん
07/01/27 09:44:05
各種ドキュメントを作成するのはいいとして、
ソースコードのほうだけ修正してドキュメントを修正しない
ということ。
コンピュータを使っているのに、
人間が手作業で対応関係を把握して、
まるで写経のようにドキュメントを更新するのは、
なんかもうアホらしい。
詳細仕様についてもJavaDocなんてアホらしかった。
書き写す元と先の距離がとても近いだけで、
結局は同じファイル上でコピペをすることになる。
ソースコード上でさえ情報を一元管理できない。
13:仕様書無しさん
07/01/27 10:13:50
俺のすごいところは何万行のプログラムでも
一度もコンパイルすることなく一気に書き上げる。
いちいち動作確認しながら作るやり方は素人
14:仕様書無しさん
07/01/27 12:14:22
>>13
天才
15:最凶VB厨房
07/01/27 12:24:50
>>1
その通りだが、本当にそんなたくさんドキュメント作ってるのけ？
16:仕様書無しさん
07/01/27 15:05:53
>>13
すごいなぁ。
自分は記憶力が足りないので何万行も頭の中に入りきらない。
きっちり把握できる分量で区切ってテストしてる。
書いてみて、コンパイルしてみて、動かしてみて
というのを数十行ごとにやっている人に、
「お前、ちゃんとわかってないで書いてるだろ?
そんなのは、たまたま動いているだけだぞ。」
なんて偉そうなことを言っている自分だけど・・・。
17:仕様書無しさん
07/01/27 22:26:08
だが、そうやって一気に書き上げられたプログラムに
何件バグが含まれているかについては一切言及されてない件について。
あれ、俺釣られた？
18:仕様書無しさん
07/01/27 23:14:59
>13
じゃあ次は cat 一発でのプログラミングに挑戦だな
19:仕様書無しさん
07/03/16 13:58:08
設計書がない方が自由にできると思われ
20:仕様書無しさん
07/03/16 18:45:09
お前等設計書が無い開発したら絶対こんな事言わなくなるぞ
現職がそうなんだが、口頭で仕様、機能追加、クライアントの言うがままを丸丸営業が持ってくる
コーディングルールすら無い
で、
「コーディングルールや要件定義書と仕様書（技術者側の）と設計書が無ければ開発しない様にしましょう。
品質管理の点からも、プロジェクトの進め方にしても開発にかかる負担を減らす事が出来ます。」
と、上に進言したら
上の人間に営業出身の奴しかいないせいか
「そんな窮屈にしたら開発の自由度が損なわれる（自分達がドキュメント書いた結果自分達の責任が露呈するのが嫌）」
「設計書のママに組んでも面白くないだろ？ウチの良い所がスポイルされてしまう（もう必死）」etc
要件定義書、設計書、仕様書は技術者の防御手段だと思っていいよ
時間掛けても書くべき、生産性云々よりも重要
21:仕様書無しさん
07/03/17 09:43:08
>>20
その通り。俺はバカだったから経験として知ってる。
22:仕様書無しさん
07/03/17 10:05:20
>>20
技術者のっていうより受注側の防御手段だろ。
23:仕様書無しさん
07/03/17 10:27:45
そこでXPですよ
24:仕様書無しさん
07/03/17 10:28:40
>>22
馬鹿だな。敵は身内にも居るんだよ。
25:仕様書無しさん
07/03/17 10:30:49
>>24
何を信用したらいいのかな？
恐いよ
26:仕様書無しさん
07/03/17 10:41:10
>>25
信じられるのは自分の力のみ。
バカ営業や、なんちゃってSEが勝手に客の仕様変更要望を受け付けてしまうことはよくある話。
紙に残ってないと責任の所在が不明確になり、結局末端に押し付けられてしまう。
27:仕様書無しさん
07/03/21 17:57:27
>>20
>口頭で仕様、機能追加、クライアントの言うがままを丸丸営業が持ってくる
論外。だが、んなことぁこのｽﾚで語ることではない。
28:仕様書無しさん
07/04/07 11:13:52
後から書く書く詐欺にあったらちょっとは考えが変わるとおもう。
発注する側に回って身に染みた。
29:仕様書無しさん
07/04/07 13:11:39
で、数年たって保守とかやらされてみそ。
設計書？メモ残ってるから見て！
ソース？バグとか変更で使ってないとこ残ってるかも？
ビルド？どーやるんだっけ？Make残ってない？え、バッチ？
ご注文は？ ∫ ／⌒ヽ …… 設計書一式。
~━⊂( ^ω^)つ-、
∧,,∧ ／／/ /_/:::::/
( ´∀｀) |:::|/⊂ヽノ|:::| ／」
/ φ口o ／￣￣旦￣￣￣／|
しー-Ｊ ／＿＿＿＿＿＿／ | |
| |-----------| |
30:仕様書無しさん
07/04/07 18:53:59
悪の組織に連れ去られる直前に博士が孫娘に託し、奪いにやって来るあまたの敵とヒーローが闘う。
それは、設計図。
31:仕様書無しさん
07/04/07 19:00:01
>>15
結構本当なのであった
32:仕様書無しさん
07/04/07 20:44:29
URLﾘﾝｸ(www.biwa.ne.jp)
ソフトウェア設計とは何か？
・プログラム・リスティングとはソフトウェア設計を表現したドキュメントです。
・多くの様々なソフトウェア設計記法は，有益なものとなる可能性を秘めています。
補助ドキュメントやツールも同様に，設計プロセスを円滑にする支援となります。しかし，
これらはソフトウェア設計ではありません。
33:仕様書無しさん
07/04/07 20:46:23
それは一部の意見だろ。
>>32には古代の暗号マクロに満ち満ちたアセンブラソースをたっぷりふりかけて煮込みたい。
34:仕様書無しさん
07/04/07 20:47:04
設計図もなしに大勢で一つの物を作れるわけが無い。
35:仕様書無しさん
07/04/07 20:49:58
>>34 それぞれがそれぞれの味付けしたソース持ち込んで闇なべ作ってたプロジェクト知ってるぞ。
無論破綻した。
36:仕様書無しさん
07/04/07 20:51:54
うちは大抵２～３人でやるような規模の小さいプロジェクトしか受けないから
結構ドキュメント周りはいいかげんだし、それで何とかなってるなぁ
37:仕様書無しさん
07/04/07 20:53:55
>>36 まあ、自分で作ったの数年たってからみてみそ。
間違っても人に投げるなよ。
38:仕様書無しさん
07/04/07 20:57:35
>>37
あームリムリ、数年も留まってないだろうから
人が書いたソースの解読から始まるなんてザラ
39:仕様書無しさん
07/04/07 21:09:46
２～３人程度のプロジェクトなら、機能分担とI/Fきっちり決めて、口頭とソースだけで済むよ。
疑問な点はその都度直接聞いて、分かったらソースに注釈で記述。
40:仕様書無しさん
07/04/07 22:47:23
だ・か・ら
そういう考え方が徹夜につながるんだよ。
割り増しもらえるからいいって？
や な こ っ た
41:仕様書無しさん
07/04/30 01:15:03
>>39
２～３人程度なら必要ないね。
42:仕様書無しさん
07/06/05 09:30:53
>>39
技量（理論の勉強と経験からの学び）のある人間で集まったら
その通りだね。ものによっては、業務フローも欲しいね。
業務遂行の道具であるシステムの目的を忘れてしまったら本末転倒だしね。
43:仕様書無しさん
07/06/08 08:17:30
まあ、この業界自己厨が多いのは確かだな。
自分さえよければ、他はどうなっても別にいいっていう糞が
その後メンテをするって事はまったく考えていないと（笑
44:仕様書無しさん
07/06/08 20:51:17
仕様書は別見積もり
45:仕様書無しさん
07/06/21 23:12:30
で、ソース以外に何も無いってのを人に分投げる、と。
46:仕様書無しさん
07/06/24 20:12:20
ｽﾚﾘﾝｸ(prog板)
47:仕様書無しさん
07/07/09 02:21:27
既存システム関連の仕事で稼動中システムの書類やソースがもらえることが
殆ど無い。ソース貰ってもメイク通らないでやんの。
何にもよこさねえで作らせるんなら新規開発した方が早いわ。
48:仕様書無しさん
07/07/09 21:22:53
ごちゃぐちゃのソースもらって頭抱えるなら、設計書もらって再設計しろのほうが
なんぼかましなことか。
49:仕様書無しさん
07/08/05 14:28:22
プロジェクト管理がしっかりできていれば、突貫、残業はそんなにないはず。
PGも、GTD、TOC、CCPMを勉強して、残業しないで済むように頑張ろう！
人生は一度きり。
マジでプライベートを充実させる時間がなかったら、後悔するかもよ。
URLﾘﾝｸ(www.amazon.co.jp)
CD‐ROM付 目標を突破する 実践プロジェクトマネジメント
大手企業、各地方自治体で続々採用!
現場で使える「プロジェクトマネジメント」のノウハウが一冊に凝縮されました。
「納期が遅れる6つの理由」をはじめ、多くのプロジェクトに共通する問題点を提示、
独自の手法によってこれらの問題を解決に導くまでを、図やイラストを豊富に使ってオールカラーで解説しています。
徹夜、寝袋、乱雑な机、いつまでも終わらない仕事……。
「こんな毎日はもういやだ!」と思っているあなたに、本書と特別付録CD-ROM(30日限定・工程管理ソフト)をおすすめします。
50:仕様書無しさん
07/08/28 01:42:31
既に手遅れになってから仕事がくることもある
51:仕様書無しさん
07/09/21 11:32:25
設計書もかけないPGは、どんなにコーディングがすごくても
アマチュアレベルだな
仕事上、設計書は相手との契約書だからな
52:基本設計書
07/09/22 00:06:16
大阪の堺筋にある株式会社●ィッツ。ここだけは就職やめとくべし。
Ｉ次長。こいつバカ。沸点30度くらいで、すぐ茹蛸みたいに切れる上に、
仕事もいい加減。自分を棚にあげて部下に八つ当たり。出向先の人も
やりにくそうだよ。自分もこいつとは仕事したくないｗ
53:仕様書無しさん
07/09/22 02:07:39
設計書の承認印をぶち破って仕様変更を押し付けてくるのは日常茶飯事ってのはおいておいて。
まぁ、ちっこいプロジェクトならフットワーク考えると無駄が多いかもしれん。
が、大きいプロジェクトだと責任分解点になるから凄く重要だと思う。
ただ、設計書もどきを作ってる作業が一番つらいな。
これ仕様どおりじゃないよね・・ってのを線表どおり工程進めたいがためだけに作成する無意味さ。
嘘の仕様書の誤字脱字指摘されて、「修正します」って・・ムナシス
54:仕様書無しさん
07/09/22 02:38:39
【IT】システム設計図の統一ガイドラインを発表…NTTデータなど開発会社9社［09/18］
ｽﾚﾘﾝｸ(bizplus板)
55:仕様書無しさん
07/09/22 03:15:26
設計書通りに作ったら動きません
56:仕様書無しさん
07/09/22 03:49:06
内部仕様書に、せめて状態遷移表ぐらい無いと
ホワイトボックスのテスト項目が作りづらくてしょうがない
57:仕様書無しさん
07/09/22 17:48:50
>>56
ソースもなしにホワイトボックスのテスト書けるのか！？
58:仕様書無しさん
07/09/22 18:32:26
>>57
56の上司「書けるか、だと？ 書くんだ！お前の首の上に乗っかっているのは飾りか？」
59:仕様書無しさん
07/09/22 18:50:00
>>58
ねつ造するくらいは出来るだけの能力は有していますが、意味が無いかと。
60:仕様書無しさん
07/09/22 21:55:53
>>57
何が言いたいのか分からんが、お前のトコでは状態遷移表書いたらソースコード書かないのか？
なんで「ソースもなしに」とか出てくるのか意味分からん。
61:仕様書無しさん
07/09/22 23:18:35
>>59
56の上司「意味？そんなものは上が考える事だ。お前は結果を残せ。」
62:仕様書無しさん
07/09/23 02:41:00
実装後に書く設計書は書くだけ時間の無駄。コード見た方が早い。
実装前に客の承認を得る意味での設計書なら必要。
>>61
おれの今の上司がそんな感じ。
人の上に立つ立場なら部下の意見に耳を傾けるぐらいの度量は持って欲しいね。
63:仕様書無しさん
07/09/23 07:26:53
>>62
実装前の客の承認を得る意味でない設計書はどうなんだ？
64:仕様書無しさん
07/09/24 02:59:31
>>63
ケースによる。
必要なときに最低限必要なものだけ書けばよい。
形式的に毎回全部を書く必要は無い。
65:仕様書無しさん
07/09/25 01:27:10
仕様確認のための設計書は書いたこと無いなぁ
ってゆーかそれならプログラマなおいらが書く時点で…
おいらが書くのは常に実装後だから
カスタマイズや保守、類似機能開発の為の仕様書だよ
うちのSEはプログラム組めないし仕様書かけないから
夢みたいなカスタマイズ受けてくるから
その指示で外注が直しちゃうと破綻すっから
日本語で読める現状ソースみたいな位置付けだ
66:仕様書無しさん
07/09/25 01:45:34
>>65
一級建築士みたいにある程度資格あってもいいのにねぇ・・
実装はできないかもしれんが、ファンタジーな絵本が上がってくる率は低くなるかと。
67:仕様書無しさん
07/09/25 23:17:15
日本のSEって存在すごくおもしろいんだな
68:仕様書無しさん
07/09/26 01:44:27
自分の漫画描いたりするもんな
69:仕様書無しさん
07/09/26 15:49:12
簡単にちゃちゃっと手を入れて作っちゃうのがいけない
簡単に出来るのね～とか思われる
70:仕様書無しさん
07/09/26 16:49:22
>>1
俺も激しくそう思うｗ
馬鹿に限って教科書通りの開発スタイルにこだわる。
そんな奴に限ってスキルが無い。
71:仕様書無しさん
07/09/26 17:05:19
>>70
ドカタ乙
72:仕様書無しさん
07/09/26 18:31:32
プログラマ崩れのSEもどきな俺はドキュメントは『メンテナンスの資料です』と嘯いてる。
クライアントの受けは悪いがな。
73:仕様書無しさん
07/09/26 18:50:06
テスト中に見つけたバグを修正するのに、バグを出した理由から始まって、腐るほどのドキュメントを書かないと、修正できない。
・・・面倒くさすぎて、みんな、バグを隠すようになったよ！
74:仕様書無しさん
07/09/26 19:43:27
構造化で作るなら、設計書なしでも大丈夫だが
オブジェクト指向で作った場合、設計書がないと
ソースが追うのが大変
（もちろん、オブジェクト指向で正しく作ってある場合で、オブジェクト指向もどきの構造化は別）
オブジェクトは一種のグローバル変数でポインター型だ
これは構造化の時も同じだが、ソースを読みにくくする最大の源因の一つ
そのオブジェクトがどのように、他のオブジェクトとどのように関係しているか
設計書が有った方が良い
75:仕様書無しさん
07/09/26 20:50:20
>>74
スキルが低いだけだろーが。木瓜。
>>73
俺も結構隠蔽してるよ。
脅威のバグ発生率９９．９９％
テスト時にバグを見つけたらこっそり修正してからテストしなおして
るからねｗｗｗｗｗｗｗ
76:仕様書無しさん
07/09/26 20:52:21
バグ発生率99.99%は脅威ですよね
77:仕様書無しさん
07/09/26 21:18:28
>>75
>スキルが低いだけだろーが。木瓜。
オブジェクト指向知らないのか？
少なくとも一般レベルのスキルは持っているが、お前のスキルは？
（俺は、別スレッドで落ちたシステムモジュールを、マシン語レベルで解析して修正するぐらいなら出来るが）
78:仕様書無しさん
07/09/26 21:43:07
>>77
バイナリ方面は何とかcoreファイル読める程度のスキルしか持ってないが、
仕様書無しなら俺は、構造化よりもオブジェクト指向のソースの方がシステムを俯瞰し易い。
79:仕様書無しさん
07/09/26 22:10:48
>>74
>オブジェクトは一種のグローバル変数でポインター型だ
オブジェクト指向で正しく作ってある場合に当てはまらないよね？
80:仕様書無しさん
07/09/26 22:15:49
俺はcaseツールでクラス図書いてスケルトン吐かせてるから、クラス図『だけ』はいつも最新だな。
ソースしかないなら規模にもよるがoopな言語は追いかけにくい。
81:仕様書無しさん
07/09/26 22:19:39
>>77
赤の他人で悪いが、>>75はスキルの高い人間の書き方ではないなぁ。
人格レベルも。
スキル低いのはいいが、それを自覚していないのが痛いんだよな。
自分の書いたクソみたいなドキュメントは役に立たないんだろうが、
優秀な人の書いたドキュメントは、凄まじく助かるシロモノなんだが、
それが理解できていない。
底辺コーダーとはかくあるべき。
82:仕様書無しさん
07/09/27 00:02:37
>>78
>バイナリ方面は何とかcoreファイル読める程度のスキルしか持ってないが、
「バイナリ方面」って何、バイナリを直接扱うのか？逆アセンブラじゃなくて？
「coreファイル」は何のために読むの？
83:仕様書無しさん
07/09/27 00:31:13
OOもどきよりもOOの方が可読性が低いと主張する
輩の集まるスレはここですか？
84:仕様書無しさん
07/09/27 08:41:32
>>82
＞「バイナリ方面」って何、バイナリを直接扱うのか？逆アセンブラじゃなくて？
>>77で「マシン語レベル」って書いてあるから、実行バイナリやらオブジェクトファイルやら
バイナリのまま解析したり編集したりするのかな、と。
＞「coreファイル」は何のために読むの？
coreファイルって、LINUXとかでセグメンテーションフォルトしたときに
メモリの内容をダンプしたファイルで、デバッグのために読むよ。
落ちた時のアドレス、コールスタックとか簡単に拾える。
まぁcoreファイルをgdbに食わす速い方が多いけどな・・・
85:仕様書無しさん
07/09/27 20:12:21
>>77
>（俺は、別スレッドで落ちたシステムモジュールを、マシン語レベルで解析して修正するぐらいなら出来るが）
>>78
>バイナリ方面は何とかcoreファイル読める程度のスキルしか持ってないが
>>78は、ダンプファイルが読める程度、これはアセンブラが出来れば普通出来る
>>77は、マルチスレッドのデバッグだから、>>78より高度かな
>>78は、後出しなんだから、嘘でも少しは高い技術を書けるだろう？
86:仕様書無しさん
07/09/27 20:40:07
よくわかんねぇけど、そこで嘘ついて高い技術書いて何になるんだ？
まぁ仕様書が皆無なら、構造化の方がというか機能分割されてる方が取っ掛かり易いだろ。
どんな機能があるかはシステムを動かしてみればはっきり分かるけど、
どんなオブジェクトがあるかは動き見ても想像までしか出来ないからな。
ある程度分かったあとならモジュール間の関係が薄いオブジェクト指向の方が詳細を理解するのは楽かね。
87:仕様書無しさん
07/09/27 21:52:51
>>86
>よくわかんねぇけど、そこで嘘ついて高い技術書いて何になるんだ？
これは>>75で、
>スキルが低いだけだろーが。木瓜。
と書いてる本人が、その相手より、後出しでスキルの無い事を書いてたから
不思議に思っただけだ
（普通、スキルが無いとバカにしたんだから、スキルが有るように書くと思っただけ）
88:仕様書無しさん
07/09/27 22:13:21
つーかさ、
一文だけでスキル判るって天才ってレベルじゃねーだろ・・・
この業界スキルあっても対人スキル持ってない奴なんて腐るほどいるだろ・・・
89:仕様書無しさん
07/09/27 22:28:29
>>75と>>78は別人
90:87
07/09/27 22:46:29
なるほど！！分った。あんがと
91:仕様書無しさん
07/09/28 10:32:13
俺は自分のチンコを30秒でイかせるくらいのスキルはある。
92:仕様書無しさん
07/09/29 00:20:17
しょうがきせいの頃は10秒くらいでいってたな
今考えるとありえんわ
93:仕様書無しさん
07/09/29 00:39:54
しょうがきせいの頃から白いもん出てた訳でもねえだろ。
94:仕様書無しさん
07/09/29 09:54:55
確かに、おまいらには仕様書はいらないな
書いても、その紙を別の事に使うだろうしｗ
95:仕様書無しさん
07/09/29 10:16:53
そもそも体裁だけ整えようとするから設計書の存在自体に疑問を感じるんだろ？
まあドキュメント自体、後回しかほったらかしにならざるを得ない状況じゃどうしょうもないかｗ
96:仕様書無しさん
07/09/29 14:47:50
設計書とソースの修正だけなら問題ないけど、
障害表、障害報告書、修正前後の画面帳票等の出力結果、横展開確認書、
さらに確認会議、とか。
こういったことに無駄が多く、生産性がすばらしく落ちる。
97:仕様書無しさん
07/10/02 22:42:56
>>96
そういうのに限って、設計はおろか
何のシステムかすらよく分かっていないような方にまで
提出しなきゃいけないんだよな…。
説明も一からだし
かなり噛み砕いた資料も添付せんといかんし…。
98:仕様書無しさん
07/10/03 16:22:49
ホワイトボックステストって、コードから起こすだろ・・・
99:仕様書無しさん
08/01/03 13:10:50
>>55
あるあるｗ
100:仕様書無しさん
08/01/03 13:56:58
ISOなんて審査員が来たときだけ辻褄合わせしときゃいいんだよ
あんなんまともにできるかボケ
101:仕様書無しさん
08/01/08 07:44:57
>>13
俺のすごいところは何万行のプログラムでも
一度もコンパイルすることなく一気に書き上げる。
しかも動作確認しないで納品する。
いちいち動作確認してから納品するやり方は素人
102:仕様書無しさん
08/01/08 08:28:30
朝から90前のレスに・・・
103:仕様書無しさん
08/01/08 10:21:46
小鳥が３歩歩くと忘れるのと同じで３行書くと
どんなものを作ろうとしてたか忘れる。仕様書は大事。
でも仕様書を何処にやったかもよく忘れる。
ていうか、仕様書がないとテストシナリオを書くという退屈極まりない仕事まで自分に回ってくる。
そういうのを他人に押し付けるために仕様書は必要。
104:仕様書無しさん
08/01/08 10:39:27
設計書は抽象化という意味ではあって然るべきだとは思う
でもソースとの乖離が問題
プログラムに設計書まで含められるような手法があればいいんだけど
105:仕様書無しさん
08/01/08 19:06:01
Windows Vista
URLﾘﾝｸ(recwav.dip.jp)
106:仕様書無しさん
08/01/08 21:09:03
亀レスだけど、オブジェクト指向を正しく適用したアプリは仕様書がないと読みづらいとか言ってたヤツは
オブジェクト指向がまるでわかってないかと。
責任の切り分け、インターフェイスの粒度の考慮、抽象化、適切な名前付け、広義のカプセル化、等を正しく行っていれば
仕様書なんてなくてもあまり問題ない。
単体テストコードもあればなお良い。
読み手がオブジェクト指向わかってなくても問題ないかどうかはわかんないけど。
107:仕様書無しさん
08/01/09 00:11:16
>>106
マジな話、研修終わったばかりでしかも出来の悪い方の新卒にも理解できる
ものを求められたことがある。
108:仕様書無しさん
08/01/09 00:14:22
全体が見えないんだよ全体が
109:仕様書無しさん
08/01/09 00:27:53
>>106
分業ができないだろ、分業が。
独りで隅から隅まで面倒見る小規模アプリならんな戯言も吐けるが。
きつい納期で中規模以上のアプリを分割して仕上げるには、どこを誰がどの程度やるのかを決めなきゃならん。
そのために設計は必要。さもないと同じような機能の関数を重複して作ったり、など無駄が出る。
ケーキのサイズがわからんのに切り分ける事はでけんよ。
110:仕様書無しさん
08/01/09 09:56:55
>>109
それ、全く別問題。
読みやすさに着目した話なんだから。
111:仕様書無しさん
08/01/11 02:14:32
>>106
＞適切な名前付け
「適切」の意味が微妙だが、「何のクラスか(とかメソッドとか)を良く表した名前」ということなら、
そんな「適切な名前」は存在しない。
みんな(プロジェクトメンバの範囲でも)に「何のクラスなのか」が伝わるような名前なんて無い。
価値観も感性も人それぞれなのに、精々単語レベルの組み合わせでで誤解無く伝わるなんて言うのは、
他人の人生をバカにしてる。(言いすぎ？)
さておき。
オブジェクト指向やら構造化やらにかかわらず
個人的には要件仕様書ぐらい無いと手の付けようが無いねぇ。
ポロっとソースだけ渡されて「理解しろ」と言われても
そのプログラムが何のためのプログラムかぐらい知っておかないと、
読み辛くて仕方が無い。
贅沢を言わないから、開発の背景、目的とシステム構成図だけでも欲しい。
表紙も目次も要らない。
A4で2ページぐらいで良いから。
ホント・・・マジで・・・引継ぎぐらいちゃんとしてください・・・orz
前任者もう居ないから誰かに聞くことすら出来ネェヨ。
俺が今何の開発してるのか、誰か教えて・・・
112:仕様書無しさん
08/01/11 06:03:05
>>111
> >>106
> ＞適切な名前付け
> 「適切」の意味が微妙だが、「何のクラスか(とかメソッドとか)を良く表した名前」ということなら、
> そんな「適切な名前」は存在しない。
> みんな(プロジェクトメンバの範囲でも)に「何のクラスなのか」が伝わるような名前なんて無い。
> 価値観も感性も人それぞれなのに、精々単語レベルの組み合わせでで誤解無く伝わるなんて言うのは、
> 他人の人生をバカにしてる。(言いすぎ？)
言いすぎ
113:仕様書無しさん
08/01/11 11:52:45
>>111
何のために人間は脳味噌があるんだ？
思考ができない人間モドキでなければ、すぐピンとこない名前でも「説明してもらったり、
勉強して推測することで、名前が表す機能を理解する」という道があるだろ。
「適切な名前」は、その理解に必要な時間を短くできるといった程度のものでよいと思う。
「誤解なく伝わる名前」に多くを求めすぎ。
脳味噌をまったく使いたくないってことか？
そんな人間モドキは、引き篭もってるのがいいと思う。
114:仕様書無しさん
08/01/11 23:37:10
>>113
＞説明してもらったり
説明のために他人の時間をいちいち使わないように仕様書があるんでしょうに、という話なんだが。
その場に説明できる人間が居るとも限らないし、推測だけでは誤解が生まれる可能性がそこそこにある。
俺自身は「誤解なく伝わる名前」に多くを求めてない。
だからこそ「ソースの理解のためには仕様書が重要なんじゃないの？」と思う。
最後まで言うと、>>106の言う「正しいオブジェクト指向」が使われていたとしても
仕様書が無かったら問題あるだろ、というのが俺の言いたかったことです。
言葉足らずですんまへん。
115:106
08/01/14 01:16:53
確かに、名前だけで意図を完璧に他者へと伝えることはできないけど、
名前とコードが組み合わさればどうだろうか？
もちろん、コードが汚ければ話にならないだろうが、
だからこそ、
＞ 責任の切り分け、インターフェイスの粒度の考慮、抽象化、適切な名前付け、広義のカプセル化
と、色々なものを挙げてある。
それと、今気づいたのだがもう一つこれに追加させてもらいたい。
それはクラスやメンバの概要を説明するコメント。
コード中のコメントは極力少ない方が良い (コメント書く代わりにリファクタリングを検討) が、
クラスやメンバの概要を説明するコメントは、あった方が良い。 (C#でいうとこのXMLコメント)
パラメータや戻り値の説明、メソッドを使用するための前提条件などもここに書く。
116:仕様書無しさん
08/01/14 01:23:37
設計書なんて後から作るもんだよ
って言う人は大抵納期を守らない
機能の箇条書きだけじゃ設計書とは言わんよな
つか完成した状態が完成してみないと分からないので
手戻りはあるは、テストはほとんどされてないわでもう…
勘弁してくださいよ先輩
117:仕様書無しさん
08/01/14 01:49:25
>>106
どんなに理想的なコードやコメントが組めても
仕様書はある方が絶対いいと思うぞ
というか最低でも業務分析フェーズで作ったものは残してくれと思う。
コードを見れば「その処理が何をやっているのか」はわかるが
「どうしてその処理が必要なのか」まではスグにはわからんよ。
118:117
08/01/14 02:15:36
ごめ、誤読した。
オブジェクト指向のコードって読みづらい・追いかけづらいから
仕様書を読ませろ、って話か。業務云々じゃなくて、
システムのアーキテクチャが理解できないってことか。
119:仕様書無しさん
08/01/14 03:00:59
>>117
ズレてたらすまん。
業務分析フェーズって企画段階でしょ？
企画→システム化で差異がでない訳無いんだからいらなくね？
受注以降フィードバックする事は無い物だし、マの納品対象でもないと思うが・・・
120:117
08/01/14 07:54:00
>>119
すまん「業務分析フェーズ」って言葉は無視してくれ。
俺が言いたかったこととは本質的には関係ない。
俺が今知りたいのは
「なんで休暇届出申請処理の“勤続年数”算出ロジックと、
貸付金申請処理の“勤続年数”算出ロジックが微妙にちがうのか」
なんだ。
ロジックを見れば、
休暇側が「申請日当日 - 入社年月日」、
貸付金側が「申請日当日の属する月の月末日 - 入社年月日-1」
になってるのは分かる。どんな処理をしてるのかはわかるんだ。
でも「なんで月末なのか」とか「なんで入社年月日から1引くのか」を
説明した文書が無いんよ。それを現場で唯一知ってたSEは大昔に辞めてて
連絡もつかないんで、結局クライアントに問合わせ中なんだが、
ドキュメントが残ってればなぁ、って思いながら書いたのが>>117だ。
こんなんだから仕様変更がし辛くてしょうがない。
121:仕様書無しさん
08/01/14 11:47:27
それはコメントに書くべきことで、外設や内説に書くのはやりすぎ。
単にソースコードレビューやってなかったツケだな。
122:仕様書無しさん
08/01/14 11:54:33
設計書書いたら後はコーダー君がやってくれる。設計書たくさん書いたから品質も最高だ！（妄想）
↓
保守や改修でスパゲティを眺めて担当者涙目。
古今東西よくある話。設計書がいかに無意味かよくわかる。
123:仕様書無しさん
08/01/14 12:06:18
OOPだー、とかほざいてクラスが増えすぎ関連性爆発に陥ってるプロジェクトも多いな。
デザパタも知らずにアーキテクチャアーキテクチャ吠えてる似非SEが多いとこうなる。
簡素で信頼できるブロックが必要なのに、水気が多すぎるうどん粉を捏ね回してるタイプだな。
124:119
08/01/14 14:43:21
>>120
その例なら要件定義フェーズの成果物でマの納品対象だと思う。
開発時の要件追加・修正がフィードバックされてないのは良くある話（単に要件定義が適当だって話っぽいが・・・）
クライアントに問い合わせ出来るだけいいよ。
世の中には要件定義書も何も残ってなくて、生ゴミ（画面足らず・一部ソース無し）しかない場合だってあるんだ。
その上、アホPM（要件非認識）が対面気にして要件再確認許可しない事があるんだから・・・
125:仕様書無しさん
08/01/14 17:28:20
>>115
中身まで読まないといけないようなら、やっぱりモジュールの一覧性悪いよ。
一通りソースに目を通しておおよそのモジュールの役割を理解しないと
システムの概要が掴めないんで、ボトムアップでしかソースが読めない。
規模にもよるだろうけど、ある既存のソースの部分を読むときには
システムにおいてどういう位置づけのモジュールなのか分かってる方が
理解し易いと思ってる。
(ここで「ボトムアップのが読み易い」という人なら、まぁ平行線だな)
ので、要件仕様書とシステム設計仕様書、もうちょい言えばクラス図ぐらいまであれば
引継ぎに掛かる時間はグッと減るはず。(まぁ仕様書の出来にもよるんだろうけど)
詳細設計レベルの話(メソッドの使い方だの)はコメントで良いと思う。
個人的には規模がデカくなるといちいちgrepすんのもしんどいから、
最初にDoxygen辺りでチョロっと一覧だけ作ることが多いけど、
詳細設計仕様書っつーほどのモンは要らないかな。
126:仕様書無しさん
08/01/15 10:10:11
>>121
> それはコメントに書くべきことで、外設や内説に書くのはやりすぎ。
> 単にソースコードレビューやってなかったツケだな。
金銭に関わる仕様なんだから、要求仕様書に書かれてしかるべき。
127:120
08/01/15 20:48:18
>>121
> それはコメントに書くべきことで、外設や内説に書くのはやりすぎ。
それって、アジャイル開発が念頭にある？
ウォーターフォールでやってきた俺にはピンとこない話なんだが。
>>124
ごめ、「業務分析フェーズ」じゃなかったか。
> アホPM（要件非認識）が対面気にして要件再確認許可しない
似たようなことは遭遇したな。「もうン年以上前の話だし、当事者も異動して
当時の経緯聞いても正確なことは分らんだろ」と言われたことはある。それでも
一応聞くだけ聞いてみたけどね・・・
128:仕様書無しさん
08/01/17 21:14:11
>>126
＞金銭に関わる仕様なんだから、要求仕様書に書かれてしかるべき。
金銭に関わる仕様だからっていうか、
システムを使用する業務の知識だからじゃないか？
本意は同じ気もするが。
129:仕様書無しさん
08/01/23 00:31:25
書き方にもよるだろうけど、改修・運用保守時に最低限必要なDocumentって何よ？
130:仕様書無しさん
08/01/23 07:05:45
>>129
契約書。
その仕事、ほんとにやるの？って。
131:仕様書無しさん
08/03/16 22:37:52
ちゃんとした設計書書かされても何故か改造や拡張の仕事の時には
元の設計書をもらえない
132:仕様書無しさん
08/06/13 10:44:23
門倉貴史「ワーキングプアは自己責任か」(大和書房)という本によると、こうだ。
「仮に、国内企業が退職する団塊世代の人たちに『継続雇用制度』を導入して(中略)団塊世代を非正規雇用として採用したほうがコスト的に圧倒的に有利になる」(p.157)
俺が爆笑したのはその直後の文。
「筆者の試算では、20～24歳と60～64歳の労働生産性には、大きな差がみられず、むしろ60～64歳のほうが20～24歳の労働者よりも平均的な労働生産性が若干高いことが観察された(0.63%程度の差)。」(p.157～158)
さすが団塊は神世代だ、20～24歳よりも何と0.63%も労働生産性が高いと認定されるなんて。
133:仕様書無しさん
08/06/14 22:12:20
お前らすごいな
俺、小規模から中規模のプロジェクトしかやったことしかないけど外部設計書、テスト指示書以外書いたことないぞ
小規模なら外部設計書しか書かないなんて普通かな
まあ一人でしか開発したことないからかもしれんが
134:仕様書無しさん
08/06/15 23:01:21
他人の作ったものをいじるとき
設計書はテストケースの網羅性を高めるために使う
でも結局はソースを読むのが一番確実なんだよな
135:仕様書無しさん
08/06/26 02:11:42
自分でアルゴルを考えてプログラミングするなら設計書なくてもいいんだけど、
他部署の人から、設計書なしにテストプログラムだけ渡されて
これを実装してとか言われて困ってます。
しかも、テストプログラムがバグだらけなんですが・・・。 せめて少しはデバッグしてくださいよ。
バグのままく見込んだらおれが怒られるし・・・
136:仕様書無しさん
08/07/08 23:12:31
日本人の大卒はおそらく
先見性・論理性・計画性にかけて飛び抜けた劣等人種
頭脳内で設計を組み立てる能力が無いのに
より具体的な設計書を作るなんで無駄無駄
137:仕様書無しさん
08/07/08 23:43:13
物を作ろうとしない奴に何やらせても無駄
138:仕様書無しさん
08/07/09 01:46:40
オレがソフトウェア開発プロジェクトを進めるうえで
必要不可欠だと感じたドキュメントはこのくらいだった。
・要件定義書（ここでDFD、E-R図も作成する）
・作業分割図（これができない＝デスマ）
・ディレクトリ/ファイル一覧（どんなファイルを作ったか網羅する）
・スキルリスト（実装技術と書いた経験がある文書、業務経験の3つが知りたい）
・コーディングルール（命名規則、使用禁止関数、コメントのルールなど）
・ユーザ向けマニュアル（PC使えない人でも読めるもの）
逆に「ここまで文書化？」と思ったのは次のようなもの。
失くすのはどうかと思うが、もうちょいシンプルにしたい。
お客さんが欲しがるなら仕方ないが、読んでくれないならやめよう。
・基本設計書（どうせ後で修正する）
・詳細設計書（ソースコード読めば分かる）
・運用計画書（GUIの管理用ツール触れば分かる情報が多い）
・画面設計書（画面みれば分かる。それよりユーザI/Fとマニュアル作りこみたい）
要するに、成果物みれば分かることの文書化に反対。修正するとムダになる。
早めに何ができるかユーザに理解させ、とっとと作ってレビューしたい。
開発メンバにできる事を把握して、納期までに何が作れるか見積もりたい。
柔軟性がないプロジェクトはメンバーの退職に繋がる。
139:仕様書無しさん
08/07/09 03:01:40
>>138
ホントにリーダ以上でやった事あんのか？
金取れんの要件定義書、ユーザ向けマニュアルだけだぞ？
まぁ、内容見る限り自社サービス系企業のPGか・・・
140:仕様書無しさん
08/07/09 21:03:30
>>139
ユーザーから金取れないから資料作らない
→後でですまですね。
開発が効率よく進む為には、ユーザーとは無関係にある程度の内部資料は必要
141:仕様書無しさん
08/07/09 22:47:46
>>140
だからリーダ以上やってないのに知ったかぶるなよｗ
142:仕様書無しさん
08/07/09 23:24:36
>>141
ユーザーから金を貰うというか、
効率よくスケジュール内に仕事が終わるために、
資料を作る方が安上がりになるから作る訳だが。
143:仕様書無しさん
08/07/10 00:42:25
こんなに仕事したら体壊すよ。
都内のPG/SEはハードすぎる。
144:仕様書無しさん
08/07/10 01:43:11
>>142
仕方ねぇな・・・
非納品ドキュメントのコストをどこから捻出するかって話だよ。
元々非納品のドキュメントを作るなといってる訳じゃないし、当然必要な物もある。
138はそのドキュメントコストを絞ってるんだから、設計？実装？テスト？リスク？
ドキュメントコストはドキュメントで一括りで管理すべき。
設計や実装にドキュメントコストが含まれてるなら問題ないが、そんな見積り方法無いだろ？
まぁ、そんな温い見積りが通る企業かも知れんがなｗ
145:仕様書無しさん
08/07/10 12:10:25
>>144
納品物に含まれてないからと言う理由で、中間作成物としてのドキュメントを作らないなんて、その場のノリで作ると噂のゲーム制作の現場でさえありえないwww
だが、毎回デスマーチ状態の携帯開発の現場では常識のようだった。
146:仕様書無しさん
08/07/10 22:29:11
日本語不自由な奴しかいねーのかよ
147:仕様書無しさん
08/07/10 23:23:22
マ板だからな
提案、見積もりからやったことあるやつは少なく、
やったつもりになってる奴はものすごく多い、
って事だろう
148:仕様書無しさん
08/07/11 12:58:49
保守も含めてトータルで考えると、生産性は落ちてない気がする。あがってもいないけどｗ
149:仕様書無しさん
08/07/11 13:07:42
>>148
ドキュメントの無いコードのメンテナンスの効率の低さは異常。
あと、エミュレータの無い組み込み系のメンテナンスも効率の悪さは異常。
ついでに、再現性の超低い不具合の改修効率の悪さも異常。
150:仕様書無しさん
08/07/12 13:04:51
新規開発で汚いソースだけ残してドキュメントを残さずトンズラこく
連中ってプロとしての自覚あるのか？
151:仕様書無しさん
08/07/12 13:10:31
>>150
仕様です。
152:仕様書無しさん
08/07/12 13:52:42
>>150
特に偽装派遣はその場凌ぎしか考えて無い奴ばっかり。
スケルトンに1行コメントで実装方針記述して渡したのに1行コメント全削除＆スパゲッティ・・・
マルチスレッドで動かない実装だったし、退場頂いて別な人に作り直してもらったよ。
153:仕様書無しさん
08/07/12 14:06:45
>>152
>スケルトンに1行コメントで実装方針記述して渡した
それは、指示の仕方を間違ってはいまいか？
154:仕様書無しさん
08/07/12 17:40:42
>>153
どう間違ってんの？
155:仕様書無しさん
08/07/12 17:45:02
>>154
ソースのコメントで作業指示www おまい最低だなwww
でもって消されたとか、当たり前だろwww 狂ってるwww
ちゃんと指示書起こせよwww
156:仕様書無しさん
08/07/12 17:59:21
>>155
詳細設計書＋指示書＋1行コメントなんだけど？
何が最低なの？どう間違ってんの？
157:仕様書無しさん
08/07/12 18:06:52
>>156
君の情報量の少なさが原因だと言う事に、今新たに気付かされたよ。
>>152 のどこをどう読んでも、設計書や指示書の類の話は出てないからね。
ま、実際そうだったんだろ？ 後付けでナニを弁解しても遅いよ。
指示書や設計書があれば、そのように実装されないという事はまず無い。
158:仕様書無しさん
08/07/12 18:24:05
>>157
設計書＋指示書は当たり前だから省いただけなんだけどさ。
まぁ、ここで理解されても意味無いし、どーでもいいやｗ
159:仕様書無しさん
08/07/12 20:38:51
>>158
スレタイ嫁 説得力無しw
160:仕様書無しさん
08/07/14 09:36:31
その設計書自体が
・スパゲッティ
・マルチスレッドで動かない実装
という可能性もある訳だが。
その１行コメントに、「エラーが起きたら最初に戻る」とか書いてあれば、
実装すればgotoとかになる訳だし。
161:仕様書無しさん
08/07/14 19:09:27
>>160
設計書にそう書いてあれば、何も問題無いんじゃね？
162:仕様書無しさん
08/07/29 01:12:57
じゃぁお前は先生が死ねといったら死ぬんだな？
163:仕様書無しさん
08/07/29 01:23:18
夏休み？
164:仕様書無しさん
08/07/30 23:29:44
そう
明後日から夏休み兼秋休み兼冬休み兼春休みだ。
165:仕様書無しさん
08/10/18 21:51:20
うちの現場さ、書けない組めない奴が上流やってんの。
もうね、設計書はもちろん、フローもテストケースも何も書けない。
人に見せるための書類が全く書けない。
でさ、何が出来るのかっていうとお客さんと話して、口頭レベルで下に伝えるだけ。
本当にそれしか出来ない。
こんなのが上やってるというだけでトップレベルの単価貰ってたりするんだから
若くて出来る人はみんな嫌になって引き上げちゃうのね。
本人は気付いていないんだろうけど、皆言ってるよ。あいつとは関わりたくないって。
シ○ポーのいしざ○！おまえのことだ！！
166:仕様書無しさん
08/10/18 21:57:54
何度も何度も何度も既出だろうが、
プログラムの世界で言う「上流」という名目は、一般的に使われる意味での「階級」という意味は持ち合わせていない。
工程を川の流れに例えて、上流→下流と表しているだけ。
どこかのバカはそれに気付かず、上流工程の方が下流工程より偉いとか思っている。
167:仕様書無しさん
08/11/13 22:50:22
書けない奴が上流ってあり得るの？
168:仕様書無しさん
08/11/23 16:11:25
>>150
納品物リストにドキュメントは含まれておりませんでしたが？
169:仕様書無しさん
08/12/05 00:10:31
>>168
それはタイトルだけそれっぽい名前が付いてて申し訳程度に書かれた中身スッカラカンの
PowerPointやExcelのファイルのことを言ってるのか？
170:仕様書無しさん
08/12/05 00:37:16
ソースファイルのコメントを抽出するツールで作ったそれの事です。
171:仕様書無しさん
09/01/07 01:00:45
>>167
コードが書けないSEもいたよ。
172:仕様書無しさん
09/01/07 01:25:16
>>171
×コードが
○ドキュメントもコードも
173:仕様書無しさん
09/01/25 23:09:04
バランスのいいやつが少ないんだよね。
コード書きは優秀なんだけど、ドキュメントになると、そもそも日本語が・・・ってなくらい。
174:仕様書無しさん
09/05/14 16:50:40
VB.NETでオブジェクト指向で作ったのに、関数仕様書書かされたことあるなあ。
ISOがどーたらこーたらで。
途方にくれたもんだｗ
175:仕様書無しさん
09/08/29 10:54:42
>>132
んなもん、経験値が違うんだから
あったりめーだろうが。
それより若いのにもっと経験値をつませろってことよ。
176:仕様書無しさん
09/08/29 16:47:25
設計書作らないで脅迫されるままに１０万行以上打ち込んだら
最初の頃打ち込んだ内容を完璧に忘れて
数ヶ月前の自分に恨み言を言ってる
そんな俺が来ましたよ。
177:名無しさん＠そうだ選挙に行こう
09/08/30 08:16:50
ITコンサルタントになるにはプログラミングの他に何を学べばいいんですか？
178:仕様書無しさん
09/08/31 00:44:45
>>177
なんでこんな過疎スレで釣りはじめてんの？
179:仕様書無しさん
09/08/31 03:18:30
10社で作って、基本設計書のフォーマットが微妙にバラバラだったのが笑った
後になって、揃えろとか言い出して、みんなで全修正。
先にきっちり決めなきゃ、そりゃどんどんずれて行く
それで終電でサビ残。
誰もが知ってる会社名なのにｗｗ
管理が専門なのに糞すぎる
180:仕様書無しさん
09/08/31 19:49:28
>>179
SIなんてそんなもんだ
181:仕様書無しさん
09/08/31 22:34:43
悪い仕事に当たると無から有を作る、原理的に不可能な事をする
連続だから嫌だ。上がプラン無しだからな。しかもやり方まで強制してくる。
「そのやり方では不可能」という意見は自動的に無視されて生産性の悪さ
だけでプログラマを叩く。
いよいよ徹夜が続くと「今更言っても仕方が無い。」の一点張り。
182:仕様書無しさん
09/08/31 23:43:36
Nで始まってDで終わる4文字のSIreが作った
大規模プロジェクトの仕様書のフォーマットに
一目で分かる誤植やらありえない日本語遣いがあって、
これが2年ぐらい放置されてるんだけど、なんなんだろう
183:仕様書無しさん
09/09/01 01:27:08
>>182
書類は中身じゃなく、あるかどうかで判断される。
184:仕様書無しさん
09/09/01 06:19:18
>182
NTTデ○タ？
185:仕様書無しさん
09/09/09 20:28:43
一機能数百枚のテスト仕様書のチェックやらされた
中国人が書いてたから俺のするのは日本語の間違いと体裁のチェックをするだけで
俺たち以外にもドキュメントの品質管理がたくさんいた。
どうみてもあんな量まともに書いてないと思うし、誰も読まないと思うし、アホかと思った。
186:仕様書無しさん
09/09/09 20:58:41
テスト仕様書はね～
正直力入れるところじゃないんだよね。
一度しか読まれないし。
187:仕様書無しさん
09/09/09 23:35:03
全くないってのはウンコプロジェクト。
ないよりはあった方がいいよ。
188:仕様書無しさん
09/09/10 00:16:11
何年も前に作られて動いてるプログラムのソースを読んで要件定義書を書けと言われた。
なにか良いコツ、良い参考書があれば教えてください。
189:仕様書無しさん
09/09/10 00:17:36
えっ
190:仕様書無しさん
09/09/10 00:45:21
とりあえずまずは全体を把握する。
パッケージ構成、フォルダ構成から、そのフォルダごとの機能を推測する。
あと、データベースの構成も押さえる。
あとは>191が教えてくれる
191:仕様書無しさん
09/09/10 00:45:31
とりあえず何をしているプログラムなのか
把握しなきゃならんと思うので、
Wikiにソースファイル名でページ作って
ガンガン内容書いてけ。Wikiじゃなくてもいい。
192:仕様書無しさん
09/09/10 00:48:54
要件定義って、むしろソフトを弄って、何ができるか書いたほうがいいんじゃね？
ソースからなんて子細すぎて要件定義じゃねえだろ。
193:仕様書無しさん
09/09/10 11:12:17
結局のところ「設計書を作れ」と言われて作ってるわけで、上司としては作らせておけば引継ぎの指示が出しやすい。
「仕様書読んどけ。設計書が解りづらい？作った奴はクビだ」という指示が出せる。
少なくとも何も無いよりはマシな状態が作り出せる。
言うまでも無いが、上司は設計書を見る気はサラサラ無い。↑の状況が欲しいだけなのさ。
194:仕様書無しさん
09/09/10 23:21:51
↑が言うところの困った上司ってどこにでもいるなｗｗｗ
195:仕様書無しさん
09/09/11 00:03:42
え？要件定義書からなんで設計書になるの？
>>192以外に考えられん。
196:仕様書無しさん
09/10/25 15:02:46
ソースコードで表現できることはドキュメントにしない。ソースコードでは表現できないことをドキュメントにする
ドキュメントにはソースコードでは絶対に表現できないことを書く。
分析ではユースケース、要求仕様、
設計では期待される入力値、出力値、副作用
あとはソースコードで表現しにくいこともドキュメントにしておく
クラス図、非同期のシーケンス図、データフロー図(OOと相性悪いので自分用だけど)等
ソースコードで表現できること(フローチャート、ステップ単位の処理の詳細等)の設計は
ビルド、テスト無しでソースコード書いてレビューするのが一番速い。
ということを会社で言いたいが言えない今日この頃。
197:仕様書無しさん
09/10/25 15:53:17
ちくちく詳細書いてる位だったらコード書くわなぁw
つーか書類書類言ってねーで本来の仕事させてくれよと、プログラムができてなんぼだろとw
198:仕様書無しさん
09/10/26 12:35:18
詳細設計なんか書かされるのは、プログラマとして信頼されてない証拠
机上でロジック組み立てさせてレビューしないと、いきなりコード書かせても
手戻りばかりでしょ、おまえらなんて
199:仕様書無しさん
09/10/26 13:00:53
詳細設計作らないとか、引継ぎどうすんだよって話。
フローチャートを描く必要は感じられないが、
システム側の仕様は決めておく必要あるだろう。
別に詳細設計だけを書くんじゃなくて、
先にコード書いてしまってもいいけどね。
200:仕様書無しさん
09/10/26 22:32:34
>>199
各関数の入出力+副作用まで書いておけば十分じゃね？
後は全体の大まかな設計と。
>>198
それステップ単位のドキュメントじゃなくてコードレビューでいいと思うんだ。ビルド、テストしなければドキュメント書くより作るのも直すのも早いし。
コードレビューして相手が理解できるまでコメント入れれば後での保守も問題無い気と思う。
だいたいもっと酷いコード散々見てきただろーが。
201:仕様書無しさん
09/10/26 23:07:24
状態遷移図は必要だな。
設計しないできちんとできるのはちっちゃなプログラムだけだろうｗ
202:196
09/10/26 23:22:29
>> 201
状態遷移図は確かに必要だね。
それはソースコードでは表現しにくいことだから。
でもこのスレで問題になっているのはコードレベルのドキュメントじゃないか?
そして状態遷移図もクラス図もまともに無いとか。
203:仕様書無しさん
09/10/26 23:26:06
>状態遷移図
いまいち何を書いていいのかさっぱりわかんね
204:仕様書無しさん
09/10/26 23:29:48
>> 203
永続的に稼働するようなシステム(サーバーとか)や割り込みが入る組み込みシステムだと
状態変数を持ってその値に応じて制御が変わるので必要性がわかると思う。
全てのシステムに必要なものでもないね。状態持たなければその方が良い設計であり理想的なわけだし。
205:仕様書無しさん
09/10/26 23:31:13
詳細の仕様書を作る時間の見積もりだけは見積もれない
すっげー時間かかる
作る時間の１０倍以上は余裕でかかる自信がある
だから書けって言われたもん以外は自分からは絶対書かないようにしてる
これ、マジで無駄だわ
めっちゃ詳細まで書く時間まで見積もってマジでこんなもん作ってほしいのか？
同じ規模のアプリが８～９本は作れるぞマジで
担当者によってショートカットやタブの動作までぎっちり書かせないと気がすまないキチガイにあたると最悪
プロジェクト終わってからしつこく電話かけてきてマジでウゼェ
詳細仕様書書けって言ったら時間で給料もらうか別料金にしてくれって思う
206:仕様書無しさん
09/10/27 05:53:44
>>205
本来は、納入仕様として取り決める必要がある部分なのに、
ＩＴ系はその辺いい加減だからねぇ。
207:仕様書無しさん
09/10/27 06:45:28
でもこんなもんマジで書くのを強制されるなら
もうこの仕事は金にならないな
ホントにこの辺はしっかり金もらっていかないとダメな部分だと思う
208:仕様書無しさん
09/10/27 08:13:51
>>200
関数のドキュメントはソースコードでいいだろう。
Javadocやらいろいろドキュメント化するツールがあるからそれでいい。
関数の設計は設計段階にやることではない。
ソース書いた後に自動出力でOK。
というか、全体の大まかな設計だけでOK。
あと項目レベルで外部とのインタフェースあるならそのドキュメント。
特殊仕様があるならそのメカニズムを説明するドキュメント。
209:仕様書無しさん
09/10/27 13:15:25
ソースが仕様書であり設計書
今回ドキュメント書きまくってそこに落ち着いた
210:仕様書無しさん
09/10/28 02:18:11
おまいらがこれまで経験したなかで、一番仕事がやりやすかった仕様設計ドキュメントってどんなの？ 量や内容といった点で。
211:仕様書無しさん
09/10/28 04:08:05
上流、下流じゃなくて
設計、製造だろ？
機械なんかは、図面書く奴と、材料集めて削って組み立てる奴は
まったく別だろ？ 町工場なんかは兼ねてる場合もあるにはあるが。
あと、設計書にフローチャートは無用。 その作成は製造の仕事。
設計で大事なのは、モジュール分割と、モジュール間のインターフェース仕様だな。
小規模なソフトには、それで十分。
規模が大きくなるほど、ＵＭＬなどを駆使して、十分な設計が必要だろ。
常識だがな。
212:仕様書無しさん
09/10/28 06:06:12
UMLってわかりやすいんだけど、仕様に依っては表現できないことがあるよな
213:仕様書無しさん
09/10/28 06:20:37
プログラムではめちゃくちゃミクロな内容で関連ができてしまうのに
上から眺めるとそういう部分が見えない場合なんてしょっちゅうだな
214:仕様書無しさん
09/10/28 08:05:29
このスレ、たまに偉そうに語り出す奴がいておもしろいなｗ
215:仕様書無しさん
09/10/28 16:25:54
>>213 それは分析が甘いから。 グローバル変数いっぱい使って値を受け渡すとか
あちこちでＤＢを書き換えているとか、あちこちで別個に１つのＩ／Ｏに
アクセスしてるとか．．そういう場合だろ？
たとえば、１つのＩ／Ｏアクセスは１つのドライバモジュールを介して
行わせるだけでも、絡み合いが少なくなるだろ？
オブジェクト指向の発想を設計に取り入れれば、モジュール間の絡みは少なくなる。
処理をほぼ丸投げできるモジュールの集まりで構成するのが、ソフト設計の極意だろ？
216:仕様書無しさん
09/10/28 20:09:35
仕様とロジック間のＩ／Ｏさえ決めれば設計が手抜きでも充分いける
逆に仕様とロジック間のＩ／Ｏが曖昧のまま設計すると後でちぐはぐなモンが出来上がる
217:仕様書無しさん
09/10/28 21:58:48
仕様とロジック間のアイオー。
それは設計とは言わないのか？
218:仕様書無しさん
09/10/28 23:15:40
形式手法とかいう
プログラムだか仕様だか設計だがよく分からないものを導入しようとしている
俺の会社の役員に何か言ってくれｗ
こんなのを仕様書にしたら、仕様書を作る段階で
設計書がいるよｗ
219:仕様書無しさん
09/10/29 02:50:06
UMLがいらないとか言ってるやつらって
プログラマとしてどの程度のレベルなの？
220:仕様書無しさん
09/10/29 07:31:19
実際の開発ではumlに書けるようなとこは問題にならないのでなんとも
221:仕様書無しさん
09/10/31 09:17:12
>>219
UML必須の開発現場なんて行ったこと無い。
クラス図だけありゃ十分
222:仕様書無しさん
09/10/31 10:54:36
仕様書のレベルが低いから仕方ない。
ソースコードが一番詳細な仕様書なのに、
ソースコードのチェックは全く入らない俺の会社。
223:仕様書無しさん
09/10/31 13:23:11
偉そうに語るだけに、いいコードちゃんと書いてるんだろうな
224:仕様書無しさん
09/10/31 17:52:51
>>185
そんなんで工数かけてもオフショア利潤まだ残ってんだろうな・・・
225:仕様書無しさん
09/11/01 01:57:25
未だに、誰が見ても同じコードが書けるような
詳細設計書がベストだと抜かす奴がいるけど
なんで、コード書いてトライ＆エラー繰り返すより
excel上でコピペしたり改ページ気にしながら
UMLとかこねくり回すのが優れていると考えちゃうんだろうね。
だいたい誰が見ても同じコードが書ける設計書なんて
未だ見たことないし。
226:仕様書無しさん
09/11/01 02:00:06
まず使用するフレームワークのマニュアルを詳細設計書に添付する作業から始まる
227:仕様書無しさん
09/11/01 02:24:02
>>225
そのままコンパイルできそうな詳細設計書を見たよｗ
228:仕様書無しさん
09/11/01 12:09:49
>>227
ifとかforが書いてあるのなら
俺も見たことあるぜ
コードレベルの詳細設計所って、最初の開発終わって年月がたつと
修正なんかが抜け落ちまくりで、最初はこう作ろうと思ってたって
だけの書類になってることが多いやね
229:仕様書無しさん
09/11/03 14:06:50
設計書でも、
・自分の頭の中を整理するため
・他のメンバーと考えを共有するために
作成するものなら、必要だし、また自然に作られるものだと思うが、
納品物のために作る設計書はマジで不要だと思う。
230:仕様書無しさん
09/11/03 15:20:06
>>229 でもそれを出せという客が多い。
プロマネは金と成果はもっていきながら、俺が全部かいて全部怒られる。
231:仕様書無しさん
09/11/04 01:11:27
納品の為につくる詳細設計書だと、
コード買いてからの方が書きやすいよね
書く前だと、どうコーディングしてもいいように
あいまいな表現をするよう気をつかわなきゃいけないし
232:仕様書無しさん
09/11/06 11:52:58
着手後の細かい仕様変更や不具合の修正分が
盛り込まれないまま提出する事も時々あるなぁ
233:仕様書無しさん
09/11/15 17:03:54
仕様書設計書、自分のいい加減な仕事を否定させないために作るな。
そういわれて作った代物
案の定
あっはっはw
234:仕様書無しさん
09/11/18 22:51:51
このスレで詳細設計は必要ないと言う奴は、こんな感じだろ
A「詳細設計は書かないの？」
B「詳細設計？、そんな物書いている暇があるならコーディングした方が早いだろ」
A「でも、オブジェクト指向で作る時は、詳細設計した方が良いよね」
B「オブジェクト指向なんて分からん！！、俺はPOA作るから良いんだ」
A「．．．（たしかに、POAなら詳細設計は、あまり必要じゃないけど｝」
A「でもオブジェクト指向覚えたら、改造やメンテが楽になるよ」
B「アホか？、楽にしてどうする、工数が減らされて俺みたいな使えない奴から切られるだろう」
A「確かにそうだけど．．．」
235:仕様書無しさん
09/11/18 23:34:43
>>234
古くさい言語で古くさい開発スタイルが好きな人間ほど
詳細設計が好きだから、それはない
236:仕様書無しさん
09/11/19 00:55:05
でも自分でも作るもんがわかってねー奴とかには書かせたほうがいい＞詳細設計書
元ＰＧのＳＥとかだったら結構安心できるけど
元素人のＳＥはダメだ
まったくダメ
金のある会社でも元素人のＳＥとか育ててるけど全く意味がわからん
はじめの一歩から踏み外してる奴はどうやっても使えないよね
いまの外勤先にはいないけど前いたところは酷かった
ってそれじゃ詳細設計書なんて書いてもしょーがーねーじゃんｗ
ってそうなんだけどさｗ書かせないと自分がした発言すら忘れるからな
237:仕様書無しさん
09/11/19 01:10:53
>>234
> A「でも、オブジェクト指向で作る時は、詳細設計した方が良いよね」
この「良い」に疑問の余地は無いのかね？
238:仕様書無しさん
09/11/19 23:01:04
>>237
>この「良い」に疑問の余地は無いのかね？
疑問の余地など１㍉もないわｗ
オブジェクト指向は詳細設計が必ず必要
詳細設計”書”はケースバイケースだなｗ
詳細設計が必要ないほど小規模は開発は
オブジェクト指向で作る必要なし
だからオブジェクト指向は必ず詳細設計が必要だなｗ
239:仕様書無しさん
09/11/19 23:19:53
>>238
お前のレスの１行１行にはいちいち根拠がまったくないな
必要とか断定口調の割りにはそれを裏付けるような内容は書いてないし・・・
240:仕様書無しさん
09/11/19 23:37:47
>>239
心配するな、始めからアホには理解できないと分かっているｗ
だいたい、説明しないと分からん奴は、説明しても分からんからｗ
必要性が分かるような技術力は、自分で身に付けないとなｗ
241:仕様書無しさん
09/11/20 00:19:18
>>240
それって後で困るぞ
言っとくけどこの業界な
アフォが学会で延命するためにすげー無駄な技術で溢れてるから
自分で採用する技術の良し悪しも判断できない人間がくるとまったく無駄な人生費やして終わるよ
オブジェクト指向も実はそのひとつで
これで生産性が上がるって説明できる人間は本当にいないから
業界全員で騙されちゃった例
根拠のない技術って怖いよ
クラウドもそうだけどこういうのバズワードっていうんだぜ
242:仕様書無しさん
09/11/20 01:36:16
>>241
じゃあ「オブジェクト指向を撤廃することで生産性が上がる」という事を説明してください。
243:仕様書無しさん
09/11/20 01:43:59
「馬鹿にはわからない理屈なんです＞＜」
っていう裸の王様ごっこか？
>>242
だれもそんな話してない。
「オブジェクト指向で作る」ことと「詳細設計した方が良い」ことのつながりが
不明だろうって話。
244:仕様書無しさん
09/11/20 02:35:24
>>243
自分の書いたレスをちゃんと読み返してくれよ。
自分は悪くないみたいなつまらない自己弁護はしないで、発言を見直してくれよ。
>>238の主張は「オブジェクト指向は必ず詳細設計が必要」だから、
「詳細設計した方が良い」というのは議論していない事のように読める。
>>242の発言は「詳細設計しないほうが良い」と言っているようには読み取れない。
「オブジェクト指向」を否定しているように読める。
「オブジェクト指向は無駄な技術」だから「後で困る」と言っているように読める。
なぜ無駄なのか、なぜ後で困るのか、そこんとこを説明してくれ。
245:243(=237)
09/11/20 03:00:15
>>244
ごめんよ。
> B「詳細設計？、そんな物書いている暇があるならコーディングした方が早いだろ」
> A「でも、オブジェクト指向で作る時は、詳細設計した方が良いよね」
これ読んだとき、詳細設計するかどうかと、それを文書として書くかどうかを
ごっちゃにしてた。
Bは詳細設計をコードと別の文書として書く必要は無いといってるのに、
それを「詳細設計しない」と思い込んだAが変な反論してるんだな。
で、つられてBも変な方向に反論してる、と。まともな会話になってないね。
っていうか、「詳細設計」ってのが何なのかわかんなくなった。
コーディングしてれば少なからず脳内で「設計」はしてるよね？それは「詳細設計」じゃないの？
246:仕様書無しさん
09/11/20 03:30:12
このスレの>>1自体が「まともな会話になってない」と、俺は思う。
「設計とはなんぞや」というのが誰も理解できてないな。
「コーディングすること」と「設計すること」を一致させるということは、
大工が設計図無しに家を作って「設計しながら作った」と主張する事に等しい。
・設計書を書かないで建築すると建築物の品質はどうなるか
・建築途中もしくは改築時に大工が変わったらどうなるか
・一生住む家と1日しか住まない家では設計の価値は変わるか
を考えると、そもそもどれも生産性とは関係ない。
「設計書を書くこと」と「生産性が落ちること」のつながりが不明だと思うのだが。
ちなみに、実装に関係ない書類を作ると実装が遅れというのは当然だぞ。
247:仕様書無しさん
09/11/20 06:35:11
>>246
大工とプログラマを同列に扱える理由は？
248:仕様書無しさん
09/11/20 07:54:32
>>246
"What Is Software Design?" By Jack W. Reeves
URLﾘﾝｸ(www.developerdotstar.com)
・・・ありゃ？ひとつだけあった邦訳が 404 になっちゃってるね。
ソフトウェア開発において、大工の立場にいるのはコンパイラであり、大工が見る
設計図にあたるものはソースコードである、という話。
つまりソースコードを書くための設計書を書くということは、大工のたとえで言うと
設計図を書く前に設計図を書くための別の手順書を書くという、明らかに無駄な
行為にあたるということ。
こっちが真実でしょ。
249:仕様書無しさん
09/11/20 10:01:37
コンピュータ視点すぎて参考にならん
250:仕様書無しさん
09/11/20 10:42:43
>>249
コンピュータソフトウェアの開発してるんじゃないの？
もしかして本職の大工さん？板違いですよ。
251:仕様書無しさん
09/11/20 11:50:19
>>246
受け売り過ぎて、しかも極端な喩えすぎて話にならんわ。
自分の言葉でしゃべれ。
252:234
09/11/20 12:47:10
オブジェクト指向は何で詳細設計が必要か？ 俺の主観で回答するな～
前提条件として小規模開発は除くから、あと、詳細設計＝実装レベル設計と考える
まず、基本設計（概念設計）は構造化、オブジェクト指向ともに必要
（まさかこれも必要ないと言う奴は、さすがにいないだろうな？）
本題の詳細設計は、構造化の詳細設計はアルゴリズムがメインだが
アルゴリズムは、実際にコーディングして動かさないと分からない事が多い物、だからコーディング前の必要性を感じられない
次に、オブジェクト指向の詳細設計は、クラス設計・クラス/オブジェクト間連携・メソッド振る舞いなど
アルゴリズム以外の設計がメインになる、そしてこれらの設計は、基本設計より難しい
これを、いきなり作り始めるのは、天才かオブジェクト指向で作っていないかのどっちかだ
オブジェクト指向で作っているかの見極めは難しいが、絶対違うのは
・クラス数＝オブジェクト数（これは、構造化だなｗ）
・クラス数が、１０個未満
・オブジェクト数が、１０００個未満（オブジェクト指向は”オブジェクト”指向だからなｗ）
まっ、これをクリアしも違う場合もあるが、どうだ、身に覚えがないかｗ
253:仕様書無しさん
09/11/20 12:50:52
>>248
>ソフトウェア開発において、大工の立場にいるのはコンパイラであり、大工が見る
>設計図にあたるものはソースコードである、という話。
どこにそんなこと書いてる？引用してくれ。
それと、ソースコードが設計図であるとも書かれてない気がする。
> If source code is a software design, then actually building software is done by compilers and linkers.
> We often refer to the process of compiling and linking a complete software system as "doing a build".
> A program listing is a document that represents a software design. Compilers and linkers actually build
> software designs.
あたりか。
254:仕様書無しさん
09/11/20 13:02:14
またリーブズ厨か。やれやれ。
255:仕様書無しさん
09/11/20 13:07:41
こうも書いてるね。
> There are other design activities?call them top level design, module design, structural design,
> architectural design, or whatever. A good software design process recognizes this and deliberately
> includes the steps.
> All design activities interact. A good software design process recognizes this and allows the design
> to change, sometimes radically, as various design steps reveal the need.
256:仕様書無しさん
09/11/20 13:23:45
>>254
最早、信者の域に達している。
だから自分の言葉で説明できない。
257:仕様書無しさん
09/11/20 14:18:49
大工の立場にいるのがコンパイラっ考えがまずおかしいだろって事
258:246
09/11/20 22:33:57
大工の喩えは嫌いみたいだからもう忘れてくれ。
「コーディングすること」と「設計すること」が、
生産性と関係するかを考えると、そもそもどれも生産性とは関係ない。
・設計書を書かないでコーディングすると、
（設計書を書いてからコーディングした場合と比べて）ソフトウェアの品質はどうなるか
・開発途中もしくは保守フェーズに開発者が変わったらどうなるか
・一生使うシステムと1日しか使わないシステムでは設計の価値は変わるか
「設計書を書くこと」と「生産性が落ちること」の因果関係が不明だと思うのだが。
>>248
個人的には、ソースコードに詳細設計を含めることは出来る（ので基本賛成だ）が、
ソースコード＝詳細設計である、というのは真実ではないと思う。
理由は、それだと「リファクタリング」という概念が説明できないから。
>>252
前提を足したのはどうして？
259:仕様書無しさん
09/11/21 01:00:43
ソースコードを書かずして詳細設計ができたと言われても、まったく信用できないね。
ソースコードは詳細設計を行い、その正しさを確かめるのに必要なもの。
ついでにソースコード中のコメントとして文書を書きこんでしまうのが楽チン。 Javadoc とかね。
260:仕様書無しさん
09/11/21 09:49:44
最初に設計書なんか書いても、偉そうにふんぞりかえってる上司がダメ出しするし
出さなきゃ出さないで責任とらされるし、正直ウンザリだね。
261:仕様書無しさん
09/11/21 10:21:22
設計書に書かなければならないことをまとめよう。
CSVファイルで、数値が入っているべき所に
なぜか文字が入ってきた場合の処理は
設計書に書くべきか否か。
262:仕様書無しさん
09/11/21 11:53:33
ドキュメントは書いたほうがいいと
ジョエル・スポルスキーも言っている。
問題は設計書でプログラムを書こうとする場合。
日本語でプログラムするくらいなら
プログラム言語でプログラムしろよｗ
263:仕様書無しさん
09/11/21 11:57:12
プログラムはひとつの切り口しか持てないけど
ドキュメントなら色々な側面から問題の解決方法を記述できる。
これは大きいんじゃないか。
264:仕様書無しさん
09/11/21 19:33:25
問題の解決･･･それは大きなメリットだ
でもそれは設計書とは呼ばれていない、多分
265:仕様書無しさん
09/11/22 06:45:07
設計者とコード書く人間が別とかいうこともままあるわけで、
そういう時のための設計書だ、という主張には一理あると思うが
設計書があれば意図が正しく伝わるかと言うと疑問
お前の設計書がクソなのだ、と言われれば自信を持った反論は出来ない
266:仕様書無しさん
09/11/22 07:39:46
>>258
おいおい、ちゃんとした日本語で書いてくれよ。
自分が書いたのを10回読み返してから書き込みボタンを押そうぜ。
内容めちゃくちゃだぞ。支離滅裂。
267:仕様書無しさん
09/11/22 08:08:12
責任者がとにかく嫌がらせのようにダメ出しをする場合
レビューって終わらないよな。
何度か試みたけど毎回喧嘩になるんで、もう勝手に作ってる。
268:仕様書無しさん
09/11/22 08:31:47
設計書を作ることを全力で阻止してるチリチリ頭のバカに暴言はかれまくり
第三者のいる展示会とかでやるか普通
269:仕様書無しさん
09/11/22 09:06:46
コードレビューが意味あるものかどうかをチェックする方法。
以下のコードを故意に入れたものをレビューにかけて、検出されるかどうかチェックする。
・境界値条件をわざと間違えておく
・メモリを破壊するコードを書く
・リソースがリークするコードを書く
・その他セキュリティリスクの要因となるコードを入れておく
270:仕様書無しさん
09/11/22 11:54:09
はい、検出できませんでしたねー無駄だから削減！
てな事にはならないんじゃないか
蓮舫がいれば話は別
271:仕様書無しさん
09/11/22 12:16:23
顔が柴田で性格が蓮舫とかならよくいるだろ
272:仕様書無しさん
09/11/22 15:04:36
コードレビューがお勉強会になる現実
んな屑みたいな書き方するなとか
んなコードじゃ保守できないからやめろとか
コーダの質が悪すぎる
273:仕様書無しさん
09/11/22 17:55:11
コーダーのレビューなんかしなくていいよ
チェックしてまずいところがあったら、問答無用で直せ
274:仕様書無しさん
09/11/22 18:19:11
プリプロセッサを3段入れ子にする奴ってどう思う？
しかもその有効範囲がすげー長いんだ。
100行以上を囲ってたりする。
インデントいれたら「余計なことすんなバカ」といわれた。
しにたお。
275:仕様書無しさん
09/11/23 09:41:33
>>274
ソース見てないから何とも言えないが、１００行以上は長すぎと思う
>インデントいれたら「余計なことすんなバカ」といわれた。
>しにたお。
これは当然、人のソースを勝手に変更する方がお前が悪い
変更するなら、了承を得ないと
276:仕様書無しさん
09/11/23 10:42:45
人のソースを修正する奴は何を考えているんだ？
自分が正しいと思っている奴に限って、とんでもない大馬鹿野郎だったりするよな
そのくせ自分の事を天才プログラマーだとか言う、本当に駄目な奴が多い
出来る人は、本人に修正させて納得出来る理由も教えてくれる人が多い
277:仕様書無しさん
09/11/23 10:56:01
>>276
面倒臭いだろ
278:仕様書無しさん
09/11/23 12:27:59
>>277
それも、不思議だよな、よっぱど火を噴いているプロジェクトじゃない限り
出来る人間は、人より多い仕事をさせらているのに、余裕があるんだよな
出来ない人間は、説明の無しに人のソースを修正して、余計な仕事を増やす
本当に、知ったかは氏んでくれと思うよ
279:仕様書無しさん
09/11/23 18:35:44
自分が書いたクソコードが修正されたのがよっぽど悔しかったんだねｗ
280:仕様書無しさん
09/11/23 19:12:25
事情を説明するのも面倒なんだが、そもそも第三者に読まれることを
考えてないコードって酷いんじゃないか。
281:仕様書無しさん
09/11/23 19:39:25
>>279
自分の事を天才とかピカソだと思っているだろうｗ
理解出来ないソースはクソコードか単純でいいなｗ
お前レベルの人間に、再帰のソースを見せるとまったく理解できなくて嫌になるよ
ループで出来るだろうとか言い始める、本当に馬鹿は自分のレベルを知らんな～ｗ
はいはい、アンタは天才ですよｗ 頑張れよ、天才ｗ
>>280
>事情を説明するのも面倒なんだが、そもそも第三者に読まれることを
>考えてないコードって酷いんじゃないか。
第三者（アホ）に合わせたソースを書けと言うのかｗ
自分は頑張らんのか？ まっ天才だから頑張らんでもいいのかｗ
282:仕様書無しさん
09/11/23 19:47:18
何コイツーｗ顔真っ赤なんですけどｗｗｗ
283:仕様書無しさん
09/11/23 19:48:07
いくら「コードがドキュメントだ」といってもそこには限界があります。
というのも，ソースコードやテストコードでは「What（何を）」や「How（どうやって）」を表現することはできますが，「Why（なぜ）」「Why not（なぜXXでないのか）」は書けません。
結果をコードで表現しているのですから，当然です。
コードのWhy，Why notは，ソースコードのコメント等に書かれるべきです。
コード以外のドキュメントでも「なぜ」「なぜXXでないのか」を書くことは重要です。
直接話のできないドキュメントの読み手に意図を伝えることができるからです。
284:仕様書無しさん
09/11/23 21:01:20
>>282
そんなんだから、「余計なことすんなバカ」と言われるんだよｗ
だいたい２ちゃんにしか、愚痴をこぼせない奴ってｗ
その性格だと職場の人間に相手にされていないだろう、いつも自分勝手にやっているから
だから、相手も「余計なことすんなバカ」と切れたんじゃないのかｗ
>>283
意味分からん、誰も基本設計をしないとは言ってないだろうｗ
285:仕様書無しさん
09/11/23 21:49:46
何かカチンと来たらしい
286:仕様書無しさん
09/11/23 22:08:38
お前等疲れてるなぁ
287:仕様書無しさん
09/11/24 00:35:24
>>285
>何かカチンと来たらしい
絶対職場に一人はいるよな、こんな奴
みんな、お前に怒っているのに、それが分からんアホが
>インデントいれたら「余計なことすんなバカ」といわれた。
まさか、インデントをTABで入れてないよな？
たまにいるんだよなTABで入れる馬鹿が、お前もそっちか？
まっ、職場で「バカ」呼ばわりされている時点で終わっているがｗ
288:仕様書無しさん
09/11/24 10:56:48
>>281
>ループで出来るだろうとか言い始める
末尾再帰ならそのまま、そうでなければコンテキストを保存すれば
ループに置換可能ですね。
289:仕様書無しさん
09/11/24 18:21:20
よほどの理由が無い限りインデントはtabだけども
何がバカなのかすらわからんわ俺
290:仕様書無しさん
09/11/24 18:42:16
放っといてやれ。
スタイルに食いつくのは素人の最終手段だ。
291:仕様書無しさん
09/11/24 20:45:24
スペース教信者か
哀れ
どっちでもいいだろ
292:仕様書無しさん
09/11/24 20:48:22
語尾に罵詈雑言付けないと意見を補強できない人って
可哀想ですね。
293:仕様書無しさん
09/11/24 21:52:44
>>289,291
ソースは他人も見るものだが、分かっていないのか？
「ソースは自分さえ分かれば良い、人のソースも自分が分かるように勝手に修正する」か
本当に駄目な技術者だな
普通の技術者は、相手のタブ設定や使用するツールに関係なく
正しく読める為に、スペースを使うのが常識なんだが
新人教育でも習う基礎だぞ、お前は転職組みが？ それとも教育もない中小企業か？
まっ、職場で『バカ』と呼ばれるだけはあるなｗ
294:仕様書無しさん
09/11/24 21:57:33
> スペースを使うのが常識
はぁ？
聞いたことねえよ
コーディングルールにあわせるのが常識だろ
295:仕様書無しさん
09/11/24 21:59:32
相手が自分より下だと思い込んでいちいちそれを書かないと納得できないって人間終わってるな
296:仕様書無しさん
09/11/24 22:16:17
こいつ他のスレで青山とか騒いでたジジイじゃないか？
297:仕様書無しさん
09/11/24 22:24:59
オブジェクト指向すら理解できず火病ってたあのアホの子か
298:仕様書無しさん
09/11/24 22:32:13
ところでtabの設定が変わったら可読性が落ちるインデントって何？
普通の技術者ならtabの設定が2だろうが8だろうが関係なく読める程度にしか使わんだろJK
コードにAAでも書いてるのか？
299:仕様書無しさん
09/11/24 22:33:13
>>294
>はぁ？
>聞いたことねえよ
それは、お前が皆から相手にされていなからだろ
>コーディングルールにあわせるのが常識だろ
お前のところでは、字下げはタブでやれと書いてあるのか？
普通は、２桁づつ字下げするとか、空白４文字字下げするとか書いてあるが
もう一度ちゃんと読んでみたらどうだ、お前、本当に使えない技術者だな(･･;)
300:仕様書無しさん
09/11/24 22:38:59
普通、タブかスペースか書いてあるよ。
どちらの場合も何文字でインデントするか書いてある。
普通はEclipseのオートフォーマッタ任せでいいでしょ。
301:仕様書無しさん
09/11/24 22:44:00
よく分かってなかった俺だが要するにアレだな
統一、徹底されていればいいって事か
302:仕様書無しさん
09/11/24 22:47:06
そうそう。
本当はタブ使ったほうが整然としてるけど、
見た目考えるとスペースだね。
それだけの話。
303:仕様書無しさん
09/11/24 22:47:36
>統一、徹底されていればいいって事か
納品する客にも徹底させるのか？ 無理だろうｗ
304:仕様書無しさん
09/11/24 22:47:51
>299
井の中の蛙だって自己紹介しなくていいよ？
つかいちいちインデント如きで拘らねえよ
並のエディタなら変換機能持ってるしIDEならなおさら
万が一気に入らなくても変換してコミットすりゃいいんだから
305:仕様書無しさん
09/11/24 22:49:30
設計書きちんと作って外注にでも出した方がいい仕事で
設計書作りを全力で妨害してるおっさん
何考えてるのかわからない。
306:仕様書無しさん
09/11/24 22:54:23
>>304
>並のエディタなら変換機能持ってるしIDEならなおさら
>万が一気に入らなくても変換してコミットすりゃいいんだから
コーディングルールの意味は？ 始めからルールどうりに書けばいいだろう
307:仕様書無しさん
09/11/24 22:58:42
お前は「万が一」の意味がわからんのか。
308:仕様書無しさん
09/11/24 23:00:03
※どうり【どおりの誤り】
こんな奴にコーディングルール云々言われても…
309:仕様書無しさん
09/11/24 23:13:27
>>300
>普通、タブかスペースか書いてあるよ。
本当に書いてあるのか？ 嘘だろうｗ
>>307
>お前は「万が一」の意味がわからんのか。
その為のルールだが、本当に駄目だなｗ
>>308
>こんな奴にコーディングルール云々言われても…
別に俺はコーディングルールを書いてもいない
それにコーディングルールと言い出したのは、そっちだが(>>294)
それが、分が悪くなると、これだ．．． 本当に駄目だなｗ
310:仕様書無しさん
09/11/24 23:19:56
>>309
おまいはいちいちペタペタスペース叩くことを推奨してるの？
救いがたいね。
311:仕様書無しさん
09/11/24 23:32:16
>>310
>おまいはいちいちペタペタスペース叩くことを推奨してるの？
>>294 >コーディングルールにあわせるのが常識だろ
>>280 >そもそも第三者に読まれることを考えてないコードって酷いんじゃないか。
次から次へと主張を変えるなｗ
しかし、技術者がキーボードを叩くのを、めんどくさがってどうする、本当に駄目だな(･･;)
312:仕様書無しさん
09/11/24 23:36:04
>>311
駄目な技術者はおまいだろう。
そのスペースを叩く無駄な時間で何行コードが書けるか考えたことあるの？
真っ当な技術者ならタイプ数は出来るだけ減らして
コミットするときに変換かけるようなフックスクリプト噛ませるよ。
313:仕様書無しさん
09/11/24 23:48:49
>>312
>コミットするときに変換かけるようなフックスクリプト噛ませるよ。
なんだ、結局タブじゃなくスペースだと認めたなｗ
つまり、人のソースを勝手に修正し、コーディングルールにも合っていなかった
それで、「インデントいれたら「余計なことすんなバカ」といわれた。」となった
本当に駄目だなｗ 真っ当な技術者じゃなく普通の技術者でもそんな事しないぞｗ
314:仕様書無しさん
09/11/24 23:54:46
>>304は、書くときはTAB、コミットするときはスペースだと言っているが
それについたレス>>306は、書くときにスペースで書けと言っている。
そこでスペースで書くことを推奨しているのか尋ねたのだが>>310
どうやら本当に推奨しているようだ。>>311
だから救いがたい。
>>313こんなことしか言えない憐れなおっさん。
315:仕様書無しさん
09/11/24 23:56:10
それで、仕事は見つかったのか？
オブジェクト指向が判らないおっさん。
316:仕様書無しさん
09/11/25 00:00:40
可読性のためにスペースで保存することと
スペース連打とにどんな相関があるの？
とか書いているうちに314が書いてくれてたのでアホの相手はまかせる
317:仕様書無しさん
09/11/25 00:03:36
> 別に俺はコーディングルールを書いてもいない
わかったわかった
こんな奴にルールを守って書けとか言われても…
に訂正してやるよ
納得したかい？
318:仕様書無しさん
09/11/25 00:34:21
ドキュメントだから文系が集まってんのか？
過疎スレとはいえ関係ないどうでもいい事で消費すんな
319:仕様書無しさん
09/11/25 00:49:15
>>314,316
だから、タブじゃなくスペースだと認めるんだな
>>300 >普通、タブかスペースか書いてあるよ。
これは、嘘だと認めるんだな、
なんだったんだ最初の方の書き込みは、嘘まで付いて本当に駄目な人間だなｗ
しかも、自分の間違いが分かると今度はコミットの時の話に変えるか、職場でもそうなのか？
言い訳ばかり上手いのか？ いるよなそんな技術者ｗ あれは一種の才能だなｗ
しかし、>スペース連打とにどんな相関があるの？
スペース連打ってｗ、根本的に間違っているだろう
そんなに連打するほど、ネストさせてどうする、どんなソースを書いているんだｗ
書けば書くほど駄目さ加減が分かるなｗ
>>317
>こんな奴にルールを守って書けとか言われても…
>に訂正してやるよ
>納得したかい？
お前は馬鹿か？ 俺からコーディングルールに合わせろといったか？
320:仕様書無しさん
09/11/25 00:59:04
まあ、開発で使うエディタで保存時にタブをスペースに置換してくれる機能が
無いのがまれだから、インデントはタブで入れて保存時にスペースに置き換える
ようにしてるな。 コーディングルールもそんな感じにしたし。
タブじゃなくてペチペチスペース打つ頭の悪いやつがいるなんて想定外だな。
321:仕様書無しさん
09/11/25 01:23:06
このひとの頭おかしくね？
コーディングルールでスペースが指定されていたらという前提で話が進んでるのに
コーディングルールにタブと記載されているのはウソなんだな？ウソなんだな？
って意味不明なこと言い出すんだ？
しかも何故そこに執着する？
つかルール通りに書けってお前が言ってるじゃん
記憶力ねーのか？
322:仕様書無しさん
09/11/25 01:24:49
？？？？
2回押下でも連打だろう？JK
323:仕様書無しさん
09/11/25 01:42:44
「一段インデント」を TAB キーに割り当てて、そのとき実際に挿入されるタブ文字なり
半角スペースなりおよびその数はエディタがよきにはからってくれるように設定しておく、
ってのが常識。
324:仕様書無しさん
09/11/25 01:59:35
あれ？今時、自動インデントじゃない環境w
325:仕様書無しさん
09/11/25 07:27:59
>>321
＞コーディングルールでスペースが指定されていたらという前提で話が進んでるのに
いや、コミット時に変換すれば別にどっちでもいい話なんだよ。
326:290
09/11/25 10:03:15
なんだこの伸び…>>290 をもう一回繰り返そうか？
327:仕様書無しさん
09/11/25 19:39:33
どうでもいい、カスがわめくスレなんぞ要らん。落とせ。
328:仕様書無しさん
09/11/25 21:18:44
ワハハハ、お前ら哀れすぎるぞｗ
>>289
>よほどの理由が無い限りインデントはtabだけども
>何がバカなのかすらわからんわ俺
>>290
>放っといてやれ。
>スタイルに食いつくのは素人の最終手段だ。
>>291
>スペース教信者か
>哀れ
>どっちでもいいだろ
最初はタブで良いと書いておきながら、自分が無知だと気が付くと、今度は
>>294
>はぁ？
>聞いたことねえよ
>コーディングルールにあわせるのが常識だろ
と言い始めるが、コーディングルールにタブと書いてあるのかと、詰められると
>>300
>普通、タブかスペースか書いてあるよ。
と嘘を書き、また自分の無知がばれたから、こんどは
>>312
>真っ当な技術者ならタイプ数は出来るだけ減らして
>コミットするときに変換かけるようなフックスクリプト噛ませるよ。
必死にコミット時に出来るといい始める、
どうだ、自分の無知が恥ずかしいだろうｗ
329:仕様書無しさん
09/11/25 21:21:29
お前の書き込みの方が恥ずかしい
330:仕様書無しさん
09/11/25 21:24:59
・相手が同一人物である証明
・相手が無知である証明
が全くされてないな
よってキミがキミの仮想敵よりアホってことが証明されてしまいました
ｶﾜｲｿ(´･ω･`)ｽ
331:仕様書無しさん
09/11/25 21:48:32
>>330
お前は本当にアホか？
>>・相手が同一人物である証明
お前らが同一人物じゃない証明をだせ、こっちは一人で相手しているんだ
>・相手が無知である証明
本当に馬鹿だなｗ 馬鹿に、あなたはこんなに馬鹿なんですよと証明して納得するか
「相手（お前）は馬鹿なんだぞ、常識的に考えろ」と、馬鹿に言ってみるｗ
>>329
>お前の書き込みの方が恥ずかしい
で？ 何処が恥ずかしい”証明”してくれｗ
332:仕様書無しさん
09/11/25 22:03:42
>>331
それで？
青山のおっさんはいつまでこのスレに居座るつもりだ？
333:仕様書無しさん
09/11/25 22:08:20
見直したら愚痴＆キチスレだな、何でこんなのログ残してたんだろう
334:仕様書無しさん
09/11/25 22:27:11
> で？ 何処が恥ずかしい”証明”してくれｗ
自らのまぬけさにようやく気がついて顔真っ赤になっちゃいましたか？
日本語書けよ
335:仕様書無しさん
09/11/25 23:10:44
>自らのまぬけさにようやく気がついて顔真っ赤になっちゃいましたか？
"真っ赤になっちゃいましたか？"なんで赤ちゃん言葉？
ちょっとキモいなマジで
336:仕様書無しさん
09/11/25 23:13:31
ボクは、キモくないでちゅうｗ
337:仕様書無しさん
09/11/25 23:32:49
お前自分がキモくないと思ってたのか？
自覚した方がいいぞ
338:仕様書無しさん
09/11/25 23:48:10
赤ちゃん言葉って、ほんと糞スレだな
339:仕様書無しさん
09/11/26 00:19:30
インデントがタブだとカーソルで移動するとき無駄に時間かかるから嫌だ
340:仕様書無しさん
09/11/26 00:20:37
はぁ？
341:仕様書無しさん
09/11/26 00:20:54
まちがい
インデントがタブでないと
342:仕様書無しさん
09/11/26 01:41:52
>>339
HOME 一発とか Ctrl+カーソル とか、タブでもスペースでも関係ない操作が
いろいろあるし、そっちのほうが速い。
343:仕様書無しさん
09/11/26 10:05:45
キーボードを休みなしにカタカタやってる奴って、大抵 >>339 みたいな奴だよな。
344:仕様書無しさん
09/11/26 19:51:45
赤ちゃんプレーのスレがあると聞いて飛んできました、ここですか？
345:仕様書無しさん
09/11/26 20:24:11
いいえ、アホなオッサンを虐めて遊ぶスレでちゅう。
346:仕様書無しさん
09/11/26 22:45:53
真面目かｗ
347:仕様書無しさん
09/12/04 23:56:11
設計書の話はどこに言った?
348:仕様書無しさん
09/12/06 00:08:06
なんか書こうと思ったけど>>20が全部言ってくれてた。
>>24と酒飲みに行きたい。
349:仕様書無しさん
09/12/06 13:55:51
>設計書なんかで妄想してるより何倍も多くのことが分かるっての。
ただし行き先すら分かっていない場合は、時間の無駄
"方向"決めや、大まかな"手段"ぐらいは設計する
で実装とテストして分かった問題によっては設計を見直し、の繰り返しだな
その方が早く終る
>で、実装とテストが終わったあとに
>改めて補足のドキュメントまとめた方が明らかにソースと食い違いのないものができる。。
こっちは同意だが
350:仕様書無しさん
09/12/06 14:08:35
仕様書について、実装の方法とか何だかんだでケチつけてこなきゃ書くけどさ
気に入らないだの何だのと
中途半端に解ってる奴が茶々いれるから書き終わらないんだよ。
非建設的な上司がいると文書作成で1ヶ月潰れるとかザラだから書きたくない。
これは俺の会社の構造的欠陥だけど。
351:仕様書無しさん
09/12/06 14:35:28
>>350
どこもそうだな
はじめに方針をいってくれりゃいいけど
大抵は出来上がったものをみてそれに文句いうだけだしね
だったらこっちが全部書いてしまう前に数ページ書いたらまずレビューしてくれと
それでフォーマットがある程度決まってから作りたいけど
そんな時間とってくれないよね
はじめに全部作らせて後からアレが足りないこれが足りないって結局書き終わる頃には
２～３ヶ月は経ってるしそのお金全部こっちもちとかもうね
開発にドキュメント書く時間も含めて請求すると２～３倍にはなるよね
どうせ金だしゃしねぇんだから本当に書きたくない
352:仕様書無しさん
09/12/06 16:52:37
>>351
>はじめに方針をいってくれりゃいいけど
>大抵は出来上がったものをみてそれに文句いうだけだしね
あるあるｗ
嫌がらせ目的だとしか思えないんだよな
まぁ嫌がらせなんだろうけど
353:仕様書無しさん
09/12/06 17:22:58
句読点打てよ、キチガイ。
354:仕様書無しさん
09/12/06 18:47:48
>>353みたいなことと仕様じゃなく実装について
言って来る客との仕様書レビューを見た。
諸外国との競争に日本が負ける理由がよくわかった。
355:仕様書無しさん
09/12/06 19:13:33
「みたいなこと」が何か知らんが、
句読点がないことと同レベルな仕様書かよ。
日本の足をあんまり引っ張るなよ。
356:仕様書無しさん
09/12/06 21:31:13
>>355
意味がわからない
何がレスの主旨なの？
357:仕様書無しさん
09/12/07 04:16:57
まともな仕様書書けってことだろ。
358:仕様書無しさん
09/12/07 06:29:36
>>357
はぁ？どこが？
句読点が一番大事なの？
馬鹿なの？死ぬの？
359:仕様書無しさん
09/12/07 06:39:39
これだから、卒論も書いてない高卒は・・・
360:仕様書無しさん
09/12/07 18:23:26
>>355
>日本の足をあんまり引っ張るなよ。
まったく、在日は迷惑よね。
361:仕様書無しさん
09/12/07 21:46:16
> ・・・
句読点が云々論文が云々言うなら三点リーダー使うだろJK
362:仕様書無しさん
09/12/07 22:38:38
他人がまともな文章を書けないのと、自分がまともな文章を書けないのには関連性は無いよね。
どんなにおかしい日本語で指摘されても、自分の文章は正しくならないよ。
363:仕様書無しさん
09/12/08 02:29:31
>>362
何が言いたいのかさっぱりわからない
上段の文章と下段の文章の関連を教えてくれない？
364:仕様書無しさん
09/12/08 11:27:54
変な日本語で指摘されて、それが変だと指摘しても自分の文章のおかしさは変わらないってことでしょ。
つーか、正しい日本語で仕様書を書きましょうって言ってるだけなのに、何で抵抗するのかなぁ。
365:仕様書無しさん
09/12/08 19:06:08
少なくとも社内内輪向けの設計書は、出来を罵倒するんじゃなくて
足りない部分を明確に指摘してほしい。
社外向けに納品する書類が出来ないのはアホ上司のせいなんだが
お前印鑑おさねーだろ。だから俺も出さない。会社がどうなろうとしらん
366:仕様書無しさん
09/12/08 19:07:22
>>364
はぁ？意味がわからない
他人の文章は関係ないんでしょ？
変な日本語で指摘されようが、なんだろうが関係ないじゃない
上の段の文章は他人の文章と自分の文章に関連性がないことを主張しているにも
関わらず下の段の文章はおかしい日本語で指摘されたからわからない
ってとれるじゃんここが意味がわからない
上の段で関係ないって言ってるのに下の段では正しい日本語で指摘されたら効果があるみたいに読めるじゃん
だから変なパラドックス入った文章だな
って思いました○
367:仕様書無しさん
09/12/08 19:39:34
お前は中卒か
368:仕様書無しさん
09/12/08 19:40:43
他人が人を殺したからといって、自分の殺人は正当化できないってことだよ
369:仕様書無しさん
09/12/08 19:45:11
>>365
客との仕様書レビューの話だよ。
客が正しくない日本語に文句つけるようだったら、正しい日本語で書けば良いだけの話だ。
ぐじぐじ言う意味がわからない。