レガシーコード読書会 20120618

レガシーコード改善ガイド読書会第１回

2012/06/18CyberX　エンジニア　石川泰式

まえがき

•最初はプログラマの心の中でけがれのない水晶のように輝いていた設計が，時間が経つことで劣化し，悪くなった肉のように腐敗していく

まえがき

•最初に必要だと言ったもので顧客が満足してくれさえすれば，設計は問題なかったはずだ，と考えて自分を慰める

•要求を変えてくる顧客がいけない

まえがき

•「要求変更が発生しました」要求の変更に耐えられない設計は，そもそも悪い設計です

•優秀なソフトウェア開発者は皆，変更に耐え得る設計を目指している

まえがき

•これはどうにも困難な課題に思える•実際あまりに困難なため，これまでに開発されたほとんどすべてのシステムがゆっくりと衰弱し腐敗していく

•この腐敗したプログラムを「レガシーコード」と特別な名前と名付けた

まえがき

•プログラミングの最初の喜びが強烈だったとしても，レガシーコードに取り組む苦痛のせいで，その炎が消されてしまうことも少なくない．

まえがき

•私たちの多くは，コードがレガシーになることを「防ぐ」方法を探し続けてきた．

•Michael Feathersは，私たちの多くが見落としていた点を見抜いた．

まえがき

•それは，防ぐだけでは不十分だということ

•腐敗を防ごうとするだけでは不十分であり，逆戻りさせる必要がある．

まえがき

•本書で取り上げるテーマは，腐敗を逆戻りさせる方法

まえがき

•絡み合った，不透明で入り組んだシステムを，ゆっくりと，徐々に，１つずつ，１歩ずつ，簡素できちんと構造化された，優れた設計に変えていくための本

•エントロピーを逆転させる．

まえがき

•腐敗を逆戻りさせるのは簡単ではないし，すぐにできることもない．

•Michaelが本書で紹介している手法やパターンやツールは有効だが，それには手間と時間と忍耐力，そして慎重さが必要

まえがき

•本書は魔法の弾丸ではない．•システムに積りに積もった腐敗を一晩で取り去る方法は教えてくれない

まえがき

•本書には今後仕事を続けていく上で役立つ，規律や概念や姿勢が書かれている

•まさにそれによって，徐々に質の落ちていくシステムを，徐々に質の向上するシステムに変えていく事ができる

はじめに

•コンピュータで何かを動かすという純粋な喜びを経験したことがありますか？

はじめに

•プログラマに尋ねてみたところ，ほとんどが経験していた．

はじめに

•その喜びは私たちがこの仕事に就いた理由の１つのはずですが，日常のどこに埋もれてしまったのでしょうか？

はじめに

•頑張ってはいるものの，スケジュールのプレッシャーからか，過去のしがらみからか，自分の仕事の見本となる優れたコードがないためか，多くの人がレガシーコードを書いてしまっている

はじめに

•レガシーコードとは，誰かから引き継いだコード

はじめに

•簡単なはずの機能追加をしようとして徹夜したことや，士気を喪失してまったこと，チーム全員がコードにうんざりしてどうでもよくなってしまった感覚，死んでしまいたくなるようなコードを思い出すでしょう．

はじめに

•そのコードを改善しようと考えることすら嫌な気持ちになるかもしれない

•そんな手間をかけるのは無駄に思えるから

はじめに

•レガシーコードとは，単にテストのないコード

はじめに

•テストのないコードは悪いコードである•どれだけうまく書かれているかは関係ない•どれだけ美しいか，オブジェクト指向か，きちんとカプセル化されているかは関係ない

はじめに

•テストがあれば，検証しながらコードの動きを素早く変更することができる．

•テストがなければ，コードが良くなっているのか悪くなっているのかが本当にはわからない．

はじめに

•きれいなコードは有益だが，それだけでは不十分

•テストなしに大規模な変更をしようとすると，チームは危険な賭けに出ることになる．

はじめに

•チームの腕が上がって，より明確なコードを書き始めたとしても，古いコードがきれになるのには時間がかかる．

•たいていの場合，完全にきれいになることはありえない．

はじめに

•本書で説明する手法は，かなり大きいコードでテストしてある．例が小さいものになっているのは，本のスペースの都合のため．特に次のようにコードの中に省略記号（ ...）が含まれている時は，「汚いコードがここに 500行入る」と読み替えて下さい．

