レガシーコードからの脱却

より良いソフトウェアを作り出すための考え方、テクニック、スキルを詳述!
保守性の高いソフトウェアを構築する上で、リファクタリングやテストファースト開発などの技術的な実践がなぜ重要なのかについて具体的なアドバイスと一緒に解説します。

版元はレガシーコードを、バグを多く含み、壊れやすく拡張が難しいコードと定義し、一度作ってしまったコードの質を上げるには初めから質の高いコードを作るよりも膨大なコストがかかると述べています。『レガシーコードからの脱却 ソフトウェアの寿命を延ばし価値を高める 9 つのプラクティス』 (David Scott Bernstein 著、吉羽龍太郎 / 永瀬美穂 / 原田騎郎 / 有野雅士 訳、オライリー・ジャパン、2019 年 9 月刊) は、その前提に立って、既にあるレガシーコードの修理法ではなく、開発の最初からレガシーコードを作り出さないための 9 つのプラクティスを説く本です。原書は『Beyond Legacy Code』で、版元サイトの分類は Business/Essay に置かれています。

全 14 章の構成、レガシーコード危機から 9 つのプラクティスへ

構成は全 14 章の 2 部立てです。第 Ⅰ 部「レガシーコード危機」の 1 章から 3 章は、なぜウォーターフォールは機能しないのか、CHAOS レポート再考とプロジェクトがなぜ失敗するのか、そしてアジャイルに入門し技術的卓越性を求めるという順で、問題の所在を描きます。第 Ⅱ 部は副題と同じ「ソフトウェアの寿命を延ばし価値を高める 9 つのプラクティス」を掲げ、4 章で守破離や第一原理を手がかりに原則とプラクティスの関係を整理し「良い」ソフトウェアを定義したうえで、5 章から 13 章にプラクティス 1 から 9 を 1 章ずつ割り当て、14 章「レガシーコードからの学び」で締めます。多くの章末には「実践しよう」と「本章のふりかえり」の節が置かれ、読んだ内容を自分のチームに持ち込むための足場になっています。

9 つのプラクティスの中身、目的の共有から CLEAN コードとテストまで

9 つのプラクティスは、目次の章題どおりに並べると、やり方より先に目的、理由、誰のためかを伝える、小さなバッチで作る、継続的に統合する、協力しあう、「CLEAN」コードを作る、まずテストを書く、テストでふるまいを明示する、設計は最後に行う、レガシーコードをリファクタリングする、の 9 本です。前半はプロダクトオーナーにいてもらう、受け入れ基準を自動化する、フィードバックサイクルを短くする、ビルドを自動化する、ペアプログラミングやスパイク、スウォーム、モブといったチームの進め方を扱い、後半はコードそのものに踏み込みます。9 章の「CLEAN」コードは、凝集性が高い、疎結合 である、カプセル化されている、断定的である、冗長でないという 5 つの性質としてコード品質を定義し、10 章と 11 章はレッド/グリーン/リファクタのサイクル、「テストは仕様だ」という考え方、モックを使ったワークフローテストまで、テスト駆動開発を設計と安全網の両面から論じます。12 章は意図によるプログラミング、循環複雑度を減らす、生成と利用を分離するといった節を通じて創発する設計を、13 章は投資か負債かという問いからリファクタリングのテクニックを扱います。

技術的負債を「後で返す」のではなく「借りない」ための技術背景

レガシーコードの難しさは、どれか 1 つの技術で解決できない点にあります。大きな一括リリースは統合時の衝突と手戻りを生み、テストの無いコードは変更のたびに壊れる恐れを生み、設計を先に固め過ぎると要求の変化に追従できなくなります。本書の 9 つのプラクティスは、小さなバッチと 継続的インテグレーション でフィードバックの周期を短くし、テストファースト でふるまいを明示してから実装し、設計は使われ方が見えた最後に整える、という順序で、これらを相互に補強する 1 つの体系として提示しています。個々の手法を知っている開発者でも、なぜその組み合わせでなければ寿命が延びないのかを原則の側から説明できる人は少なく、7 章の節題「完了と、完了の完了と、完了の完了の完了が違うことを知る」に表れる、完了の定義を疑う姿勢がその補強材料になります。翻訳書ですが、扱うのは特定の言語やフレームワークに依存しない開発の進め方なので、2019 年刊という時点が内容の有効性を損なう性格の本ではありません。

開発者だけでなく運用管理者 / マネージャも対象、コード例を求める人には向かない

版元が対象に挙げるのは、信頼性や拡張性が高いソフトウェアをリリースしたい開発者、運用管理者、マネージャです。プラクティスの前半がプロダクトオーナーとの目的の共有やバッチサイズ、チームの協力の仕方を扱うため、コードを書かない立場でも読める作りになっており、開発チームと発注側が同じ言葉で開発の進め方を議論するための共通言語として使えます。一方で、言語別のリファクタリング手順やテストコードの書き方を大量のコード例で学びたい人には、考え方の解説が中心のこの本は期待と合いません。また既に大規模なレガシーシステムを抱え、その救出手順そのものを求めている場合、13 章がリファクタリングを扱うとはいえ、本書の主眼は「作らない」側にあることを踏まえて選ぶ必要があります。なお版元公式ページには正誤表が公開されているので、手元の刷と突き合わせて読むと確実です。

テストや設計の個別技法を学ぶ本については テスト本の選び方 で整理していますが、本書はそれらの技法を「なぜ」で束ねる位置にあります。TDD やリファクタリングの手順書を読んでも現場に定着しなかった経験がある人、開発の進め方を見直したいがチームやマネジメント層との合意形成で詰まっている人にとって、原則から実践までを 9 つに絞って語る本書は、投じた時間が会話の質と次のリリースの安定に直接返ってくる一冊です。