SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

翻訳書「レガシーコード改善ガイド」の注目トピック

「レガシーコード改善ガイド」のススメ
第5回:レガシーコードを攻略するための原則とプラクティス

邦訳版『Working Effectively With Legacy Code』の重要トピックを紹介

  • X ポスト
  • このエントリーをはてなブックマークに追加

 このシリーズでは7月に刊行される翻訳書「レガシーコード改善ガイド(Working Effectively With Legacy Code)」に書かれている内容から、重要なトピックを取り上げて紹介していきます。連載最終回の今回は、『レガシーコード改善ガイド』で取り上げている原則とプラクティスの一部を紹介しましょう。

  • X ポスト
  • このエントリーをはてなブックマークに追加

保守開発のための原則とパターン、プラクティス

 前回までは、『レガシーコード改善ガイド』で紹介している技法の中から、レガシーコードをテストで保護するための手法を紹介しました。しかし、この本で取り上げているのは、コードのリファクタリング技法だけではありません。魅力の一つは、取り上げるテーマの幅広さであり、開発者が保守開発で必要となるさまざまなテクニックやノウハウを紹介していることです。

 こうしたテクニックやノウハウは、原則、パターン、プラクティスの3つに分けることができます。前回の記事で紹介した「テストで保護するための24のリファクタリング技法」はパターンに相当します。連載最終回の今回は、『レガシーコード改善ガイド』で取り上げている原則とプラクティスの一部を紹介しましょう。

レガシーコードを改善するための原則

 レガシーコードの問題の一つは、度重なる変更でコードが大きくなりすぎていることでした。結果として、1つのクラスがたくさんのメソッドと多すぎる責務を持つことになってしまいます。

 保守や再利用のしやすさの観点からすると、1つのクラスに数多くの責務があることは望ましいことではありません。こうした状況にしないための原則が「単一責務の原則」です。

単一責務の原則(Single-Responsibility Principle:SRP)

 クラスが持つ責務は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回でもお話しましたが、逆に設計スキルを磨くチャンスとも言えます。『レガシーコード改善ガイド』で紹介されているテクニックやノウハウはその助けになることでしょう。

会員登録無料すると、続きをお読みいただけます

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

次のページ
既存のコードの責務を把握する3つのプラクティス

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
翻訳書「レガシーコード改善ガイド」の注目トピック連載記事一覧

もっと読む

この記事の著者

田村 友彦(タムラ トモヒコ)

ウルシステムズ株式会社 シニアコンサルタントICカードの通信プロトコルからWebアプリケーションまで、さまざまなソフトウェア開発をさまざまな言語・環境で経験してきた。2006年より現職。現在は、技術的な支援を行う立場でシステム開発に携わっている。支援だけでなく、ときにはどっぷりとコーディングをすることもある...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/4220 2009/07/31 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング