読者です 読者をやめる 読者になる 読者になる

ひだまりソケットは壊れない

ソフトウェア開発に関する話を書きます。 最近は主に Android アプリ、Windows アプリ (UWP アプリ)、Java 関係です。

まじめなことを書くつもりでやっています。 適当なことは 「一角獣は夜に啼く」 に書いています。

読んだ: レガシーコード改善ガイド

レビュー 書評 書籍

Web 上でそこそこ評価が高いようですね。 何か得られるものがあるかなーと思って読みました。

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

結論としては本書に書かれている内容から私が得られるものはほとんどなかったのですが、内容的にはソフトウェア開発者が当たり前に知っておくべき内容が書かれていると感じました。 これまでテストを書いたことがほとんどないとか、テストしやすい設計について考えたことがないというようなソフトウェア開発者は本書から得られるものがいろいろあると思いますので、読んでみると良いのではないでしょうか。 普段からテストを書いたりしてるけど、テストがないコードを変更するという経験をしたことが少ない人にも参考になるかと思います。

内容紹介

本書では、「レガシーコードとは、単にテストのないコードです」 と述べられています。

第 1 部は、既存のソフトウェアを変更する際の理由を 4 つ (要件追加、バグ修正、リファクタリング、最適化) に分類したり、レガシーコードを変更する際にテストで保護することがいかに有効であるか、単体テストを行いやすくするために何を考慮すべきか、といったこと、そして、リファクタリング単体テストに有効なツール (IDE とかテストハーネスとか) の紹介がされます。

第 2 部が本書の主たる部分で、レガシーコードを変更する際の 「具体的な問題設定」 と、それに対する 「具体的な解決策」 がそれぞれの章に書かれています。 安全に変更するためにはテストで保護する必要がある、という主張のもと、いかにして依存関係を排除してユニットテストを書くか、ということが述べられていたり、テストでの保護が難しい場合に、変更箇所以外に影響が及ばないように変更するにはどうすればよいか、というようなことが書かれています。

例えば、6 章 「時間がないのに変更しなければなりません」 では、既存のシステムに追加された要件を満たすように短時間でシステムを変更する必要があるが、(既存のメソッドに変更を加えた場合に) 追加された要件以外の部分に影響がないことを確認することが困難である、という状況に対する解決案が述べられています。 他の章も、章の表題自体がソフトウェア開発者が直面しがちな問題を表していて、どの章でどういう問題について述べられているかすぐにわかるでしょう。

対象となっている言語は、主に C、C++JavaC# です。

第 3 部は 25 章 「依存関係を排除する手法」 のみからなり、第 2 部の説明の中で使われた依存関係を排除するためのリファクタリング手法がカタログ形式で掲載されています。

感想

全体として、

  • テストしづらいコードをどういう風に変更すればテストしやすくなるのか、
  • 依存関係を排除するためにどうすればいいのか、
  • 理解しづらいコードを理解するためにどういう手段を取ると良いか、

ということが、著者の経験を基に述べられています。 内容的にはさほど高度なものはなく、ちゃんとテストを書きながら保守開発を行うということをしていれば得られる知見が文書としてまとめられている、という感じです。 そういう意味では、経験のあるソフトウェアエンジニアが読んだところで得られるものはほとんどないでしょう。

一方で、そのような知見が 1 冊の本としてまとめられているというのは価値あることで、保守開発の経験が少ない人は読むといろいろ得られるものがあるでしょう。 実際の開発時に本書で述べられている手法を使うかどうかはともかくとして、本書で述べられているような手法があることはソフトウェア開発者であれば知っておくべきだと思いますし、本書に書かれている内容を知識として持っていないソフトウェアエンジニアには、是非本書を読んでほしいと思います。

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)