はじめに

•本書は美しいコードを書くための本でも，美しい設計をするための本でもない．

•優れた設計を目指すべきではあるが，レガシーコードにおいては，不連続ないくつものステップへ経なければそこには到達できない．

はじめに

• 本当に必要なのは，ありのままの患者を受け止め，悪いところを直し，より良い健康状態にすること

• コードをより健康に，より作業しやすくすることは可能

• 患者の状態が少し回復したら，その後で，より健康的な生活が送れるよう患者を手助けする

はじめに

•ちょっと落ち着いて楽になれるところまで持って行きたい

•私たちはそれを望み，コードの変更を楽にしようと頑張っている．

•チームがその意識を持ち続けることができれば，設計は良くなる．

はじめに

•本来プログラミングは非常にやりがいのある，楽しい仕事のはず

•日々の仕事の中でそのように感じられずにいる人が，本書の手法によってその気持を発見し，チームに広げてくれることを望んいでいます．

第１部変更のメカニズム

第１章ソフトウェアの変更

ソフトウェアの変更

•コードの変更は素晴らしいこと•私たちの日々の生活を困難なものにしてしまうコードの変更方法はいくらでもある．

•逆に楽にできる方法もいくらでもある．

ソフトウェアの変更

•本書では，その議論を少し広げて，非常に厄介な状況のコードに取り組む方法について考えてみる．

•そのために，まず変更のメカニズムについて掘り下げてみる．

1.1 ソフトウェア変更の４つの理由

•話を簡単にするために，ソフトウェア変更の理由を大きく４つに分けて検討する．

•要件の追加•バグの修正•設計の改善•リソース利用の最適化

1.1.1 要件の追加とバグの修正

•要件の追加は，変更の理由の中で一番わかりやすいものと言える

•ソフトウェアが実現する，ある動作に対して，別の動作も行ってほしいとユーザーが言う場合である．


•マネージャが左側にある会社のロゴを右側に移してほしいといったとする．


•しかし話を聞いてみると，実現するのがそれほど簡単ではないと気づく．

•マネージャはロゴの移動だけでなく，次のリリースではユーザの操作に応じてロゴの表示を動的に変化することを望んでいた．


•これはバグ修正？それとも要件追加？


•顧客の立場からすると，マネージャは紛れもなく問題の修正を依頼している．

•開発者の立場からすると，この変更は完全に新しい要件とも取れる．


•見方によっては，要件追加かバグ修正かは終わりのない議論かもしれない．

•結局はコードやその他の成果物を変更することに変わりはない．

•残念ながら，バグ修正か要件追加かの議論によって，技術的にもっと重要なことが隠されてしまっている．


•それは振る舞いが変更されるかどうかである•新しい振る舞いの追加と，既存の振る舞いの変更には大きな違いがある．


•ソフトウェアで最も大切なのは「振る舞い」であり，振る舞いこそがユーザの求めるものである．期待される振る舞いを私たちが追加すればユーザは喜ぶが，ユーザの求める振る舞いを変更，あるいは削除してしまえば，バグの作り込みとなり，私たちの信頼は失われてしまう．


•会社のロゴの例は振る舞いの追加？•答えはイエス•なぜならその変更によって，システムはページの右側にロゴを表示するようになるから


•振る舞いの削除？•答えはイエス•なぜなら左側のロゴがなくなるから


public class CDPlayer { public void addTrackListing(Track track) { ... } ...}


•このクラスには，曲目リスト（ TrackListing）を追加するメソッドが定義されている．

•ここに曲目リストを置き換えるメソッドを追加する．


public class CDPlayer { public void addTrackListing(Track track) { ... }

public void replaceTrackListing(Track track) { ... } ...}


•このメソッドの追加は，新しい振る舞いの追加だけか？それとも変更か？

•答えはどちらもノー•メソッドを追加するだけで，どこからも呼び出されなければ振る舞いは変化しないから


•ある程度の変化なしに振る舞いを追加することはほとんど不可能と言える．

1.1.2 設計の改善

•設計の改善は，別の種類のソフトウェア変更•保守しやすくなるようにソフトウェアの構造を変更する時，通常は振る舞いを同じに保つ必要がある．

•もし，その過程で必要な振る舞いが失われてしまえば，それはバグと呼ばれることになる


