プログラマーだけどこの画像になってる
■ このスレッドは過去ログ倉庫に格納されています
設計書が悪い
設計書レビューしたやつが悪い
と責任転嫁しろ >>4
テストは実装者とレビュワーがやる小さな会社です エディターがアホみたいにバグ見つけるこの時代にバグだらけとは? >>9
エディタが見つけるバグは言語レベルのバグであって条件式がどんな意味を持つのかとかまでは解析してくれないんだよ エディタがみつけるバグとかもはやバグとは言わないレベルだろ というか1から設計して1から実装するなら簡単なんだが既存の機能を壊さずに機能実装していくの至難の業 動作確認しなすぎで一目みて修正されてないってわかるのにマージリクエスト出してくる🥺 >>6
実装者はどんどん修正しろよ
実装者にデバッグやらせても無意識に正しい操作しかしなくて納品時困るぞ 見た目修正くらいならいけるかと思ったらデータがnullになるだけでエラーになるのあげてくる🥺 俺はMR出す前に二回は確認するしコミットはわかりやすいように整理する >>21
ヌルチェックは流石にエディタが警告出してくれるじゃん テストコードの必要性軽視するくせにそういうときだけ文句いうよね >>25
テストが書かれている範囲だと思ったらちょうどそこだけテストが漏れているとかありがち 担当する機能の運不運もあるだろうし
上流工程での考慮の甘さもあるだろうし
自身の実力不足ももちろん否定できないけど、運不運も大きいからな
100パー個人の責任に帰する空気があるとしたら、ちょっと理不尽よな テストが漏れているっていう話にありがちだけどモジュール分解の粒度が身の丈にあってないんじゃね
言語によるけどn行以上とか分岐n回以上とか自信過剰に気づいたら基準下げないとだめだよ >>29
そもそもそのモジュールのテストだけじゃバグに気がつけるはずがないんだもん
自分の実装した部分は問題ないと思っても自分の実装した部分によってその後の処理に影響を与えてデグレっちゃう
ちょうど影響を受ける部分のテストが書かれていなかった場合死ぬんだよ ウォーターフローでやってるとまじで下流が全て割りを食うからな
結局アジャイルが一番精神衛生上いい
大変だけど
上流で寝そべってるやつらの時代はもう終わりよ 講義で一回習った程度の無知なんだけどこういうのってスコープの問題ってこと?
結合度の問題なら設計の責任?それとも設計全体をリーディングしないことによる末端のミス? >>33
影響調査と設計ミスとウンコーディングのコラボレーション テスト無し
設計書無し
いまはそんなの当たり前
細かい内部的な仕様はここの判断に任せられる
だから初心者にはまじで難しい そもそも千行のメソッドにバグ無しで機能追加しろって方が無理 千行のメソッドね
パスタ好きな奴が作ったんだろうな >>37
誰が作ったとかではなく人手不足でテストにもリファクタにも手が回らなかった結果こうなった このままリファクタしても重大なバグが起きると考えると怖くて手が出せない >>40
えーー!イッチの担当箇所がバグだらけ!? ■ このスレッドは過去ログ倉庫に格納されています