初めてのpull requestのその前に聞いてほしい話

この記事は以前ちょっと株式会社 社員ブログで公開していたものです

概要、背景

みなさまこんにちは。フロントエンドエンジニアのはしばです。
現在までにありがたいことに複数名の エンジニアになりたい or 新人エンジニア の方のサポートを経験してきました。
その中でほぼ毎回共通して伝えていることがあったので記事にしてみました。
これから初めてチーム開発するという方も、学習開始したばかりの方にも参考になる内容かと思いますので是非最後まで見ていって下さい~

PRを出すその前に

①developの更新を都度作業ブランチに反映していますか?

これをやりたくない気持ち...少し分かります。僕も最初Git使うの恐怖だったので。
コンフリクトも怖いし、マージ??プル??リモート?????と最初四苦八苦しながら対応したのを覚えています。
ただ、この重要性を理解できていない === Gitを利用したチーム開発のフローが理解できていないのでしっかり挑戦しましょう。
むしろコンフリクトのひどい状況を避けるためにも早め早めに最新のdevelopを取り込むのです。

②最後にpushしたその状態は動作確認をしていますか？

しっかり動作確認したものを上げましょう。
で動作確認ってどこまで??っという話ですが、

must: 要求されている仕様を満たす(もしくはデザイン通りに実装する)
better: 動的に値を受け取る場合は境界値や最大最小の値を入れて確認する
better: 実際にユーザーがしそうな動きで不具合がないか(例: ボタン軽く連打してみる)
ぐらいまでは確認して欲しいです。

あるあるなのが

1. 動作確認してPRあげる
2. コンフリクトを修正したりちょっとだけ追加の修正入れる
3. 修正後に動作確認してない

で動かしてみたらバグがあるみたいなパターンもあります。

③検証ツール確認してますか？

開発も中盤~後半に差し掛かってくると徐々に綻びが出てきます。
そんな時にdebugしながら開発するのですが、consoleが汚いと無茶苦茶見にくいんですよね...
たかがwarningでも放置しておくと他への影響も考えられます。
errorやwarningはうざい警告文ではなく既知の障害を教えてくれるものなのでしっかり確認しましょう。

PRを出したその後に

Draft PRを最初に出して以下の項目を確認して下さい。

①file changedは確認しましたか？

画像の黄色い枠のところを押したら表示できます。
targetにしているブランチとの差分が表示されます。

• 不必要なメモや使わなくなったコード残していないですか?
• 意図していない修正が含まれていないですか?
• 第三者が見てよく分からない命名などになっていませんか?

②マージできる状態になっていますか?

画像はPRのページ下部にある箇所です。プロジェクト毎に微妙に表記は異なります。

• コンフリクト起きていないですか?
• buildは通っていますか?
• testはpassしていますか?

③概要を確認して分かりやすいPRになっていますか?

画像白枠の箇所です。PRのテンプレートがあればそれに添いましょう。

• バグ修正の場合は原因と対処法も明記する
• viewの作成、修正の場合はデザインと実装ページのスクショも貼る。デザインはfigam/xdのURLでも可

とまぁできる限りわかりやすく書きましょう。

このほかにはlocalで試す場合のURLやブランチ名、login userを明記したり機能の場合は動画を載せたりします。実際の挙動を見せるため

ｲｲｶﾝｼﾞ!!のPRを出すためのtips

変更行数をできる限り抑える

少なければ少ないほど見やすいです。大きくなりすぎた場合はPRを分割することも視野に入れましょう。

変更のスコープをできる限り狭くする

変更行数と何が違うの?というところですが、共通コンポーネントの修正と個別ページでしか使われないコンポーネントの修正と置き換えていただけるとわかりやすいかもです。
複数のページにまたがる共通コンポーネントは数行の変更でもプロジェクト全体に与える影響が大きいです。なので慎重に見ざるを得ない。
それと引き換え固有のコンポーネントなら変更file、行数が多くとも影響は1人だけになる可能性が高いのでマージの敷居が少し下がります。
(=いったんマージしてisuueにしておけばいいか みたいな対応ができたりします)

わかりやすいcommitを意識する

https://github.blog/2022-06-30-write-better-commits-build-better-projects/

↑こちらはGitHub公式のブログです。要約すると

• 1commit1関心(削除、修正、新規作成などのジャンルを混ぜない)
• 適切なcommitにまとめる(細かすぎれば良いというわけではない)
• commitの順番を意味のあるものにする(A機能作成途中にviewを挟まない。流れでわかりやすくする)
• rebase -i を使って見やすいcommit logを目指していきましょう

コメントを残す。特にWHYの部分

必要なものはコードに残して欲しいですが、コードに残すのは微妙な場合は下記の方法で残せます。

①PRのfile changedのところで写真の青いプラスを押すとformが出てきます。

②コメント入力後 start a review と押すと下記の写真のようになります。
この状態はpendingなので全てのコメントが入力終わったら画面右上のreview changes → submit review を押してください。

単一のコメントを打ちたい場合はstart a review ではなく add single comment を押してください。

さいごに

みんな大好きリーダブルコードに 「コードはあなたがか書くものではなく、他者が見るもの」 といった記載があります。
PRも同様です。少し面倒に感じるかもしれませんが、良いプロダクトを作るためにも見やすいコードと見やすいPRを作っていきましょ~！！