この会社辞めようと思った腐れ上司の一言0x20

この会社辞めようと思った腐れ上司の一言0x20 at PROG

85:仕様書無しさん
07/12/21 23:02:32
転職していきなり丸投げされた仕事、せっせことVC++で組み上げたんだけど、
出来上がってから上司に、誰が見ても分かるようにファイル名と
クラス名を全部識別コードに置き換えろ、と言われたんだけど、
これって普通なの？（ってか先に言えよ…）

書き換えた結果、AA00001.cppとかAB00002.cppとかもはや暗号と化した
ファイルやクラスがうん百と並んでるんだけど…。
英語名とか、可読性が落ちるから使っちゃダメなんだって。

86:仕様書無しさん
07/12/21 23:05:49
>>85
置換ツールでも作って提出時にかければいいよ。
そんな悪しき習慣にとらわれた会社からは脱出すべし

87:仕様書無しさん
07/12/21 23:11:55
>>86
習慣か。こういう要求って結構あるものなの？
俺には>>85みたいなのはネタにしか見えない。

88:仕様書無しさん
07/12/21 23:26:19
>>85
ご愁傷。

>>87
ある。
というかあった、数年前に常駐してた糞会社では。
今も会社が残ってるかどうかは知らんｗ

89:仕様書無しさん
07/12/21 23:28:08
>>85
こういうソースコード使ってる人って、
逆コンパイルしたソースコードそのまんまなんだろうな。

僕は名前が付いてないとさっぱり分からないから、
逆コンパイルしたら解析して名前を付けるところから始めるが。

90:仕様書無しさん
07/12/21 23:36:24
>>85
コボラー出身者にはよくある。
可読性というか、変数や関数をグローバールスコープに全て詰め込んで
一覧表がなければ目的のものを探せないような設計をする人がリーダーだとそうなる。

91:仕様書無しさん
07/12/21 23:49:44
ないないw
廃刊になったCマガ系のライターがよく書く妄想ネタそのものじゃん。

こういうネタ書く奴ってのは自分の能力に自信がないからさあ、
馬鹿にして蔑む対象を持ってないと不安になっちゃうんだよw

92:仕様書無しさん
07/12/21 23:50:47
たとえそれが妄想の産物であっても、の一行を書き忘れた

93:仕様書無しさん
07/12/21 23:51:41
>>85
こういう上司はそもそもVC++なんて読めないんじゃね？

94:仕様書無しさん
07/12/21 23:55:06
パソコンを製造している某企業が作っている
Java製の銀行業務ソフトのソースがそんな感じだったぞ。

95:仕様書無しさん
07/12/21 23:58:15
逆コンパイルして便宜上適当につけられた関数名を見て
本当にプログラミング時から関数名がそんな風につけられていると
よく知らないライターが勝手に勘違いしちゃったという線はないのか

96:仕様書無しさん
07/12/22 00:03:54
いや、コード体系としての意味はあるんだ。
最初の1文字は業務の区分を示し、次の2文字は、処理の種類のコードとかな。

97:仕様書無しさん
07/12/22 00:11:10
で、関数コード体系表とか変数コード表とかの冊子みたいなヤツがあるのよ。
それを見ないと何の関数なのかわからんの。

98:仕様書無しさん
07/12/22 00:11:24
>>91
あるってばｗ
設計書書く段階からして「管理台帳」から連番取って
このモジュール名はA102200-01とする、から書き始めなきゃいけなかったり。

ひどい所になると内部変数名も a_（コーディング年月日）_（連番）とかに
しなきゃいけなかったり
しかも a_ の部分は a…整数 b…文字 c…浮動小数点数とか
一般的な略称（i_ とか c_ とか）とはかけ離れた命名規則で、それをやっぱり
「管理台帳」を使うことでようやく意味が把握できる、とか・・・。

いや、そういうプロジェクトと関わり合いになったことがないなら幸せだし
今後も避けることはお奨めするけどな・・・ｗ

99:85
07/12/22 00:16:04
うほ、ネタ扱いされてるし…。

>>93
正解。
上司はVBプログラマーで、C++は専門で囓った程度、とか言ってたよ。

なんか上司が嫌みったらしく言うには、今の状態じゃどうせ君しか読めないんだから、
改変とか今後やる人間にとってはこういう形のほうが良いに決まってる、
だそうだ。

とりあえず、ソースもロクに読めない人間に改変させるなよ、と言いたい。

100:仕様書無しさん
07/12/22 00:26:36
その手のコードは番号を一つ間違えるだけで大変だろう
チェックサム入れてみたりしてないかい？

101:仕様書無しさん
07/12/22 00:30:28
俺はVC++じゃなくてDelphiだったけど
C0101001.pasなんて当たり前だったぜ。
CがシステムのＩＤ、01がサブシステムID、
残りがプログラムIDだ。
どうだまいったか。

>>91の自信がどこから沸いてんだかしらねぇけど
幸せもんだな、うらやましいよ。

102:85
07/12/22 00:32:04
>>96
そうそう、先頭のアルファベットが一応の機能別にはなってる。

>>97
その一覧作らされたよ。
今のままでも分からないんだから管理コードにしても一緒だろってさ。

>>98
幸い変数までは言われなかったよ…。

103:仕様書無しさん
07/12/22 00:33:54
DBのテーブル名とか列名がそうなっていることもあるぞ。
暗号そのものなSQLが地獄なんだぜ。

104:仕様書無しさん
07/12/22 00:36:22
俺もこういう話、ネタだと思っていたけど
でかいシステム作るときあんまりウィンドウの数が多くなってそのひとつひとつを
UTやらITやら連番でテストやってくとさすがに名前なんていちいちつけてられない

WT00GTyyHHTTU0102
分類：ウィンドウID：種別ID：・・・
なんてしておいたほうが絶対管理しやすい
あんまりでかいとウィンドウ作るだけでだるくなる
名前なんて機械的にふるしかない
並べたときにそろってないってだけで管理で死亡

こういう世界があるとは思わなかった・・・
連番は必ずしも駄目じゃない・・・

105:仕様書無しさん
07/12/22 00:38:19
ぶっちゃけると名前だろうがIDだろうが駄目な時は駄目なんだけどな。。。。

