bon now

Web+DBPRESSを購入するつもりで書店に寄ったはいいものの、 発売日を間違えて覚えていて、欲しい本がまだ店頭に並んでいなかった。 そのため、目についたオライリー本の 「リーダブルコード　－より良いコードを書くためのシンプルで実践的なテクニック」をその日は購入したのだった。

僕がこの本を購入しようと思ったきっかけは2点。現在SIerとして作業する中、 昔誰かが書いたコードやチームで書いたコードをほぼ毎日目にしているわけで、 そこから「これ何やってんだ？」とか「何がしたいんだろう」という疑問が湧くことの多いこと多いこと……。 自分1人での作業ならともかく、それを保守したり改修したりして食いつないでいかなければ行けない場面もよくあるので、 コードを如何に読みやすく、良い方向に持っていけるかと悩んでいたのが1点。 もう1点は、Webサーフィンしていると各種ブロガーのブログ下部で宣伝されていた&Amazon評価が高いからだ。

読んだ感想を簡単にまとめてみる。

コメントがすべてではない

僕がまだ大学生でFPSでプレイヤーキルしていたころ、 授業では「各行の処理にコメントを書けよ。変数とかメソッドのコメントは『Stringを返す』とか『Intを代入』て書くなよ｣と 言われていた。 めんどくせー！絶対採点基準にするために書かせてるだろとか思ってたけど、 業務を通してでも本を読んだ後でも、あながち嘘言ってないしおかしい話でもないなと考えるようになった。 本にも同じような視点でソースコメントについて書かれてあったし、 それが「良いコードなのだ」という認識であるというのを知ることができたのはかなりプラスだった。
(ソースコメント意外と重要じゃね？とか思ってたのは自分だけじゃないという認識も持てた)

じゃあコメントだけで良いコードになるのかといえばそうではなく、 コメントも「やりたいこと」や「どうなるか」に着目した上で、 ソース全体ではなく必要な箇所に埋め込むことがシンプルでより良いコードだという説明があった。 これは目から鱗で、とりあえずコメント書きまくればOKという方向性のない僕の意識に、ズバッと切り込んできた。 これだけでも読んだ価値はあったと思う。

ネストを省き、1行書きを極力わかりやすくする

どっかのオレオレコーダがリファクタリングという名目で、 Rubyのコードをほとんど1行ないし後置ifとかで23行に抑えながら「オレすげー」やってたのをWebでみたけど、 あれが自分のチームだとするとゾッとするなぁと思った。 もちろん、コードが読みやすければそんなに問題はないのだろうけど、 コードの表記方法や意味導出までのアルゴリズムの流れは、 チームとして統一化・基準化されたほうが良いだろう。

昔からプログラムは芸術とは思ってたけど、それが自己表現に徹するのは「個人」であるときだけ。 プログラムにおける芸術の定義を自分流に表せば、創造すること、デザインすることに近い。
(つまりアートじゃないということ)

で、本書ではそういう自分の中で引っかかってた点をきっちり説明してくれている。 やっぱりプロジェクトとして、仕事としてコードを書くというのは、 表現することよりも「伝えること」に重きを置かなければならないと再認識した。

最終章の例題が難しい

これは僕がC++を知らないとかFPSみたいなタイマー処理の理解に乏しいとか外的要因が大半を占めるんだけど、 リファクタリングを繰り返してシンプルイズベストにコードを変えていく著者がWizardに見えたのだ。 まあ、分からないなりに手順としては以下のようになると思う。

1. とにかく書く
2. 1メソッド=1つの処理(主処理に必要なサブ処理は別メソッドにできるだけ外出し)
3. オーダー(計算量)を考える
4. 必要と思われるコメントを追記・修正する

大学でやったことが、ちょっと自分のためになっていたというのを十数年経ちそうな今気付かされたのだった。