『Clean Code』を読んだ

達人に学ぶDB設計 徹底指南書に続き、言語やフレームワークに依存しない本として何か読みたいと思い、評判の良さを以前から聞いていた『Clean Code』を読みました。なかなか読み応えのある良い本でした。

日本ではリーダブルコードがよく新人にお勧めする本として挙がりますが、redditの開発系subredditなどを読んでいると、海外ではリーダブルコードの名前が挙がることは少なく、代わりにこのClean Codeの名前をよく目にするような気がします。内容としては読みやすい = 綺麗なコードの書き方ということで似ているのですが、Clean Codeは日本では訳書が絶版になってしまっていることが影響しているのか、あまり広く読まれていないようです。

(2018/01/24 追記)
訳書が2017/12/18より再出版されているようです。

構成としては、1〜13章が本編、14〜16章がバッドコードをリファクタリングするケーススタディ、17章がコードの臭い・ヒューリスティック集となっています。

どういう本か

序文で、近代建築の巨匠であるミース・ファン・デル・ローエの「神は細部に宿る」という言葉を引用し、ソフトウェア開発では細部にこだわることが重要と言っています。また、この本は読んだだけで"feel good"にしてくれる本ではなく、Clean Codeを書くのは”hard work”であると述べています。例となるコードがたくさん含まれており、頭に入ってきやすいように作られています。

以下、特に印象に残ったことを章ごとに箇条書きで書いていきます。Scrapbox読書メモを残しているので、さらに読みたい方がいたらそちらを読んでいただければと思います。

Chapter 1: Clean Code

  • 最近は人工知能の躍進が著しいので、やがてプログラマーの職も奪われるのではないかと危惧している人もいるのではないかと思いますが、この本では、「人間でさえ顧客の曖昧な仕様をシステムに落とせないのだから、機械がコードを勝手に作ってくれるようになるなんていうのは幻想。もしそうなったとしたら、今度は仕様書がそれだけ形式的になるというだけ」と述べており、なるほどと思いました。
  • マネージャーにバッドコードを放っておかないよう伝えるのはプログラマーの務め。バッドコードを放っておくのは、医者が手術をする際に時間がかかるからといって手洗いをしないのと同じ。
  • 「この本は柔術の流派の1つを教えるようなもので、絶対的に”right”であるとは考えないで欲しい」と言っていますが、確かに著者の得意とするJavaアジャイルの文化が色濃く反映されているので、全てを鵜呑みにする必要はないと思いました。

Chapter 3: Functions

  • 関数の最初のルールは小さくあること、2番目のルールはさらに小さくあること。
  • 関数の長さは20行を超えるべきではない (異論が挟めそう)。
  • Kent Beckの視覚効果を画面に出すJava/Swingプログラムを見せてもらったら全ての関数が2〜4行に納まっていた。
  • 文章を推敲するように、まずは汚く書いて徐々に綺麗にしていく。その際にテストコードをまず書いておき、改良したあともテストが通るようにすると良い。

Chapter 4: Comments

  • コードの表現を補わなければいけなかったという意味でコメントは常に"failure"である。
  • コメントはメンテナンスされずにいると正確性を欠くようになっていまう。コードだけにしか真実は表されていない。

Chapter 5: Formatting

  • 新聞には見出しがあり、最初の段落であらすじが書かれ、次に詳細が書かれる。ソースファイルも同じように名前は簡潔かつ明瞭で、上部に高レベルな概念とアルゴリズム、下部に低レベルな関数と詳細が書かれているべき。
  • かけ算、割り算の演算子は1*2のようにひっつけて書き、足し算、引き算の演算子は3 + 4のように離して書くと優先度が分かりやすい。

Chapter 6: Objects and Data Structures

  • オブジェクトはデータを抽象化の背後に隠蔽し、公開された関数を通してデータを操作する。データ構造はデータを公開し、意味のある関数を持たない。
  • 手続き型コード (データ構造を使用するコード) は既存のデータ構造を変更することなく関数を追加することが容易。オブジェクト指向コードは既存の関数を変更することなく新しいクラスを追加することが容易。
  • 手続き型コードは全ての関数の変更が必要なため、新しいデータ構造を追加することが困難。オブジェクト指向コードは全てのクラスの変更が必要なため、新しい関数を追加することが困難。
  • 全てのものがオブジェクトというのは神話でしかない。時にはシンプルなデータ構造と手続きが必要なときもある。

Chapter 9: Unit Tests

  • 3つのことがテストを綺麗にする。それは可読性、可読性、可読性である。テストコードではプロダクションコードより可読性が重要とも言える。

Chapter 10: Classes

  • クラスのサイズを測定する際、行数ではなく責任 (responsibilities) によって測定する。
  • 70個のpublicメソッドを持つクラスを5個に減らしたからといって、責任が減るというわけではない。
  • SuperDashboardのように、Super、Processor、Managerといった名前のつくクラスや、"if"、"and"、"or"、"but"のような言葉で繋げなければ説明できないクラスは責任の多さを示唆している。

Chapter 15: JUnit Internals

感想

「そうなのか!」という驚きというよりは、「ふんふん、そうだよね」という感じが多かったです。ある程度、開発経験を積んだからかもしれません。

ただ、「どこまで当たり前のことを当たり前にやれるか」ということが開発をする上で大事なことのように思います。一度サボりだすと雪崩を打って、割れ窓理論で言われるように全てが崩壊してしまうものだと思います。そこのところを注意しつつ、最初から完璧に綺麗なコードを書こうとせず、初めはダーッと書いて、まとまったところですぐにリファクタリング、の繰り返しをしていくのがいいのではないかとこの本を読んで思いました。