106:仕様書無しさん
07/12/22 01:00:58
IDが管理しやすいとかいう以前に、初老のSEはそういうものだと思い込んでいる。
名前空間やクラスを階層状に作ればわかりやすいといくら説明してもなぜか通じない。
別の関数に同じ名前を付けちゃったら混乱するだろとか言われるんだよ。
異なるクラスに同じ名称の関数があっても大丈夫だという説明も理解しているんだとは思うんだが、
なぜか許せないらしい。

107:仕様書無しさん
07/12/22 01:03:40
まローマ字つける奴とどっこいどっこいだな

108:仕様書無しさん
07/12/22 01:19:06
で、ローマ字も"jyu"なんて書いたりする

109:仕様書無しさん
07/12/22 01:27:42
>>106
>名前空間やクラスを階層状に作れば
否
一番わかりやすいのは一覧
階層は最悪
数が多くなったときに絶対死ぬ

>異なるクラスに同じ名称の関数があっても大丈夫だという説明も
>理解しているんだとは思うんだが、なぜか許せないらしい。
ちゃんとXXX：：XXXXXまで書けば許してくれるんじゃね？

結局、オブジェクト指向ってどうなのかなぁ・・・って最近思うようになってきたよ俺は
階層になってるとテスト一覧とか作りにくいだけでなんのメリットもないじゃん
数が爆発的に多くなってきたときに果たして複雑なツリーから規則的な一覧を作れるかどうか？
って話が仕事に直結してるわけでな・・・

110:仕様書無しさん
07/12/22 01:41:58
そりゃ、一覧を作るためのやってるんじゃないからな。

111:仕様書無しさん
07/12/22 01:49:33
つか、オブジェクト指向ならﾊﾞﾗして個別テストするのが普通だろ
それが出来ないのならオブジェクト指向に反してる

112:仕様書無しさん
07/12/22 01:51:17
>>110
でも、何度もテストするし、一覧を作れなきゃテスト項目も作れない
結果、品質が劣化してしまうのなら、なんのためのオブジェクト指向なのかわからない
ソースは定量的に書くべきなんじゃないかと・・・

結局、全工程のうちの設計と開発しか見えてないんだよな
この手法って・・・

113:仕様書無しさん
07/12/22 01:53:50
>>111
組み合わせたら結局テストやり直さなきゃいけないだろ？
組み合わせて動くかどうかはやっぱりやってみなきゃわからない
いくら理論上「動くはず」であってもそれはやっぱり予想でしかなくて確定ではない
仕事では許されないし、実際、テストはやらなきゃ承認はおりない
場所によるかもしれんが少なくとも俺の派遣先では駄目

114:仕様書無しさん
07/12/22 01:57:18
>>113
組み合わせないと動きが判らないってのはその時点で既に間違ってますよって事だよ
実際にあわせて動きがおかしいのならそのモジュールにはバグがある

個別の問題があるからこそ組み合わせた時に問題があるのであって
組み合わせたモノに問題があるのではないよ

115:仕様書無しさん
07/12/22 01:57:53
>>112
> 結果、品質が劣化してしまうのなら、なんのためのオブジェクト指向なのかわからない

オブジェクト指向だと品質が劣化するって事か？
それともどのような開発手法であっても、品質が劣化するって事か？

なにがいいたいのかわからん。

116:仕様書無しさん
07/12/22 02:09:34
>>114
そうとは限らない
組み合わせてはじめてでる問題も当然ある

例えば音を鳴らすモジュールが２つあって片方は曲、片方は音声
組み合わせて動作させてみると同時には鳴らないといったような問題が出ることもある

仕様の考慮漏れか、バグにするかは悩むところだが
単体では動作し、結合では動作しない問題が起きたことを明記する必要がある

117:仕様書無しさん
07/12/22 02:14:04
それはひょっとしてモジュール分割の時点で既に間違ってるんじゃ・・・
合掌

118:仕様書無しさん
07/12/22 02:14:40
>>115
レスの要点を言うとオブジェクト指向だと品質が劣化するってことだな
２行目は意味不明、そんなこと言ってない

ただ、お前、オブジェクト指向だと品質が劣化するといっても
何と比べて品質が劣化するといってるかわかって質問してるか？
いきなり噛み付いてくるなよ

119:仕様書無しさん
07/12/22 02:20:34
>>116
音のモジュールが何で別々になるかは別として、そういうのもあるんだ
ウチは基本ソフトウェアだからそういうのはほとんどないわ

120:仕様書無しさん
07/12/22 02:30:52
>>116
一覧にした方が良いというのは、
その例だと、AとB2つ同時に鳴らす処理と、
AとBを各々鳴らす処理を完全に別の処理として作るってことなのか？

121:仕様書無しさん
07/12/22 02:48:08
>>119
曲はストリーミング、
音声は短い場合はメモリに溜め込んでおく処理になるから別にしちゃうことも多い
ストリーミングを同時に２つとかでも、プログラム自体にエラーはなくても
動作のエラーとして遅延をすることがあるため動作に問題があるレベルで遅延したらこれもバグだろ？

別に音じゃなくてもメモリからデータをロードに置き換えてもいいけど・・・
想像できないかな？
動画データをメモリからロードでもスムーズにできなきゃ駄目だよね？
単一モジュールでバグはおきないけど単純に同時に実行したら
なにも考えてなかった普通にバグりそうじゃない？

122:仕様書無しさん
07/12/22 02:55:43
すべての組み合わせをテストしている兵がいるみたいだな。
ちょっとしたプロジェクトになれば１秒１テストでも１００年かかるなんてことも普通なのにすげぇな。

123:仕様書無しさん
07/12/22 04:47:00
とりあえずオブスレこいや

124:仕様書無しさん
07/12/22 05:32:33
さっき、引越で転出届出したら死亡届として社保庁に通知されて
年金支給停止されてる人がいるって。

オペレータ（窓口）が、転出を意味する３１と入力すべきところを、
３２と、死亡を意味する数字を入力したんだってさ。

役場じゃ税金とれなくなる転出も死亡もまったく同じ扱いなんだね。

125:仕様書無しさん
07/12/22 09:25:14
>>124
ソースではコンパイルエラーで大抵ひっかかるから
当てはまらないケースやホントにレアなケースを言ってるよね？

126:仕様書無しさん
07/12/22 09:26:08
レアなケースをあげて全体を見てない奴って昔の俺を見てるみたいでむかつくなｗ

