おっさんのプルリク疲れ

シェアする

ヨメレバCSS

 次はプルリクの無いところにいきたい。

スポンサーリンク
レクタングル (大)

争いしか生まれない

 転職してから初めてコードレビュー、GithubのPull Requestを使った開発フローに携わった感想としてもうこれイヤだ。争いしか生まれない。

 割と自分の性格として、自分が関わったことで納得いかないと絶対退かないみたいなところがあるようなのですけれど、これがどこで一番出てくるのかと言えば自分の書いたコードなんですよね。

 バグ、実装漏れ、コーディングルールから逸れているなど明確な間違いについてはごめんねとしか言えないので別に良いのです。問題はコードの書き方や実装方法について意見されたときに発生します。

 僕自身が、そちらのほうが良いと納得した場合はそれでよく、その提案は採用できないと却下したときにそこで終わる場合もいいのですが、提案を却下した後で揉めるパターンが割とあって本当に辞めたい。

 こっちはこっちで当然ながらそれなりに考えて実装しているものではあるので、レビュアーの見解から別の意見があることは理解しつつもその提案は受け入れられないとすることはあります。そこから対応についての議論になればいいんですけどひたすら正論(笑)を詰められて終いには「そんな実装素人かよw」「時間の無駄だろ(俺の言うとおりにしないから)」みたいなこと言われたらあとは命のやりとりしか残ってないだろ。

 しかも提案されたのは僕個人から見て修正前よりひどい。俺が素人なら素人以下の提案だわ。(個人の感想です)

 そんでそこまで抗争してそれがどれだけ一大事かって話になると引数をboolにするか文字列にするかみたいなレベルの話なんですが絶対退けないんで相手が「いっぱんてきーいっぱんてきー」言ってる根拠調べて理解しようとして何も出てこなくて聞いてもなんかぶつぶつ言って「そんなことに時間掛けてる暇ないんで」とか言い出すし本当に嫌になる。まあ僕はこれでも社会人経験長くなっているのでこっちが折れて転職サイトを検索し始めるんですけど。

Pull Requestは良い機能

 それはそれとして、GithubのPull Requestは割と便利だと感じました。

 やってみる前は、いちいち作業用ブランチを切ることやマージ前のコードを確認することに面倒さを感じていましたが、慣れと理解の問題でしたね。

 コードレビューのプラス作用として、担当メンバー以外への理解や不具合の早期発見などはあると思います。全部理解できるか? って思うところありましたけど、おおむね分かってくるとあとは変更差分になるのでいいかなと。機能単位だから変更そのものは意外と少ないですし。

 また複数のリリースブランチを運用していく場合の修正適用などは、それぞれがんばるよりもプルリク出してしまったほうが楽ですね。

 ただこのフローの欠点として、レビュー時間を取って貰うことまで含めるので時間は掛かります。(とはいえ必要な時間であることに違いないので、欠点と呼ぶのは適切ではないかもしれません)

 レビューの差し戻しなどで予想外に時間が掛かることもあるので、スケジュールの仕方は工数見積もりとは別の慣れが必要になるかもしれない。

コードレビューがないほうが精神的負荷は低かった

 前職ではバージョン管理にGitを使って、コードについてはそれぞれがpushしているような運用をしていました。他の人の修正コードには一応目を通していましたがそんなに深くなく、半ば形骸化しているような感じすらありました。

 率直に言ってそっちのほうが精神的負荷は低かったですね…

 バグなどは無いわけではありませんでしたし、今の職場くらいレビューしていれば防げたものもあったかもしれませんが。逆にいえばそのバグをコストとして支払っても精神的負荷が低い方が良い。

 別にちょっと改行やインデントや書き方が違ってたりとかしても全然支障ないから。みんなそれぞれベストを尽くして書いているわけだから、そうそう変なことにはならなかったように思う。

 今ちょっと、コードを書いてプルリクとレビュー依頼をすることそのものに心理的抵抗を感じ始めていて、これこのまま行ったらコードが書けなくなって本末転倒になるんじゃないかなあってすら思ってます。

 もしかしたら少し前に話題になった「口の悪い人間をエンジニアとして採用するべきか」問題に通じるものがあるかもしれません。Google風に言うと「心理的安全」の話になるのかも。心理的安全面についてはA・Tフィールドガリガリ削られるようなところあるからなうちの職場。

 次はコードレビューの無いところに行きたい。

スポンサーリンク
レクタングル (大)

シェアする

フォローする

スポンサーリンク
レクタングル (大)