【書評】「レガシーコードからの脱却」の9つのプラクティスは圧倒的に正しい（経験者談）

はじめに

株式会社アトラクタの原田騎郎さん（@haradakiro）から、書籍「レガシーコードからの脱却」をご恵贈いただきました。（どうもありがとうございます！）

せっかくいただいた本なので、本書を読んだ僕の感想を書いてみようと思います。

どんな本なの？

端的に言うと、「初めからレガシーコードを作りださないための9つのプラクティスを説明した本」となります。

最初にタイトルを見たときの印象は「今そこにあるレガシーコードを、どうやってイケてるコードに書き直していくのか？」を説明した本なのかなと思ったんですが、本書が主眼としているのは「そもそもレガシーコードを作らないこと」でした。

ですので、「レガシーコード改善ガイド」とは毛色が違う本だと考えた方が良さそうです。
（「レガシーコード改善ガイド」は、「今そこにあるレガシーコードを改善する方法」を解説した本です）

レガシーコード改善ガイド (Object Oriented SELECTION)

ちなみに、原著のタイトルは "Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software"です。

Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software

本書におけるレガシーコードの定義

「レガシーコードって何？」という人のために簡単に説明しておくと、本書におけるレガシーコードとは「修正や拡張、作業が難しいコード」（訳者まえがきより抜粋）のことです。

ポジティブかネガティブかでいうと、明らかにネガティブな意味です。
「弊社にはレガシーコードがたくさんあります」とのたまう人がいたら、その会社はちょっと大変な状況であることが疑われるので注意しましょう。

本書が提示する9つのプラクティス

本書は「ソフトウェアの寿命を延ばし価値を高める9つのプラクティス」として、以下のプラクティスを掲げています。

1. やり方より先に目的、理由、誰のためかを伝える
2. 小さなバッチで作る
3. 継続的に統合する
4. 協力しあう
5. 「CLEAN」コードを作る
6. まずテストを書く
7. テストでふるまいを明示する
8. 設計は最後に行う
9. レガシーコードをリファクタリングする

それぞれの具体的な内容についてはここには書きません。
本書を購入してご自身でチェックしてみてください😉

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

正直に言うと、あまり目新しい内容はなかった・・・が！

さて、ここから下は僕の感想です。

本書をひと通り読んだあとの感想は、「うーん、あまり目新しい内容はなかったな🤔」でした。

ネガティブですよね？disってるように聞こえますよね？？

いや、でも違うんです！

なんで目新しい内容がなかったのかというと、この本に書かれているほぼすべてのプラクティスが今僕が勤めているソニックガーデンで実践できていたからです。
そして、ソニックガーデンにはレガシーコードがありません。
かれこれソニックガーデンで7〜8年働いてきましたが、「うわー、これはないわー。まさにレガシーコードだわー」と思ったことは一度もないのです。

反対に、僕が以前勤めていた前職や前々職の会社では「勘弁してくれよ〜、まったく！」とうんざりするようなレガシーコードを何度も見てきました。
そうした職場では本書に書かれているプラクティスがほとんど実践されていませんでした。

このことから何が言えるのか？

これはつまり、「本書に書かれている内容は圧倒的に正しい」ということです。

本書で紹介されている9つのプラクティスを実践していけば、確実にレガシーコードから脱却できます。
これは僕自身の経験と照らし合わせて断言することができます。

では、どうやって実践するのか？（要検討）

本書に書かれている内容が正しいことはわかりました。
でも、もしこのブログを読んでいるみなさんが、「今の職場では全然実践できていない！なんとかしたい！」と思ったときはどうすればいいのでしょうか？

残念ながら、その答えは本書には載っていません。（もし僕が見落としているだけだったらすいません💧）

僕もSIerで働いていた経験があるので予想が付くのですが、「ウォーターフォール型かつ、多重下請けかつ、納品型の受託開発」をやっていたりすると、ビジネスモデル上の制約や会社の力関係等があるために、こうしたプラクティスを一（いち）開発者の意見で導入するのはほぼ不可能だと思います。

