PullRequest門番制度への懐疑
https://gyazo.com/a42cf35d9e0e412e3d22e433702af330
門番のあまりの潔癖さに、風すらも通るのを待たねばならない。
個人的に共感を持った記事
僕が Pull Request のレビュワーのとき、ほとんど全てのコメントは単に自分の考えとして表明し、変更を要求しない。Request Changes にするのはバグがあるときだけである。それから、書き手と自分の間の理解の差分を埋めるのが難しいことを認め、どうしても必要なら質問するし、そうでなければ、「こういうケースが考えられそうだけど大丈夫? 大丈夫なら問題ないよ」みたいなレビューの書き方をする。
とっととメインラインに入れてしまって、必要ならそこから直してしましょう でいいと思う。
「それだとどんなことするかわからない」とかお声が聞こえてくる気がします（実際言われたこともある）が、それって何をするかわからないメンバーを既にチームに入れてるってことですよね。コードだけ取り繕ってる場合ではないのでは……。
コードレビューで「コードのクオリティ」をあげようとするのはコスパが悪いだけではなく危険ですらある
これです。
言い換えると、コードレビューでやるべきなのはプロダクトそのものの品質を下げるようなコードがmasterに入るのを防ぐことではないか、ということです。
３０代くらいまでは自分の考えを押し付けていたと思います。ただ、チーム開発やいろんな人のコードを見て修正するということを繰り返していく中で、その人が考えていることを無理やり修正するとバグが出てしまうということが分かりました。それからは、その人の考えた構造を守りながら最小限の直しで、リリースまで進めていくということを意識しています。最終的に、ちゃんと動くコードであれば、そんなにこだわらなくてもいいという考え方になりました。 XXはYYなのだからWWでなくZZすべきだのような理屈は、文面上は正しくエンジニアリングの現場でたくさん見かける言葉だ
が、しかしこういった他者の成果物に対する意見が常に正の影響を持つとは限らないように思う
Unity開発をしているが、Pull Request門番制度でなかなかマージされない時間ロスと、それによる品質向上の天秤が釣り合ってないなぁと感じる だったら、メインストリームに突っ込んで開発スピードは落とさずに、マージ後に全体を見通してレビューやリファクタリングをしたり、テスト環境を整えたほうが中長期のスピードと質に貢献できるのでは？と思う