『リーダブルコード』を読んだ
良い。
簡単なものが大半を占めているのがとても良い。簡単でそれで効果がある。簡単だから続けられる。リファクタリングとかおおげさな言葉を使わなくても可読性向上のためにできることがたくさんあり、それらをきちんと説明してくれている。
変数名一つ、コメントの修正やコメントの追加による段落分けだけでも可読性は大きく向上する。難しい理屈やデザインパターンなど知らなくても、それらを知っている、大幅に構造を整理し、シンプルで強力なプログラムを作ることのできる力のあるプログラマを、コメント一つで助けることができる。
ざっくり
とりあえずあいまいな名前、tmp, length, limit などは今すぐコードを検索して見直したらすぐに効果が出そうだ。
3章「誤解されない名前」では自分でも悩んでいた first/last, begin/end の使い分けに明確な指針を示してくれて、とても助かった。boolean を返す場合に is, has, can, should を使うというルールは確かに自分も使っていた。これはオープンソースのコードや各言語、ライブラリ、フレームワークを読んでいるうちになんとなく身に付いたものだろう。
7章「制御フロー」、8章「巨大な式」については本当にしょっちゅう話題にのぼるので、おさえておくとよいと思う。
心に留まったもの
仕事しない行
if ( cond )
; # 何もしない
elsif ( cond )
; # 何もしない
else
... # 何かする
end
を否定していない。
この書き方、たぶんきらいな人はきらいだし、コードチェッカは杓子定規に弾いてくる可能性の高い書き方だけど、個人的にはアリだと思っている。その方が書きやすく読みやすければそれでいいと思う。同じ考え方の人がいて嬉しい。
目立ちすぎる値、多すぎる値はテストコードを見にくくする
プロダクトコードよりもテストコードの方が荒れやすいが、特に境界値をいろいろやろうとしてひどいことになることはよくある。
そうしたときになぜそうなってしまったかを考えると、たぶん上の理由が多い気がする。
ライブラリを知る
書かなくて済むことを書かないためにも、言語、ライブラリを知ることが大切だ。リファレンスを読み、サンプルコードを読み、実装を読もう。
レビューのお供に
『リファクタリング:Rubyエディション』の序文にこうある。
私は、会議やコードレビューの席にはハードカバーの『リファクタリング』をかならず持ち歩いて、武器としても防具としても活用した。私は自分の仕事と（より強く）ソフトウェア開発の技に情熱を注ぎ込んでいたので、同僚のデベロッパたちの多くは、私がこの本を抱えて彼らのキュービクルに向かってやってくるのを見ると戦々恐々としていたようだ。もっとも、会議でたびたびこの本の内容を参照して発言していたわけではない。
以前、自分は後輩のコードを逐一レビューしていた。その際、指針が自分でもしっかりしていなかったので、なんとなく気持ち悪いとか、単に長いとか、そういう感じのレビューになってしまい、結局役に立っていたのかよく分からないとか時間が掛かる割に効果を感じてもらえていない1、仕事の進め方や分担が変わったなどの様々な理由で現在はあまりレビューはしていない。
『リーダブルコード』に出てくるポイントははじめにも書いたがとても簡単で効果の出るものが大半なので、特にコードのバラツキに悩んでいたり指導に悩んでいたりするならレビューのお供に使えると思う。ほぼ言語は関係ないノウハウだし。
この本には以前なら大量のコードを読んで初めて気づいたような良い作法が、とてもコンパクトにまとまっているので、自信のない人には特にオススメしたいし、自分が良いと思っている作法を効果的に後輩に伝えられずに悩んでいる人2にもオススメしたい。
もう一度。本書の内容の大半は簡単なことだ。だから良い。
これからは以前よりは納得がいって効果の高いレビューができるかな。