「コードレビューをする」という成長の機会

Pocket

「何かコードレビューについて、良いネタないですかね」と社内で振ってみたところ、「最近コードレビューされる側の記事を書いているみたいだけど、視点を変えて、する側の視点で考えてみては?」というアドバイスをいただきました。なるほど。

コードレビューをすることによる成長

「コードレビューをすると、いろんな発見があるよね」という話。なるほど、確かに言われてみれば、いつもいろんな発見がある気がする。他の人からもらう指摘も確かに勉強になるけれども、いざコードレビューするというときにもいろんな勉強をさせてもらっている。

例えば「うーん、読みづらいな・・・」と思うとき。何で読みづらいと思うのか? 自分のコードではどうなのか? どうすれば読みやすくなるのか? なんてことを逡巡したりする。

読みづらい、というのは単にコードが汚いというわけではなくて、コードレビュー時のチェックポイントをチェックする上で、権限周りがかなり複雑に作りこまれていたりすると、正しいか正しくないかの判断がつきにくくなるとか、そういうレベルのこと。もちろんテストも用意されている。

一方で「これ、良い書き方だなー」とフムフムすることもある。「うーむ、何も文句が言えない・・・」別に文句を言うためにコードレビューするわけではないのだけど、コメントが一つもできないと何だか負けた気になるのも確か。しかし良いコード書く人がいるんですよねー。

そういうわけで他人のコードをが読めると、物凄く勉強になるし、一気に学習曲線が上がる気がする。他人のコードをしっかり読み解ける素養というのは、プログラマの基本アセットなのですね。

そんなコードを読み解く技能、同僚と話している中で三段階あるよね、という話になった。

  1. 全く分からない
  2. ぼんやり、なんとなく分かる
  3. 自分で書ける

はっきり分かるというのは、つまり自分でも書けるということだよねという話になって、確かにその通りだなーと思いました。そういえば自分でもこれに関連して、こんな記事を書いていました:コードを読んでいるときって、どんな思考プロセスで読み進めているんだろう

しかし読めなきゃ書けないし、書けなきゃ読めないし、どっちが卵でどっちが鶏だっていう話ですね。個人的には、クソコードでもなんでもどんどん書き散らかして、その後に良いコードを読んで自分のコードを改善していくようなスタイルが、一番近道かなっと思ったりします。最初から完璧に上手くやろうと思うと、全く書けないし、全く前に進めないと考えています。