Clean Code アジャイルソフトウェア達人の技

ロバート・C.マーチン【著】, 花井志生【訳】

• 販売会社／発売会社: アスキー・メディアワークス/角川グループパブリッシング
• 発売年月日: 2009/05/29
• JAN: 9784048676885

商品レビュー

2018/10/23

ソフト業界でのビッグ・ネーム、ボブ・マーチンのコード解説本。オブジェクト指向の奥義の続本で、非常に優れている内容となっている。特に、リファクタリングの例と、巻末のプラクティス集についての記述はすばらしい。コードはすべてJavaで書かれているが、C++、C#プログラマにも十分役に立つ内容となっている。

2017/03/29

Javaを例にきれいなコードを書くための考察

きれいなコードを書くためにどうすればいいかということをテーマにした本。Javaをサンプルコードとして，汚い状態のコードからきれいな状態のコードにするにはどうすればいいか，けっこう具体的に書いてある。後半に行くにつれて，コードの量が増えるので，Javaに詳しくないとあまりおもしろくないと思う。

前書きのp. 14にかかれていた5S（整理，整頓，清掃，清潔，しつけ）や神は細部に宿る，p. 15「小さなことに忠実な人間とは，多くのことにも忠実なものです。」など，細かいことにこだわることは大きな成果をもたらすということをとても強く主張していたよかった。

個人的に特に興味を持ったのは，「第5章　書式化」と「第6章　オブジェクトとデータ構造」だ。

「第5章　書式化」ではコードの書き方の中で，配置について特に記述された章だ。垂直方向の配置（空行を入れるかどうか）や，水平方向の位置揃え（インデント，アライメント）など。この中で，p. 122-123の内容が印象に残った。

インスタンス変数をどこに置くかという議論で，クラスの頭で置くべきと主張されていた。これは，うまく設計されたクラスではインスタンス変数はひじょうに多くのメソッドで使用されるからとのこと。

その他，依存関数をどういう順番で記述するかというテーマでは，呼び出し側を呼び出される側の上に置くべきとあった。この理由は，上から下にコードを読む際に，自然な流れとなるからだった。新聞の見出しと同じように，大きな概要が上にあり，詳細が下の方に来ると呼びだされている関数を見つけるのが簡単になり，モジュール全体を読むのがはるかに簡単になるとのことだった。

p. 129では水平方向の位置揃えについての議論があった。例えば，以下のように変数の代入の羅列が合ったときに，空白の位置で揃えるかどうかという議論がある。
private Socket socket;
private InputStream input;

個人的には見やすいのでこの形式を採用しているのだが，筆者はこの欠点を指摘していた。
位置合わせをすると，間違ったことが強調され真の意図に目を向けることを妨げられてしまう。例えば，右端の列が強調され，左端の型を見逃してしまうといった具合に。
当初は著者も水平方向の位置揃えをしていたようだが，この欠点が気になりやめたようだ。位置揃えが必要になるということは，位置が揃っていないことが問題なのではなく，リストが長いことが問題だとも主張があった。

「第6章　オブジェクトとデータ構造」では，p. 141の内容が印象に残った。手続き型とオブジェクト型の双方の利点と欠点が指摘されていて参考になった。
手続き型：新たな関数を既存のデータ構造に影響を与えずに追加できるが，新たなデータ構造を追加するには既存の関数全ての変更が必要。
オブジェクト型：既存の関数を変えることなく，新たなデータ構造（クラス）を追加できるが，新たな関数を追加する場合には，全てのクラスの変更が必要。

後半はけっこう読み流してしまったが，上記の考え方が参考になった。

2014/03/22

CleanなCodeを書くための実践本。主にJavaが対象だが、書いてある内容は言語を問わないだろう。
特に、筆者が開発しているFitNesseでの例がよくでてくる。
コメントアウトされたコードは消せなど基本的なところから、SOLID原則やオブジェクトとデータ構造はどちらか片方にしろなどの話まで。

特に、17章の「においと経験則」は本書のまとめといってもよく、注意すべきポイントがまとまっていてわかりやすい。

一方で、Javadocレベルの記述ですら書くなという主張もあるように感じられ、少し違和感。
筆者はよほどコメントが嫌いなのだろうか。
無意味な記述しか書かないなら書くなというのには一理ありますが・・・。

その他、本書で共感した点としては、プログラミングとはシステムを記述するためのドメイン特化言語の設計と、それを使ってシステムを記述することであるという話。
クラスという名詞と関数という動詞を適切に抽出し、システム内で起きるすべての事象をカバーするストーリーを語ることこそがコーディングだと筆者は主張しているように思う。
テストについても、ドメイン特化テスト言語の考え方をベースに読みやすいテストコードにするなど、この思想が現れているように感じた。
ということは、ソフトウェアエンジニアにはシステムのストーリーを英語で書くだけの最低限の英語力と文章力は必須だということである・・・。
やはり論理的な文書を書くライティング能力も必要なのかもしれない。