変更可能なコードを書こう /「レガシーコードからの脱却」を読んだ

9月に発売された「レガシーコードからの脱却」を読んだ．本書はサブタイトルに「ソフトウェアの寿命を延ばし価値を高める9つのプラクティス」と書いてある通り，変更可能なコードを書くための「原則とプラクティス」に対する理解を深めることを目的にして書かれている．よって，意図的に抽象度は高くなっていると思う．実際に読んで，そう感じた．

原著の著者 David Scott Bernstein は IBM などでソフトウェアエンジニアのトレーニングを担当されてきた方で，そのエピソードも本書に多く出てくる．そして「認定スクラムデベロッパー研修」の講師で来日されることもあるらしく，気になる！来年研修を受講する予定なので，開催予定を調べてみようと思う．

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

目次

• 第I部 : レガシーコード危機
  • 1章 : 何かが間違っている
  • 2章 : CHAOSレポート再考
  • 3章 : 賢人による新しいアイデア
• 第II部 : ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 4章 : 9つのプラクティス
  • 5章 : プラクティス 1 : やり方より先に目的、理由、誰のためかを伝える
  • 6章 : プラクティス 2 : 小さなバッチで作る
  • 7章 : プラクティス 3 : 継続的に統合する
  • 8章 : プラクティス 4 : 協力しあう
  • 9章 : プラクティス 5 : 「CLEAN」コードを作る
  • 10章 : プラクティス 6 : まずテストを書く
  • 11章 : プラクティス 7 : テストでふるまいを明示する
  • 12章 : プラクティス 8 : 設計は最後に行う
  • 13章 : プラクティス 9 : レガシーコードをリファクタリングする
  • 14章 : レガシーコードからの学び

既に正誤表も公開されている．読んでいて気付いた誤植はほとんど載っていた．あと1箇所気付いたので，記事の最後にメモ程度に残しておく．

www.oreilly.co.jp

9つのプラクティス

本書の軸は，当然ながら「9つのプラクティス」だけど，Extreme Programming (XP) を中心に以下のように構成されている．

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

そして本書に載っている読者層は以下の5種類で，僕自身は当てはまる．ただし，過去の開発経験と今まで読んだ関連書籍の知識もあり，本書の内容で既知に感じる箇所も多かったので，新しく得られた知識は少なかったように思う．ただし，改めて理解を整理できたという側面でメリットを感じた．

• ソフトウェア開発者
• ソフトウェア開発と IT のマネージャー
• ソフトウェアの利害関係者
• さまざまな業界のプロダクトマネージャー，プロジェクトマネージャー
• この欠くことのできない技術に興味を持つ人すべて

今回の書評記事では，個人的に本書を読んで印象に残った「プラクティス」を紹介しようと思う．

完了の完了の完了

「プラクティス 3 : 継続的に統合する」では，コードを書くたびに統合することの大切さを学べる．例えば「継続的インテグレーション」や「継続的デリバリー」など，よく知られたプラクティスの軸になる考え方となる．この「統合された状態」を表現する言葉として「完了の完了の完了」と書かれていて，センスの良さに驚いた．確かに「ローカル環境でビルドができた状態」で「完了」と表現する人も過去にいたし，今後も積極的に「完了の完了の完了」という表現を使おうと思う．

ブランチを避ける

「プラクティス 3 : 継続的に統合する」に載っている「リスクを減らす7つの戦略」の中に「ブランチを避ける」という内容もある．統合されるまでリスクに気付けないので，ブランチを使わずにフィーチャーフラグを使うと書いてあり，まさに先週あたりから議論が巻き起こっていた話題に関連している．

irof.hateblo.jp

スパイク

「プラクティス 4 : 協力しあう」では，質の高いコミュニケーションを作り上げるために協力し合う（協働する）ことの大切さを学べる．ペアプログラミングをしたり，モブプログラミング（モブワーク）をしたり，個人的にも強く意識して実践と推進をしているスタイルなので，共感できる点ばかりだった．

そして「スパイク」という用語は今まで使ったことがなく，新鮮だった．簡単に表現すると「未知の課題に対して技術的な調査などを行うこと」と表現できる．実は書籍「アジャイルコーチング」にも「スパイク」が出てくるので，界隈ではよく知られた用語なのかもしれない．

アジャイルコーチング

カンファレンスをすっ飛ばす

さらに「プラクティス 4 : 協力しあう」の中に「知識を広げる」というテーマもあり，そこに「カンファレンスに行ったら，カンファレンスをすっ飛ばし，友達を探してペアリングするべし」という面白いテクニックが紹介されている．確かに「カンファレンスに行ったら廊下で話すべし」という話もあるし，著者の素晴らしい体験談から学べるのも本書の魅力かなと思う．今年はほとんどカンファレンスに行ってなく，久し振りに行ってペアリングしたいぞ！

誤植

10.6「テスト可能なコードを書く」の最後に以下の文章があり，文脈的には「トレーニング "で" 教えたり」だと思う．

ブログを書いたりトレーニングを教えたりするには、十分な休憩と大量のカフェインが必要だ。

まとめ

タイトルに惹かれて「レガシーコードからの脱却」を読んだ．最初からレガシーコードを作り出さないように「どんなマインドセットを持っておくべきなのか」という原則とプラクティスを学ぶことができる．黙々と読むよりも，チームで輪読をして，ディスカッションを組み合わせるとより効果が高そうな書籍だと思う．個人的には今まで読んだ関連書籍の知識もあり，書評にまとめたプラクティスに偏りはあるけど，それでも理解を整理できたという側面でメリットを感じた．

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