読書感想文『レガシーコードからの脱却 　ソフトウェアの寿命を延ばし価値を高める9つのプラクティス』

翔泳社が主催するITエンジニア本大賞でも2020年の技術書部門大賞を受賞した書籍だが、約1年ほど積読になっていたのを最近になってようやく読み、そこに書かれていることを実感する出来事があったので、自分の備忘も兼ねて整理してみる。

１．本の情報

タイトル：レガシーコードからの脱却
　　　　　　ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
著者　　：David Scott Bernstein (著)、吉羽 龍太郎 (翻訳)、
　　　　　永瀬 美穂 (翻訳)、原田 騎郎 (翻訳)、有野 雅士 (翻訳)
出版社　：オライリージャパン
出版時期：2019年9月19日

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

２．この投稿でのスタンス

本題に入る前にあまりつらつらと書くべきことではないかもしれないが、本投稿では目次1章ずつ事細かに記載をするつもりはない。
なぜかと言うと、書籍の内容の劣化コピーや、引用を超えて盗作や剽窃になってしまう可能性があるからだ。

線引きは難しい問題だし、自分で引いた線が著者からしたらNGの可能性もある。他人をどうこう言うつもりもない。ただ、私にできる中で最大限著作権を尊重し、またその上でご指摘事項があれば真摯に耳を傾ける所存であることを予め明記しておきたいと思う。

３．要約

本書は大きく2つの構成に分かれている。

先に後半の話をすると、後半はレガシーコードから脱却するための9つのプラクティスについて、各プラクティスに対して1章を割り当てながら、具体的な方法が詳細に解説されている。

前半は現在までのシステム開発プロセスの歴史と手法の問題点などの解説から、レガシーコードの定義やそもそもなぜレガシーコードが生まれてしまうのかといったことについてを解説している。
そして前半の最後に、それらの問題や悪しき風習への対策として、アジャイル開発という知恵が生まれたことについて記載されている。

つまり、後半の各プラクティスは、アジャイル開発を実践する上での方法論でもあると言える。
ここで章レベルまでの目次を確認すると以下の通りである。

第一部　レガシーコード危機
　1章：何かが間違っている
　2章：CHAOSレポート再考
　3章：賢人による新しいアイデア

第二部　ソフトウェアの寿命を伸ばし、価値を高める9つのプラクティス
　4章：9つのプラクティス
　5章：プラクティス1 やり方より先に目的、理由、誰のためかを伝える
　6章：プラクティス2 小さなバッチで作る
　7章：プラクティス3 継続的に統合する
　8章：プラクティス4 協力しあう
　9章：プラクティス5 「CLEAN」コードを作る
　10章：プラクティス6 まずテストを書く
　11章：プラクティス7 テストでふるまいを明示する
　12章：プラクティス8 設計は最後に行う
　13章：プラクティス9 レガシーコードをリファクタリングする

上述の第一部が前半、第二部が後半というくくりとなる。

そして後半の4章で具体的な9つのプラクティスの頭出しを行い、5章～13章で各プラクティスのそれぞれ具体的な内容について記載している。
各プラクティスの解説の中では、より細分化し、理解や実践をやりやすくするために7つの戦略に分けて記載されている。

それらを一つ一つ解説することは冗長であるし、何より全てを解説することは著作者と著作物に対する尊重や敬意とは異なると思われるため、ご興味のある方はぜひご購入頂きたいと思う。

４．学んだこと

そもそもタイトルの副題にもある「プラクティス」という言葉自体が、初見ではいまいちしっくりくる言葉ではないような気がする。（あくまで個人的な感想だが。）
なぜ単なる「テクニック」＝「技術」という言葉ではなく「プラクティス」という言葉が使われているかというと、「プラクティス」＝「習慣」という意味だろうと思う。

局所的な問題解決の技術や方法ではなく、日々実践すべき「習慣」についてを解説した書籍故に「プラクティス」という表現が使われている。
つまり、「どのように問題を解決するか」ではなく、「いかにして問題を作りこまないようにするか」が最も大切ということではないかと思う。

それともう一つこの書籍から（改めて）学んだことは、「品質は作りこむもの」ということである。
この「品質は作りこむもの」というのが理解できた時、9つのプラクティスにもあるようなCI/CDやテスト駆動開発（TDD）、あるいはペアプログラミングやモブプログラミングなどを通してのコードレビューの持つ意味やメリットが、今まで以上にきちんとしっくりと理解ができたように思う。

テストはもちろん重要だ。呼称は会社文化によっても異なるだろうが、単体テスト、結合テスト、システムテスト、受入テストなど、それぞれのテストにはそのテストごとの目的があり、バグを検知したり対応する要件定義書やシステム設計書と照らし合わせることで、機能や要件の漏れや認識相違を明らかにする。

しかしながら、テストは品質をチェックするための方法や工程であり、いかにしてテストで発見されるような問題を作りこまないかという意味では、テストまでの工程、すなわち要件定義や設計、開発工程こそが品質を作りこむためには重要であるということが理解できる。

５．雑感

自分自身の経験からも、残念ながら炎上するプロジェクトであればあるほど、テストのしかも後続の方の工程で問題が発覚する。そんな時には何とかして品質を向上させる方法を模索しなければならず、苦肉の策としてテストサイクルを追加したりする。
期限の迫る中で、時間を稼いでるのか浪費しているのかもはや謎である。

そもそもウォーターフォール開発であれば、品質を作りこむ工程に戻ることなんかできなかったりする。アジャイル開発ならそれが避けられるかといえば必ずしもそうではない。プロジェクトの背景やステークホルダーの事情なども当然ある。

だからこそ本書の内容は、プログラマーレベルに限らず、プロジェクトに関わる全ての人が実践すべき習慣なのだと思う。いかにしてレガシーコードを生まず、質の高いプロダクトを作り、健全なプロジェクトとして進行させていくかは、システムベンダーだけではなく、プロジェクトに関わるステークホルダー全員に責任があることを自覚しなければならないと感じた。

それを自覚してもらうことがとてつもなく難しいわけではあるが。。。