ひな形を元にしたコードファイルを立ち上げるような改修をする場合、その改修のピアレビューを求める場合は「○○ファイルを微変更して△△を立ち上げました」というフィーチャーブランチを立てることになるわけですが、これってレビュアーの立場で考えてみると負担ですよね。
そう、レビュー用の差分表示にはその元になった○○ファイルはまったく表示されませんので、レビュアーはその○○ファイルのどこに変更が加わっているのかまったく画面上わからないのです⋯⋯
今日は1分で読める小物の記事です。エムスリーエンジニアリンググループ、Unit1（製薬企業向けプラットフォームチーム）三浦(@yuba@reax.work) [記事一覧 ]です。
「微変更」がレビューできるようになる技
さて、差分レビュー画面上ではひな形ファイル○○がどうなのか全然わからないという問題があるわけですが、その結果、真面目にレビューするならレビュアーは手元にファイルをダウンロードしツールなどを駆使して○○vs△△のdiffを作り出すか、もしくは不真面目に「ひな形の微変更ならまあそんなに新しい問題はないか」とほとんど未検証で👍するかです。多くの場合後者になるのでは（私もまずそうなりますごめんなさい）。でもこれではピアレビューの意味がなくなってしまいますね。
それを、こうしたら⋯⋯？
コミット時刻は気にしないでください、夜8時半にコミットしていますが弊社決して長時間労働の会社じゃないです、私がその、リモートワークなのを利用して夕方は早めに抜けて家族と夕食とってつづきの仕事を夕食＆寝かしつけ後に回すことが多いだけです。
まず○○ファイルの丸コピーを作るだけのコミットをして、その後に今回案件分の改修をするコミットを入れています。
これなら同僚には、「2個目のコミットだけ見てもらえばわかります！」とピアレビュー依頼できるわけです。
これを本流マージするときにsquashするかどうかはまた流儀がわかれてくると思いますが、私はこの場合はsquashしません。
どのひな形を使ったというのも大事な情報なのでそれを強く主張させておきたいのと、コード調査でgit blameしたとき、私が書いた部分とコピってきただけの部分がわかれて見えれば、誰に質問すればいいかで無駄な回り道せずにすみますからね。
We are hiring
レビュアーのレビューしやすさ、将来のコード調査のしやすさのことまで考えて開発、してます⋯⋯？ えっそんなの当たり前！？ そんなあなた様、是非とも一緒にお仕事したいです！ 私達とちょっとお話ししてみませんか。
いきなり応募するのを前提にしない、そういう興味があるところについてだけ聞いてみたいってお話ができるカジュアル面談、やっています。こちらのページからどうぞ。
