プログラマの雑談部屋 ★31
■ このスレッドは過去ログ倉庫に格納されています
>>200
捏造する手間とテストする手間って
テストした方が早いだろ 素人がelseいらないなんて言い出すとは思えない
どちらかというと何かをこじらせたタイプ >>181
方々で頑張ってたけど結局Cの上っ面に落ち着いた感がある エビデンスの入出力通りの結果にならなかったら
明確に責任の所在追求出るし
何個も間違ってたらそれこそ捏造ってわかるから契約切る口実にもできる罠
なんの証跡もない状態でギャーギャー喚くのとはわけが違う 技術バカリーダーの気まぐれで
ほとんど使わない、パフォーマンスも要求されないような部分なのに
クソ面倒くさい実装しなくちゃならなかったときに
それを白紙に戻すいい方法ないかね そもそも捏造してまでテストOKにするって相当な奴だぞ
100人いて何人が捏造しようと思うんだよ
たかがテストとは言え、捏造ってほぼ犯罪に近い感覚だからな 上策：しばらっくれて諦めるのを待つ
中策：膨らんだテスト仕様書を見せつける
下策：やる ノルマきついからな
周囲がやってたら染まっていく
そういうことだ >>201
コアライブラリに変更があったら本来なら影響箇所のエビデンス全部取り直し
でもバグ報告のあった実行手順だけ取り直して終わり
とかやりたい放題 一般的なテストの話なのにコアライブラリガーとかホントあほだよね コアライブラリの変更なんてあったら全再テストだろｗ >>178
同意する
屁理屈とか言う奴もいるだろうけど結局最終的には責任の擦り付け合いだから、責任逃れ出来る環境を作るかみたいな所あるよな え？バッチ流してなんとなく動いてたらＯＫぐらいのもんじゃないの？ テストなんて本当にだるい、それなりにやるけど早くその場から立ち去りたいわ。 なんか周囲ははりきって過剰仕様を修正させようとしてる
なぜ今になってそんなこと頑張る気になったのかはわからん
もう実装終わってるんだけど まわりと統一とれてないから変な感じはしてた
ひょっとして基本無くなったのに俺のとこだけ取り残されてるのか
いやな予感してきた >>215
請負？派遣？
派遣だと炎上させた方が作業員には得だから自発的に作業をさせちゃ駄目だぞ >>210
一般的なテストの話だからこそ考えなきゃだめだろ
ライブラリは無条件で信じちゃうような素人じゃないんだからさ
>>211
本来ならそうなんだけどスクショとデータダンプ撮るだけのエビデンスではごまかし放題ってこと なんの業務案件の話してるのか知らんけど
webで開発中や保守の追加業務中にコアライブラリの変更なんてただの一度たりともない
オープンソースだからクソみたいなバグあったらすぐわかるし自分でソースも終えるし
中枢部分のライブラリ変更なんてコンバージョンという名の元にプロジェクトレベルで行う
お前の言ってるようなことなんて通常のテスト中じゃありえないんだよアホ しかも簡単にごまかせる結果のエビデンスってどんなクソ画面だよ
結果の出力が入力するみたいに簡単にできるのかよアホか ライブラリの変更とかエビデンス誤魔化し放題とか
学生レベルの木っ端は上級（爆裂）ｗ雑談スレでelseいらない爺とレスしあってろよｗ
アホ どうせ数人しか使わないような社内ツールレベルの話だろ セキュリティ対応もろくにせんのやろうなぁ
出来合いのもの深掘りしないでなんとなく使って組み立てるだけのWeb屋さんはイージーそうで羨ましいよ Ｊａｖａで
自分のと別のバージョンのライブラリ使ってるライブラリって取り込んで大丈夫なん？ >>225
やってるとそのうち
使ってる他人のコードから悲鳴とか怨嗟の声とか聞こえてくるようになる Web系でバージョン管理そんなに厳密にやる？
運用中でもPHP5からPHP7にあげるし
データベースもメジャーバージョンあげるし
フレームワークだって適当に最新バージョンにするじゃん
EC-CUBE2から3に変えるような根本的に違うものだったらしないけど
出たとしてもちょっとしたエラー程度で済む範囲ならやっちゃうだろ エビデンスってのは、テストをウソつかずに
ちゃんとやらせるために取らせてるだけのものだから、
適当にねつ造してやったことにしても実は案外バレないものなんだぜ。
なぜなら誰もチェックなんてしないからな。
ただしモノが普通に完成した場合。
炎上したらエビデンスを必死になって精査し始めて
責任を全て押し付けようとし出す。元請けがな・・・
もう誰も完成させようと努力しようとなんてしなくなるからな。 >>225
セキュリティて何すればいいん
悪魔の証明のような作業に思える 碌なCI環境の無い時代じゃあるまいしOSとライブラリのマイナーアップデートはデイリービルドで取り込むだろう普通
そんなんにいちいちプロジェクト建ててたら仕事にならんよw https://srad.jp/about
皆さんこういうサイトで情報集めてたりします？ 工場やインフラみたいに簡単に首をすげ替えることができないからな、この世界は。
でも経営者はバカだから、ソノヘンがわからず、そんで現場でこういう事態になる。 ゾゾタウンの天才募集しても上司がオブジェクト指向読みにくいから禁止クラス名はブロックコードとかケチ付けてCOBOLやらせるんだろ >>237
経理がプログラマ不要というBIツール買ったけどUIはGUIでポトペタだけどデータベース設計は当然出来ないといけないから誰がやるんだよって話になって死蔵された
700万円也 >>233
他人が100行書き連ねたSQLをメンテしろ言われた時の絶望感 巨大なSQLもよくよくみれば、selectの後のフィールド羅列が大半さ。 >>239
ホント、バカだねー。
「プログラマ不要」なんて謳い文句にマジで引っかかっちゃうんだ。 100行ならかわいい。
馬鹿プロパーが書いた仕様書の無い糞300行超の糞SQLが、
仕様変更で一部のSELECTをごっそりUNIONして一部変えて追加
500行超の爆弾ウンコSQLになっていて、何がしたいのか本人以外全く分からず、
もはやそれを貼り付けるしかなかった苦い過去。 せっかくだから、elseいらない厨の代わりに、
joinはleft joinだけで十分厨にでもなるかな。 プログラマ不要でも詳細設計までは出来ないと意味ないしな
しかし最終的にプログラマ不要論ってあるけど、仕様考える人間の方が駆逐されそうな気がするわ
仕様漏れによる手戻りのせいでデスマ起きるんだから
AIに仕様考えて貰って人間がコード起こした方が安全じゃないのかっていう 顧客も顧客で、おととい入った新人をイキナリ
情シスに送ったりなどはしちゃいけないな。
その会社の本来の業務もわからずにIT業に指示なんてねぇ。 長大SQLや正規表現を書くなら、コメントでこれでもかこれでもかと解説入れさせんとダメだよ
半分はコメントになるくらいまで そして各コメントに日付だな
そして、SQL文にコメントを付けられない仕様なせいで、全てSQLの前に書かれる
あ、コメントを削除するのはコーディング規約で禁止してるからダメよ >>239
その手のツールを使うと汚いビューがシステムの中心になってドメインとデータベースがグチャグチャになる 「プログラマ不要」ツールなどというのが開発されるきっかけは
プログラマが日本語を満足に話せないのが原因なので、
おまえらは自覚した方がいい。 【不健康】無能時間外労働違反の追放【高離職】
☆不利益で迷惑だから料金増やすか生産減らせ☆
無能実態派遣残業する高稼働低所得者は辞めろ！
【契約料金や知的財産の生涯損害促進者ばかり】
［偽装請負多重派遣の従犯SEを追放すべき］
偽装請負多重派遣SEの動機
コミュニケーション障害
コンピュータ趣味
人格障害
文系大卒
低偏差値大卒
情報処理資格非保有者
偽装請負多重派遣SEの迷惑
無償プログラム提供
事前面接
契約外期限遵守
客先指示遵守
知的財産譲渡
中間搾取促進
時間外労働違反
低予備工数見積
残業見積
無料追加
学習不足
裁判苦手
対人障害
健康障害
孤独死
偽装請負多重派遣SEの代償
低収入低技術
非婚離婚
鬱病早死 >>251
日本語でやりとりしようとするのがまず間違い
英語、図表、コードがプログラマとの正当な対話手段 使い捨ての単純労働力扱いなのに日本語のコミュ力(笑)を求められる不思議 プログラマが高いんだよ
頼んでもいない残業で利益をすり減らしやがる >>251
いずれ、「プログラマ不要」ツールの専門職が生まれる
プログラマという名前が無くなるだけで結局は同じようなポジションの人はいなくならない
むしろこれをきっかけに多重請負構造をぶっ壊せるのではないか Javadocでちゃんとコメント付けられないエンジニア多いからな
こういう類の奴らは英語出来てもダメだよ
そもそも伝えられる文章や力を書く能力がない >>260
javadocのコメント見てる奴なんていない
キモいゴミだよあんなのは
ヴァカ アプリに閉じたコードのjavadocはほぼ無意味だな
そんなもんに時間使うならdoc無くてもわかるような命名したほうがいい ソースコードには
コメントは一切入れない、
ってのが最近正解じゃないかと思えてきた。
どうせソースの実際とコメントがズレてくるし
最初から間違ったこと書いてて混乱をさせたりするしな。 >>261
そんなんだから君は使えないって帰されたんやで？ クラス説明だけはまじ必要
あとバク改修で特殊判定や処理を入れたところ >>265
>どうせソースの実際とコメントがズレてくるし
意味が分からん コメント入れるべきってのは、暗にコメントが常に正しいことを前提にしてるってことでしょ。
もっと言うと、変数やメソッドの命名がおざなりなコードでそこがしっかりメンテナンスされてるか？ってところに関わる 違うぞ、実装した理由とかコードで表現できないものをコメントに書くんだぞ
コード見ればわかるようなコメントはいらない 俺はコメント一切入れない主義
ソース見て分からない馬鹿はPG失格
昔コメントなんて書いてやったら
句読点が変とか文句言われたからな コメント無いのと変数や関数名がdata0025とか、funk0132とかだけなら無理。 >>272
コード見て分かるなら
デスマーチなど発生しない。
基本、分からないのだよ。 >>205
使わないことなどを理由に優先度下げまくってなあなあにする >>272
すまん、俺が主張したかったのは、
「>>268に対してソースのを綺麗に書いたり、命名をしっかり出来ないのに、コメントがしっかり書かれてメンテナンスされる訳ないでしょう？」
ってことだった。
>>272の意見自体は俺も正しいと思ってる >>278
>>272は典型的な勘違い
そういう言い訳は独立したドキュメントに書け
ソースコードのコメントは処理の内容を書くもの コードレベルの言い訳のためにわざわざドキュメント起こすのかよ コードからドキュメントの自動生成
ドキュメントからコードの自動生成
あるいは別の何かからコードとドキュメントの自動生成
があると便利だな
周知されると納期が縮むだけだがｗ // カウンタ変数の宣言
// カウンタ変数をインクリメントして次のループへ進む
・・・とか書いてないと規約に合ってないから納品できない、
全部見直せ、とか言われるのだぜ。 大規模で技術レベル統一できないならそうなるのもしゃーない
世の中書いてるうちに何の要件で書いてんのか見失う奴らもいるしな >>286
カウンタ変数で思い出した
// カウンタ変数
// ここから○○で使う >>265
正解
コメント付ける暇使ってコードをリファクタリングする方が大事 >>290
それどういう方針で何を理想としたリファクタリングなの？ なぜ雑談部屋には頭おかしいプログラマしか沸かないのか
せめてリーダブルコードと達人プログラマーぐらい読んでくれ >>293
何それ？
100万部ぐらい売れてるの？ JavaのInterfaceのコードを読むのか
コメント書くしかないだろ >>279
処理の内容とか一番要らんところだろwww
必要な情報はcontractだよ
そんでもってcontractはコメントではなくテストに書くものだ
コメントは不要 前に言ってた事前面接反対っていう話、
どういう事情かわかった、というより思い出した。
あれってオンナの派遣の話なんだよ。
面接して顔で選ぶ会社が後を絶たないからな。
で、女性差別だなどと騒ぎ出したってわけだ。
だからまあ、この世界では特に関係ないんだな。 ノンプログラマBIツール使うのをノンプログラマが嫌がって派遣プログラマの俺が使うという悲哀
第三正規化まで出来てテーブルと密結合する帳票出力を、導出表を巧みに使って表現する鬼仕様なんだこれが
俺は特派で今年居なくなるけど、基本月給20万円でやってくれる派遣が見つかると良いねって感じ
でないと派遣先に来年度組織変更あったら死ぬ 単価上げても営業がピンハネするだけだもんねぇ。
まあ一般派遣を使うようにでもなるのだろう。 ■ このスレッドは過去ログ倉庫に格納されています
