アラフォーからのプログラミングとデザイン

大人から始めたプログラミングとデザインについてのあれこれ

人のプルリクを受ける側になってみたら結構大変

f:id:simpledancer:20201001152646j:plain

先日から某サイトを請け負ってます。
3人での共同開発で、私がその中でも勉強してた期間が長いということでPM的ポジションになってしまいました。

 
今までプルリクをする側、もしくは一人で開発してプルリクの練習をするくらいだったので、受けて、レビューを返す、他人のコードをローカルで確認するというのが結構大変だったのです(まだまだ開発は終わらない)。コンフリクトも起こるし、いざ受ける側になって難しかったことを書きます。

simpledancer.hatenablog.com

issueを書き出す

githubのissueを使ってタスクを書き出す作業が、まずは大雑把な私は、切り分けがめちゃくちゃ雑だったので、大変でした。
大まかに作業を決めてタスクを分けてみたのですが、ざっくりすぎて他の人にイメージが掴みにくいという事例。

で、今度は細かく分けすぎて、プルリク受けて返すという作業が多くなりすぎる。
ちょうどいい塩梅が難しいです。
確かにプルリクは今まで出してきたときに、量が多すぎると見る方が大変ということもあったけど、細かすぎてもやりとりがめんどくさい。

他人のコードの動作確認をする

今まで、プルリクを出してきて、レビューをしてもらう側だったので

「あれ、、そういえば、他人のpushしたブランチの動作確認って、みんなどうやってるん、、、?」

ってなりました。ググりまくって、今の所プルリクIDをgit fetchでローカルに持ってきて見るということをしてます。

で、いざコードをレビューしても、「ああ、、ここも見落としてた、、」ってことが多発。そういうためにプルリクって細かく出した方がいいのですね。

コメントの書き方(メンタル)

今回は共同開発なので、しかもあった事のない人との作業です。
相手の心を折らずに、かつ、わかりやすく、、これを文字に乗せていくのはなかなか難しい。
文字だけにすると素っ気なくて向こうは嫌な気分するかなあ、なんて気にしてしまったりします。そこまで気を使う必要はないのですが、モチベーションに関わってくるので大切だなあと思いました。
私自身がもともとメンタルが弱かったので特に。

まとめ

  • プルリクは細かく出してもらった方がレビューがしやすい
  • でもissueは細かくしすぎるとそれも大変。かといってざっくりすぎても負担がでかい。
  • ローカルで確認するのはgit fetch origin pull/プルリクID/head:ブランチ名
  • コンフリクト起こらないように同時に同じファイルに着手してないかなど確認要

とりあえず。自分もまだまだわかってないことが多すぎるので手探りで今後も進めていきます。

逆引きが便利かもしれないと、今更思いました、、、。

そういえば派遣のweb制作の仕事が最近はやっと企業面談、選考まで進むようになりました。実案件をこなすとやっぱり派遣会社内でもポートフォリオを確認してもらえる機会が増えました。

simplelifedancer.hatenablog.com