新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)
- オーム社 (2014年7月26日発売)
- Amazon.co.jp ・本 (480ページ)
- / ISBN・EAN: 9784274050190
作品紹介・あらすじ
マーチン・ファウラーが本書で真価を世に示してから15年、「リファクタリング」が当たり前で身近な作業となったいま、さらに読みやすくリファクタリングを施した日本語版、再誕。実践に照らした広範な訳文の見直しに加え、リファクタリング・カタログの使い勝手を向上。さらに、付録「Javaのバージョンアップに伴うリファクタリングをめぐる環境の変化」を収録。
感想・レビュー・書評
-
リファクタリング 既存のコードを安全に改善する
新装版詳細をみるコメント0件をすべて表示 -
・システムは「設計して作って終わり」ではなくメンテナンスし続けるものでそこに面白さと難しさがある。
・実務経験でオブジェクト指向での開発経験がないけど、この本でイメージしやすくなった
・デザインパターンの重要さを感じることができたので勉強し直す。。 -
かなり簡単なリファクタリングでも、慎重にステップを踏みながらリファクタリングしていくのが、印象的でした。
おそらくここに書いてあることですべてのリファクタリングを網羅できると思われる。書いてないことはここに書いてあることの組み合わせか、応用でできるだろう。
ソフトウェアにおけるリファクタリングとは組織におけるリストラクチャリングに相当すると思う。結局のところ、人材に対する適切な責務の付与などは最初から出来ないと思えば、採用に悩むこともない? -
「リファクタリング」という呼び名を一般的にし、リファクタリングの必要性、逆にしない方がよいケースを言語化、リファクタリングをカタログ化した名著。
「当たり前のことしか書かれていない」という感想を持った人も、間接的にであれ何らかの形で影響を受けているのではと思う。
実際にリファクタリングしながら読むことをお勧めしたい(特に第1章) -
リファクタリングの例を順を追って丁寧に解説されていて思考の過程が参考になる。その他、いろいろなリファクタリングのパターンが、これでもかというくらいたくさん、かつ、丁寧に解説されていて、ケーススタディとして役に立ちそう。そういう内容なだけに、じっくり腰を落ち着けて読む必要がありそうで、図書館から借りている期限内に読み切れなそうなので、今回はサラッと流し読み。
-
上司がお勧めしていた本。
「より良いプログラミングをするための本」はたくさんあるが、本書はリファクタリング、つまり既にあるコードについて焦点を置いている。
個人的にエンジニアとして勤めて10年近くなるが、意外と1から実装することより、既にあるコードをコピペ的に流用することのほうが多い。その際にこの観点は重要になる。
…ただ、この本はJavaで書かれているが、仕事ではJava使わないんだよなぁ。 -
Javaならではの部分もあるものの、未だに有効な内容。
-
本書はあのMartin Fowlerによるリファクタリングのガイドブックの新装版である。
本書で言うリファクタリングはかならずしも「シンプルになる、もしくは良くなる方向に」行うものだけではなく、その逆も得てして含まれている総括的なハンドブックである。本書は要素技術的なリファクタリングについて解決されており、あるシステムやプログラム全体をどうリファクタリングするかについては、あまり記述がない。
リファクタリングでバグが混入することを避けるため、本書の手順に従いプログラムを変更していくことで安全にリファクタリングができる。
しかし、EclipseなどのIDEが発展した現在ではあまりこのような手作業に頼る必要がないので、その点での本書の価値は高くない。ただし、p.189「観察されるデータの複製」のような、インタラクションパターンを書き換えるようなリファクタリングの説明書としては今なお有用である。
必携の書というほどではないが、超有名書なのでITエンジニアは機会があれば読んでおくとよいと思う。★3つとする。 -
資料ID:81400515
請求記号:007.64||F
配置場所:工枚普通図書
2015年ITエンジニア本大賞ノミネート -
コードの体質改善カタログ。
昔から読んでみたい一冊ではあったが、思ったほど感銘を受けることはなかった。
本書に書かれている作業は感性で実施できてしまうこともあるだろう。しかし、敢えてパターンを定義して作業ステップを明示し定型作業まで落とし込むことで、リファクタリングはミスなく誰でも正しい手順で実施できるものだということが強調されている。
気になったのは、ドキュメント修正に関する言及が一切ないこと。確かにテストと体系化されたリファクタリング手法があれば、コードの振る舞いを変えることなく恐れずに保守性を上げることができるのだろうが、ドキュメントはどうなるのか。
ドキュメントをそれほど重要視しないようなプロジェクトであれば効果覿面な行いであるだろうが、昔からの慣習が根付くドキュメントありきのプロジェクトではコードを修正するよりもドキュメントを修正するコストの方が高くつく。
そんなプロジェクトに未来はないと言われればそれまでだが。