レビューしやすいプルリクエスト | DevelopersIO

普段レビューをしていて、レビューしやすいプルリクエストに対して個人的に感じている特徴をまとめてみました。 普段レビューをしていて、レビューしやすいプルリクエストに対して個人的に感じている特徴をまとめてみました。 割と大きめなソースコードに対するレビューの話が主となります。 ざっくりまとめ 本記事では以下のようなトピックについて記載しています。 差分の目的が1つ レビューをしながら「私はいま何のレビューをしているのか」のコンテキストスイッチが発生しないので嬉しい 何を達成したいのかがわかる レビューの多くは「やりたいこと」と「実現方法」のすり合わせなので、前者の精度を上げたい 分割されすぎていない 他のコードとの関連性や構造についてのレビューがしやすい レビューの強弱をつけるための情報がついている 機械的な変換の差分だったりした場合、それが事前にわかると嬉しい 検証結果が書いてある コードだ

[yatta47]

「見られる」の義務感ではなくではなく「見てもらう」の要望という観点でプルリク出すようになるところからスタート。

[Ikalga]

レビュイー視点だと「指摘が少なければよい」って思いがちだけどむしろたくさんコメントを貰えれば勝ちだよ、とは言ってるな (元の品質が悪いというのは除くがw)

[Error401]

2,000行レベルのPRが飛びかうプロジェクト･･･

[tk_web]

レビューする人のことを考えてリクエストを書くということは、自分以外の視点で物事を考えられるので、結果シンプルで分かりやすくなっていく。エンジニアの文化は良い方向に進んでいると思う。

[tk_musik]

なんだか知らんがとにかくヨシ！(ﾎﾟﾁ

[inabajunmr]

かいた

[kwhrtsk]

個人的には「ファイル間の関連がわかる」が一番大事かな。理解するにはどんな説明が必要かを”読み手の視点”で考える能力が必要で、これは良いREADMEを書くのにも必要。自分が知ってる事は相手も知ってると思いがち。

[sigwyg]

2000行のPRとか見たくない…

[fuji_haruka]

ポエムではなくエッセイ

[shikiarai]

昔直してもらったのをレビューした時はIDEの設定が他と人とずれてたみたいでありとあらゆる差分を投げつけられて辛かった

[usako1124]

[[git] [review] ]

[tg30yen]

差分の目的がコミット単位で分かれているならレビューもコミット単位で見るというやり方もできる。

[braitom]

レビューしやすいPRについて。差分の目的が1つ、分割されすぎていない、ファイル間の関連が分かるなど。

[udonj]

まごころ

[seal2501]

可能な限りこれやりたいけど、動く状態を維持するポリシーでPRにするとデカくなりがち(密結合なんだろうか

[takamii228]

レポジトリの管理者がPRのテンプレート作ったり粒度の例を出したりCI設定したりしてある程度のレールを引くものだと思ってた。

[maecchi]

目的が一つだと追うべき内容が限定されるのでレビューが楽だなと感じます。

[tick2tack]

整理されててありがたい

[wwolf]

細かいPRを出す話、マージされるまで開発をブロックしてしまう変更がある場合どうしてんのか気になる。いちいちモックを作るのかマージされるまで待機なのか…

[t-cyrill]

最近同じようなことを書いたから同意しかない

[fukken]

迷ってるところがある場合、その点に触れられてると分かりやすい（issueやSlackなどで事前に解消しておく運用ならそれはそれでよい）。

[D_first]

レビューだとかプルリクエストという文化があるところで働いてみたいものじゃのう

[kubecorn]

同意。今のところはGithub flowみたいにトピックブランチでやっていくのがちょうど良い。それでPRが巨大になりすぎたら、どっちかというとチケットの切り方の問題な気がしている。

[yug1224]

PRはレビュアーファーストだと良いなって思っている

[com4dc]

やってるうちに色々気づいて、余計な修正も入れ始めて結果巨大なPRになったりするので、レビュワーの気持ちになって粒度を適切に保ちたい