また、そうした開発スタイルではなくても、同僚にあまり向上心がなかったり、上司がまったく理解してくれなかったりすると、自分のやる気だけが空回りして疲弊することもよくあります。（こちらも経験あり）

じゃあ、僕自身はどうしたのかというと、今の職場を変えることは諦めて転職しました。
その転職先が今僕が働いているソニックガーデンです。
前述の通り、ソニックガーデンに入ってからは本書に書かれているような理想的な環境を手に入れることができたので、僕にとっては「転職する」という選択肢は正解だったと思います。

では、みなさんだったらどうしますか？
これはみなさん自身の宿題なので、自分の頭でよ〜く考えてみてください。

「9つのプラクティス」は転職活動するときにも役立つかもしれない

もしあなたがよりよい環境を求めて転職しようと思った場合は、本書の「9つのプラクティス」が役に立つかもしれません。
なぜなら、面接官から「何か質問はありませんか？」と聞かれたときに、9つのプラクティスで書かれていることをベースに「◯◯はどうされていますか？」とか「◯◯は実践されていますか？」と尋ねれば、その現場のレガシーコード具合が予測できそうだからです。

これから転職しようとしている方は、本書を読んで質問リストをあらかじめ作っておきましょう👍

その他の感想：翻訳が非常に読みやすい！（重要）

本書の内容とは直接関係がありませんが、本書を読んでいる最中、僕は翻訳が非常に読みやすいところに密かに感銘を受けていました。

訳書ってたまに翻訳がめちゃくちゃ読みづらいことがあるんですよね。
過去に読んだ訳書の中には、いくら翻訳を読んでも内容が頭に入ってこないので、「もはや原著を買って英語で読んだ方が良いのでは？」と思ったものもあります。

その一方で、僕自身が英語の技術書を日本語訳したことがあります。
（「Everyday Rails - RSpecによるRailsテスト入門」という電子書籍です ↓ ）
leanpub.com

実際に翻訳をやってみると、これがめちゃくちゃ難しいんですよね〜。
英文の構造や言い回しって、日本語と大きく異なる部分が多々あるので、素直に翻訳すればするほど「読みにくい日本語」が量産されていくんです。
Everyday Railsの翻訳をするときも「翻訳臭」を消すのにすごく苦労しました。

そういった「読む側」と「翻訳する側」の両方の経験がある僕からすると、本書「レガシーコードからの脱却」の翻訳は非常に高レベルだと思います。
訳書臭がまったくしないので、すらすら読むことができました。

なので、本書を読むときはそういった翻訳の自然さ、滑らかさにも注目して読んでみてください！

まとめ

というわけで、このエントリでは書籍「レガシーコードからの脱却」の書評を書いてみました。
本書の感想は次のように大きく２つに分かれると思います。

まず、僕のように、本書を読んで「あまり新しいことが載ってないなー」と思ったそこのあなた！
あなたはきっと幸せな環境で開発ができている人です。（良かったですね😄）

反対に「へー、こんなやり方があるのか」とか「これは実践できてないな」と思ったそこのあなた！
あなたは今から何かアクションを起こすときなのかもしれません。

自分が置かれている状況を判定する「リトマス紙」として、ぜひ「レガシーコードからの脱却」を読んでみてください。

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

あわせて読みたい

我田引水になってしまいますが、弊社ソニックガーデンの働き方を紹介した本がいくつか発売されています。
ソニックガーデンは受託開発をやっているのに、なぜレガシーコードが生まれないのか？
その答えを知りたい方はこちらの書籍も読んでみてください。

ザッソウ 結果を出すチームの習慣 ホウレンソウに代わる「雑談+相談」

管理ゼロで成果はあがる ~「見直す・なくす・やめる」で組織を変えよう

リモートチームでうまくいく

「納品」をなくせばうまくいく