対面レビューに参加した話

対面レビューの重要性

僕は、新卒で今の会社に入社した。 ほんの数カ月前まで、全くの未経験だった。

ここ数ヶ月で手取り足取り色々なことを教えて頂き、 本当に楽しい毎日をすごしている。

ところで、今日、同期の対面レビューがあった。 うちの会社のレビューの流れは、
1. コードを書く
2. GitLab で主にチームメートがレビュー
3. 修正する
4. ある程度修正が溜まった段階で、会議室でディスプレイにコードや作ったものを映しながらレビュー

という流れになっている。

僕のレビューは約2週間前にあった。
その時は、結構つっこみが多く、修正するのが大変だった。

そんな思い出もありつつ、今日、同期の対面レビューに参加した。

自分が指摘される側では気づけないことがあると思ったからだ。

そして、気づいたことは、

• コメントアウトはイラッとする(console.log('hoge');とかも)
• 適度にスペースを使わないと見づらい
• 2箇所以上で用いる処理は、メソッドとして切り出す
• コードレビューはメモを取りながらしてもらう

みたいな感じだ。

コメントアウトはイラッとする

僕も結構コメントアウトを残したままpush してしまうことがある。
だけど、初めてレビューする側に回ってかなり嫌な気持ちになった。
理由は、
- 画面に映せる範囲が限られているので、スクロールしなくてはならなくなる。
- なぜ残っているのかを考えてしまう
だ。他にも何か思った気もするから、思い出したら書く。

適度にスペースを使わないと見づらい

コードを書いているときは、集中しているから、多少見づらくても関係ない。
だが、読む人からすると、少しの見づらさは致命的だ と気づいた。
似たような処理をしている箇所はまとめて、少し毛色が違う処理はスペースを開けるといいと思った。

2箇所以上で用いる処理は、メソッドとして切り出す

これは、同期のコードを見て気づいたことだ。
僕は、2行ぐらいでかけてしまう部分は、わざわざメソッドとして切り出す必要はないと思っていた。
可読性とかあんまり関係ないし。
だが、実際に、メソッドに切り出されたコードを見て、
読みやすいことに気づいた。
これは、即実践しようと思う。

コードレビューはメモを取りながらしてもらう

これは、録音とかでもいいかもしれない。
とりあえず、後で見返せる何かが欲しい。
僕は、コードに直接 // TODO を書いていったが、
TODOは、その箇所を修正したら消してしまう。
見方を変えれば、プロのエンジニアが僕にかけた時間が水の泡になっている。
もちろん、一度言われたことを二度と間違えない人間なら問題無いだろうが、僕は超人ではない。
ということで、今度から対面レビューをしてもらうときはメモを取ろうと思う。

今日学んだことは、こんな感じです。
今日作ってしまった ポンコツAPI の話はまた次回。

ルール

今日は、1ポモドーロ以内！読みなおす時間も少し残っている！素晴らしい！