•多くのプログラマがあまり設計を改善したがらないのは，その過程で振る舞いを失ってしまったり，間違った振る舞いを作りあげてしまいやすいから

•振る舞いを変えずに設計を改善することをリファクタリングと呼ぶ．


•リファクタリングの基本として，変更前と変更後で振る舞いが変わらないことを確認するためのテストを書き，検証しながら少しずつ作業を進めることで，ソフトウェアの保守性を向上できるという考え方がある．


•リファクタリングは，ただソースコードの書式を修正するようなリスクの低い作業ではない

•リスクを顧みずに大規模にソースコードを書き直す作業でもない


•リファクタリングでは小さな構造修正を繰り返し行う

•その際，容易に変更を行えるようにテストでサポートする．

•変更という面から見て重要なのは，リファクタリング時には機能を変更すべきではないということ

1.1.3 リソース利用の最適化

•リソース利用の最適化はリファクタリングと似ているが，目的が異なっている．

•最適化における変更するものは，プログラムが使用しているなんらかのリソース（通常は時間やメモリ）に相当する．

1.1.4 ４つの変更のまとめ

要件追加バグ修正リファクタリング最適化

構造変化する変化する変化するー

新機能変化するーーー

機能ー変化するーー

リソース利用ーーー変化する


•要件追加，リファクタリング，最適化のいずれでも，既存の機能は変わらずに保たれる

•実際には，バグの修正の場合でも，詳しく調べてみると，機能を変更するものの，変更されない既存機能に比べると，変更量はごくわずかな場合がほとんど


•要件追加やバグ修正は，リファクタリングや最適化とよく似ている．

•４つのいずれの場合でも，一部機能や一部振る舞いを変更するが，元のままに保たれている部分のほうがずっと多い


既存の振る舞い新しい振る舞い


•変更を行った時に何が起きるかを，整理する良い面は，何に集中するべきかがわかりやすくなること

•悪い面は，集中すべきは変更箇所だけではない．厄介なことにコードに触れていないからと言って，振る舞いが変わらない保証はない


•変更時には，対象箇所以外の振る舞いが変っていないことを確認する必要があるが，それはとても困難な作業

•しばしば問題となるのは，ある変更によってどれだけの振る舞いに影響が及ぶかを把握できないこと


•変更を安全に行うために最も重要なことは，影響範囲を理解すること


•既存の振る舞いを変えずに保つことは，ソフトウェア開発における最も困難なことの１つである．主要な機能を変更をしようとする時でさえ，通常は既存の振る舞いの大部分を変更せずに保たれなければならない．

1.2 危険な変更

•振る舞いを保つのは非常に困難なこと•変更を行いながら振る舞いを維持する作業は大きなリスクを伴う

1.2 危険な変更

• リスクを緩和するには，次の３つの点を考慮する必要がある．

• どんな変更を行わなければならないか• 変更が正しく行われたことをどうすれば確認できるか

• 何も壊していないことをどうすれば確認できるか

1.2 危険な変更

•変更を避けることでソフトウェアの問題を最小限に抑えられるという考え方は魅力的だが，残念なことに必ず問題は付きまとう

1.2 危険な変更

•良いシステムでは調べることで安心でき，これから行う変更に確信を持てる

•悪いコードでは，物事を調べた後で変更に取り掛かる時には，虎から逃げるために崖から飛び降りるような気持ちになる

1.2 危険な変更

•大きなクラスを分割する作業は，週に２，３回ぐらい行ってない限り，極めて困難な仕事になりがち

•頻繁に変更を行っていれば，日常業務になる•何が分割できて，何ができないかの見当を付けやすくなり，変更作業もずっと容易になる

1.2 危険な変更

•変更の回避は恐怖をもたらす．•不幸なことに，多くのチームが変更に対して信じがたいほどの恐怖を抱いていて，その恐怖は日に日に強くなっていく．

1.2 危険な変更

•他の方法として，やみくもに頑張るというのがある．人を増やして，机に向かって分析する時間を確保し，すべてのコードを調べ尽して「正しい」やり方で変更を行うこともできる．

•時間をかけてじっくり精査すれば，変更は安全に行えるはず．

1.2 危険な変更

•しかし，これは本当だろうか•すべての作業を終えた後で，精査が正しかったかどうかを判断できる人などいるのか？

レガシーコード読書会 20120618

Technology