5万部売れた技術書、リーダブルコードを読んだ

書評

日本でトップクラスに売れているリーダブルコード

Web系の技術書の中でトップクラスに売れているのがリーダブルコードだそうだ。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

特定言語に縛られないコードの書き方とか開発手法といった分野が一般的に部数を伸ばしやすいという背景もあるのだろう。

まあ、それでも5万部なんだよね。

http://www.oreilly.co.jp/sales/2015/08/ebook-discount-campaign-readable-code-50k.html

先日、セールで40%OFFだったので読んでみた(セールはすでに終了)。

内容は、変数名の付け方とかコメントに何を書くかとかトピックごとに短いサンプルコードを使ってほらこうすれば読みやすくなりますよねって流れで進む。

この本で悪い例のようなコードを実装することが無きにしもあらず、てかあるので「あーあるある」と胸を痛めて読んだ。

中身もコンパクトでイラストも豊富で面白いのでサクッと読める(コードが読めれば)。

仕様を言語化するというプロセス大事

以下を意識すればいい必然的にコードはよくなると思う。

  • 自分がどのようなロジックのコードを書くのかを明確にする

  • コードが何をするかを明確にする

  • 変に技法に走らない

いや、これやらないでどうやってコードを書くんだって思うかもしれないが自分はたびたび実践できずにいる。

最初は意図が明確なつもりだったがいざ実装してみると動かない。 手当たりしだいに手を動かしてなんとか動くコードにはなったけどという状況は往々にしてある。

設計 → 実装 → 動かない＼(^o^)／ → 修正する → 別のバグが生まれる＼(^o^)／ → 修正する → 動いたけどコードはぐちゃぐちゃ

というスパイラルに陥る。

一人でコードを書いているせいもあるが、たいていコードが読みにくくなるのは時間に追われているせいだ。あせって近道をしようとして結果的に遠回りになっている。

時間という概念がなくなれば人はストレスから自由になる。そして進歩しなくなる。

僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う．

テスト先に書きたい若者よ - hitode909の日記

これからは設計が間違っていたと気づいた時に一度落ち着いてきちんと仕様を言語化するというプロセスを意識的に取らなきゃいけないんだなというのが個人的な気付きです。

これだけでも1億万円くらいの価値がある。

定量的な評価がない

ここから少し批判的なことを書くと、訳者まえがきにもあった"Noting New" というAmazon.com のレビューに以下のようにあってですね。

Amazon.com: W. Doran's review of The Art of Readable Code (Theory in Practice)

For an experienced programmer, there is nothing new in The Art of Readable Code.

「経験豊富なプログラマーにとって、リーダブルコードに目新しい物はなにもない」

なんでかって言うと、読みにくいコードもほらこうすることで読みやすくなっただろってサンプルコードを使って説明してくれるが、結果的にそうすることでどのくらい読みやすくなったかについては客観的な記述がないからだ。

Aというサンプルコードではプログラマーがコードを理解するのにX分かかっていましたが、リファクタリングを行った結果Y分まで改善しました、などのような定量的な評価がない。

リーダブルコードで述べられているのはただの意見にすぎない。

例えば、以下の2つのコードではネストをなくしている分、後者のほうが読みやすい。

if (user_result == SUCCESS) {
    if (permission_result != SUCCESS) {
        reply.WriteErrors("error reading permissions");
        reply.Done();
        return;
    }
    reply.WriteErrors(""); 
} else {
    reply.WriteErrors(user_result); 
}
reply.Done();

if (user_result != SUCCESS) { 
    reply.WriteErrors(user_result);
    reply.Done();
    return;
}

if (permission_result != SUCCESS) {
  reply.WriteErrors(permission_result);
  reply.Done();
  return;
}

reply.WriteErrors("");
reply.Done();

でも、どのくらい読みやすくなったのかについての記述は曖昧だ。 とても読みやすくなったとか曖昧で主観的な表現しかこの本にはでてこない。

段落の内容を切り抜く関数名はClipとTruncateでは、確かにTruncateの方が正確だ。だがそれがどのくらいの影響をどこにもたらすのかまでは書かれていない。

限界値を含めるときは min と max を使う場合と使わない場合ではバグの発生率はどのくらい変わるのだろう。

リーダブルコードでよい例とされている方が間違いなく理解しやすくバグも生みづらいだろう、と自分は思う。

だが、どのくらいよくなるかについては何も実験していないのでデータがない。

おそらくそれをやるには多大な時間と費用が発生するのだろう。

なのでお金持っているところがどこかやってくれないかな。もうすでにやってたりしてたら教えて下さい。

ただ、こういうプログラマーにとってのコモンセンスみたいなものがあるとコンテキストが高いレベルでコミュニケートできてコンセンサスが取りやすくなってトゥギャザーできてイイカンジプロジェクトが生まれる要因になるのでいい本だと思います。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)