ソフトウェア工学 理工学部 情報システム工学科 新田直也

リファクタリング リファクタリング（refactoring）： 「プログラムの外的振る舞いを変えることなく，その内部構造を改善すること」 もともとSmalltalkのコミュニティで使われていた． M. ファウラーの1999年の著書 「リファクタリング～プログラミングの体質改善テクニック～」 によって広まった．（72個のリファクタリングをカタログ化） プログラム変換の一種．ただし，コンパイラが行うようなプログラム変換はプログラムの高速化を目的としており，リファクタリングと変換の目的が異なる． 現在，eclipse，Visual Studio 2005などで実用化＆注目されている．

リファクタリングの例 「スーパークラスの抽出」を使って，Observerパターンを作成しよう…（やや単純化してある．）

リファクタリングの例 空の親クラス（Subject）を作る

リファクタリングの例 「フィールドの引き上げ」リファクタリングを適用．

リファクタリングの例 「メソッドの引き上げ」リファクタリングを適用． →以上で「スーパークラスの抽出」は完了

リファクタリングの例 「フィールドの引き下げ」リファクタリングを適用．

自動リファクタリングと 手動リファクタリング 当初はリファクタリングは手動で行われていた． 手動リファクタリングの場合，以下の2点が重要： 1つ1つの作業が単純でわかり易いこと． 作業が終わるたびにテストを行って動作確認すること． 自動リファクタリングではすべての作業が自動かつ安全に行われる． 自動化されているリファクタリングは一部． eclipse，VisualStudio2005のリファクタリングは自動． 自動/手動いずれのリファクタリングでも，機能追加とリファクタリングを同時に行わないようにすること．

リファクタリングの背景 最初から完璧な事前設計を行うことは難しい． 後から仕様が変わる可能性がある． 実装して初めて設計の不備に気づく場合も多々ある． 設計者の力量不足． リファクタリングの使用を前提すると，事前設計を「気楽に」済ませることができる．（設計に不備があったら後で変更すればよい．） その他の効用： 潜在的なバグの発見 プログラミングの高速化

アジャイル（agile）前夜 開発プロセスモデルは何を問題にしていたか? そもそも顧客からして仕様をわかっていない． 例えば，バグが見つかったときの責任は誰にあるか? 仕様書をきちんと書いていれば，顧客側の責任か開発者側の責任かがはっきりする． 例えば，開発プロジェクトの破綻，工程のやり直し（手戻り）を防ぐにはどうすればよいか? 不備がないように慎重に仕様書を書こう． 不備がないように慎重に設計を行おう． → ウォーターフォールモデルの誕生 そもそも顧客からして仕様をわかっていない． 仕様変更しなければ時代についていけない． 厳密な仕様なんてプログラムと大差ない． → 早い段階からの実装．（スパイラルモデル，プロトタイピングモデル） → 開発予算，出荷時期の見積もりの問題をどうするか?

アジャイル開発 アジャイル開発： アジャイル宣言（http://www.agilemanifesto.org/） K.ベック，M. ファウラーなどが中心になって提唱した新しい一群の開発手法の総称． アジャイル（俊敏な，素早いの意） → 変化に対し素早く反応することを目指す． サイクルの短いスパイラルモデルともみなせる (http://www007.upp.so-net.ne.jp/kengai/fowler/newMethodology_j.html#A39) アジャイル宣言（http://www.agilemanifesto.org/） プロセスやツールよりも、個人と相互作用を 包括的なドキュメントよりも、動作するソフトウェアを 契約交渉よりも、顧客との協調を 計画に従うよりも、変化への対応を

eXtreme Programming (XP) 4つの価値 コミュニケーション シンプル フィードバック 勇気 14の実践項目 計画ゲーム，小さなリリース，オンサイト顧客，メタファ，シンプルな設計，リファクタリング，テスト・ファースト，ペア・プログラミング，コードの共同所有，常時結合，コーディング規約，持続可能なペース，オープンワークスペース，日ごとのスキーマ移行

まとめ 開発プロセスモデルの話題は今日でも発展している． ソフトウェア工学の歴史は，プロセスとプロダクト相互の発展の歴史． プロセス： ウォーターフォール，スパイラル，プロトタイピング， アジャイル，ソフトウェアファクトリ… プロダクト： 構造化技法，オブジェクト指向，UML，アスペクト指向… アジャイルプロセスは最近，産業界で急速に注目されつつある．（ソフトウェア工学の歴史では稀）

12/8東証システムの不具合 12/8 みずほ銀行の誤発注，東証システムの不具合でみずほ銀行側に400億円の損失．（http://www.yomiuri.co.jp/atmoney/mnews/20051213mh11.htm） 12/8 9:27，みずほ銀行がジェイコム株を1株1円，61万株で売り注文． 1分25秒後，みずほ銀行側が誤発注に気づき，取り消し注文． 東京証券取引所の売買システム の不具合のため取り消し注文が受け付けられず． ジェイコム株の値幅制限の下限５７万２０００円で取引が行われ，みずほ銀行側に400億円の損失．