プログラマの雑談部屋 ★31
■ このスレッドは過去ログ倉庫に格納されています
>>144
唯一の解決策は、自分はそういうのに悩まされる立場にならないこと、だな。 全くのプログラミング初心者なんだけど、仕事辞めて暇だからPythonの入門書を注文してみました Pythonはやったことないや。
どういうアプリを作るのに向いてるんだろう？ 一度リーダーをやってみたんなら、今一度下っ端からやり直すのがいいと思うよ。
そうすれば、かつてよりは地に足ついた仕事ができるようになるってもんだ。 責任的に考えたら当人に投げ返すわけだが
ちゃんと確認したいんだったらどう考えても別人にやらせたほうがいいよな…
本人はいっぺん確認したと思ってるし
頑張って見つけりゃそれだけマイナス評価にしかならないのに頑張るわけがない 普通に書くのは趣味でやれ。
仕事のプログラムは普通じゃないからな。
まったく別物だよ。高度だ、って意味じゃなくてな。 無能な奴が最初に元となるソースを書くと、それが基準となる。 生産性を下げるための規約ばかり
工数=>人数=>金
資本主義に則っただけなんだけど末端としてはやってられんわ 稼働落ち着いたら抜けたいか聞かれたんだけど稼働落ち着いたらどうでもいいよ
めちゃくちゃなスケジュールの今こそ抜けたい 他社の給料事情が分かりづらいから安易に責められないのが辛い
残業の上限が極端に少なかったりボーナスが出なかったり >>191
でも>>144みたいなの割といるで
俺らもそういうの排除する仕組み自分らで作らんのも悪いんやで みんな本気で解決させたいわけじゃないもんねぇ。
そもそもできる奴が揃ってないと効果がないしね。 証跡なんてどこの現場でも基本中の基本なのに
手抜かれたら困る現場で証跡も取らないでギャーギャー文句言うアホって何なんだろうな 排除しようとするとパワハラんなるからな
ケンカ売るなら覚悟せえよほんま エビデンスは捏造簡単だし環境やリビジョンに依存するから品質保証の根拠としては弱い >>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の意見自体は俺も正しいと思ってる ■ このスレッドは過去ログ倉庫に格納されています
