More Related Content
Similar to レガシーコード読書会 20120618
Similar to レガシーコード読書会 20120618 (20)
レガシーコード読書会 20120618
- 22. はじめに
• テストのないコードは悪いコードである
• どれだけうまく書かれているかは関係ない
• どれだけ美しいか，オブジェクト指向か，き
ちんとカプセル化されているかは関係ない
- 23. はじめに
• テストがあれば，検証しながらコードの動き
を素早く変更することができる．
• テストがなければ，コードが良くなっている
のか悪くなっているのかが本当にはわからな
い．
- 24. はじめに
• きれいなコードは有益だが，それだけでは不
十分
• テストなしに大規模な変更をしようとすると
，チームは危険な賭けに出ることになる．
- 25. はじめに
• チームの腕が上がって，より明確なコードを
書き始めたとしても，古いコードがきれにな
るのには時間がかかる．
• たいていの場合，完全にきれいになることは
ありえない．
- 26. はじめに
• 本書で説明する手法は，かなり大きいコード
でテストしてある．例が小さいものになって
いるのは，本のスペースの都合のため．特に
次のようにコードの中に省略記号（ ... ）が含
まれている時は，「汚いコードがここに 500
行入る」と読み替えて下さい．
- 27. はじめに
• 本書は美しいコードを書くための本でも，美
しい設計をするための本でもない．
• 優れた設計を目指すべきではあるが，レガシ
ーコードにおいては，不連続ないくつものス
テップへ経なければそこには到達できない．
- 28. はじめに
• 本当に必要なのは，ありのままの患者を受け止
め，悪いところを直し，より良い健康状態にす
ること
• コードをより健康に，より作業しやすくするこ
とは可能
• 患者の状態が少し回復したら，その後で，より
健康的な生活が送れるよう患者を手助けする
- 29. はじめに
• ちょっと落ち着いて楽になれるところまで持
って行きたい
• 私たちはそれを望み，コードの変更を楽にし
ようと頑張っている．
• チームがその意識を持ち続けることができれ
ば，設計は良くなる．
- 30. はじめに
• 本来プログラミングは非常にやりがいのある
，楽しい仕事のはず
• 日々の仕事の中でそのように感じられずにい
る人が，本書の手法によってその気持を発見
し，チームに広げてくれることを望んいでい
ます．
- 31. はじめに
• 本来プログラミングは非常にやりがいのある
，楽しい仕事のはず
• 日々の仕事の中でそのように感じられずにい
る人が，本書の手法によってその気持を発見
し，チームに広げてくれることを望んいでい
ます．
- 34. ソフトウェアの変更
• コードの変更は素晴らしいこと
• 私たちの日々の生活を困難なものにしてしま
うコードの変更方法はいくらでもある．
• 逆に楽にできる方法もいくらでもある．
- 35. ソフトウェアの変更
• 本書では，その議論を少し広げて，非常に厄
介な状況のコードに取り組む方法について考
えてみる．
• そのために，まず変更のメカニズムについて
掘り下げてみる．
- 36. 1.1 ソフトウェア変更の４つの理由
• 話を簡単にするために，ソフトウェア変更の
理由を大きく４つに分けて検討する．
• 要件の追加
• バグの修正
• 設計の改善
• リソース利用の最適化
- 37. 1.1.1 要件の追加とバグの修正
• 要件の追加は，変更の理由の中で一番わかり
やすいものと言える
• ソフトウェアが実現する，ある動作に対して
，別の動作も行ってほしいとユーザーが言う
場合である．
- 39. 1.1.1 要件の追加とバグの修正
• しかし話を聞いてみると，実現するのがそれ
ほど簡単ではないと気づく．
• マネージャはロゴの移動だけでなく，次のリ
リースではユーザの操作に応じてロゴの表示
を動的に変化することを望んでいた．
- 41. 1.1.1 要件の追加とバグの修正
• 顧客の立場からすると，マネージャは紛れも
なく問題の修正を依頼している．
• 開発者の立場からすると，この変更は完全に
新しい要件とも取れる．
- 42. 1.1.1 要件の追加とバグの修正
• 見方によっては，要件追加かバグ修正かは終
わりのない議論かもしれない．
• 結局はコードやその他の成果物を変更するこ
とに変わりはない．
• 残念ながら，バグ修正か要件追加かの議論に
よって，技術的にもっと重要なことが隠され
てしまっている．
- 44. 1.1.1 要件の追加とバグの修正
• ソフトウェアで最も大切なのは「振る舞い」
であり，振る舞いこそがユーザの求めるもの
である．期待される振る舞いを私たちが追加
すればユーザは喜ぶが，ユーザの求める振る
舞いを変更，あるいは削除してしまえば，バ
グの作り込みとなり，私たちの信頼は失われ
てしまう．
- 48. 1.1.1 要件の追加とバグの修正
• このクラスには，曲目リスト（ TrackListing ）
を追加するメソッドが定義されている．
• ここに曲目リストを置き換えるメソッドを追
加する．
- 49. 1.1.1 要件の追加とバグの修正
public class CDPlayer {
public void addTrackListing(Track track) {
...
}
public void replaceTrackListing(Track track) {
...
}
...
}
- 50. 1.1.1 要件の追加とバグの修正
• このメソッドの追加は，新しい振る舞いの追
加だけか？それとも変更か？
• 答えはどちらもノー
• メソッドを追加するだけで，どこからも呼
び出されなければ振る舞いは変化しないか
ら
- 52. 1.1.2 設計の改善
• 設計の改善は，別の種類のソフトウェア変更
• 保守しやすくなるようにソフトウェアの構造
を変更する時，通常は振る舞いを同じに保つ
必要がある．
• もし，その過程で必要な振る舞いが失われて
しまえば，それはバグと呼ばれることになる
- 53. 1.1.2 設計の改善
• 多くのプログラマがあまり設計を改善したが
らないのは，その過程で振る舞いを失ってし
まったり，間違った振る舞いを作りあげてし
まいやすいから
• 振る舞いを変えずに設計を改善することをリ
ファクタリングと呼ぶ．
- 54. 1.1.2 設計の改善
• リファクタリングの基本として，変更前と変
更後で振る舞いが変わらないことを確認する
ためのテストを書き，検証しながら少しずつ
作業を進めることで，ソフトウェアの保守性
を向上できるという考え方がある．
- 55. 1.1.2 設計の改善
• リファクタリングは，ただソースコードの書
式を修正するようなリスクの低い作業ではな
い
• リスクを顧みずに大規模にソースコードを書
き直す作業でもない
- 56. 1.1.2 設計の改善
• リファクタリングでは小さな構造修正を繰り
返し行う
• その際，容易に変更を行えるようにテストで
サポートする．
• 変更という面から見て重要なのは，リファク
タリング時には機能を変更すべきではないと
いうこと
- 57. 1.1.3 リソース利用の最適化
• リソース利用の最適化はリファクタリングと
似ているが，目的が異なっている．
• 最適化における変更するものは，プログラム
が使用しているなんらかのリソース（通常は
時間やメモリ）に相当する．
- 58. 1.1.4 ４つの変更のまとめ
要件追加 バグ修正 リファクタリング 最適化
構造 変化する 変化する 変化する ー
新機能 変化する ー ー ー
機能 ー 変化する ー ー
リソース利用 ー ー ー 変化する
- 59. 1.1.4 ４つの変更のまとめ
• 要件追加，リファクタリング，最適化のいず
れでも，既存の機能は変わらずに保たれる
• 実際には，バグの修正の場合でも，詳しく調
べてみると，機能を変更するものの，変更さ
れない既存機能に比べると，変更量はごくわ
ずかな場合がほとんど
- 60. 1.1.4 ４つの変更のまとめ
• 要件追加やバグ修正は，リファクタリングや
最適化とよく似ている．
• ４つのいずれの場合でも，一部機能や一部振
る舞いを変更するが，元のままに保たれてい
る部分のほうがずっと多い
- 62. 1.1.4 ４つの変更のまとめ
• 変更を行った時に何が起きるかを，整理する
良い面は，何に集中するべきかがわかりやす
くなること
• 悪い面は，集中すべきは変更箇所だけではな
い．厄介なことにコードに触れていないから
と言って，振る舞いが変わらない保証はない
- 63. 1.1.4 ４つの変更のまとめ
• 変更時には，対象箇所以外の振る舞いが変っ
ていないことを確認する必要があるが，それ
はとても困難な作業
• しばしば問題となるのは，ある変更によって
どれだけの振る舞いに影響が及ぶかを把握で
きないこと
- 65. 1.1.4 ４つの変更のまとめ
• 既存の振る舞いを変えずに保つことは，ソフ
トウェア開発における最も困難なことの１つ
である．主要な機能を変更をしようとする時
でさえ，通常は既存の振る舞いの大部分を変
更せずに保たれなければならない．
- 66. 1.2 危険な変更
• 振る舞いを保つのは非常に困難なこと
• 変更を行いながら振る舞いを維持する作業は
大きなリスクを伴う
- 67. 1.2 危険な変更
• リスクを緩和するには，次の３つの点を考慮す
る必要がある．
• どんな変更を行わなければならないか
• 変更が正しく行われたことをどうすれば確認
できるか
• 何も壊していないことをどうすれば確認でき
るか
- 68. 1.2 危険な変更
• 変更を避けることでソフトウェアの問題を最
小限に抑えられるという考え方は魅力的だが
，残念なことに必ず問題は付きまとう
- 69. 1.2 危険な変更
• 良いシステムでは調べることで安心でき，こ
れから行う変更に確信を持てる
• 悪いコードでは，物事を調べた後で変更に取
り掛かる時には，虎から逃げるために崖から
飛び降りるような気持ちになる
- 70. 1.2 危険な変更
• 大きなクラスを分割する作業は，週に２，３
回ぐらい行ってない限り，極めて困難な仕事
になりがち
• 頻繁に変更を行っていれば，日常業務になる
• 何が分割できて，何ができないかの見当を付
けやすくなり，変更作業もずっと容易になる
- 71. 1.2 危険な変更
• 変更の回避は恐怖をもたらす．
• 不幸なことに，多くのチームが変更に対して
信じがたいほどの恐怖を抱いていて，その恐
怖は日に日に強くなっていく．
- 72. 1.2 危険な変更
• 他の方法として，やみくもに頑張るというの
がある．人を増やして，机に向かって分析す
る時間を確保し，すべてのコードを調べ尽し
て「正しい」やり方で変更を行うこともでき
る．
• 時間をかけてじっくり精査すれば，変更は安
全に行えるはず．
- 73. 1.2 危険な変更
• しかし，これは本当だろうか
• すべての作業を終えた後で，精査が正しかっ
たかどうかを判断できる人などいるのか？