127:仕様書無しさん
07/12/22 11:09:39
名前をIDにすると、検証すべき組み合わせまで分かるってすごいよな。

128:仕様書無しさん
07/12/22 11:46:05
>>125
おまえは何を言ってるのか

>>126
全体を見てないって何の話だろうな。

生きてることが確認できても支給することがルールとして認められていないのは全体とは関係のない
矮小な、ほとんどには当てはまらないようなことなんだろうか。

たんなる入力ミスが復旧できないって言うのに。

129:仕様書無しさん
07/12/22 11:47:25
そもそも行政のシステムは二重請求できるシステムだから
抜け穴ばっかりなんだろう。

130:仕様書無しさん
07/12/22 11:48:51
振り込みミスしたときはたった１０００円なのに何度も電話してくれて手紙まで持ってきてくれたよ。
金額が５０マン以上のときは追い返されたけど。

131:仕様書無しさん
07/12/22 11:52:15
>>82
知ってる人かも。
にしてもKYネタとはwww

132:仕様書無しさん
07/12/22 11:55:37
俺的にはオブジェクト指向はかなりバグを減らせると思う。

133:仕様書無しさん
07/12/22 14:23:54
>132
まずは設計者の脳内からバグを追い出してもらおうか。

134:仕様書無しさん
07/12/22 15:34:52
>>133
そこはオブジェクト指向とかあんま関係ないから
まず手前様が何とかしてくれ

135:仕様書無しさん
07/12/22 18:23:28
腐れ上司の話題は？？

136:仕様書無しさん
07/12/22 18:33:41
言葉の意味を正しく理解してない上司の一言があったのでは？

137:仕様書無しさん
07/12/22 20:06:27
ここでテストファースト厨が一言

138:仕様書無しさん
07/12/22 20:16:02
まず上司をテストして、駄目なヤツはクビにしていけば、そのうちまともなのが残るンじゃね?

139:仕様書無しさん
07/12/22 20:17:29
だれも残らないというオチ

140:仕様書無しさん
07/12/22 20:30:23
20年前の実装大切にしてる人は、実務から外れた方がいいんじゃないかと思う。

141:仕様書無しさん
07/12/22 21:08:59
>>132
無理無理、それはオブジェクトの数が脳内で手に負える範囲であることが条件
１００単位でインデックスつけて管理しなきゃいけないようになったら
いちいちオブジェクトに名前つけてらんない
せいぜい種別や番号だけ

結局、数が少なけりゃどんなやり方したってできんだよ
って話しかしてねぇな

