レガシーコード読書会 20120618

994 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
994
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

レガシーコード読書会 20120618

  1. 1. レガシーコード改善ガイド読書会 第1回 第1回 2012/06/18 CyberX  エンジニア 石川泰式
  2. 2. まえがき• 最初はプログラマの心の中でけがれの ない水晶のように輝いていた設計が, 時間が経つことで劣化し,悪くなった 肉のように腐敗していく
  3. 3. まえがき• 最初に必要だと言ったもので顧客が満 足してくれさえすれば,設計は問題な かったはずだ,と考えて自分を慰める• 要求を変えてくる顧客がいけない
  4. 4. まえがき• 「要求変更が発生しました」要求の変 更に耐えられない設計は,そもそも悪 い設計です• 優秀なソフトウェア開発者は皆,変更 に耐え得る設計を目指している
  5. 5. まえがき• これはどうにも困難な課題に思える• 実際あまりに困難なため,これまでに 開発されたほとんどすべてのシステム がゆっくりと衰弱し腐敗していく• この腐敗したプログラムを「レガシー コード」と特別な名前と名付けた
  6. 6. まえがき• プログラミングの最初の喜びが強烈だ ったとしても,レガシーコードに取り 組む苦痛のせいで,その炎が消されて しまうことも少なくない.
  7. 7. まえがき• 私たちの多くは,コードがレガシーに なることを「防ぐ」方法を探し続けて きた.• Michael Feathers は,私たちの多くが見 落としていた点を見抜いた.
  8. 8. まえがき• それは,防ぐだけでは不十分だという こと• 腐敗を防ごうとするだけでは不十分で あり,逆戻りさせる必要がある.
  9. 9. まえがき• 本書で取り上げるテーマは,腐敗を逆 戻りさせる方法
  10. 10. まえがき• 絡み合った,不透明で入り組んだシス テムを,ゆっくりと,徐々に,1つず つ,1歩ずつ,簡素できちんと構造化 された,優れた設計に変えていくため の本• エントロピーを逆転させる.
  11. 11. まえがき• 腐敗を逆戻りさせるのは簡単ではない し,すぐにできることもない.• Michael が本書で紹介している手法やパ ターンやツールは有効だが,それには 手間と時間と忍耐力,そして慎重さが 必要
  12. 12. まえがき• 本書は魔法の弾丸ではない.• システムに積りに積もった腐敗を一晩 で取り去る方法は教えてくれない
  13. 13. まえがき• 本書には今後仕事を続けていく上で役 立つ,規律や概念や姿勢が書かれてい る• まさにそれによって,徐々に質の落ち ていくシステムを,徐々に質の向上す るシステムに変えていく事ができる
  14. 14. はじめに• コンピュータで何かを動かすという純 粋な喜びを経験したことがありますか ?
  15. 15. はじめに• プログラマに尋ねてみたところ,ほと んどが経験していた.
  16. 16. はじめに• その喜びは私たちがこの仕事に就いた 理由の1つのはずですが,日常のどこ に埋もれてしまったのでしょうか?
  17. 17. はじめに• 頑張ってはいるものの,スケジュール のプレッシャーからか,過去のしがら みからか,自分の仕事の見本となる優 れたコードがないためか,多くの人が レガシーコードを書いてしまっている
  18. 18. はじめに• レガシーコードとは,誰かから引き継 いだコード
  19. 19. はじめに• 簡単なはずの機能追加をしようとして 徹夜したことや,士気を喪失してまっ たこと,チーム全員がコードにうんざ りしてどうでもよくなってしまった感 覚,死んでしまいたくなるようなコー ドを思い出すでしょう.
  20. 20. はじめに• そのコードを改善しようと考えること すら嫌な気持ちになるかもしれない• そんな手間をかけるのは無駄に思える から
  21. 21. はじめに• レガシーコードとは,単にテストのな いコード
  22. 22. はじめに• テストのないコードは悪いコードである• どれだけうまく書かれているかは関係ない• どれだけ美しいか,オブジェクト指向か,き ちんとカプセル化されているかは関係ない
  23. 23. はじめに• テストがあれば,検証しながらコードの動き を素早く変更することができる.• テストがなければ,コードが良くなっている のか悪くなっているのかが本当にはわからな い.
  24. 24. はじめに• きれいなコードは有益だが,それだけでは不 十分• テストなしに大規模な変更をしようとすると ,チームは危険な賭けに出ることになる.
  25. 25. はじめに• チームの腕が上がって,より明確なコードを 書き始めたとしても,古いコードがきれにな るのには時間がかかる.• たいていの場合,完全にきれいになることは ありえない.
  26. 26. はじめに• 本書で説明する手法は,かなり大きいコード でテストしてある.例が小さいものになって いるのは,本のスペースの都合のため.特に 次のようにコードの中に省略記号( ... )が含 まれている時は,「汚いコードがここに 500 行入る」と読み替えて下さい.
  27. 27. はじめに• 本書は美しいコードを書くための本でも,美 しい設計をするための本でもない.• 優れた設計を目指すべきではあるが,レガシ ーコードにおいては,不連続ないくつものス テップへ経なければそこには到達できない.
  28. 28. はじめに• 本当に必要なのは,ありのままの患者を受け止 め,悪いところを直し,より良い健康状態にす ること• コードをより健康に,より作業しやすくするこ とは可能• 患者の状態が少し回復したら,その後で,より 健康的な生活が送れるよう患者を手助けする
  29. 29. はじめに• ちょっと落ち着いて楽になれるところまで持 って行きたい• 私たちはそれを望み,コードの変更を楽にし ようと頑張っている.• チームがその意識を持ち続けることができれ ば,設計は良くなる.
  30. 30. はじめに• 本来プログラミングは非常にやりがいのある ,楽しい仕事のはず• 日々の仕事の中でそのように感じられずにい る人が,本書の手法によってその気持を発見 し,チームに広げてくれることを望んいでい ます.
  31. 31. はじめに• 本来プログラミングは非常にやりがいのある ,楽しい仕事のはず• 日々の仕事の中でそのように感じられずにい る人が,本書の手法によってその気持を発見 し,チームに広げてくれることを望んいでい ます.
  32. 32. 第1部変更のメカニズム変更のメカニズム
  33. 33. 第1章ソフトウェアの変更ソフトウェアの変更
  34. 34. ソフトウェアの変更• コードの変更は素晴らしいこと• 私たちの日々の生活を困難なものにしてしま うコードの変更方法はいくらでもある.• 逆に楽にできる方法もいくらでもある.
  35. 35. ソフトウェアの変更• 本書では,その議論を少し広げて,非常に厄 介な状況のコードに取り組む方法について考 えてみる.• そのために,まず変更のメカニズムについて 掘り下げてみる.
  36. 36. 1.1 ソフトウェア変更の4つの理由• 話を簡単にするために,ソフトウェア変更の 理由を大きく4つに分けて検討する. • 要件の追加 • バグの修正 • 設計の改善 • リソース利用の最適化
  37. 37. 1.1.1 要件の追加とバグの修正• 要件の追加は,変更の理由の中で一番わかり やすいものと言える• ソフトウェアが実現する,ある動作に対して ,別の動作も行ってほしいとユーザーが言う 場合である.
  38. 38. 1.1.1 要件の追加とバグの修正• マネージャが左側にある会社のロゴを右側に 移してほしいといったとする.
  39. 39. 1.1.1 要件の追加とバグの修正• しかし話を聞いてみると,実現するのがそれ ほど簡単ではないと気づく.• マネージャはロゴの移動だけでなく,次のリ リースではユーザの操作に応じてロゴの表示 を動的に変化することを望んでいた.
  40. 40. 1.1.1 要件の追加とバグの修正• これはバグ修正?それとも要件追加?
  41. 41. 1.1.1 要件の追加とバグの修正• 顧客の立場からすると,マネージャは紛れも なく問題の修正を依頼している.• 開発者の立場からすると,この変更は完全に 新しい要件とも取れる.
  42. 42. 1.1.1 要件の追加とバグの修正• 見方によっては,要件追加かバグ修正かは終 わりのない議論かもしれない.• 結局はコードやその他の成果物を変更するこ とに変わりはない.• 残念ながら,バグ修正か要件追加かの議論に よって,技術的にもっと重要なことが隠され てしまっている.
  43. 43. 1.1.1 要件の追加とバグの修正• それは振る舞いが変更されるかどうかである• 新しい振る舞いの追加と,既存の振る舞いの 変更には大きな違いがある.
  44. 44. 1.1.1 要件の追加とバグの修正• ソフトウェアで最も大切なのは「振る舞い」 であり,振る舞いこそがユーザの求めるもの である.期待される振る舞いを私たちが追加 すればユーザは喜ぶが,ユーザの求める振る 舞いを変更,あるいは削除してしまえば,バ グの作り込みとなり,私たちの信頼は失われ てしまう.
  45. 45. 1.1.1 要件の追加とバグの修正• 会社のロゴの例は振る舞いの追加? • 答えはイエス • なぜならその変更によって,システムはペ ージの右側にロゴを表示するようになるか ら
  46. 46. 1.1.1 要件の追加とバグの修正• 振る舞いの削除? • 答えはイエス • なぜなら左側のロゴがなくなるから
  47. 47. 1.1.1 要件の追加とバグの修正public class CDPlayer { public void addTrackListing(Track track) { ... } ...}
  48. 48. 1.1.1 要件の追加とバグの修正• このクラスには,曲目リスト( TrackListing ) を追加するメソッドが定義されている.• ここに曲目リストを置き換えるメソッドを追 加する.
  49. 49. 1.1.1 要件の追加とバグの修正public class CDPlayer { public void addTrackListing(Track track) { ... } public void replaceTrackListing(Track track) { ... } ...}
  50. 50. 1.1.1 要件の追加とバグの修正• このメソッドの追加は,新しい振る舞いの追 加だけか?それとも変更か? • 答えはどちらもノー • メソッドを追加するだけで,どこからも呼 び出されなければ振る舞いは変化しないか ら
  51. 51. 1.1.1 要件の追加とバグの修正• ある程度の変化なしに振る舞いを追加するこ とはほとんど不可能と言える.
  52. 52. 1.1.2 設計の改善• 設計の改善は,別の種類のソフトウェア変更• 保守しやすくなるようにソフトウェアの構造 を変更する時,通常は振る舞いを同じに保つ 必要がある.• もし,その過程で必要な振る舞いが失われて しまえば,それはバグと呼ばれることになる
  53. 53. 1.1.2 設計の改善• 多くのプログラマがあまり設計を改善したが らないのは,その過程で振る舞いを失ってし まったり,間違った振る舞いを作りあげてし まいやすいから• 振る舞いを変えずに設計を改善することをリ ファクタリングと呼ぶ.
  54. 54. 1.1.2 設計の改善• リファクタリングの基本として,変更前と変 更後で振る舞いが変わらないことを確認する ためのテストを書き,検証しながら少しずつ 作業を進めることで,ソフトウェアの保守性 を向上できるという考え方がある.
  55. 55. 1.1.2 設計の改善• リファクタリングは,ただソースコードの書 式を修正するようなリスクの低い作業ではな い• リスクを顧みずに大規模にソースコードを書 き直す作業でもない
  56. 56. 1.1.2 設計の改善• リファクタリングでは小さな構造修正を繰り 返し行う• その際,容易に変更を行えるようにテストで サポートする.• 変更という面から見て重要なのは,リファク タリング時には機能を変更すべきではないと いうこと
  57. 57. 1.1.3 リソース利用の最適化• リソース利用の最適化はリファクタリングと 似ているが,目的が異なっている.• 最適化における変更するものは,プログラム が使用しているなんらかのリソース(通常は 時間やメモリ)に相当する.
  58. 58. 1.1.4 4つの変更のまとめ 要件追加 バグ修正 リファクタリング 最適化 構造 変化する 変化する 変化する ー 新機能 変化する ー ー ー 機能 ー 変化する ー ーリソース利用 ー ー ー 変化する
  59. 59. 1.1.4 4つの変更のまとめ• 要件追加,リファクタリング,最適化のいず れでも,既存の機能は変わらずに保たれる• 実際には,バグの修正の場合でも,詳しく調 べてみると,機能を変更するものの,変更さ れない既存機能に比べると,変更量はごくわ ずかな場合がほとんど
  60. 60. 1.1.4 4つの変更のまとめ• 要件追加やバグ修正は,リファクタリングや 最適化とよく似ている.• 4つのいずれの場合でも,一部機能や一部振 る舞いを変更するが,元のままに保たれてい る部分のほうがずっと多い
  61. 61. 1.1.4 4つの変更のまとめ既存の振る舞い 新しい振る舞い
  62. 62. 1.1.4 4つの変更のまとめ• 変更を行った時に何が起きるかを,整理する 良い面は,何に集中するべきかがわかりやす くなること• 悪い面は,集中すべきは変更箇所だけではな い.厄介なことにコードに触れていないから と言って,振る舞いが変わらない保証はない
  63. 63. 1.1.4 4つの変更のまとめ• 変更時には,対象箇所以外の振る舞いが変っ ていないことを確認する必要があるが,それ はとても困難な作業• しばしば問題となるのは,ある変更によって どれだけの振る舞いに影響が及ぶかを把握で きないこと
  64. 64. 1.1.4 4つの変更のまとめ• 変更を安全に行うために最も重要なことは, 影響範囲を理解すること
  65. 65. 1.1.4 4つの変更のまとめ• 既存の振る舞いを変えずに保つことは,ソフ トウェア開発における最も困難なことの1つ である.主要な機能を変更をしようとする時 でさえ,通常は既存の振る舞いの大部分を変 更せずに保たれなければならない.
  66. 66. 1.2 危険な変更• 振る舞いを保つのは非常に困難なこと• 変更を行いながら振る舞いを維持する作業は 大きなリスクを伴う
  67. 67. 1.2 危険な変更• リスクを緩和するには,次の3つの点を考慮す る必要がある. • どんな変更を行わなければならないか • 変更が正しく行われたことをどうすれば確認 できるか • 何も壊していないことをどうすれば確認でき るか
  68. 68. 1.2 危険な変更• 変更を避けることでソフトウェアの問題を最 小限に抑えられるという考え方は魅力的だが ,残念なことに必ず問題は付きまとう
  69. 69. 1.2 危険な変更• 良いシステムでは調べることで安心でき,こ れから行う変更に確信を持てる• 悪いコードでは,物事を調べた後で変更に取 り掛かる時には,虎から逃げるために崖から 飛び降りるような気持ちになる
  70. 70. 1.2 危険な変更• 大きなクラスを分割する作業は,週に2,3 回ぐらい行ってない限り,極めて困難な仕事 になりがち• 頻繁に変更を行っていれば,日常業務になる• 何が分割できて,何ができないかの見当を付 けやすくなり,変更作業もずっと容易になる
  71. 71. 1.2 危険な変更• 変更の回避は恐怖をもたらす.• 不幸なことに,多くのチームが変更に対して 信じがたいほどの恐怖を抱いていて,その恐 怖は日に日に強くなっていく.
  72. 72. 1.2 危険な変更• 他の方法として,やみくもに頑張るというの がある.人を増やして,机に向かって分析す る時間を確保し,すべてのコードを調べ尽し て「正しい」やり方で変更を行うこともでき る.• 時間をかけてじっくり精査すれば,変更は安 全に行えるはず.
  73. 73. 1.2 危険な変更• しかし,これは本当だろうか• すべての作業を終えた後で,精査が正しかっ たかどうかを判断できる人などいるのか?

×