入社５年目を迎えて自分でプログラムを書く機会よりマネージメントしたり、レビューする機会が増えて来ました。
私のいるSIerでは軽視されがちなコードレビューですがとても大切なことだと思っています。
今私が自社で取り組んでいることについて書いていきたいと思います。
アドバイスありましたらコメントお願いします。
#なぜコードレビューをしないのか？
なぜSI業界ではコードレビューをしないのか考えてみました。
SI業界の完全な作業分業制に原因があると思います。
コードレビューをするのにはそのプログラムの仕様を理解していないといけません。
しかし作業が完全に分業されてしまい、担当者以外プログラムレベルの仕様を理解している人がいないということが多いと思います。
これはコードレビュー以前に仕事の属人性を高めてしまいます。
#コードレビューをする機会作る
以下の場面でコードレビューをするようにしました。
１．業務内で作ったプログラム
２．研修として作ったプログラム（SIでは案件がなくて暇な時間ができる）
１については社内の人も時間があればやる（優先度が低め）くらいの認識はあったのですが、私はむしろ最優先にしました。
時間がなくて他のレビューはできなくてもコードレビューはやる！
２についてはレビューするという習慣がありませんでした。
むしろ書いたコードも研修期間が終わるとPCを初期化するので消えてしまいます。
理由としては「お客さんに納品するわけじゃないしそこまでやらなくてもよい」というところです。
練習でできないことは本番でできないと私は考えているのでこの考えを全く理解できませんでした。
研修でクソコードを量産させてそれをスルーして、現場でOJTと称して指導する。
この二度手間になんの意味があるんでしょうか？
とくに弊社では未経験で入ってくる人が多いので研修＝「はじめてのプログラム」と言う人も多いです。
それなのに変な癖をつけないでほしいというのが本音です。
#コードレビューで見ているポイント
大まかな流れとして以下のポイントを中心に確認します。
・プロジェクトでのコーディング規約を守っているか？
・変数名、コメント等がわかりやすいか？適切か？
・オブジェクト指向で作られているか？
・処理効率が悪くないか？
この内容で記事が一本かけそうな気がするのでその２の記事を書きたいと思います。
#逆にコードレビューで見ないポイント
アウトプットの結果や詳細は確認していません。
確認している人がいてそれを悪いというつもりはないですが、それは目視で確認してもあまり意味がないことでテストプログラムで確認するべきと思っています。
ただプログラムは一度動かしてみます。
これは詳細な中身を見たいわけではなくコードだけだとどうしても見落としてしまう部分が出てしまうからですね。
#その他で気をつけているポイント
##指摘の仕方・伝え方
コードレビューは人対人で行うものです。
そのためある程度、主観的な情報も入ってしまいます。
なので指摘の伝え方には注意を払う必要があります。
**この書き方は間違っている！すぐ直せ！！**みたいな高圧的な言い方は良くないと思います。
また口頭で伝えてしまうと直し忘れが出てきてしまいますね。
ケースバイケースで適切な方法を考える必要があると思います。
##気になった点はできるだけ伝える
レビューではこれを直してほしいという点以外に少しでも不思議に思った点は伝えるようにしています。
私が理解できなかったということは何かしら改善の余地があるポイントだと思います。
※私の理解力が低いだけかもしれません
レビューはレビューワーの私がレビューイの人をテストするような場だとは思っていません。
より良いプログラムを作るための工程だと思っているので
こうしたほうがいいんじゃない？
でもそうするとここで問題が発生するんだ
じゃあここをこう変えよう
みたいな議論をするのが理想かなと思っています。
#コードレビューを必須にして得られたもの
まだ初めて間もないのですが大きく分けると２つあります。
・チームメンバーのレベルアップ
・コードを直接書いていない自分のレベルアップ
今までなんとなくでプログラムを書いていた後輩たちがちゃんと考えてプログラムを書いてくれるようになったと思います。
「よくわからないけどこうすると動きます」みたいなことをしているとレビューで引っかかりますからねｗ
あと自分は直接手を動かしていないのですが、作ったプログラムすべてに目を通しているいるので処理を考えたりする時間はむしろ増えたように思います。