スパゲッティコード

色々やりたいので書いてこうと思います

コードレビューについて思うことを書いてみたよ(思ってることだけだよ)

WEB+DB PRESS Vol.72

WEB+DB PRESS Vol.72

  • 作者: 近藤宇智朗,生井智司,久保達彦,道井俊介,飯田祐基,中村知成,規世やよい,後藤秀宣,天野祐介,奥野幹也,Dr.Kein,tokuhirom,森田創,中島聡,堤智代,A-Listers,はまちや2,竹原,川添貴生,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2012/12/22
  • メディア: 大型本
  • 購入: 10人 クリック: 86回
  • この商品を含むブログ (5件) を見る
今月は半分放浪の旅をして、半分は引きこもっていたせいで、そもそもはまるようなことがありませんでした。
そんなわけでしばらく放置してましたが、大晦日と言うことでとりあえずWEB+DB PRESS Vol.72の記事に コードレビューについて書いてあったのでこれを読んで思った事書きます。
大して役に立ちませんよ。思った事書いてるだけですから。

初めてはレビューする側だった

僕が初めてコードレビューというものを体験したのは、前の前の会社(新入社員で入った会社です)で2年目くらいでしたね。
しかも、レビューされる側ではなくなぜかレビューする側。
あのときはなんだかよくわからないうちにリーダー的なポジションにされてたので、お前みんなのコードレビューやってと言われてやりました。
コード書いてる人とかって、上の人とかがいっぱいいて、しょーもないやつもいたんですけど、非常に勉強になりました。
ああ、こうやって書くんだ、こういう書き方もあるんだ-、的な。
正直、コードの品質として向上したかどうかはよくわかりませんが、ここでレビューやらせてもらった経験はけっこうでかかったな、と思ってます。

レビューされる側になってまたレビューする側に

その後、前の会社に入って自分が書いたコードをレビューされたわけですが、大体ここらへんでコードレビューちゃんとやろうと思ったわけですね。
人から言われるのってまあなんかイヤなんですけど、あーここは見落としてたなあとかちゃんと素直に反省するべきところとかあってよかったなあ、と思ってます。

コードレビューのメリット

なんだかコードレビューの効能が勉強的な作用を前面に出して話しちゃってますが、これはこれで必要なんじゃないかな、と思ってます。
特にそんなにみんなのレベルが高くないところでは。
自分が言うのも何ですが、今までいた会社はそんなにレベルは高くなかったです。
全体の底上げをするという意味でコードレビューをして、後々それが綺麗なコード、バグりにくいコードってのになるので、即効性はないかもしれませんが、勉強的な作用を前面にしたコードレビューってのは必要なのかな、と思います。

ソースコードの共有

あと、本でも書かれてるんですが、コードの共有ってのはけっこう大きいですね。
僕は関わってるプロジェクトのほとんど全てのコードにレビュアーとして関わらせてもらってました。
そのため、実際には作成してないんだけど大体どこのコードがここにあってバグったときにここ直せばいいというのはほぼ把握できてました。
これなら作った人が仮にいなくなってもレビューした人がいたらすぐに対処できる!というわけですね。
ま、僕はいなくなりましたけど。
共有ってのは非常にメリットあるな、と思いましたね。

どんなレベルでやるか

これってすげえ難しい。
レビューだけやって、って言われて入ったら、そもそもここ設計おかしくねえか?と言うと相手がムッとしちゃう。
いやあ、ムッと思わせたいわけじゃないんだけどね、だっておかしいじゃないですか…。
大体そういうときはもう最初からある程度変な設計になってても言わなかった。
設計レベルで指摘するのは自分が設計から関わってるもしくは実装を自分もやってる時にしてた。
よくないレビュアーですね。

改修案件って

改修な案件って、これまた難しいんですよね。
改修した部分それだけを見ればいいのか、作り的な部分からちゃんと見るのか。
もちろん、後者の方がいいに決まってるんだけど、「既存をいじると…」とかお決まりのやらない理論が飛び出すわけです。
うん、困ったね。
メンバーの力量がわかってる場合は、それでもがんばればできると思えばやれよ、と言います。
まあそれでもやらないわけですけど。

結局それって…

テストがちゃんとできてないとか、CIな環境が整っていないとかなんで、しょうがないんですよ。
それはある意味で正しい。
けど、間違ってもいるわけで。
レガシーなプロジェクトはほとんどそうなんですよ。
これってたぶんこれからもずっとそうで、よほどリニューアルしますとかじゃない限りそんなん構築できませんよ。
既存に影響を与えないように作り替える方法なんていくらでもあるんだけどね。

あのう、レベルの話は…

はい、あれです。
その時々です!
新規でやってるんだったらフルで言います。
設計レベルから、実装レベル、規約レベル etc...
改修である程度環境が整ってるならできる限りレビューします。
ここらへんも時々ですね。
レガシーなプロジェクトは、やれる範囲ですね。
あんまり設計レベルにまで落とし込まないかも。
単純に実装で論理的なおかしいところとかのレビューになるのかな。
書いてて思ったけど、これだと大して意味ないし、やる側も楽勝ですね!
ま、フルでやらなければそれがずっとつきまとって負債となるんですけどね。

ホントはやりたくないけどやらざるを得ないこと

ホントはしょうもない命名規則違反のコードとかは指摘したくないんですよ。
だから最初に規約とかはちゃんと覚えとこうね。

まとまらないまとめ

そんなわけでコードレビューについて思うこと。

  • 規約は覚えとこう
  • 団体の技術レベルによっては教育的意義が強い(こういうところ多いと思います)
  • コードの共有は重要
  • 状況によっててかげんしちゃう
  • レビューは絶対必要だってばよ

とまあこんな感じでした。

WEB+DB PRESS Vol.72

WEB+DB PRESS Vol.72

  • 作者: 近藤宇智朗,生井智司,久保達彦,道井俊介,飯田祐基,中村知成,規世やよい,後藤秀宣,天野祐介,奥野幹也,Dr.Kein,tokuhirom,森田創,中島聡,堤智代,A-Listers,はまちや2,竹原,川添貴生,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2012/12/22
  • メディア: 大型本
  • 購入: 10人 クリック: 86回
  • この商品を含むブログ (5件) を見る