第6章 ビッグ・リライト
この章で学ぶこと
書き換えプロジェクトの範囲を決める
既存のソフトウェアが新しい実装に与える影響
レガシーデータベースをどうするか
あなたが「大いなるリライト」（The Big Rewrite）に挑戦するなら、他の選択肢をすべて試した後のことだと思いたい。あなたはコードベースのリファクタリングを試みたが、行き止まりに達した。レガシーソフトウェアをサードパーティ製ソリューションで置き換える方法についても、実現可能かどうか調べたが、あまりにも多くのカスタマイズが必要になって、ゼロから書くより仕事の量が多いことが分かった。リライト（書き換え）から逃れる手段はないと、あなたは結論を下した。それは鳥肌が立つような状況だ。
自分はレガシーアプリケーションをゼロから書き換えるのだ、と覚悟すると、なぜ鳥肌が立つのだろうか。まずは、その理由を確認しておこう。第1に、そのプロジェクトは際限なく引き伸ばされるだろう。思ったより長くかかることを私が保証する。最初は、書き換えなど比較的単純な作業だと思われるかも知れない。既存のコードが行っていることを、ただ真似すればよいのだから。けれども、いったん実装を始めると、既存のソフトウェアには（実装にも、仕様にも）、あらゆる種類の隠れた特殊ケースや、不可解な抜け穴があり、そのすべてを調査し文書化する必要が生じる。これによってプロジェクトが停滞するだけでなく、しばらく続けていると飽き飽きしてしまうのだ。もちろん開発者は、たいがいコードを書きたくてしょうがないのだが、リライトの場合、その仕事の大部分が、レガシーソフトウェアの謎めいた振る舞いを解き明かし、それをどう扱うのが最良の策かを議論するために費やされてしまう。
第2に、書き換えは、それに費やされる努力と困難が大きいのに、ソフトウェアのエンドユーザーに提供される直接的な価値が、あまりにも少ないことが、しばしばある。何か月もかけて構築したアプリケーションなのに、エンドユーザーから見ると、以前とまったく同様に動作するとしか思えない。それどころか、人々は既存のソフトウェアにあったバグや欠点に慣れてしまい、特徴のように思いがちだから、もしそれらを忠実に再現しないと、熱心なユーザーを失望させるリスクがある。さらに、あなたの新しい実装によって、独自の新しいバグが導入されることは、ほとんど確実である。
とはいえ、ときにはリライトが本当に（悪い選択肢ばかりの中では）最良のオプションかも知れない。そうだとしたら、リライトをスムーズに進めるために考慮すべきことが、いくつかある。この章では、プロジェクトの範囲を決める方法を学び、新しいソフトウェアに対する既存の実装からの影響を、どこまで許せばよいのかを考慮し、レガシーデータベースを扱う戦略について検討する。
第3部 リファクタリングの先へ ― プロジェクトのワークフローと基盤を改善する
この本の最後にあたる第3部では、これまでの「どういうソフトウェアを書くべきか」という話題を超えて、そのソフトウェアを「どうやってビルドし、保守するか」を考える。
これは範囲の広いトピックで、ローカルマシンを効率的なソフトウェア開発のためにセットアップする方法から、ソフトウェアを実行する必要のある複数の環境を管理し、チーム作業のためにバージョン管理システムを使い、ソフトウェアを迅速かつ信頼できる方法で製品にデプロイする方法まで含まれる。
今後の3章では、Vagrant、Ansible、Gradle、Fabricなど、かなり多くのツールを紹介する。これらを今までに使ったことがなくても、あるいは同じ仕事をする同様なツールを使って満足していても、心配は無用だ。これらを使うのは、ただ基本的なテクニックを学べるように具体的な例を示すためなのだ。同様に使える他のツールについての情報も、随時紹介しよう。
そして最後の章では、今日あなたが書くソフトウェアが、明日には悲惨なレガシーになる、というホラーストーリーを防ぐためのヒントを提供する。
第7章 開発環境を自動化する
この章で学ぶこと
優れたREADMEファイルの価値
VagrantとAnsibleを使って開発環境を自動化する
外部リソースへの依存性を排除して、開発者の自立性を高める
ほとんどすべてのソフトウェアは、何らかの形で周囲の環境に依存する。実行されるマシンの上で、ある特定のソフトウェアが実行されることや、ある特定の構成が設定されることを、ソフトウェアは（というより、それを開発した人は）期待している。たとえば多くのアプリケーションは、データの保存にデータベースを使うから、どこかでデータベースサーバーが実行され、それをアクセスできることに依存する。構成に対する依存の例としては、ログファイルを保存するために特定のディレクトリの存在を期待するソフトウェアがある。
これらの依存性をすべて調べ、それらを満足させる環境を用意するのは、とても面倒な作業になりかねない。依存性は十分に文書化されていないことが多いが、その理由はおそらく単順で、ドキュメントを置くのに適した場所か、標準のフォーマットが、存在しないからだ。
この章では、あなたが（そして他の人々が）開発環境をセットアップしてレガシーソフトウェアの保守を開始するまでの作業を、できるだけ簡単にする方法を調べよう。ここで書くスクリプトは、プロビジョニング（provisioning）のプロセスを自動化するだけでなく、ドキュメントを残す役割も果たすので、後に保守を行う人たちがソフトウェアの依存性を理解するのが容易になる。
第8章 テスト、ステージング、製品環境の自動化
この章で学ぶこと
Ansibleを使って複数の環境にプロビジョニングする
開発基盤をクラウドに移す
前章ではUADアプリケーション用のローカル開発環境に自動的なプロビジョニングを行う、Ansibleのplaybookを書いた。この章では、開発マシンから製品サーバーにいたる全部の環境へのプロビジョニングに再利用できるよう、そのAnsibleスクリプトのリファクタリングを行う。
実際に作業を始める前に、ソフトウェアを実行させる必要のある環境には、どのようなものがあるのか、また、それらの環境へのプロビジョニングを、なぜ自動化したいのかを、簡単にまとめておこう。
アプリケーションの開発と実行に、どのような環境が必要かは、ケースによって微妙に異なるが、一般的な要件は次のものだろう。
- 開発環境―開発者のローカルマシン。これをDEV環境と呼ぼう。
- テスト環境―ソフトウェアのテストを、現実的なデータを使って、製品で使われるのと同様なハードウェアで実行する環境。ニーズによっては複数の目的に複数のテスト環境が必要になるかも知れない（ひとつは日常的な手作業によるテスト用、ひとつは最終的なステージング用、もうひとつは性能テスト用など）。この章ではテスト環境が1つだけであると想定し、それをTESTと呼ぶ。たとえ準備が必要な環境がいくつあっても、原則は同じである。
- 製品環境―実際にユーザーがソフトウェアとやりとりするのが製品の環境だ。もしソフトウェアが、ネイティブなモバイルアプリや、ユーザー自身がホスティングするビジネスソフトのようなものであれば、この環境には我々の制御がおよばないので、準備に関わる必要はない。けれども、あなた自身がホスティングするWebアプリケーションのようなものなら、あなたが製品環境を制御するのだから、プロビジョニングを行う責任があるはずだ。この章では後者を想定して、その環境をPRODと呼ぶ。
もちろん実際には、たとえばライブラリのように、それ自身が実行されるのではなく、実行されるソフトウェアの一部を構成するようなソフトウェアも存在する。ただし、そういう場合であっても、独立したTEST環境を持って、その中で統合テストを実行し、そのライブラリが、あるアプリケーションの一部として正しく機能することをチェックするのは有益なことだろう。
第9章 レガシーソフトウェアの開発／ビルド／デプロイを刷新する
この章で学ぶこと
開発とビルドのツールチェインをレガシーから切り替える
Jenkinsを使ってレガシーソフトウェアを継続的に統合する
製品のデプロイメントを自動化する
これまでの2章で見たプロビジョニングは、レガシーソフトウェアが依存するものを、すべてインストールして設定するものだった。ここで話をソフトウェアそのものに戻し、ツールチェインとワークフローに少し労力を費やすことでレガシーソフトウェアの保守を容易にする方法を紹介しよう。
第10章 レガシーコードを書くのはやめよう！
この章で学ぶこと
これまでに習ったテクニックを、レガシーコードだけでなく新しいコードにも応用する
使い捨てにできるコードを書く
もう読者は、どんな「放置されたレガシーコード」を継承しても、その扱い方や、健康な状態に戻す術を知っているはずだ。我々はリライトも、リファクタリングも、継続的インスペクションも、ツールチェインの刷新も、自動化も、まだ他にも、さまざまなことを見てきた。けれども、たぶんあなたには新しいコードを書く時間も、少しはあっただろう。すべてのコードは、いつかレガシーになる運命なのだろうか？ それとも、いまあなたが書いているコードが数年後に誰かの悪夢になることを、予防する手段があるだろうか？
これまでの9章で、我々は非常に広い範囲を扱ってきたが、いくつかのメインテーマが（明示的に書かれた場合も、暗黙的に推測される場合も含めて）本書のいたるところに現れていた。それらのアイデアは、これまでレガシーコードの文脈で論じてきたが、多くは新規プロジェクトにも同じように適用できる。この最後の章で総括する、それらのテーマとは、次のものだ。
- ソースコードがすべてではない
- 情報はフリーになりたがらない
- われらの仕事は終わらない
- すべてを自動化せよ
- 小さいのが美しい
これらのテーマに関する詳細を論じ、過去・現在・未来に渡るレガシー対処法を提示する。
