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

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

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

商品レビュー

2025/08/23

プログラミング界隈でよく話題になる名著。
調べてみると新しいKADOKAWA版と内容は同じらしいので、安くなっていたのでアスキー版の古いほうを購入して読んだ。

2009年発売と少し古い本だけど、根本のコードのクリーンな書き方は変わってないのだろうなと。今だったらどう変わるだろう。DRYについて、同じコードがあったらまとめるということではないとかは書きそうな気はする。

ソフトウェア開発にも5S原則、いわゆる「整理・整頓・清掃・清潔・しつけ」という考えが必要ということが、前置きに書いてあってビックリした。うまいこと、sが頭文字の英単語にあてはめているらしい(sort、systematize、shine、self-disciplineというように。「清掃」だけ記載が無かったけど、なんと英訳してるんだろう)。

第1章には「いずれはすべてのコードが生成されるようになるので、書く必要はなくなると。そしてビジネス領域の人達が、仕様を元にプログラムを生成できるようになるので、もはやプログラマは必要ないと。」と書かれてあって、ちょっと笑った。今の時代になって、この言葉は現実味が増してきたきがするけど、著者としてはそうなってもコードから逃れられるわけがないとのこと。確かに、AIがコードを生成しても、よりソフトウェア設計という考え方は重要になるなんていってる人もいるしね。それは分かる気がする。

粗悪なコードを管理することができなくなって、会社を廃業に追いやったという話は、ドキッとした。廃業まではいってないけど、粗悪なコードのせいで不具合が多発して大赤字というプロジェクトになってしまった経験があるのでよく分かる。もう、ああいうのにはなりたくない。

呼び出される関数は、呼び出し元よりも下に置くべきという言葉には、結構意外だった。自分自身、順序はそんなに意識してたわけじゃないけど、むしろ逆のような気もするし。
例えば、privateメソッドとpublicメソッドだと、publicメソッドが上のほうがいいらしい。意識していきたい。

それにしても、Javaって本当、nullチェックが面倒で忘れがちな言語だなと思う。今は静的解析で防ぐようになってるのだろうか。

テストを書く際の、F.I.R.S.Tという原則は初めて知った。Fast、Independent、Repeatable、Self-Validating、Timelyの頭文字をとったものらしい。自分はいまだにテストを書く癖はついていないので、書くようにしたい(とここ数年ずっと言っている気がする)。

フラグ引数ってついつい使いがちだけど、やっぱりやめたほうがいいんだろうな。ここも気を付けたいと思う。

それにしても、ソースコードの間違いが多く、訳注で「おそらく、○○の間違い」とあるのだけど、これって原作者に確認とって、ソースコードのほうを書きかえるってことはできなかったのかと思う。

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

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