リファクタリングの勧め [プログラマー現役続行]
最近、コードレビューをしていて感じていることを、15年前に記事として書いていました。その記事は、「リファクタリングの勧め」（「Java PRESS Vol.12」、2000年5月、技術評論社）です。以下は、15年前に書いた内容をそのまま再現しています。
みなさんは、「リファクタリング（Refactoring）」という言葉を聞かれたことがありますか？私自身は、リファクタリングを意識するようになったのは、 Martin Fowlerの『Refactoring』注1を1999年の夏に読んでからです。それまでは、言葉としては他の書籍にも現れていたのでしょうが、貝体的に何を言っているのか深く考えることなく読んでいたのだと思います。今回は、私自身のフログラミングの経験を振り返り、Martin Fowlerの本の内容を簡単に紹介したいと思います。
1999年に、延べ250人以上のソフトウェアエンジニアに対してコードレビューに関するガイダンスを実施し、その中で次のような質問をしてきました。
私自身を振り返ってみますと、最初から読みやすく、変更が容易なソースコードを書けたのではありません。特に、製品向けに開発したコードは、「動作するJことが優先であり、読みやすさや保守性は、プロジェクトとして注意を払うことがない場合がほとんとでした。一般に多くのソフトウェアエンジニアは、仕事でのプログラミング経験しかない場合が多いと思います。その結果、「自分が理解できて、動作すればよい」として、動作しているプログラムを書き直した経験が少ない人が、ほとんどではないでしょうか。
読みやすいコードを書くことの重要性については多くの本に取り上げられています。代表的な本としては、Steve McConnellの『Code Complete』注2があります。最近の本では、Brian KernighanとRob Pikeの『The Practice of Programming』注3があり、最初の一章をプログラミングスタイルに費やして，読みやすさの必要性を説いています．
新しいプログラミング手法を学んだらそれを適用して書き直したり、機能を追加する際にデザイン変更を行ったほうが追加が容易と判断した場合には，動作しているコードを捨ててでもデザインを変更したりしてきました。仕事で開発したソフトウェアでも、ある程度はこのような修正は行った終験はありますが、ツールでの経験が圧倒的に多かったと思います。
自分て作成したツールでも全体で数万行にもなると、とても隅々まで記憶しておくことはできません。ときどきエンハンスやパグ修正を行い、さらに何年も保守をしなければならないので、自分自身でも読めない、理解できない、エンハンスが困難なコードであっては困るのです。したがって、エンハンスやパグ修正を行う都度、自分自身の理解を助けるために、プログラムのデザインを変更して改良を行いました。このような書き直しにより、プログラムが読みやすくなり、パグの修正や機能の追加が容易になっていったのです。また、私自身は、このようなツールの作成と書き直し作業で実に多くの事柄を学んできました。たとえば， C言語でsetjmp/longjmpライブラリはツールでしか使用したことはありません。おそらく．動作しているプログラムを何度も何度も書き直す経験をしているソフトウエアエンジニアは少ないと思われます。
「悪いデザイン、間違った決定、ひどいコードをそのままにしておくと、さらにそのプログラムは悪くなっていく」とAndrew HuntとDavid Thomasは、その著書『Pragmatic Programmer』注5の中で述べています。建物や路上の車の窓ガラスが割られて、それを修理することなく放置しておくと、さらに窓ガラスが割られて、状況が悪くなると述べています。
同様に、どんなにきちんと設計/コーディングされたソフトウェアでも、一旦誰かが悪いデザ’インやひどいコードを入れはじめたら、そのソフトウェアはどんどん悪くなっていくので、そのような悪いデザインやコードを見つけたら、無視することなく修正するのがプログラマの心得だと説いています。つまり、「Don’t Live with Broken WindowsJ （窓ガラスが割れたままに放置しておくな）と言っているのです。
みなさんは、時間がないという理由で、妥協しながら、読みにくい、悪いデザインのコードを書いた経験はありませんか注6。ソフトウェアの機能を拡張する際に、割れた窓ガラスで増築するのではなく、すでに割れた窓ガラスを新しい窓ガラスと取り替える方法を知って、その上で増築する必要があります。そのためには、取り替える方法を知っていなければなりません。そのような方法を書籍としてまとめたのが、Martin Fowlerの『Refactoring』です。
注1) Martin Fowler, 『Refactoring. lmproving the Design of Existing Code』, Addison-Wesley,1999, ISBN 0-201-48567-2
注2) Steve McConnell、『Code Complete: A Practical Handbook of of Software Construction』、Microsoft Press、1993、ISBN1-55615-4844。翻訳本『コードコンブリー卜』、ISBN 4-7561-0210-7、マイクロソフトプレス
注3) Brian W. Kernighan、Rob Pike、『The Practice of Programming』、Addison-Wesley、 1999、ISBN 0-201-61586-X
注4) 『Java Report』、Volume 5、Number l （2000年1月号）、SIGS Publications
注5）Andrew Hunt、David Thomas、『The Pragmatic Programmer: from iourneyman to master』、Addison-Wesley、1999、ISBN 0-201-61622-X
注6) 実際には、何が良いデザインかを知っていなければ、悪いデザインのコードを書いていると認識することはできませんが。
Refactoring: Improving the Design of Existing Code (Addison-Wesley Object Technology Series)
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2012/03/09
- メディア: Kindle版
みなさんは、「リファクタリング（Refactoring）」という言葉を聞かれたことがありますか？私自身は、リファクタリングを意識するようになったのは、 Martin Fowlerの『Refactoring』注1を1999年の夏に読んでからです。それまでは、言葉としては他の書籍にも現れていたのでしょうが、貝体的に何を言っているのか深く考えることなく読んでいたのだと思います。今回は、私自身のフログラミングの経験を振り返り、Martin Fowlerの本の内容を簡単に紹介したいと思います。
プログラミング経験
私が初めてプログラミングを覚えたのは、1978年4月に九州工業大学情報工学科に入学して、プログラミングのコースで習ったFORTRANでした。単科大学であったため、一年生からプログラミングを含む専門科目がありました。大学および大学院での6年間を通して、FORTRAN、Pascal、PL/I、APL、Z80アセンブリ言語、Forth等を使ってプログラミングを行い、社会人になってから今日までに、C、Mesa、 C++、Javaでフログラミングを行ってきました。社会人になってから仕事としてソフトウェア開発に従事してきたのですが、一方で、自分に必要なツールも開発してきました。プログラムの読みやすさ
開発が遅れていたあるプロジェクトのソフトウェアのソースコードの一部を見る機会があったのですが、プログラミングの経験が10年以上ある人が書いたとは信じられないような、プログラムの読みやすさや保守性はあまり考慮していないソースコードでした。同じような例、つまり、プログラミングの経験年数がある人が書いているにもかかわらず、デザインの悪い、読みにくいソースコードを見かけることは多いです。1999年に、延べ250人以上のソフトウェアエンジニアに対してコードレビューに関するガイダンスを実施し、その中で次のような質問をしてきました。
- 今まで、「自分が書いているコードを他の人が読んで理解できるか」を意識してプログラミングをしてきましたか？
- 今まで、他人が書いたコードのパグ修正や保守作業で、プロクラムが読みにくいために苦労したことはありますか？
私自身を振り返ってみますと、最初から読みやすく、変更が容易なソースコードを書けたのではありません。特に、製品向けに開発したコードは、「動作するJことが優先であり、読みやすさや保守性は、プロジェクトとして注意を払うことがない場合がほとんとでした。一般に多くのソフトウェアエンジニアは、仕事でのプログラミング経験しかない場合が多いと思います。その結果、「自分が理解できて、動作すればよい」として、動作しているプログラムを書き直した経験が少ない人が、ほとんどではないでしょうか。
読みやすいコードを書くことの重要性については多くの本に取り上げられています。代表的な本としては、Steve McConnellの『Code Complete』注2があります。最近の本では、Brian KernighanとRob Pikeの『The Practice of Programming』注3があり、最初の一章をプログラミングスタイルに費やして，読みやすさの必要性を説いています．
プログラムを書き直す
「他のソフトウエアエンジニアと私自身とで、何が異なっていたのか」と考えたことがあります。そのとき気づいたのは、社会人になってから、自分自身の開発環境を改蓄するために多くのツールを自分自身で開発し社内に配布してきたことです。さらに、単なるツールの開発だけであれば、それほど珍しくはないかもしれませんが、同じツールを何度も書き直してきた経験が異なっていたと思っています。新しいプログラミング手法を学んだらそれを適用して書き直したり、機能を追加する際にデザイン変更を行ったほうが追加が容易と判断した場合には，動作しているコードを捨ててでもデザインを変更したりしてきました。仕事で開発したソフトウェアでも、ある程度はこのような修正は行った終験はありますが、ツールでの経験が圧倒的に多かったと思います。
自分て作成したツールでも全体で数万行にもなると、とても隅々まで記憶しておくことはできません。ときどきエンハンスやパグ修正を行い、さらに何年も保守をしなければならないので、自分自身でも読めない、理解できない、エンハンスが困難なコードであっては困るのです。したがって、エンハンスやパグ修正を行う都度、自分自身の理解を助けるために、プログラムのデザインを変更して改良を行いました。このような書き直しにより、プログラムが読みやすくなり、パグの修正や機能の追加が容易になっていったのです。また、私自身は、このようなツールの作成と書き直し作業で実に多くの事柄を学んできました。たとえば， C言語でsetjmp/longjmpライブラリはツールでしか使用したことはありません。おそらく．動作しているプログラムを何度も何度も書き直す経験をしているソフトウエアエンジニアは少ないと思われます。
Don’t Live with Broken Windows
そのような経験が少ないためか、多くのソフトウェアエンジニアは、プログラムのデザインをどのように変更すれば良くなるかについての知識そのものを持っていなかったりします。英文月刊誌『Java Report』のEditor's NoteでDwight Deugoは、「Refactoring and Optimization」注4と題してその中で次の通り述べています。リファクタリングと最適化は、しばしば忘れられてしまいますが、重要な活動です。忘れられるには理由があります。開発者から私が聞く理由は、「時間がない」です。しかし、私はその理由を信じてはいません。本当の理由は、「知識がない」からです。もし、どこが悪く、どうすれば良くなるか、どうすればもっと保守が容易になるか、どうすればもっと早く動作するかをあなたか知っていれば、そのように修正するでしょう。そうではありませんか？つまり、知識がないためにプログラムを良くすることができないと言っているのです。
「悪いデザイン、間違った決定、ひどいコードをそのままにしておくと、さらにそのプログラムは悪くなっていく」とAndrew HuntとDavid Thomasは、その著書『Pragmatic Programmer』注5の中で述べています。建物や路上の車の窓ガラスが割られて、それを修理することなく放置しておくと、さらに窓ガラスが割られて、状況が悪くなると述べています。
同様に、どんなにきちんと設計/コーディングされたソフトウェアでも、一旦誰かが悪いデザ’インやひどいコードを入れはじめたら、そのソフトウェアはどんどん悪くなっていくので、そのような悪いデザインやコードを見つけたら、無視することなく修正するのがプログラマの心得だと説いています。つまり、「Don’t Live with Broken WindowsJ （窓ガラスが割れたままに放置しておくな）と言っているのです。
◇ ◇ ◇
みなさんは、時間がないという理由で、妥協しながら、読みにくい、悪いデザインのコードを書いた経験はありませんか注6。ソフトウェアの機能を拡張する際に、割れた窓ガラスで増築するのではなく、すでに割れた窓ガラスを新しい窓ガラスと取り替える方法を知って、その上で増築する必要があります。そのためには、取り替える方法を知っていなければなりません。そのような方法を書籍としてまとめたのが、Martin Fowlerの『Refactoring』です。
（・・・書籍『Refactoring』の紹介部分は省略・・・）
注1) Martin Fowler, 『Refactoring. lmproving the Design of Existing Code』, Addison-Wesley,1999, ISBN 0-201-48567-2
注2) Steve McConnell、『Code Complete: A Practical Handbook of of Software Construction』、Microsoft Press、1993、ISBN1-55615-4844。翻訳本『コードコンブリー卜』、ISBN 4-7561-0210-7、マイクロソフトプレス
注3) Brian W. Kernighan、Rob Pike、『The Practice of Programming』、Addison-Wesley、 1999、ISBN 0-201-61586-X
注4) 『Java Report』、Volume 5、Number l （2000年1月号）、SIGS Publications
注5）Andrew Hunt、David Thomas、『The Pragmatic Programmer: from iourneyman to master』、Addison-Wesley、1999、ISBN 0-201-61622-X
注6) 実際には、何が良いデザインかを知っていなければ、悪いデザインのコードを書いていると認識することはできませんが。
著書（PDF）
翻訳本（Kindle版）
翻訳本（PDF）