142:仕様書無しさん
07/12/22 21:14:11
>141
どんだけ管理能力が無いんだと、小一時間(ry

143:仕様書無しさん
07/12/22 22:57:13
>>141
クラスの数なんてすぐ100超えるけど、名前つけに困って連番ふるなんて
やったことねえな。

自分が手作業のしょぼい品質管理しかできてないからってそれを普通だと思うわないほうがいいよ。

144:仕様書無しさん
07/12/23 01:40:38
>>141
”１００単位でインデックス”て、総数どれだけの規模さ？　
大体でも数いわないと、管理能力の不足なのかそうでないのかの判断つかね-よ。

145:仕様書無しさん
07/12/23 02:05:06
>>84
亀レスだがお前の狭い知識だと理解出来ないみたいだね。ご愁傷様。

>>143
実際、システムの規模によってはクラスの命名等も
連番で振る等のほうが良い場合はあるし、実際にそうしているところも多いよ。

理由はまさに>>141の通り、例えばウィンドウ周りとかDB周りとか。

余談だけど、オブジェクト指向が実際の業務に
適しているかというと必ずしもそうでもない。
例えば、巨大なプロジェクトを人海戦術で回す場合とか
運用しながらシステムを拡張していく場合とか。

146:仕様書無しさん
07/12/23 02:10:44
>>144
実際、ちょっとしたアプリケーションくらいじゃないの？
クラス数が数100程度で済む単位ってのは。

147:仕様書無しさん
07/12/23 02:39:08
>>144
こないだ作ったので俺のところだけでも約３０００ぐらい
こんなの３０００回もクラス名決めてらんないってｗ

148:仕様書無しさん
07/12/23 02:49:24
>>147
オブジェクト指向言語で仕事したことないからそれがどの規模かわからんが・・・
だからって3000個全部が連番ってことはないんじゃね？
内容が異なるから異なるクラスが作られるわけなんだし。

149:仕様書無しさん
07/12/23 03:50:01
似たような処理なら一部連番になるのはやむをえないが、
そのプロジェクトで使うクラスすべてを連番にするってのはどう考えても普通じゃない。

そんなのは化石時代のマやPLCプログラマの発想だ

150:仕様書無しさん
07/12/23 04:52:48
>>148
一応命名規則があって種別？＋ID+種別？＋IDって形になってるけどね
連番は種別＋IDのIDの部分だけだよって前も書いてるやんけ

>>149
まあ、時間があったら考えればといいと思うよ
ただ、この規則を無視するとテスト一覧とか他のフォーマットに影響がでるからね
そこのケツまでしっかりサポートできるならやったらいいかも
階層になってるともうテスト一覧つくれんねｗ

せっかくできてるこのシステムを崩す必要もないからねぇ
仮にオブジェクト指向的にツリー構造でクラス構築したときに
うまいテスト一覧や詳細仕様の作り方があればいいけどなかなかマッチするように作れないっしょ？
定量的にできないのが欠点なんだよね

151:仕様書無しさん
07/12/23 09:34:37
>>150
お前みたいなのとは一生関わる事はなさそうだから、連番だろうが何だろうが好きにやってくれ

クラス名払い出しソフトとか変数管理D/Bとか使ってるんだろ？
もう住む世界が違いすぎてコメントもできねぇよ

あんたの方が俺より上等な仕事をしてるってことにしてやるからもうこの話は終わりな

152:仕様書無しさん
07/12/23 10:32:48
>>150
ネタにしてもつまらないな。

153:仕様書無しさん
07/12/23 10:34:43
>>150

>仮にオブジェクト指向的にツリー構造でクラス構築したときに

↑この辺りの発言で OOP が何なのかさっぱり分かってないのが良く分かるな。
同じ土俵に乗れない奴は、引っ込んでろよ。

154:仕様書無しさん
07/12/23 10:42:25
>>150みたいなのはさ、「枯れた技術や方法論を知らない若造って惨めｗｗｗ」
なんて思っているんだろう。実際は自分の知識が立ち枯れちまってるのにな。
職場で若手に白い目で見られてイライラしてるのかも知れないが、
ここで憂さ晴らししようとしてるのなら、みっともないからやめとけ。

あとな、>>150みたいな考え方は、広く受け入れられなくなってるから、そこのところも理解しとけ。

と、化石時代の俺から忠告。

155:仕様書無しさん
07/12/23 10:55:23
Windowsという大規模プログラムでも連番じゃないんだから
連番なんてアホだよ

156:仕様書無しさん
07/12/23 11:34:55
>>151-154
罵倒ばっかりで全然代替案がないな
くやしいくやしい言い返せない
それしか伝わってこないぜｗ

157:仕様書無しさん
07/12/23 11:56:26
番号が振ってあるのはいいけど、
名前がないプログラムなんて使えないよな。

0001って何のプログラムだっけ？
ああ、連番がついてるのはテンポラリファイルだから削除して。
いや、それはウィルスが検出されたファイルだから防疫センターに送らないと。
いやいや、ディスクが壊れてて修復されたファイルですよ。HDD取り替えないと。

158:仕様書無しさん
07/12/23 12:17:43
>>156
おっと！勝利宣言です！

ところで、
> 仮にオブジェクト指向的にツリー構造でクラス構築したときに
> うまいテスト一覧や詳細仕様の作り方があればいいけどなかなかマッチするように作れないっしょ？
> 定量的にできないのが欠点なんだよね
これ、命名規則にID使ったらなんで定量的になんの？
テスト一覧も詳細仕様も内容の問題であって、名前関係なくね？

あと、G172351とかそういうIDな名前をぱっと言われて、「これ何？」って言われてすぐに思い出せる？
逆に「こういう機能はなんてクラス？」って言われてぱっと答えられる？
いちいち一覧見るの？

さらに、クラスが追加追加でID桁足りなくなったときどうするの？
桁足すために全ソースに手入れんの？

くわえて言うと、クラス数3000って多すぎね？MFCにも3000もクラスあるとは思えないし、
.NET Frameworkでもそんなにあるかね？
なんか設計に問題あるんじゃね？

159:仕様書無しさん
07/12/23 13:25:17
1変数1クラス
当然でしょ？

160:仕様書無しさん
07/12/23 14:41:48
タグ：【これはひどい】【突っ込みどころ満載】

161:仕様書無しさん
07/12/23 14:45:19
もしかしてローカル変数まで一つ一つユニークなID振らなきゃだめなのか

162:仕様書無しさん
07/12/23 14:53:47
ごく稀な例を持ち出して
連番こそ最強って云いたいだけだろうから
ほっといてあげてくれｗ

163:仕様書無しさん
07/12/23 15:00:46
まあ、自分のやってる仕事を否定したくないんだろうなｗ
気持ちはわからんでもない。

164:仕様書無しさん
07/12/23 15:03:49
>>161
無くはないｗ
ローカル変数という概念はなくて全部グローバルで
それを「変数表」に載せろ、それこそが一貫性、可読性だ
というボコラーが巣食うプロジェクトも経験した

変数の型や役目など知ったこっちゃない
　(プロジェクト略称)_(モジュールID)_(コーディング年月日)_(通し番号)
みたいな命名規約が存在して
例えば、ただの for (int i=0 …のときに使う i みたいな物でも
　A10_B002_071223_001：ループインデックス
とかｗｗ

165:仕様書無しさん
07/12/23 15:10:29
>>164
なんじゃそりゃ・・・
文字通り工業的に管理生産されてるわけか
ソフトウェア工場ここに極まれりだな

166:仕様書無しさん
07/12/23 16:50:19
いい加減スレ違いだということがわかっているのかが心配だ。

167:仕様書無しさん
07/12/23 18:29:02
連番振るとか馬鹿みたいなこといってる奴は自分が
どんだけ会社に損害与えてるかわかってないんだろうな・・・

168:仕様書無しさん
07/12/23 19:04:04
>>164
そこまでするんならソースコードのバージョンと行番号で管理すればいいのにな。
１関数１ファイルにして、変更無ければ行が移動しない。
定義はファイルの先頭に集めれば、処理が変更されても変数の定義位置は変わらない。

そもそもソースコードをプログラムで処理してサポートするって考えないのかな。

169:仕様書無しさん
07/12/23 19:16:45
>>158
>これ、命名規則にID使ったらなんで定量的になんの？
いきなりそんなこと書いてないけど？
あくまでオブジェクト指向で階層つけて作ったときの話をしてからしてるでしょ？
レス読んだ？

>テスト一覧も詳細仕様も内容の問題であって、名前関係なくね？
命名規則から自動でテスト項目に落とせるって程度なんだけど？
そりゃ構造的にはできるけど実際の作業としてひとつひとつ命名していくやりかたで
テスト一覧作ったらどんだけ工数かかるの？
種別＋IDって決めてあるのはそういうことだよ

>あと、G172351とかそういうIDな名前をぱっと言われて、「これ何？」って言われてすぐに思い出せる？
種別＋IDって書いてるのに人のレス全然読まないの？馬鹿なの？

>さらに、クラスが追加追加でID桁足りなくなったときどうするの？
>桁足すために全ソースに手入れんの？
拡張の意味をもつ種別を増やしてそこに追加
その程度も想像つかないの？

>わえて言うと、クラス数3000って多すぎね？MFCにも3000もクラスあるとは思えないし、
小さいクラスまで含めて言ってるけど？
しかもMSのは１つのクラスがかなりでかいと思うんだけど？

はい、全部返しましたよ
あなたの疑問に答える回答はあったでしょうか？

170:仕様書無しさん
07/12/23 19:17:25
>>168
それじゃコメント削除しただけで色々変更しなきゃいけないじゃん
テキトーに言ったにしても馬鹿すぎる

171:仕様書無しさん
07/12/23 19:51:00
>>169
あんたのネタはつまらないってそろそろ気づいてくれないかな
今時関数名やクラス名がIDになってて台帳管理してるなんて語ったところで誰が信じるんだよ。
うちのコンピューターは真空管式で、プログラムは配線を切り替えてやるんだってくらいありえねぇだろ。

172:仕様書無しさん
07/12/23 20:22:39
>>171
しかし、多くの場合真実は小説より奇なり

173:仕様書無しさん
07/12/23 20:50:21
おまえらって、結局自分が正しい、間違った奴には負けを
認めさせないと気がすまない、かなりＫＹな存在だよな。
そんなだからＰＧ/ＳＥが馬鹿にされるんだぜ？

普通にスルーする/できるのが一般社会人
（何事も思い通りにはいかない事を知り、その中で和をとりつつ最善を目指す）

さて、叩きくるかな？

174:仕様書無しさん
07/12/23 20:58:47
方式の議論ならまだいいよ
自分の経験にないことはネタだとしか書き込まない
見識の狭い奴はどいてくれねえかな

175:仕様書無しさん
07/12/23 20:59:08
自家撞着

176:仕様書無しさん
07/12/23 21:28:12
>>170
＞それじゃコメント削除しただけで色々変更しなきゃいけないじゃん

何を変更する必要があるってんだ。
テスト仕様書か？

177:仕様書無しさん
07/12/23 21:58:29
てか、オブジェクト指向ってどっちかてーと
再生産性にかかわるんじゃねーかな。

テストが大変とゆーよりも、テストどころか
開発そのものを省略させる場面に意味がある
キガス。

178:仕様書無しさん
07/12/23 22:09:47
>>177
確かに連番なんてあとのメンテや変更を無視した使い捨てだしな。

179:仕様書無しさん
07/12/23 22:29:00
>>178
ここ数年年代物の連番プロジェクトを片づけまくっている俺には使い捨てなんて言葉は慰めにもならないわけだが...orz

180:仕様書無しさん
07/12/23 23:03:31
【数々の悪行】ＭＯＴ　牧野聡代表
・７億円の脱税
・本山グラフシステム時代の偽装請負
・社名変更や似た名前の異なる会社を用いての詐術行為、トカゲの尻尾切り
(MOT,MOFT,本山グラフシステム,本山グラフシステム(MGS),有限会社,株式会社等 )
・経歴詐欺の強要、経歴粉飾による単価吊り上げ
・強引な勧誘工作、脅迫メール、洗脳工作、無理な退職引き留め
・面接後に、証拠にさせないための名刺回収
・求人票の仕事と実際の仕事で内容が全く異なる
・多重派遣、事前面接は当たり前(社員がバックレても会社の責任になります)
・社会経験の乏しい学生やフリーターをカモにしている
・会社ぐるみのボッタクリ（社内マニュアル有り）
・労働者の使い潰し、極端なまでの中間搾取、給与を改竄しての極端な値引き、
最終月の給与未払い、残業代未払い、寮費の非常識搾取、ボーナスゼロ、
交通費自前、有給休暇無し、福利厚生さえ渋る
基本給が存在せず、働いた分だけがその月の給料になる。
・正社員になれるとうたいつつも契約社員のまま
・昇給の約束をした後に、難癖つけての昇給無し
・年金手帳とか雇用保険被保険者証等の書類は、請求しないと出さない。
（普通は言わなくても出してくれる）
・仕事で必要なノートＰＣを自前で買わされ、
レシートのコピーを会社に提出させられた（脱税に用いられた疑い有り）
・残業を一番多くした人間に対しては図書券を出すと言いつつも、
一番多く残業をした架空の人間をでっちあげ、図

181:仕様書無しさん
07/12/23 23:26:34
>>178
そうかい？
テスト一覧は作るの楽だけどねｗ

182:仕様書無しさん
07/12/23 23:30:01
プログラムの設計や作成には苦労することになるけどな…

183:仕様書無しさん
07/12/23 23:50:48
>>181
ソースコードも見ないでエクセルで連番作るから楽なんだろうな。

184:158
07/12/23 23:51:48
>>169
> >>158
> >これ、命名規則にID使ったらなんで定量的になんの？
> いきなりそんなこと書いてないけど？
> あくまでオブジェクト指向で階層つけて作ったときの話をしてからしてるでしょ？
> レス読んだ？

ごめん、これはたしかに俺の読み間違いだ。取り消す。
ところで、
> 定量的にできないのが欠点なんだよね
と言ってるが、じゃあ「定量的にできる」方法はなに？

あと、えらく「種別が重要であってIDは補助」と主張してるようだが、
これの説明が無いのでイマイチ想像できない。具体例挙げて説明して欲しい。

> >あと、G172351とかそういうIDな名前をぱっと言われて、「これ何？」って言われてすぐに思い出せる？
> 種別＋IDって書いてるのに人のレス全然読まないの？馬鹿なの？

とくにここ。もし種別がなんらかの一般的な単語だとして、じゃあ今度は
「CBit01」と「CBit02」の違いはなに？って質問が考えられる。

> >さらに、クラスが追加追加でID桁足りなくなったときどうするの？
> >桁足すために全ソースに手入れんの？
> 拡張の意味をもつ種別を増やしてそこに追加
> その程度も想像つかないの？

あなたが「種別」の説明をしてないので想像できません。

> 小さいクラスまで含めて言ってるけど？
> しかもMSのは１つのクラスがかなりでかいと思うんだけど？

小さなクラスが大量にあるってのもへんな設計な気がするよ。

185:仕様書無しさん
07/12/24 00:00:15
>>184
> 小さなクラスが大量にあるってのもへんな設計な気がするよ。
継承を使わず、ほとんど同じで少しずつ機能の違うクラスが山のようにあるんじゃね?

186:仕様書無しさん
07/12/24 00:03:50
>>183
ソースコードと命名規則表を渡すだけでなんも知識ない奴でもテスト一覧が作れて単体テストができるのが楽
つっても打ち合わせはやっぱり必要だけどｗ

187:仕様書無しさん
07/12/24 00:07:33
>>186
連番との関連性がないんだけど。

188:仕様書無しさん
07/12/24 00:13:51
>>184
はぁ？もう自分の何を導き出すためにしてる質問なのか意味不明だな
種別もIDの説明もちゃんと上から読めば書いてあるし

正直、お前のレスの前まではみんなが経験した共通の知識の元で会話していた
からお前みたいになんの経験もないようなのがなんの知識もなしに
会話に参加しようとした時点でたくさん説明が必要で面倒で会話成り立たないよ

なにせ状況を説明するのに必要な前提知識が乏しすぎる
算数しか知らない小学生に高校３年程度の数学教えるようなもの

まず、自分の一番の疑問は何で
そのためにこんな質問をしてるってのを明確にしてくれない？

レス返しても「その質問はちょっとしてみただけで実は私の疑問をなにも解決しません」じゃ
お話にならない

まず、一番聞きたいことを１つにまとめて書いてくれない？
どうしてもまとまらない、疑問が２つ以上にわかれてしまう場合はそれを明言してから質問してくれない？

189:仕様書無しさん
07/12/24 00:17:37
>>188
>>186について、
名前が連番である意味がみじんもないことはどう説明してくれる？

字が読めませんかけませんとかそういうわけでもないだろ。

190:仕様書無しさん
07/12/24 00:21:40
>>189
意味がないって何に対して？

191:仕様書無しさん
07/12/24 00:22:37
ところで一番聞きたいことは>>189でいいの？

192:仕様書無しさん
07/12/24 00:23:33
>>188
最初から読んでみたけど、
> お前のレスの前まではみんなが経験した共通の知識の元で会話していた
ようには見えなかった。

まあ、はなから人を馬鹿にしたようなレスしかできない奴は大抵自分が一番馬鹿。

193:仕様書無しさん
07/12/24 00:24:10
>>192
なんかいきなり違うことを話はじめたけど
質問はもういいのかな？

194:192
07/12/24 00:25:44
あ、言っとくけど俺は 184 じゃないからね。
IDなし板はめんどくさいな。

195:仕様書無しさん
07/12/24 00:37:56
>>186
これはわからんなぁ。
なんで命名規則とソースコードだけでテスト一覧（？）

ん？そもそもテスト一覧って何だ？

196:仕様書無しさん
07/12/24 00:45:56
URLﾘﾝｸ(thumb2.uploda.org)

197:仕様書無しさん
07/12/24 00:48:09
タンポポを載せ易くするために刺身はこうあるべきだと議論するスレ

198:仕様書無しさん
07/12/24 00:50:58
テスト内容をソースコードから作るってこと？
それテストになるの？

199:仕様書無しさん
07/12/24 00:52:30
>>190
何に対してとは？

じゃあ逆に教えてください。
何に意味があるんですか？
テスト一覧と連番の関係を

ソースコード読めない奴でも変数が幾つあるか数えることが出来れば
一覧表作れるって意味なんでしょ？
そんな奴の作ったテスト一覧なんか見る価値ないでしょ？

200:158
07/12/24 00:54:48
>>188
いきなり罵倒されてしまいました。

じゃあ一つに絞ろう。
「種別+IDという命名規則の具体例を挙げて説明してくれ」。

一応スレを「種別」で検索してみたら
>>104 >>141 >>150 >>169 >>188が引っかかった(自分で書いたのは除外)。
少なくとも俺の足りない脳みそじゃ「種別の具体例」はどこにも無いように見えるんだが。

201:仕様書無しさん
07/12/24 00:55:23
上司の言葉じゃないんだけど

仕様書に書かれていることが全部中途半端で、日本語がおかしい

コレは辞める理由になりますか？

202:仕様書無しさん
07/12/24 00:56:09
種別+ID制は完璧で、理解できない奴は前提知識が乏しすぎる。
だめな奴には単体検証を任せないから問題ない。

そういう事だろ。

203:192
07/12/24 01:00:19
なんかね、ム板のふらっとC#スレでの昨日から今日にかけての不毛なやりとりと
大変よく似てたもんでつい茶々入れたくなったんだけど、そこでの教訓は、
他人を頭ごなしに馬鹿にすると痛い目を見るよ、ってこと。
まあ、興味があったら見てみてね。

204:仕様書無しさん
07/12/24 01:04:17
>>203
恥かいてナンボだろ

205:仕様書無しさん
07/12/24 01:43:26
>>200
で？説明するとどうなるの？

俺が説明することで君のなんの疑問が解決して
どういう結果に結びつくのかな？

まさか、説明させるだけさせて終わりじゃないよね？
それじゃさすがに説明する意味ないんだけど？

だから、まず、一番聞きたいことを１つにまとめてくれって言ったんだけど？
「説明してくれ」っていうなら、なんらかの疑問があるんだよね？
それを言ってくれればいいんだけど？

206:仕様書無しさん
07/12/24 01:47:04
終わったかい？
続きは雑談スレで宜しくぅ

207:192
07/12/24 01:54:36
>>205
単純にわかりやすく具体例を書けば済む話なのに、
言い訳をグダグダとまあ。
ボロが出るから説明できないんじゃね? って邪推しちゃうよ。

でも、一番の疑問は、「なんでそんなに必死なの?」ってことだと思う。

208:仕様書無しさん
07/12/24 01:58:17
>>205
別に説明なんかしなくていいよ。
馬鹿には説明しても分からないんだからさ。

とりあえず結論は連番はゴミなんだからさ。

209:仕様書無しさん
07/12/24 02:00:30
お前ら上司は嫌いでも仕事は大好きなんだな
羨ましいぜｗ

210:仕様書無しさん
07/12/24 02:07:40
>>209
こんな仕事、好きじゃなきゃやってられねぇよ。

なんせ仕事で毎日プログラム書いてるのに、家に帰ればまた趣味プログラミング
してるぐらいだ。
しかも仕事とは違う言語で。

211:仕様書無しさん
07/12/24 02:54:29
>>201
なんか熱い議論のせいでスルーされてかわいそうだから・・・
前後の文章などから日本語がおかしい部分の意図が読み取れる程度のものであれば気にすることもない。
あまりにもひどく仕様が複数に解釈で来たりする場合でも、すぐに確認できるような環境があれば良い。
そういうのが多かったり、もう「日本語でおｋ」って言いたくなるような仕様書なら初めて転職を考えては？

正しい日本語で過不足なく作成された仕様書なんてなかなか巡り合えないさ。

212:158
07/12/24 03:23:44
>>205
俺の一番の疑問は「種別とやらはいったいどんなもんなんだ？」ってことだ。
だから「説明してくれ」って言ってるの。

俺が>>158と>>184で出してる質問は全体的に「種別」とやらが
分からないから発生してると自分で判断した。
個別には既に書いたとおりの疑問がたくさんでてるが、それらは
「種別」とやらが分かれば自分で解決できるものもあるだろう、と考えてる。

> 俺が説明することで君のなんの疑問が解決して
> どういう結果に結びつくのかな？
> まさか、説明させるだけさせて終わりじゃないよね？
> それじゃさすがに説明する意味ないんだけど？
あんたの病気が治ったりはしないよ。俺の疑問が解決する可能性があるだけだ。

213:仕様書無しさん
07/12/24 03:46:07
>>212
>俺の一番の疑問は「種別とやらはいったいどんなもんなんだ？」ってことだ
ふーん
じゃ、それで本当に答えられうのかちょっとテスト

>「CBit01」と「CBit02」の違いはなに？
仮にこれの種別（と俺が言ってるものここではCBitがそれにあたる）が
わかったところでどんな結論がでるの？

214:192
07/12/24 04:01:53
>>213
俺の疑問は、「そんなにもったいぶるようなことかよ?」ってことだな。
つうか、158 はどんな結論を出せるのかを知りたいから質問してるのに、
「どんな結論がでるの？」って質問はキチガイとしか思えん。

質問に質問で返すのは、普通は「負け」の印だよ。

215:仕様書無しさん
07/12/24 04:37:49
>>214
いやね
２ちゃんでこういう意味のない単発質問連発しておいて
結局なんにも実にならないこと多いじゃない？
質問するのは自由なんだけどねｗ
ちょっと本質と離れてない？ってとこ

結局、連番管理とそうでないのとどっちがいいかなんてお前等も答えはもってない
だから議論の節々に出たレスの揚げ足をとって人格否定から主張自体の否定につなげないだけだろ？

正面から、きっちり連番とそうでないのと優劣をはっきり示せるか？
ってところだな
はじめに主張したのがこっちだから答えてるけど
たまたま逆の立場でお前等に連番が駄目な理由を言ってみろといったところで
納得できるような説明はできないことは目に見えている

正直、無駄な議論だなｗってのは承知の上で会話してるぜｗ

216:158
07/12/24 04:52:35
>>213
もしそのような命名規則であれば、違いが名称から判別できない。
よって、プログラムを書く際に障害になる可能性が非常に高いので、
やはり使い物にならない、または使いにくい。
# CBitからビットに関係するなんらかのクラスであろう、とは予想が付くが、
# 01と02の違いが不明。名称が*適切に*付いていれば、一度調べたら
# 数字よりは覚えていられるはず。
# この辺が「いちいち一覧見るの？」に繋がる。

>>215
勝手に決めないで欲しいな。俺は連番否定派だ。
ただ、連番肯定派がいたから、なぜ連番がいいと考えているのか聞きたかったのが
根底にある。もし連番のほうがいいという俺が納得できる根拠があるなら
それを知りたいからね。
2chなのでついつい多少の煽りを入れたのは事実だが、
あの程度で頭に血が上ってちゃここじゃ話できないな。

217:192
07/12/24 04:57:37
>>215
連番がダメな理由なんぞすぐに出せるだろう・・・
見ただけではなにを意味してるのかさっぱりわからんとか、
継承関係がある時にIDのつけ方を入れ子にするのかとか、
そうしたらどんどん長さが増えるじゃないかとか・・・
でもまあ、そちらにそもそも「納得する」気がないから理由を言ってみても
意味ないんだろうけど。

だから、そういう問題を回避するためにどんな種別のつけかたしてるんだ?
ってのが158の知りたいことなんじゃないかと思うんだが。
そして、もしそれが理にかなったものであれば、じゃあそれを取り入れてみよう、てな
建設的な議論にもなりうるのに、あんたは「どうせ馬鹿だからわからんだろ」という
上から目線でモノを言って、のらりくらりとその利点を示さずにいるんだよ。

おわかり?

218:仕様書無しさん
07/12/24 05:05:11
>>216
>違いが名称から判別できない
おやおや、「種別」の意味もわからないのにそんな結論はでないでしょうよｗ
それともわかってるのにわかってないフリしてんの？ｗ

まあ、あおりはおいておいてｗ
それはソースだけ見た場合でしょ？
例えば、ウィンドウ内の部品だとしてスクリーンショットと
それに番号（IDね）が振ってある資料があるだけで種別＋IDの価値が上がるよね？
っていうか余計なこと書くよりこれで十分でしょ？
この状況だと逆にフルスペルで書いたもんただ長いだけで邪魔じゃない？

スクリーンショットのほかにクラス図というか機能モジュールというか
プログラムの構造を図にしたもんがあればなにもソースにすべてを注ぎ込まなくてもいいよね
仕様書とリンクしていればなおよしってところでしょ？

種別＋IDだけだと駄目かもしれんね
ただ、ちょっと別の要素が入っただけでその状況は変わる可能性があると思わない？

219:158
07/12/24 05:05:25
>>217
そう、そういうこと。
あなたとはいい酒が飲めそうだｗ

220:158
07/12/24 05:13:56
>>218
えっと、俺はあんたの言った「種別」の仮定の上で
結論出しただけなんだけど…。まぁいいや。

資料の話が唐突に出てきたけど、それは
「資料とクラス名のリンクが取れてれば便利だよね」でしかなくて、
「種別+ID」の理由じゃないと思うぞ。

> この状況だと逆にフルスペルで書いたもんただ長いだけで邪魔じゃない？
どっちにしろその横に画面なら「なんたら機能画面」って書くでしょ普通。
その「なんたら機能画面」がそのままソース上で読み取れるようなクラス名のほうが
利便性が高いと思うんだが。

ソースと設計書と仕様書がリンクしているべき、ってのは同意する。
ただ、仕様書->設計書は日本語の意味ある言葉でリンクさせる(ここでコードは使わないよね？)のに、
なんで設計書->ソースのリンクはコードじゃなきゃいけないのかがよく分からない。

221:仕様書無しさん
07/12/24 05:22:39

　　　　　,| 　　　　　.|
　　　　　 || 　　　　　||
　　　　　 || 　　 /(・) 　 ||
　　　　 |.|　　 | |　　　| |
　　　　　|　|　 /　|　　/| .|　　　
　　　　　|　| 　| __| 　/ |　|　　
　　　　　| |＼/　　l_/ /| .|　　　　　
　　　　 ||＼　　　／ '||
　　　　　|　/）　（　　|
　　　　　　(_/　　　＼
　　　　　（＿／＼＿）
　　なまえなんてどうだっていい

222:192
07/12/24 05:38:58
>>218
あんたの言ってる「種別」ってのは、あんたの会社でのルールであって、
それはあくまでもローカルルールなんだわ。
そんなのは会社によって違うんだから、その意味が他人にはわからないのは
当然なんだけど。
だから、具体的に説明しろ、と。それをあくまでも拒否する理由がさっぱりわからん。
あんたの周りで世界がまわってるんじゃないんだよ。

で、資料とセットでなきゃわからんのは、つまりコードを読む時に
常に資料と首っ引きでないとコードが読めないってことだよな?
デバッグする時に、いちいち「えーと、CBit03はなんだっけ」って資料を引っ張り出す
わけだ。
小さなメソッドであればその中で使ってる名称を覚えることもできるかもしれんけど、
これが大規模になればなるほど、どんどん難しくなってこないか?

223:私はこの一言で辞めました。
07/12/24 06:09:19
ぐだぐだいってねぇで動くモン作れや！！！
うごきゃいいんだよ！うごきゃ勝ちなんだよ！
お前らの自己マンには付き合ってらんねーんだよ！

224:仕様書無しさん
07/12/24 09:30:50
面白いから連番厨がんばれｗ
新スレが必要になるくらい

225:仕様書無しさん
07/12/24 09:42:19
連番の優位性なんてまったく無いだろｗ

226:仕様書無しさん
07/12/24 10:29:09
まあ、名前の頭やケツに番号振るのはありだと思うけどな。

第一の理由は紙の書類じゃなくて検索に使うときの足がかりだな。

100桁が大番号10桁が分類別番号一桁が機能別番号とか。
でたりなくなってＡとか1Ａとかが使われ始める(ｗ。

227:仕様書無しさん
07/12/24 11:09:24
ま、まだやってる・・・

おまえらには関係ないんだろうな、ＸＤａｙも

228:仕様書無しさん
07/12/24 11:13:46
連番がありがたいのはプロジェクトの管理側。
発注される側は、特にプログラマから見ればマイナスも多い。
でも発注側はプログラムなんて読まないしデバッグやらもしないから、
一覧で見れたほうがいいんだよ。
プログラマにとってマイナスでも知ったこっちゃないｗ
IDにしたからって受注額をその分増やすなんて通用しないからな。

229:仕様書無しさん
07/12/24 11:13:53
は?
XデイはCO2削減のため世界的規模で中止だよ何言ってんの
常識だよ

230:仕様書無しさん
07/12/24 11:16:50
業務AP部分のクラス名のみコード（ID）ってのはよく見る。
中のメソッドや変数、共通的なライブラリや基盤機能なんかは普通の名称。
だから、読めないこともない（AP機能名がIDになってるだけだから）

231:仕様書無しさん
07/12/24 11:18:08
発注側がﾌﾟﾛｸﾞﾗﾑ読まないなら一覧だけIDふっとけばいいじゃんｗ

232:仕様書無しさん
07/12/24 11:22:42
見つかったときに問題になるようなことをするくらいなら
ちゃちゃっと置換ツール作るのがマだろ

233:仕様書無しさん
07/12/24 11:29:14
一度IDで慣習になってるとこはそう簡単に変えないからな。
変えるリスクと変えないリスクなら変えないリスクを選ぶ。

234:仕様書無しさん
07/12/24 11:44:11
IDなんかつけるやつはあれだろ？コボラーだろ？

235:仕様書無しさん
07/12/24 11:53:32
コボラーあがりだよ

236:仕様書無しさん
07/12/24 11:55:50
むしろボコラー

237:仕様書無しさん
07/12/24 12:14:14
番号にしちゃうから、人が死ぬことになっちゃうんだよ

238:仕様書無しさん
07/12/24 12:17:53
番号で呼ぶな！私は自由な人間だ！

239:仕様書無しさん
07/12/24 12:22:09
国民総背番号制なんてとんでもない　親から貰った名前というものがあるだろう

240:仕様書無しさん
07/12/24 12:58:38
連番の優位性を説かれたら辞めたくもなるわな。
でも、面白いからもっとやってくれ。
長いレスは読み飛ばすけど。

241:仕様書無しさん
07/12/24 13:21:46
連番
・作る人間。作っているうちに、何が何だがわからない。
・そのほかに人間。とりあえず、何だが分かった気がする。
・発注元。ＩＤかっくいー。

242:仕様書無しさん
07/12/24 14:07:37
コボラー上がりのプロ管には
今時の開発でのID連番のマイナスは理解できない。

243:仕様書無しさん
07/12/24 18:04:27
大規模なプロジェクトを経験していない人か学生が多いのかな？

横槍だけど連番を使った(もちろんただ連番にするだけじゃないよw)ほうが
いいプロジェクトは存在するよ。
というか、普通に使ってると思うけどな。

理由はトータル(コーディングだけの事じゃないよw)でメリットがあるから。

というか>>218の説明をされてもイメージ出来ない
または、しない人は大規模プロジェクトに向いてないよ。

そもそもクラス名で直感的にわかるなんて事は
フレームワークじゃないんだから、ありえない。

244:仕様書無しさん
07/12/24 18:12:51
もしかして、ここに書き込んでいる人達は連番で進める
業務のノウハウを知りたいけど、プライドがあるので煽る形をとってるのか？

そうだとしたら失笑もんだけどw

245:仕様書無しさん
07/12/24 18:15:00
連番なんて誰が最初に始めたんだろうね
連番の有効性に関する論文とかあったのかな？

246:仕様書無しさん
07/12/24 18:25:05
そんんあもんだろ、大体。

247:仕様書無しさん
07/12/24 18:30:26
大規模ってあれだろ画面がたくさんあるだけだろｗ

248:仕様書無しさん
07/12/24 18:43:39
>>243
>横槍だけど

え？なに？連番君キャラ変わったことになってんの？
もしかして>>220の質問に答えたくないから？w

249:仕様書無しさん
07/12/24 18:47:20
交換機とかは連番まみれだぞ。
ルータとかもな。

状態管理しているファームは殆ど採用している。
ファームっつっても数MBとかのちっちゃな奴じゃないからな。

250:仕様書無しさん
07/12/24 18:54:22
だからバグだらけなんだよなー

251:仕様書無しさん
07/12/24 20:13:22
すげー他人事ﾜﾛﾀ

252:仕様書無しさん
07/12/24 20:14:33
>>244つまらんこと書いてもアホと思われるだけだよ。

次ページ