ぎんさんマインド

いちエンジニアの思考とか趣味についてつらつらと書いてみるかもしれない。

今年は人に教えたりコードレビューすることが多かったので備忘録まとめとく

どうも。

もう年末になって、個人的にはそろそろ今年一年を振り返ろうかなーと思い始める時期です。

そうして自分の一年を振り返ってみると、仕事で客先の方のコードみたり、最近でも自社の新人のコードみたり、なんだかレビュアーとしての作業が多かったかな?という感じです。(まぁ自分でもたくさん書いてますが)

その経験を元に、人からちょっとコードみてくださいと言われたときに自分ならどうみるかというのを、備忘録がてらまとめてみようかなと思いまふ。

 

とりあえずMUSTなもの

要件に沿った実装が行えているか

エラーメッセージが決まっている場合はそれらも含めて実装できているか。

作ったものが、どんなに素晴らしいものでも、相手が求めているものじゃなきゃ意味がない。

ここがはずれてたら大きく修正が入るので、まず真っ先にみなきゃいけない部分、手持ちの資料とかと並行して見ないといけないので、量が多ければそれなりに時間も根気もいる。

面倒だけど必須。これ見逃すのはアカン

 

テストが網羅できているか。

C0C1とかプロジェクト開始時の規約として決まると思うので、それが網羅できているかどうか。

そもそも抜けたテストがあるかどうかも含めてよく確認しておく。

抜けてたテストの部分にバグが潜んでたとかもたまにあるし、そもそもテストしにくい部分にバグが潜んでたとかもまぁある。

バックエンドなら一回実際にcurl叩いて見たり、フロントなら打鍵して見たりするのも良いかもしれない。

時間はかかるけれども。 

 

臭いを嗅ぐ

なんのこっちゃ?突然抽象的になったな。

実際うまく文章化も言語化もできないから辛い。でもこれがとても重要。

長年コード書いて人の見てりゃあざっとみて、「ん?なんかこの辺臭うぞ?」って思う時はままある。

新人の場合は人のコードを見様見真似で書いて見たとか、そういう場合はきな臭い。

「違和感あるけどなんだかうまく伝えられないし、まぁ言わなくても良いかな?」とか思ってスルーしてるとどんどん臭くなってくる。

 

ここから下はRailsで教えることが多かったからというのもあるかもしれない。

 

コードの可読性

ただでさえ、できる人のコードは魔法みたいだとか言われるのだから、どのレベルで記述するのかは予め定めておくべき(コーディング規約の統一)

ただ、そんな事言ってられない時もあるので、その時は各言語に定められている規約に沿って書いているかどうかを見る。

Rubyなら、true falseを返すメソッドなのに疑問符がついてないとかそんなものを見る。

mustではないけれども、新人が多い環境でそれをみんなが真似し始めるとヤバイ。

https://ja.wikipedia.org/wiki/%E5%89%B2%E3%82%8C%E7%AA%93%E7%90%86%E8%AB%96

 

レールに沿っているか

Railsは設定より規約という考えに沿っているので、もちろんその規約を知っていなければ道を外れていく、あまり経験がない新人相手ならこの辺は丁寧に教えていかなければならない。

その人個人の事前知識はバックグラウンドに大きく左右されるので、アレは知ってるけどコレは知らない。とかもありうるからここは丁寧に教えていこうね。

自分の知識の薄さにも気付かされるから勉強にもなる。

 

 

テストの可読性

Rspecは書き方が多様なので規約を付けないと十人十色のテストコードが出来上がる。これが本当に見辛くて、見てるだけでとても時間を取られてしまう。

 コーディング規約とか付けれたら良いけれども、開発中は忙しいからそっちに手が回らないなんてのもよくあるからなかなか辛み。

そんなのもあって結局、細かいフォーマットはどうしても良い。だがなるべく見やすいコードを書けという意味でコメントするようにしている。

でも実際のところ読みやすいテストコードに関しては私も勉強中。できる人に教えを乞いたい所。

 

ここからはコメントの書き方や言い方

 

なるべく丁寧な文章でかく

文字ベースだと思った以上に高圧的に捕らえられる可能性があるので、できうる限り丁寧にかく。日本人特有の、言葉だとこうだけど、裏ではこう思っているみたいな表現はなるべく避ける。

例えば

「どうしてこういう実装をしたんですか?○○だとダメなんですか?」

なんていうのは、書き手からしたら純粋な疑問なのかもしれないが、読み手からすると

「なんでこんな汚い書き方してんだよ!もっとこう書けよ!」

って意味合いに捕らえられる事もある。

というかそういう意味合いで使ってる人もいると思う。 

 

なのでこういう表現は避けて、IMO(私ならこう書くかなー)やIMHO(IMOの謙虚にした版)とか加えて言っておいた方が無難ちゃ無難かな?もっと良い言い方はあると思う。

 

教える場合は参考となるリンク等を提示し、答えだけを書かない。

書き方がおかしいとか間違ってるとかそういう時はよくあるし、それはどんどん言うべきだと思う。ただその場合、答えだけを教えるんじゃあ相手のためにならない。

教育の観点で言うならば、できるだけ相手に考えさせて答えを導き出せるようになってもらわなければならない。

なぜなら、これを覚えた後にその人が他の人に説明するというフェーズが必ずしも出てくる。

これはこうなんだという問題と答えだけ暗記したって、相手が「じゃあこういう時はどうなんですか?」「なんでこんな事してるんですか?これじゃダメなんですか?」とか質問されたときにスムーズに答えられないんじゃあやっていけない。教える側としてはそれは避けたい。

 

なるべくソースとなるリンクを加えておく

この辺は情報モラル的な考えも含めていくらか当たり前な事だとは思う。

自分がこういう考えを持ってコメントするのであるならば、それ相応の理由があるし、それを提示しなければ、相手だって、なんでこうしなきゃいけないの?って思う。

それを突き詰めていくのは時間の無駄だし、レビュアーの責任でもあると思うので、これは大事。

  

 

こんな感じだろうか。足りなければ後で増やしていく。

というか来年以降もどんどん増やしていきたいな。