なるほど、正しいかも。
“RefactorとArchitectureは、PRレビューの場では遅すぎる。” それはその通りかも！。 他の検証内容も興味深い。
とりあえず動くからマージして後からリファクタリングみたいな対応はメンテナンスの難易度を数倍にするので好きじゃない。なんとなくでかいプルリクな感じがして嫌な予感もする。
styleは人力レビューだと好みの問題やコーディング規約読んでない愚か者が出てくるから機械的に指摘、修正させるのに賛成
linterで自動化できる指摘に時間使うのはマジでリソースの無駄やな
どちらかと言えば、設計工程で流出していたことに気がついた、だな。
イマイチ状況がわからん。何を評価したいんだろ？
スタイルは強制的に適用しとくし潜在バグやある程度の命名規約は静的解析にかける。人間やAIはそれ以外の不具合のレビューに注力するのでいいのでは。アーキテクチャは設計の段階で指摘漏れしたヤツかな
nits指摘、案件入場直後のタイミングなんかでへーそうなんや！みたいな知識を授けてもらえたりしたなぁ。PR外でそういうレベル合わせの場を持ちたい。
“仮説はこうだ。レビュアーの認知容量は有限で、nit:に30件コメントしたPRでは、Bug候補の検出感度が落ちる。書く側も「全部直さなきゃ」で疲れ、設計判断への思考が浅くなる。” < 説得力のある考察
コードが良くなったか？ってどうやって根拠は何？ 開発速度も微妙すぎてなにも言えない
フックとかフォーマッターの話ってAI開発黎明期によくあったやつだな。今そこで悩んでいる人はもういないから懐かしい
コードレビュー指摘300件を3ヶ月分類したら効いていたのは2種類だけだった
なるほど、正しいかも。
“RefactorとArchitectureは、PRレビューの場では遅すぎる。” それはその通りかも！。 他の検証内容も興味深い。
とりあえず動くからマージして後からリファクタリングみたいな対応はメンテナンスの難易度を数倍にするので好きじゃない。なんとなくでかいプルリクな感じがして嫌な予感もする。
styleは人力レビューだと好みの問題やコーディング規約読んでない愚か者が出てくるから機械的に指摘、修正させるのに賛成
linterで自動化できる指摘に時間使うのはマジでリソースの無駄やな
どちらかと言えば、設計工程で流出していたことに気がついた、だな。
イマイチ状況がわからん。何を評価したいんだろ？
スタイルは強制的に適用しとくし潜在バグやある程度の命名規約は静的解析にかける。人間やAIはそれ以外の不具合のレビューに注力するのでいいのでは。アーキテクチャは設計の段階で指摘漏れしたヤツかな
nits指摘、案件入場直後のタイミングなんかでへーそうなんや！みたいな知識を授けてもらえたりしたなぁ。PR外でそういうレベル合わせの場を持ちたい。
“仮説はこうだ。レビュアーの認知容量は有限で、nit:に30件コメントしたPRでは、Bug候補の検出感度が落ちる。書く側も「全部直さなきゃ」で疲れ、設計判断への思考が浅くなる。” < 説得力のある考察
コードが良くなったか？ってどうやって根拠は何？ 開発速度も微妙すぎてなにも言えない
フックとかフォーマッターの話ってAI開発黎明期によくあったやつだな。今そこで悩んでいる人はもういないから懐かしい