Clean Code アジャイルソフトウェア達人の技
- アスキー・メディアワークス (2009年5月29日発売)
本棚登録 : 335人
感想 : 18件
本ページはアフィリエイトプログラムによる収益を得ています
Amazon.co.jp ・本 / ISBN・EAN: 9784048676885
作品紹介・あらすじ
コードを書き、読み、洗練するときにどう考えるべきか?原則、パターン、実践、そして経験則を身につける。ケーススタディを注意深く読むことで、コードを洗練していく過程で行うべき判断について学ぶ。
みんなの感想まとめ
コードを洗練させるための思考法や実践的な手法が詳しく解説されており、特にリファクタリングに関する具体的な手順が示されている点が魅力です。著名な著者による内容は、オブジェクト指向プログラミングの深い理解...
感想・レビュー・書評
-
プログラミング界隈でよく話題になる名著。
調べてみると新しい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の頭文字をとったものらしい。自分はいまだにテストを書く癖はついていないので、書くようにしたい(とここ数年ずっと言っている気がする)。
フラグ引数ってついつい使いがちだけど、やっぱりやめたほうがいいんだろうな。ここも気を付けたいと思う。
それにしても、ソースコードの間違いが多く、訳注で「おそらく、○○の間違い」とあるのだけど、これって原作者に確認とって、ソースコードのほうを書きかえるってことはできなかったのかと思う。
0
詳細をみるコメント0件をすべて表示 -
平易な内容。リファクタリングを手順を追って示しているのは良い。が、類書もたくさんあるため、わざわざこれを選ぶかというと疑問。なので、★4
0
-
ソフト業界でのビッグ・ネーム、ボブ・マーチンのコード解説本。オブジェクト指向の奥義の続本で、非常に優れている内容となっている。特に、リファクタリングの例と、巻末のプラクティス集についての記述はすばらしい。コードはすべてJavaで書かれているが、C++、C#プログラマにも十分役に立つ内容となっている。
0
-
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の内容が印象に残った。手続き型とオブジェクト型の双方の利点と欠点が指摘されていて参考になった。
手続き型：新たな関数を既存のデータ構造に影響を与えずに追加できるが，新たなデータ構造を追加するには既存の関数全ての変更が必要。
オブジェクト型：既存の関数を変えることなく，新たなデータ構造（クラス）を追加できるが，新たな関数を追加する場合には，全てのクラスの変更が必要。
後半はけっこう読み流してしまったが，上記の考え方が参考になった。
0
-
CleanなCodeを書くための実践本。主にJavaが対象だが、書いてある内容は言語を問わないだろう。
特に、筆者が開発しているFitNesseでの例がよくでてくる。
コメントアウトされたコードは消せなど基本的なところから、SOLID原則やオブジェクトとデータ構造はどちらか片方にしろなどの話まで。
特に、17章の「においと経験則」は本書のまとめといってもよく、注意すべきポイントがまとまっていてわかりやすい。
一方で、Javadocレベルの記述ですら書くなという主張もあるように感じられ、少し違和感。
筆者はよほどコメントが嫌いなのだろうか。
無意味な記述しか書かないなら書くなというのには一理ありますが・・・。
その他、本書で共感した点としては、プログラミングとはシステムを記述するためのドメイン特化言語の設計と、それを使ってシステムを記述することであるという話。
クラスという名詞と関数という動詞を適切に抽出し、システム内で起きるすべての事象をカバーするストーリーを語ることこそがコーディングだと筆者は主張しているように思う。
テストについても、ドメイン特化テスト言語の考え方をベースに読みやすいテストコードにするなど、この思想が現れているように感じた。
ということは、ソフトウェアエンジニアにはシステムのストーリーを英語で書くだけの最低限の英語力と文章力は必須だということである・・・。
やはり論理的な文書を書くライティング能力も必要なのかもしれない。
0
-
クリーンなコードを書くためのノウハウ集。
命名規則・関数の長さといった基本的なところから、リファクタリングする際に着目すべき点と言った応用まで、幅広い範囲での示唆がある指南書。
一つの関数は一つの目的しか持ってはならない、というポリシーは理解できるけれども、現実問題としてかなり難しいことは経験上よくわかっていることなので、それをどう実装しているのかを実際のコードを見て、非常によくわかった。
日本語で説明できないものをプログラムに置き換えることは出来ない。それは完全に真理だ。
0
-
タイトル通りクリーンなコードを書くためのTipsのような内容！
ただそれだけにとどまらず、腐敗したコードにならないようなプログラマとしての考え方の面までとても参考になります。
個人的にはちょうど一年前に初めて読み終えたんですが、その時は約1か月くらい時間がかかって読んだのを今回は年明けから約1週間半くらいで読み終えました。ちょっとは成長しているのかなと感じる瞬間でした。
それだけ内容はとても濃く物理的にページ数も多いですが、『17章 においと経験則』だけでもとても参考になるところは多いと思います。
サンプルはすべてがJavaですがJavaプログラマ以外でも生きたコード、保守しやすいコードを書くという点でいえばとても読む価値がある本です。
また、前半部分はプログラミングの知識が深くなくてもとても読んでて参考になると思います。
0
-
オブジェクト指向とアジャイルに特化した今どきの『コードコンプリート』 http://booklog.jp/asin/489100455X といった感じで、プログラミングの細かいところを書き尽くしてる本。「神は細部に宿る」。サンプルはJava。
著者は、先日読んで大きな影響を受けた『アジャイルソフトウェア開発の奥義』 http://booklog.jp/users/frooprogrammer/archives/4797347783 と同じ Robert C. Martin。今作も非常に面白くてボブおじさんマジ師匠。
前著から抽象度を一段下げて実装の詳細レベルをテーマにした続編的位置づけ。というか、より身近なテーマで即効性高いので、こちらを先に読んだほうが良かったかも。
この人の本はどれもケーススタディが充実している。これが分厚くなる原因なのだが、現実のプログラムを例にしてとても丁寧に解説してくれて、理論と実践の溝を無理なく橋渡ししてくれる。
クラスもメソッドも短ければ短ければ良いとそこら中で強調されていて、私も異論はないんだけど、そうすると小さな要素それぞれに名前が必要。ところが、自分は英語が不自由なので、良い名前が付けられないのがもどかしい。分かりやすい変数名を付けるためにも英語を磨かなければ。
0
-
きれいなコードを書くための指針。
・スコープの大きな変数名、関数名、クラス名などの名前は冗長でも意味がわかるように付ける
・ただしスコープの短い変数や慣習に従うもの（ループ変数）は適切に短い名前を
・重複コードはくくり出す
・関数・クラスのサイズは小さく
・ユニットテスト書け
・リファクタリングちゃんとやれ
などなど。ある程度分厚いけど、目次を読んで知らない項目があれば読んでおくべき。
ちなみにサンプルコードはJava。
.oO(しかしよく名前重要って言われるけど、英語で知らない熟語表現とか出てくるとまったく意味が分からなくて困るという。英語勉強しろって話だろうけどねぇ・・・）
0
-
命名、関数、コメント、テストについて読みやすさを追求するための本。
説明だけでなくソースコードも載っているのでそれらを併せて読めば理解も深まるかと。本の内容やソースコードはJava中心ですが他の言語のコーディングでも十分通用すると思います。
コーディング時には常に手元に置いて、迷った時に手にとって読みたい本です。
0
-
コードを書くことについて再認識させられる良書。
名前重要、コメント重要、わかりやすさ重要、いろんなキーワードがちらばっていてコードを書くものにとって本当に勉強になる。自分が１０年かかって経験から身につけて来た様々な「良い」とされる習慣がこうもあっさり書かれているとちょっぴり今の人がうらやましくなる。
とりあえず新人に薦めてみた。ちょっと分厚いけど、絶対読んで欲しいなぁ。
0
この本が好きな人におすすめの本
著者プロフィール
花井志生の作品
