March 13, 2014
■ 些末なコードレビュー
朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。
あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。
コードが難読化されていない、コメントがそのまま残ってるから消しましょう・・・実にくだらない。
ところで話は変わってコードレビューについて。
コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい議論が紛糾しているのは「コードのインデント幅が違う」とか「return が省略されてる。俺は return があったほうが好み」とか「その場合は字下げをした方が綺麗にみえるんでは」とか、そんな些末なことばかりである、ということが多い。必ず一度は通る道である。
そんなことを延々議論していたって、はっきり言って何の意味もない。何の意味もない、は言い過ぎにしても、そんなところを改善したところで実質的な品質は何ひとつ上がらないわけだし、どうしても揃えたいなら lint ツールか何かで機械的にチェックすればよいことであって人間がやることではない。
やらなければいけないのは、その「設計は拡張に対して開いていないから開くべき」とか「これではエッジケースが想定されていないからこういう不具合につながるのでは」とか「そのテストでは後日見返したときに第三者が要求仕様を解釈しづらい」とかそういう指摘である。これらはちゃんとコードを読んで、コードの構造を把握して、そこに書かれているコード以外のシステムの全体感が頭に入っていて、初めてできる指摘である。当然、それをするにはレビュワーにも知識とスキル、そして真摯な態度が要求される。
JavaScript にコメントが残っているからダメだ、なんてのはインデント幅が2じゃない、4にしろ、と言っているようなものである。自転車置き場の議論を読むべき。難読化は、しなければいけないというものではない。仮に難読化ではなくソース圧縮だって速度的にそこが律速ならするべきだが、多少の JavaScript の文字数を減らしたところで、他のファイルとのサイズ間あるいは gzip 圧縮との相対感からいくとその効果はハナクソみたいなものであることがほとんどだ。
インデントがとか、コメントがみたいな指摘をしているのを目にすると、くだらない、と妙に腹が立つ。
なんで腹が立つのだろうか。
それは過去の自分がまさにそれそのものだったからだ。人間、他人に腹を立てるときは、そいつがあまりにも自分に似ているか、そいつが過去の自分・・・自己嫌悪の対象だった自分と重なってみえるからだ。自分の実力のなさをごまかすため、自分を大きくみせたいがために、些細な指摘をする。そのコメントは必要ないとか、if 分の条件の書き方がなってないとか、そこの括弧は省略できる、とか。そしてそんなことで優位に立ったと、自分を大きく見せられたと、思いこんでいる。やがて時が経ちいろいろ経験を積んだ頃になって、当時周りの先輩たちは、お里の知れてる自分を生暖かく見守ってくれていただけであることに気づくのである。
- 82 http://t.co/Id3tgZmb08
- 4 http://htn.to/KEC2Y1
- 4 http://t.co/cHx4xtHvRu
- 4 http://t.co/tLYEF7uZUZ
- 4 http://www.google.com/url?source=web&url=http://d.hatena.ne.jp/naoya/20140313/1394664578
- 2 http://api.twitter.com/1/statuses/show/443881946590883840.json
- 2 http://api.twitter.com/1/statuses/show/443882811259244547.json
- 2 http://api.twitter.com/1/statuses/show/443883416753160192.json
- 2 http://b.hatena.ne.jp/entry/www.itmedia.co.jp/news/articles/1403/12/news121.html
- 2 http://b.hatena.ne.jp/entrylist?sort=hot