保守開発のための原則とパターン、プラクティス
前回までは、『レガシーコード改善ガイド』で紹介している技法の中から、レガシーコードをテストで保護するための手法を紹介しました。しかし、この本で取り上げているのは、コードのリファクタリング技法だけではありません。魅力の一つは、取り上げるテーマの幅広さであり、開発者が保守開発で必要となるさまざまなテクニックやノウハウを紹介していることです。
こうしたテクニックやノウハウは、原則、パターン、プラクティスの3つに分けることができます。前回の記事で紹介した「テストで保護するための24のリファクタリング技法」はパターンに相当します。連載最終回の今回は、『レガシーコード改善ガイド』で取り上げている原則とプラクティスの一部を紹介しましょう。
レガシーコードを改善するための原則
レガシーコードの問題の一つは、度重なる変更でコードが大きくなりすぎていることでした。結果として、1つのクラスがたくさんのメソッドと多すぎる責務を持つことになってしまいます。
保守や再利用のしやすさの観点からすると、1つのクラスに数多くの責務があることは望ましいことではありません。こうした状況にしないための原則が「単一責務の原則」です。
クラスが持つ責務は1つだけにするべきである。責務が1つであれば、そのクラスを変更する必要があるのは、その責務に関する変更をする場合だけである。
このSRPの他にも、『レガシーコード改善ガイド』では、設計を改善するために目指すべき原則として、次のようなものを紹介しています。
- Liskovの置換原則（The Liskov Substitution Principle：LSP）【第8章】
- コマンドとクエリーの分離（Command/Query Separation）【第10章】
- インターフェース分離の原則（Interface Segregation Principle：ISP）【第20章】
- 解放／閉鎖原則（Open/Closed Principle：OCP）【第21章】
これを見て「おやっ」と思った方がおられるかもしれません。そう、これらはどれもオブジェクト指向設計の一般的な原則としてよく知られているものです。実際のところ、レガシーコードの保守開発でも新規のシステム開発でも、設計目標として目指すべきことは何も変わらないのです。著者のマイケル・フェザーズ氏は、設計スキルとして、責務を把握することと責務を適切に分割するやり方を学ぶことが重要であると書いています。そして、このような設計スキルを身につけるには、新規開発よりもレガシーコードの保守開発の方がはるかに多くのことを学べる、と述べています。
その理由は、実際に動作するコードがあるからです。確かに、設計はこうあるべき、という考え方を理解することも基礎知識としては大事ですが、保守開発での実際の変更作業やオープンソースのコードを読むことの方が、「腹に落ちた」と感じることが多いのではないでしょうか。
保守開発に経験の少ないプログラマが投入されがちなことは連載第1回でもお話しましたが、逆に設計スキルを磨くチャンスとも言えます。『レガシーコード改善ガイド』で紹介されているテクニックやノウハウはその助けになることでしょう。
