いきなり1,000行越えの差分のあるPRのレビューを依頼するのは今すぐやめろ。何年前の開発スタイルだよ

いきなり1,000行越えの差分のあるPRのレビューを依頼するのは今すぐやめろ。何年前の開発スタイルだよ 今回語りたいこと PR/リリース単位の違いの変化を時代と共に語るというのが主旨です この記事を書いた意図 最近開発速度を上げたい的なお話が多く、その際に何回も同じ話を説明することになっているので改めてここに書いておこうと思います。 もう少し膨らまして講義としてまとめた上で、オンボーディング研修の受講動画にしたいですね。 変化をざっくり言うと リリースされる単位は時代が下るごとに細かいサイズでリリースする方向に変化しています。 近年だと平均差分の中央値は（差分行数で比較した場合で）一桁台とかありますね。 古代、いにしえの時代 少数の大企業だけが使える「基幹系業務システム」というピラミッドみたいな代物を、SEという大工のような人たちを多数抱えたごく少数の「大規模SIer」という集団だけが造れ

[takyam1213]

デカい機能のPRはデカくなる。細かく見せたいならコミット単位小さくするで十分。PRしてもらいやすくする努力は常に意識する。その方法が書いてあるのかと期待したけど何もなかった。

[p-baleine]

「+5,000行、 -3,000行のPRが出てきました」の対策として「前提知識や設計も含めて握っておけば」は飛躍し過ぎるのでは？ 「時間が足りなくなってしまいました」でしめるのは手落ち過ぎるのでは？？

[inabajunmr]

段階的に進めるべきだ、というところは同意だけどレビュー自体は凝縮されてる3000行の差分のほうが凝縮されてない100行のPR30個よりやりやすいと思う

[getcha]

意味のわかる1回の変更で1000行越えは行ってもおかしくない。行数でプログラミングを縛るのは本末転倒で、PRレビューが持っている本質的に解決しようがない問題。

[nishi1231chang]

普通に適度に細かい粒度でタスク分解して、その粒度でPR出せばいいよね

[queeuq]

まともに人を説得させられないのに声はでかくて、説得できないことを相手の知識不足にするという一番害悪なやつ/1000行のPRをなんの説明もなくレビューオナシャスで投げるのはなしというその部分だけは同意する

[tanishiking24]

わかるけどこういう文章も短くあってほしい この記事が自分の言いたいことすべて言ってくれてた https://opensource.com/article/18/6/anatomy-perfect-pull-request

[kazkun]

言いたいことはわかる。自分もそんなレビューは馬力必要。でも全体に影響あるリファクタリングとかこうなるよ。あと不完全でmergeとか、自分からすると正気の沙汰じゃない。こんなんされたら自分なら荒ぶる。

[tattyu]

延々と分かりにくい例えを続けた挙句結論は次回とかクソ記事やんけ。こういう記事みたいなPR出すのが正解って事？クソデカいPRがムカつくのは分かるが。。

[k_oshima]

伝聞の歴史認識がおかしい

[Tomosugi]

例えがあまり上手くなくて集中できなかった

[ghostbass]

そういうのfeature でやるんじゃないんだ

[kobito19]

でかいのがNGつってこんな未完成でPR出されても

[knok]

Linusも巨大パッチにうんざりしてそれが最終的にgitを生んだんだよなあ

[qtamaki]

良い示唆を与えてくれる記事だけど色んな機能が同時並行に開発され完成していない項目やらフラグやらがアチコチにある状態でリリースするの？

[Keisuke69]

同意できるところと、やり過ぎに感じるところと。一般的にはどの程度賛同得られるもんなんだろ

[tinsep19]

PowerAutomateのコードをGitに入れたんだけど、末尾のリポジトリ(JSONの文字列表現)がでかいのでアレどうにかしないとな。PR差分は+1,-1なのにMB単位の差分になってる。

[tanority]

古の民族目線だとよさが全然わからなかった。 この違和感はなんだろう？今やってるウォーターフォールな案件に取り入れるとしたらどうすりゃいいか

[onesplat]

“私は1人のメンバーあたり、1日にPRを20個くらい作って欲しいと思っています” さすがにポチポチ作業のオーバーヘッド大きすぎるだろ

[dodecamin]

パワポで設計レビューすればイイ！コードを先に書いちゃったら、パワポもつけてPR出せばイイ！

[coppieee]

zennにもポエム増えてきたな