コードレビュー初心者視点

gistfile1.md

1. 新しいチームに入って最初に見たコードなんでわからないことしか無いので、「なんでこうしてるんだ？」っておもったらまず聞くことを心がけた

• 聞かないことには始まらないし、深い理由を追えない
• 理由を聞くと思想がわかってくるから、他のコード見た時「あ、なるほどな」ってなるようになるのでいい

2. コードで大切にしている方針を見ながらレビューするようにした

• ポケットだと「良いコード = みんなが理解しやすいコード」みたいなのがざっくりあったからそれを意識してレビューしてた
• ex) mapとgrep使いまくって一行で納めてるコードより、methodに細分化して名前をつけたコードのほうがみんな分かりやすい的な
• チームで大切にしている考えをもとにレビューしていけば、いいプロダクトになる

3. LGTMつかってこ　

• ポケットに入ってから使い始めたけど、和やかになるからよかった

4. レビューの書き方

• 「このコードはほげほげだからいいと思いますが、ふがふがみたいな書き方のほうがぽけぽけでいい」みたいなかんじで、相手の良いコード部分をほめて自分の意見もかくようにした(できてなかったかもだけれどもですが)
• 相手のコードでいいとおもったところには 🙆‍♀️ をとりあえず書いた。褒められたらだれだってうれしいし、褒めることはいいスパイラル。

できるならこうしたほうが良かった

1. コードの設計とかの点でももっとみれたらよかった

• 自分に設計の力が全然無いからできなかったけど、こっちのほうがええやんっておもう意見があれば言ったほうがいい。とりあえず意見言うの大事

2. 実例のコードもっとのせてもよかっや

• 自分に設計の力が全然無いからできなかったけど、実例のコードをもっと添えて載せればよかった。コメントと、コード見せるがいちばん伝わりやすいだろうから

困ったこと

1. 上司が怖くて思ったことがかけない

• 言い方気をつけれおこる人なんてそんないないのでがんばってかこう。とりあえず明るくしてれば怒られない！
• 言いたいことだけ言って、LGTMでとりあえず回避。(逃げの戦法だからだめ)

2. 自分は力量無いのにそんなレビューで偉そうなこと言っていいのか

• 相手を尊重してれば何も悪いことは怒らないはず。
• 周りの人も最初から「こいつ！完璧やで！」と思ってる人なんてそんないないので気軽にレビューしよ。(たまにできないで苦しむ人いる自分とか)

まとめ

最初はわからないことしかないので、コードみてわからないことがあったらまず、聞かないとアカンっていうのが一番大事なことかなと思いました。 コード見て自分で考えるのもいいけどコードレビューは10分みてわらかなかったらきいたほうがいい！自分で考えると時間かかってもったいない。 人にきいたほうが考えも一緒にきけるし。 とりあえずわからなかったらきく！