先日から某サイトを請け負ってます。
3人での共同開発で、私がその中でも勉強してた期間が長いということでPM的ポジションになってしまいました。
今までプルリクをする側、もしくは一人で開発してプルリクの練習をするくらいだったので、受けて、レビューを返す、他人のコードをローカルで確認するというのが結構大変だったのです(まだまだ開発は終わらない)。コンフリクトも起こるし、いざ受ける側になって難しかったことを書きます。
issueを書き出す
githubのissueを使ってタスクを書き出す作業が、まずは大雑把な私は、切り分けがめちゃくちゃ雑だったので、大変でした。
大まかに作業を決めてタスクを分けてみたのですが、ざっくりすぎて他の人にイメージが掴みにくいという事例。
で、今度は細かく分けすぎて、プルリク受けて返すという作業が多くなりすぎる。
ちょうどいい塩梅が難しいです。
確かにプルリクは今まで出してきたときに、量が多すぎると見る方が大変ということもあったけど、細かすぎてもやりとりがめんどくさい。
他人のコードの動作確認をする
今まで、プルリクを出してきて、レビューをしてもらう側だったので
「あれ、、そういえば、他人のpushしたブランチの動作確認って、みんなどうやってるん、、、?」
ってなりました。ググりまくって、今の所プルリクIDをgit fetchでローカルに持ってきて見るということをしてます。
git fetchってプルリク受ける側になって初めて使ったかも。
— Yumiko@癌サバイバーのミニマリスト (@engineerman8) 2020年12月11日
git fetch origin pull プルリクID/head:ブランチ名
で手元で人からのプルリクされたブランチをローカルで確認できる #プログラミング
で、いざコードをレビューしても、「ああ、、ここも見落としてた、、」ってことが多発。そういうためにプルリクって細かく出した方がいいのですね。
コメントの書き方(メンタル)
今回は共同開発なので、しかもあった事のない人との作業です。
相手の心を折らずに、かつ、わかりやすく、、これを文字に乗せていくのはなかなか難しい。
文字だけにすると素っ気なくて向こうは嫌な気分するかなあ、なんて気にしてしまったりします。そこまで気を使う必要はないのですが、モチベーションに関わってくるので大切だなあと思いました。
私自身がもともとメンタルが弱かったので特に。
今までだったら、これくらいいっかーって思ってた所、ああ、ここはやっぱり修正お願いしたほうがいいな🤔と思えるようになった。文字だと冷たく感じたらきっと凹むし、書き方も考えねば🤔🤔レビューするの難しいー😅#Web制作 #プログラミング
— Yumiko@癌サバイバーのミニマリスト (@engineerman8) 2020年12月13日
まとめ
- プルリクは細かく出してもらった方がレビューがしやすい
- でもissueは細かくしすぎるとそれも大変。かといってざっくりすぎても負担がでかい。
- ローカルで確認するのはgit fetch origin pull/プルリクID/head:ブランチ名
- コンフリクト起こらないように同時に同じファイルに着手してないかなど確認要
とりあえず。自分もまだまだわかってないことが多すぎるので手探りで今後も進めていきます。
逆引きが便利かもしれないと、今更思いました、、、。
そういえば派遣のweb制作の仕事が最近はやっと企業面談、選考まで進むようになりました。実案件をこなすとやっぱり派遣会社内でもポートフォリオを確認してもらえる機会が増えました。