言語仕様が貧弱な言語を使ってるとバカになるCOBOL [転載禁止]©2ch.net

[1 仕様書無しさん 2015/10/24(土) 19:45:15.63]

あいつらプログラマとしての最低限の知識すらなくて困る。

[19 仕様書無しさん 2016/04/09(土) 20:42:12.65]

言語なんてなんでもいいんだよ
>>1は具体的に何を作ったのかプログラムアップロードしてみろよｗ

[20 仕様書無しさん 2016/04/15(金) 17:02:23.31]

>>18
その考え方は、顧客不在で、技術偏重やな
お客様有って初めて、金になるんやで

[21 仕様書無しさん 2016/04/18(月) 22:58:42.52]

メインフレームの仕事している奴って言語仕様や環境すら理解していない自称ＳＥばかりだろ
形式に拘るばかりでソースなんか見ないし、組むこともできない
お決まり文句は「しばらくコーディングはしていないから手が動かない」（藁）

基本的な記述しか見ても分からないから言語関数の使用も禁止する現場が多いし

例えば、プログラム上マイナス値の定義なんかしていなくて仕様上もマイナス値が発生する事のないプログラムに対しても
項目名やプログラム名だけ見てマイナス値のテストが必要だとか抜かし始める

単純に昔どこかで見た似たようなプログラムにマイナス値のテスト項目が記載されているのを覚えていて
適当に言っているだけ、ソース見ればマイナス値が発生する余地が無いことくらい普通に分かるレベル

酷い連中は言語仕様を理解していないが為に使用する関数や命令文の仕様エビデンスをテスト実施で出せとか抜かし始める
ＩＢＭのマニュアルを読めよゴミクズ共って思うが、たぶん読んでも理解できないんだろうね
何でもかんでも形式だけで判断して「横串通す」とか「平仄を合わせる」とか
形式的な事だけ馬鹿の一つ覚えみたいに気にする連中

膨大な工数掛けてゴミドキュメントを大量生産するのもお得意だよね

[22 仕様書無しさん 2016/04/21(木) 01:24:06.48]

っていう夢を見たｗ

[23 仕様書無しさん 2016/04/21(木) 07:42:57.25]

メインフレームは金かけれるケースが多いのと、基幹業務が多くてバグ一個で、被害が大きいから慎重にならざるえないのが原因なんだがな

まぁ、表面しか見えないから仕方ないか

[24 仕様書無しさん 2016/04/21(木) 22:43:12.98]

>>21
マイナス値のテストをしておけば
未来の仕様変更によるデグレの発生率が下がるじゃないの
あなたって今目の前のことしか見えないのね

[25 仕様書無しさん 2016/08/25(木) 22:55:50.52]

>>1

それは正に俺の事だｗｗｗ