2016-04-07

いまさら「リーダブルコード」

春もうららか、読書が気持ちいい季節になってきました。しばらくの間、夏ぐらいまで自由な時間が増えるので、積んでいる技術書を崩していく活動を始めました。

その中で、プログラマなら誰でも知ってるであろう、「リーダブルコード」をいまさらながらキチンと読んだので、印象に残った部分を読書メモとして残しておきたいと思います。

気づき

全体として 4 部に別れており、第 1 部で「表面上の改善」、第 2 部で「ループとロジックの単純化」、第 3 部で「コードの再構成」、第 4 部で「選抜テーマ」というように、部を追うごとにリファクタリングのレイヤーを上げていくような構成になっています。

特に第 3 部の 13 章「短いコードを書く」と第 4 部の 14 章「テストと読みやすさ」から、特に興味深い気づきがありました。

前線でサービス開発に携わっていたときは、いわゆる ディレクター と呼ばれる役割の方と協業することがほとんどでした。会社のカルチャーによってディレクターの役割は異なると思います。ここでは、プロダクトについて常に考えていて、仕様を考えてディレクションをする人 とします。

この本にも書かれているように、エンジニア（特にわたし）は往々にして甘い見積もりをしてしまいます。コードを書き始める前は「よし！こんなにイケてる機能を実装するぞ〜！」と思ってしまい、アレもコレも二つ返事で実装しようとするので、最初の計画よりもリリースが遅れてしまうことがありました。

シニアなエンジニアは、ディレクターのやりたいことを聞いて、工数を考慮しながら巧みに仕様を削り、実現が難しい場合は代案を考えて、キッチリと期限に成果を出します。そして、そこから生まれるコードは簡潔で、過度に複雑ではなく、あとから触るのも苦痛でないコードになります。

何気なく使っている RSpec や test/unit ですが、「リーダブルコード」に書かれてている「良いテスト」を書くためのデザインパターンを、そのままフレームワーク化したものであることに気づきました。

たとえば、RSpec ではテスト対象のアサーションとして、以下のような記法で書けます。

expect(user.name).to eq 'Alice'

これは、本文中で紹介されている「テストの本質を 1 行にまとめる」の実践であるといえます。

また、テストが fail したときの親切なエラーメッセージは、本文中の「手作りのエラーメッセージ」の実践であるといえます。

このように、テストフレームワークは良いテストを書くためのデザインパターンを実装したものであるので、その裏にある概念をしっかり理解してテストフレームワークを使っていくことは価値が高いなと思いました。

「これってほんとかな?」と思う部分もちらほらあって、ちょっとのどごしが悪いですが、時間をかけて読む価値はある本だと思います。キレイなコードを書けるようになりたいですね。