見出し画像

僕なりのソースレビューの仕方

目が痒いのは花粉症なのか
ponzuです

ソースレビューっていっすよねー
ソースレビュー

昔はレビューなんて文化を知らなかったりして
質もクソもあったもんじゃなかったんですが
ある案件に携わったときに
ソースレビューで何回もChangeRequestされて
すげぇイラついたんですが、
完成したソースのクオリティをみて
あーこのためにやってたんかー
ソースレビューの大切さとすごさに気づきました

そんなソースレビューですが
我がチームでもレビューをしていたりするんですが
そのレビューの仕方をちょいと書き出してみます

レビューの目的

結論から言っちゃうと、
・ソースの質の向上
・バグを未然に防ぐ
があげられるかなと思います

まだ僕も未熟なもんで、
もっとたくさんメリットはあると思いますが
とりあえずこれらは必ずあると思います

コーディング規約
ベテランエンジニアからのベストプラクティスの提案
などを受けることができるので、
必然的にソースの質やレベルが向上します

また、作った本人でない人が見るので
バグを見つけやすかったりするので
サービス・システムとしても質が向上しますね!

また、レビューされる側のメリットだけでなく
レビューする側のメリットも存在してたりしてー
・いろんな作り方を見ることができる
・システムへの理解が深まる
・他人が何をしているかを理解できる
などなど、
こちらに関してももっと大量にメリットはあると思います

人が作ったものを見る
という行為が
エンジニアにとって一番勉強になる行為だと
僕は思っています

なのでレビューをすることで得られる
メリットっていうのは非常に多いんですよね!

注視すべきところ

さて、レビューをするにあたって
注視すべきところというよりは
僕が注視しているところ
に関してあげていきます

基本的な
・規約に沿っているか
・バグが潜んでいないか
という点は必ず見る、最低限の項目として、

まずは
・誤字(typo)
ですかね

見落としがちなのでレビュー時に指摘してあげましょう

これって最近のIDEの性能が良くて
変数名を間違えて定義してしまったら
入力補完で間違えたことに気づかずに
全部の変数名をその間違えた名前で作っちゃったりします

エラーも出ないので別にいいじゃんとも思えちゃいますが
typoのせいで他の人が困っちゃうことも
十分に起こり得ることなので
誤字はないに越したことはない!ということですね

あとは
・可読性
ですね!

僕はこの可読性というものがプログラムにおいて
かなり重要なことだと認識しています

なぜなら、
ソースコードは人が読むもの
だからです

人が読むものを読みにくいものにしてしまっては
ソースコード本来の用途を果たせていない
と言っても過言ではない(過言)

こう書いた方が読むときに楽ですよ
とか
この変数名じゃわかりにくいよ
とか
この処理は関数化すべきですよ
とか
定数にしちゃいましょうよ
とかとか

パターンが場合によって複数存在するので
例にあげるのは難しいですが
意識するべきは「可読性」ですね

何が可読性の高いものなのか
というのはリーダブルコードとか
その他コードを綺麗に書くための文献で
学んでみるといいかもしれません

僕はリーダブルコード読んだ

レビューする側の心持ち

注視することはさておき、
心持ちですね

だってレビューってめんどくさいじゃないすか
(こんな持ち上げておいて言うことではないですが)

そのめんどくさいと言う気持ちを抑えて
目的を意識して、前向きな心持ちでレビューすべきです

どう言う心持ちでいればいいかと言うと
「こいつのソースからバグ見つけてやるぜ!」
とかじゃなく
このソースから何を学べるか
と言うところが大切だと思います

もちろんバグ見つけるのも大事だけど!

ソースを読んで学ぶ
と言うことを先述しましたが
まさにそれで、
たとえ初心者のソースからでも、
ロジック面やコードの書き方、名前の付け方など
たくさん学べることは存在するはずです

ソースの中にある悪いところだけでなく
良いところも見つけるぞ!と言う心持ちが大切かなと
思います
うん

レビューをお願いする側の心持ち

とりあえずできたからレビューオナシャース
指摘箇所直したのでレビューオナシャース
じゃなくて!

どう言う意図があってこう言う指摘をされたのか
同じ指摘をされないためにはどうすべきか

と言うところを考えながら開発することで
レビューの本領が発揮されると思います

前指摘されたことはもう指摘されないようにしよう
と言う心持ちは大切だと思いますよ!

あと、レビューに関しても人に読んでもらう行為なので
たとえば対象ファイルが1000ファイルあった場合、
レビュワーは果たして全てのソースをしっかりと見れるでしょうか
見れない
見れるわけない
見たくない
んですよね!

逆の立場ならそうですよね

逆に10ファイルくらいのレビューであれば
変更箇所を隅々までチェックできたりするわけです
余裕があれば影響範囲を調べたりまでできたり
挙動のチェックに時間を使えたりと
メリットはたくさんあるわけですね

なので、レビューを依頼するときには
レビューをしやすいような状態で依頼しよう
と言う心持ちが大切だと思います

自分で書いて自分を見直してます

僕も
ちゃんと意識できてるか?
心持ちは正しく持ててるか?
と言われると沿っていないようにも思うので
このブログを機にちゃんとしようと思いますよ
えぇ

実際レビューってどれくらいの人が実施してるんだろう

結構人間的な作業だと思うので
大変ではありますが、
自分の知見を深められたり
システム・サービスの質に直結すると思うので
是非ともやってみてね!

僕も頑張るよ!!

ponzu

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
ありがとうございます!!!!励みになります!!
4
MiddleField株式会社のプロダクト開発チームによる技術ブログ(技術に限らない)です 弊社HP : https://middlefield.co.jp/

こちらでもピックアップされています

MiddleField株式会社 エンジニアブログ
MiddleField株式会社 エンジニアブログ
  • 35本

「モタガレ」をはじめとしたMiddleFieldのサービスを支えるエンジニアたちのつぶやきです。

コメントを投稿するには、 ログイン または 会員登録 をする必要があります。