書籍名「レガシーソフトウェア改善ガイドー複合型アプリケーション時代に即した開発、保守技法」
Chirs Birchall著
吉川邦夫訳
翔泳社
読もうと思った動機
- 既存システムの保守を担当しており、関連する知識を集めたいため
- 「レガシーコード改善ガイド」を読んで、関連書籍として本書が紹介されていたため
印象に残った部分
前書き
なぜなら私たち開発者のほとんどは、全く新しいアプリケーションを書くよりも、既存のソフトウェアの仕事をすることに、多くの時間を費やしているからです。ところが、技術者向きのブログや本を読むとほとんどの人たちが、新しい技術を使って行う新しいソフトウェアの構築について書いています。それは理解できることでしょう。
なにしろ私たちは好奇心の塊で、ピカピカした新しいおもちゃを、いつも探しているのだから。けれども私は、人々がもっとレガシーソフトウェアについて話すべきだと感じました。
それと同時に私は、大勢の開発者たちが、自分たちのレガシーソフトウェアを改造し、より保守しやすくしようとする試みに挫折したことに気づきました。多くの人々が、自分が保守するコードに、おっかなびっくりで接しているようです。だから私は、この本によって、彼らを呼び寄せたい、レガシーなコードベースの管理を引き受けやすいように開発者を激励したい、と思うのです。
p3レガシープロジェクトの難題を理解する
けれども、あなたの気分は沈み込む。これらのテクノロジーを自分の仕事に使ってみるような時間はとれないだろう。製品を改善するために使うことなど、なおさら無理だろうと思って、どうしてできないのだろうか？それはあなたが何億行もありそうな、テストもされず、ドキュメントもなく、到底理解できそうにないレガシーコードの保守を任されているからだ。
就業時間の半分はコミットを検査して、何かリグレッションを起こしていないかチェックすることに費やされ、残りの半分は、割けようのないバグが侵入したため、その消化作業に対やさっれる。そして、一番気が滅入るのは、時間が経過するつれて、コードベースにもっとコードが追加され、どんどん壊れやすくなり、問題が悪化していくことだ。
p4 レガシープロジェクトの性質
古い
プロジェクトが本当に保守が困難など乱雑になるには、何年か存続が必要だ。
その期間に、何世代のメンテナ（保守要員）が交代するだろう。移管によって、
システムの元来の設計や、前のメンテナの意図に関する知識も失われる。
大きい
言うまでもないが、プロジェクトは大きいほど保守が難しくなる。理解すべきコードが
多くソフトウェアの隠密度が一定すれば、「コードが多ければバグも多い」のだから
存在する。バグの数も多い影響を及ぼす可能性のある既存のコードが多いのだから新しい
変更によって退化も起きる可能性が高い
引き継がれている
legacyという言葉の一般的な意味（遺産）が示すように、レガシープロジェクトは通常、
前の開発者またはチームから引き継がれる。言い換えると、そのコードが最初に書いた人々と、今、それを保守している人々は、同じではない。それどころか、間に何世代もの開発社が早まっているかもしれない。したがって、現在の保守担当者には、現在の保守担当者には、なぜコードがそのような仕組みになっているのかを知るすべはなく、しばしばそれを書いた人々の意図と、設計上の暗黙の想定とを推理する必要に迫れる。
ドキュメントが不十分
ドキュメントを正確かつ徹底したものにしておくことが、そういう長寿に欠かせないはずだ。ところが残念なことに、開発者がドキュメントを書くより嫌がるのがドキュメントを更新し続ける作業だ。おかげで、たとえ技術的なドキュメントが存在していても、読むほうは、半信半疑にならざるを得ない。
p15 レガシーカルチャー
・変化が怖い
多くのレガシープロジェクトはあまりにも複雑でドキュメントが貧弱なため、その保守を任されているチームでさえもすべてを理解できていない。例えば、次のことがわからない。
・どの機能なら、もう使われていないので、安全に削除できるのだろうか？
・どのバグならば修正しても安全なのだろうか？（ユーザーの中には、そのバグに依存し、
機能のひとつとおっ持っている人がいるかもしれない）
・振る舞いを変更する前に、どのユーザーに問い合わせる必要があるのだろうか
こういう情報が欠如しているので、多くのチームは現状を最も安全な選択として尊重するようになり、ソフトウェアに「不必要な変更」を加えることを恐れるようになってしまう。
どのような変更も、まったくのリスクと見なされ、変更によって利益が得られる可能性は無視される。このため、プロジェクトは進展のない沈滞の状態に陥り、開発者は現状を維持することをに勢力を注ぎ込み、まるで琥珀の塊に封じ込められた蚊のように、ソフトウェアのあらゆる外的影響から保護しようとするのだ。
p55リファクタリングの準備
理想的な世界なら、美しいコードを作るのに完全な自由と無制限の時間を使えるだろうが、ソフトウェア開発の現実は、しばしば妥協を強いられるものだ。もしあなたがチームのメンバーとして働いていて、そのチームが（計画と目標、予算と期限を持つ）大きな組織の一部であれば、あなたの同僚である技術者たちと、技術者ではない関係者たちの両方から、進むべき最良の道について同意を得るため、あなたの交渉術を発揮する必要があるのだ。
親身に忠告するのだが、リファクタリングは常に、組織の目標を念頭に置いていく必要がある。誰があなたに給料を払っているのかを忘れてはいけない。リファクタリングはそれがビジネスに長期的な価値をもたらすと、あなたが証明できる時にだけ行うべきだ。
p56伝統主義者
伝統主義者はどのような変更をひどく嫌がる保守派の開発者だ。彼らだって扱いにくいレガシーソフトウェアシステムの仕事を、他の連中よりも楽しんでいるわけではないのだが、だがリファクタリングは不必要なリスクだと考える。「壊れていないのなら直すな」というのが、彼らのモットーだ。
また、伝統主義者はリファクタリングを我々、開発者が給料をもらっている本来の仕事からの逸脱だと考えているかもしれない。彼らは命じられた仕事をできるだけ早く、余計な面倒は最小限にしてこなしたものであり、コードベースに対する「不必要な変更」がその役立つなどとといっことは理解できないのだ。
p59急進主義者
急進主義者は、逆にレガシーコードを憎悪する革新派の開発者である。かれらはコードベースにある全部のファイルを直すまで満足しない。「書き方が下手なコードを見るのは画面できない」というのだが、「書き方が下手なコード」の定義は「誰か他のやつが書いたコード」とほとんど同じであることが多い。
皮肉なことに、急進主義者は、しばしば独断的である。例えば、もし彼がたｍたまTDDの信奉者であれば、レガシーコードベース全体を見直してTDDで書き直すことが、彼の個人的な使命だと思い込むだろう。
p183 VagrantとAnsibleで開発環境作りを自動化する
開発マシンのセットアップと自動化するのに、役立つツールには様々なものがある
VagrantとAnsibleを使ってその自動化を行う。
・Vagrant・・Vagrantは仮想マシンを管理するプロセスを自動化する。重要なポイントはあなたが開発するソフトウェアごとに、1個のVMを持つことができることだ。
ここの
ソフトウェアの依存関係（例えば、Rubyランタイム、データベース、Webサーバー）はすべてVMの内側に置かれるので、あなたが自分のマシーンにインストールした、それ以外のものとは、きちんと隔離される。
・Ansible・・Ansibleは、あなたのアプリケーションに必要なプロピジョニング（すべての依存関係のインストールとコンフィギュレーション）を自動化する。
p238 窓が割れたら、すぐ直せ。
ソフトウェアとのアナロジーは、言うまでもないだろう。
あなたがコードベースを管理して、常にきれいな状態になるよう整理整頓しなければいけない。ハックや弱点を、あまりにも多く直さずに放置したら、コードの品質は急速に悪化する。開発者たちはコードへの敬意を失って、仕事がいい加減になり始める。
開発者の場合、誰かが努力してコードベースの技術的負債をクリーンアップしているのを見たら、品質を維持してコードを無秩序に堕落するのを防ぐのは自分たち全員の責務だということを、思い出すのではないだろうか。
実践できること・感想
感想
「レガシーコード改善ガイド」よりも取り扱っている範囲が広く、とても参考になりました。
前著はテストコードとソースコードの修正方法にフォーカスしていましたが、テストコードを書くにもコストがかかるため、すべての現場で適用できるわけではありません。本書はより実践的な視点で書かれていると感じました。
プログラマであってもインフラの知識はある程度必要だと実感しました。現実で直面する問題は、ソースコードだけでは解決しないことが多いからです。特定の領域にフォーカスを絞らず、越境型人材を目指したいと思いました（Ansibleが取り上げられていたのは意外でした）。
長く使われるシステムほど、この手の問題は避けられません。「新しい言語で開発すればレガシーではない」「ノーコード開発で全部解決」といった安易な考えに逃げず、真正面から対処する方法を学ぶことが今後ますます重要になると感じました。
実践できること
- 現在担当しているシステムの経緯を詳しく調査する
- VagrantとAnsibleでWindows Serverの構築を試す
- TerraformによるWindows Server構築方法を調べる
- 改善できそうな箇所を洗い出し、調査結果をQiitaに投稿する
- ビジネス側にも理解しやすいよう、効果を定量的に示す
- 何が改善されるか、必要な工数、削減される工数などを記載する（概算で可）