【感想】『レガシーコードからの脱却』：既存のやり方を越えたその先の探求

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

　コロナウィルス騒動でIT系イベントの中止が相次ぐ最近ですが、技術書の感想エントリです。「ITエンジニア本大賞 2020」の技術書部門大賞も受賞した2019年9月刊行の本。名著の予感がしていたのでAWS認定に受かってから読むことにして、楽しみに取っておいてありました。

　文脈によって「テストコードのないコード」などの意味で使われることもある「レガシーコード」ですが、本書では「修正や拡張、作業が難しいコード」と定義しています。
一見するとレガシコードを避けるためのプログラミングテクニックに焦点を当てた本にも思えますが、帯に「レガシーコードを初めから作らない」とあるように焦点はプロセス。レガシーコードを生み出さないような開発形態、手法、エンジニアとしての在り方などを総合的に述べた本となっています。

www.oreilly.co.jp

　メインはレガシーコードをビヨンドしていくための９つのプラクティス。認知心理学における短期記憶の容量、いわゆる「マジカルナンバー」の7±2が当てはまりますが、より詳細に論じた内部にもあちこちに「～ための7つの戦略」といった具合に幾つかのポイントに分けて述べています。
　翻訳も自然で読みやすいです。テスト駆動開発の実例で簡単なJavaのクラス例は出てきますが他に直接のコードはなし。開発言語や技術に依存せず、日本語の文章でじっくり読むことができます。各章の最後にもふりかえりがついていて、獲得した知識を整理しながら読み進めていけます。

　序盤は実際の数字を出して、本書が出た2010年代のアメリカにおいても今もなお失敗するソフトウェア開発プロジェクトは多く、何百億ドルレベルの損害が出ていることを説明。
登場から15年経って広まった(であろう)アジャイル開発のアプローチ、オブジェクト指向や単一責務原則、技術的卓越性を活かし、変化に対応しやすいソフトウェア開発をしてレガシーコードを越えていく事が重要だ…と、メインの9つのプラクティスの話に続いていきます。

1. やり方より先に目的、理由、誰のためかを伝える

　どう作るかはエンジニアに任せて細かい指示はせず、それよりもっと対話してなぜそれを作るのか明らかにしてうまくやっていこうという話。そもそも作る理由を伝えて細部は権限委譲して任せる、というのはエンジニアのモチベーション維持にも同感です。
　後半にはプロダクトオーナー向けの戦略があったり、ストーリーベースで語ろう…などと出てくる単語も本格的にアジャイル開発が前提になっています。伝統のウォーターフォール開発やエンプラ系開発だと適用しづらいかもしれません。

　自分の周りを振り返ると…エンプラ開発なので毛色は違いますが、僕は設計にも実装にも関わるけど自分やマネージャーがチームメンバに説明する時は根本的な目的は伝えるし、何なのか分からない巨大なものを盲目的に延々と作り続けるようなダメなシーンはないですね。

2. 小さなバッチで作る

　えっDBの中身を定期的に更新する夜間バッチ処理とかクラウド上のサーバーレスアーキテクチャでの小さなプログラム処理の話ですか…と一瞬思ってしまいましたがここでのバッチはそういう話ではなくて、作るものを小さく切り分けて少しづつ作っていく。
　小さい単位ほど予測もできるしリスクもわかるし見積もれるし良いという話。複雑さを分解することで対処するという設計原則と関連して、分割統治法の話も出てきます。カンバンの話も出てきて明確にアジャイルベースです。

　僕たちもタスクを細分化してWBSに並べて並行で進めたり、機能ごとに別々に設計や実装やテストを進めたり、共通化できるところは独立して最初に仕組みを作ってしまってお膳立てをしてから全体を進めたりもします。このへんがソフトウェアアーキテクトの工夫のしどころですが、明確なアジャイル開発でなくても分割による対応はしている感じ。

3. 継続的に統合する

　知っている方や実践している方にはおなじみCI/CD、Continuous Integration/Continuous Delivery 関連の話。
とにかくコード全体はすぐ統合して自動ビルド、なるべく短い時間でデプロイ、すぐ状況が分かるようにせよ。開発者が各自でバラバラに開発して最後の最後で繋げたら案の定大問題…みたいなウォーターフォール的な旧来のやりかたはやめようと論じています。
　個々の開発者の開発環境で動くのを「完了」、バージョン管理と統合に含まれて正常に動くのを「完了の完了」、さらにそこに後から修正を加えても常にクリーンで保守可能な状態を「完了の完了の完了」と名付けてこの3段階目が必要だ…と述べているのは面白いですね。技術スタックでJavaや.NETが出てきて、2015年の本ですが著者の方の世代的にもこのへんがベースなのだなと思います。

　僕も規模が大きいプロジェクトではJenkinsを使って定期的に自動ビルドが反映される環境でやったりしたことはあるし、そこまで行かなくても複数人が触れる評価用の環境を作ったりはよくしています。
その一方で完全なCI/CDが整備された環境での継続的な開発はやれていないので、AWSならCodeBuildなどそののへんの仕組みを使って一度試してみたいところです。このへん自社サービス開発でないと完全な適用は難しいんじゃないかなあと思う時もあります。

4. 協力しあう

　もうレガシーコードはほとんど関係なく、最大の価値であるお互いを重視し、対話して助け合ってチームでうまくやっていこうという話。著者の方がかつてIBMの契約社員で開発していたころ、プロジェクトルームに放り込まれていたがチームとの対話が密な環境が活かせて、おそらく個室や区切りのあるオフィスなのであろうIBMのエライ人達より良い結果が出せた…なんて間接的にビッグ・ブルーをdisっている逸話にニヤリとします。ペアプログラミング、モブプログラミングの話もかなり取り上げています。
　日本ではあまり聞かない単語ですが、1日にちょっとの時間だけペアでやる「バディプログラミング」、問題解決のために一時的に複数人でチームを組んで対処する「スパイク」「スウォーム」なども紹介されています。
　節のタイトルにある

常にメンター、メンティであれ

の名言が熱い。常に学び続ける姿勢を持とうという話ですが、エンジニアとしていつもかくありたいものです。

　2020年のエンジニア向けイベントDeveloper Summitのテーマも「ともにつくる」、東京五輪のスローガンも「United by Emotion」でした。エンプラ界隈のお固い会社の資料にもよく「共創」なんてワードは出てきます。助け合い学び合いながらやっていくというのはもうアジャイル関係なく大事だと思っていますが、2020年代はより重視されていくのかなと思っています。

　自分は普段の開発では協力し合うのは実践できていると思いますが、本章のプラクティスにあるペアプロやモブプロは本格的にやったことがないですね。複数プロジェクトに携わることが多かったり、そもそも社員にがっつりプログラミングできる人の割合が多くないというのはエンプラ系企業の悩みどころです。

5. 「CLEAN」コードを作る

　他の名著でもよく語られる、より良いコード設計の話。C)ohesive, L)oosely Coupled, E)ncapsulated, A)ssertive, N)onredundant でCLEAN。
それぞれ凝縮性が高い、疎結合である、カプセル化されている、断定的で目的がわかりやすい、冗長でない。

　若干無理やり揃えた感もあるし日本人からすると馴染みの薄い単語もありますが、良いコードが品質を保ちレガシーコードを避けるのだということで本質的なところを解説しています。このへんのテーマを扱った本は他にもいくつかありますが、概要ということでも学びになるでしょう。
CLEANなコードを目指すためには最初から完璧を目指さずに後から改善したりリファクタリングしながらやっていく、レビューする、お互いに学び合う、継続的に学んでいく…などのテクニックが述べられています。

　自分は…もうコードレビューする側でプロジェクト全体を支える立場なので、完璧にCLEANではないですがそれなりのものは書けるところまでは成長してきたかなというところ。

6. まずテストを書く

　章タイトルから分かるようにテストファーストな開発、テスト駆動開発(TDD: Test Driven Development)の入門的な章。その高い効果を述べる一方で万能ではないこと、ときには失敗することも書いてあって、アメリカでも完全には受け入れられていないのかなと思ったりします。

　僕もJavaのJUnitが脚光を浴びた頃はがっつり使ったしNUnitやPHPUnitも触ったりはしましたが、完全なTDDは実践できていなくてこういう話を見聞きする度にむむむとなります。テストの工数にテストクラスの分が入っていないことがほとんどだったり、プロジェクトの特性次第というところもあります。ソフトウェアの一部分に重点的に使うと効果が高い時もあるし、もっと活用していかねば。

7. テストでふるまいを明示する

　伝統的なJavaのクラスを例に取ったJUnitによるテストクラスの作成、テストファースト開発の実例。題材になっているのはメンバ変数に名前と年齢を持ったPersonというクラスで、コンストラクタをコールしてインスタンスを生成した時に与えられた年齢にチェックが走り例外もスロー、というかなりシンプルなもの。Javaを使っていない方にも雰囲気でだいたい分かると思います。テスト、バグ修正の戦略についても語られています。

　この章はJUnitに入門した頃を思い出すような、いつもどおりの懐かしい感じでした。

8. 設計は最後に行う

　ノー設計でプログラミング？それってスタートアップ企業なんかでありそうな速度最優先の開発で落ち着いた後で技術的負債が溜まって後悔するやつでは…と思ったらそんなことはなく、テストで現在のコードを保護した後の継続的な修正や、本格的なリファクタリングに繋がる改善を行っていく話でした。
　節のタイトルにある

ソフトウェアは書かれる回数より読まれる回数の方が多い

なんてのはまったくその通りですね。変更容易性や保守性を高めるための様々な工夫が述べられています。どこの現場でも役立つところでしょう。

　自分を省みると、自分以外の誰かがいつか触って保守することを考えていつもコードは構築しているしコメントも丁寧めに書いているし、どのプロジェクトでもレビュー後にコードをより良く直していくことは多いし、実践できているかなというところ。
　一方でずっと長く続いている古い基幹システムの保守開発なんかで、コードを1行変えるだけですごく大変だった…なんて話は伝聞で時々見聞きします。このへんはSIerやエンプラ開発の悪しき伝統なんですがこういう本を読んで変わっていって欲しいものです。

9. レガシーコードをリファクタリングする

　プラクティス8の流れを受けて、具体的なリファクタリングを説明した章。冒頭にオフィスでより上位職の人にリファクタリングの価値を説明するときの話が出てきて、アメリカでもこういうシーンってあるのだなと思います。
詳細は名著『リファクタリング』がありますが入門的な形で、リファクタの価値ややり方、コツなどを説明しています。具体的なテクニックも幾つか上げられている中にやはり「依存性の注入」があり、Javaの定番FWのSpring Frameworkがちらりと名前を見せています。最後にある、いつリファクタリングを行うかの7つの戦略も役立つことでしょう。

　自分を省みるとリファクタリングは最近のプロジェクトでも品質維持のためにがっつりやったし、このへんも実践できているところ。しかしリファクタリングが行えるぐらいの技量がある人があまり多くないしなかなか増えないのが、エンプラ開発の現場の悩みどころです。

最後の章：レガシーコードからの学び

　ソフトウェア開発の未来は明るいが今はまだ暗い...！と最後に熱く語りかけるエモい章。本書は開発手法は完全にアジャイルを推しているのですが、著者の方の考えではアジャイルやスクラムはマネジメントに寄ってしまったので技術的なプラクティスこそがレガシーコードを越えて大事だ、成長する勇気を持ってソフトウェア開発者はもっともっとスキルを伸ばしていこう…という感じのことを述べています。
　本全体がアジャイル前提でありながらもツールとして捉えており、一節ではアジャイルより良いものが現れたら飛びつくつもりだと語っています。
　一番最後にある

問題解決にはさまざまな方法があるというのが、私が学んできたことだ。人が問題のことを考え解決する方法はそれぞれだ。人間が持つ考え方の幅広さは驚くべきものだ。どの方法が正しいのだろう？
すべてだ！

　がアツい。ソフトウェア開発の有名な格言「銀の弾丸はない (No Silver Bullet)」と通じるものを感じます。

　僕も単にコードを書く以上のスキルを伸ばそうと、設計やアーキテクティングの本やWebの情報など色々巡ってきました。そこで得られたひとつの真理は、唯一絶対の正解というものはなくてその場その場で違うものであり、試行錯誤したり成功したり失敗したり人から学び合ったりして経験を貯めていくしかないんだなということ。
　やはり学び続け、探求し続けることに意味があるんだなと本書を通しても感じました。

まとめ：2020年代を生きるエンジニア向けの名著がまた1冊

　原題はBeyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software。
　ビヨンドなので「～からの脱却」もいいですが「～を越えて」という感もあります。大きなレガシーの問題がそびえたつ古い山や峠や丘を越えてその先の新しい景色、新しい地平へ、より良い段階を目指して次の旅路を始めよう、さあ終わらないジャーニーへ……みたいなニュアンスでしょうか。

　僕は商業本や技術同人誌を読んだ後よく各所の感想を巡ったりするのですが、Twitterやブログを巡っていると開発経験の豊富な方、より良い開発手法の実践や探求をしている方ほど、本書に「どこかで見たような内容が多かった(けれども正しいし役に立つ！)」という感じの感想を持っているような気がします。
　それもそのはず、プログラム言語や技術やパラダイムやトレンドは定期的に移り変わりますが、本書はそうした表層に影響されない本質、ソフトウェア開発の根本的なところを語っているからでしょう。
原著は2015年、日本語版翻訳が2019年ですがこの先2020年代もしばらくずっと使える、エンジニア向けバイブルの一冊的な名著として役立つと思います。思想は完全にアジャイル寄りですが、ウォーターフォール寄りの開発をしている方にも気づきがあるでしょう。

　また海外産の本で重要なところとして翻訳があるのですが、自然な日本語に訳されていてかなり読みやすいです。本の厚さも手頃なので、鈍器になるぐらい物理的に分厚い本には抵抗がある方も手を出しやすいかと思います。本書で基本を知った後、テスト駆動開発やリファクタリング、ペアプロなどなど他の本に進んでいくのも良いと思います。

　本エントリでもいくつか上げていますが、本書の中にも名言が多数収録されています。輪読会やイベントやエンジニア飲み会のテーマにしたら盛り上がりそうな勢いです。各所の感想エントリを拝見すると皆さんけっこう別のところを引用していて、やはり人それぞれ刺さるところが違うんだなと思います。

　本書で論じられている９つのプラクティスの実践度合いも、読者それぞれ、開発現場やチームやプロジェクトや所属企業や文化によってもそれぞれ違うでしょう。自分の場合はどうだろうかと問いかけになることにも価値があると思います。自分の持っている開発技術や手法、思想や姿勢などの知識や定期的なアップデートにもなります。

　ソフトウェア開発に携わるエンジニアとして駆け出しから中堅へスキルアップしたい方にもベテランにも、プロジェクトマネージャーやプロダクトマネージャーなど管理する側の方、プロダクトオーナーとか管理職で職位が上の方の全体を俯瞰する立場の方、開発チームをサポートする立場の方、これからエンジニアを目指す方、様々な立場の方にオススメです。
　それぞれの職種や熟練度や世代によって感じる所、示唆を得る所が違うであろうということにも本書の価値があるでしょう。名著の中の一冊に入る間違いなしの本です。

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

作者:David Scott Bernstein
発売日: 2019/09/19
メディア: 単行本（ソフトカバー）

関連書籍

　本書で紹介されていたり、テーマが似ていたりよく同じ文脈で語られそうな本、時が経っても色褪せない名著などを上げてみます。以下「本書」とは『レガシーコードからの脱却』のほうを指します。

『レガシーコード改善ガイド』

　こちらは本書を手に取った時に最初に連想するように、レガシーな「コード」そのものをどう直していくかを徹底的に論じた本。テストで保護して小さい範囲で直していく……という根本のあたりは本書と思想は同じですが、実際の改善のテクニックが多数載っています。新規開発でも既存コードの保守でも学びになる本です。読んだときに感想を書きました。

iwasiman.hatenablog.com iwasiman.hatenablog.com

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

作者:マイケル・C・フェザーズ
発売日: 2009/07/14
メディア: 大型本

『レガシーソフトウェア改善ガイド』

　まだ読めていないのですが、こちらは開発環境の自動化やCI/CDなど、レガシーコードを取り巻く周辺の環境の話も交えた本。表紙のデザインが上の本と似ているのでちょっと注意です。

レガシーソフトウェア改善ガイド (Object Oriented Selection)

作者:クリス・バーチャル
発売日: 2016/11/11
メディア: 単行本（ソフトカバー）

『Code Complete』

　本書に直接参考文献としては上がっていませんが、かなり共通すると思われる名著。上下巻で鈍器になるぐらい分厚い本ですがコードを書いて開発することについて様々な要素を漏れなくコンプリートした有名な本。変数の命名や関数、クラス、バグの探し方や休憩の仕方まで、リファクタリングの話なども出てきます。
　前に仕事で日帰り出張が多かった時期に電子版で車内で読破したのですが、一通り通して読むとめちゃくちゃ学びになりました。

iwasiman.hatenablog.com

CODE COMPLETE 第2版上完全なプログラミングを目指して

作者:スティーブマコネル
発売日: 2005/03/26
メディア: 単行本

CODE COMPLETE 第2版下完全なプログラミングを目指して

作者:スティーブマコネル
発売日: 2005/03/26
メディア: 単行本

『Clean Code アジャイルソフトウェア達人の技』

　こちらも分厚い本ですが、よく名が上がります。プラクティス5のCLEANなコードはこれになぞらえたのかなと。

Clean Code アジャイルソフトウェア達人の技

作者:Robert C.Martin
発売日: 2017/12/18
メディア: 単行本

プログラマとしてのありかたを論じた『Clean Coder プロフェショナルプログラマへの道』は前に読みました。語調がフランクで面白い。

Clean Coder プロフェッショナルプログラマへの道

作者:Robert C.Martin
発売日: 2018/07/27
メディア: 単行本

『テスト駆動開発』

　日本だと@t_wadaさんのサバンナAAで有名なこの本。

テスト駆動開発

作者:Kent Beck
発売日: 2017/10/14
メディア: 単行本（ソフトカバー）

『新装版リファクタリング―既存のコードを安全に改善する』

　レガシーコードをよりよくしていく中のリファクタリングについて、深く学ぶならこちら。マーチン・ファウラー大先生の有名な本です。
　僕は2000年代にJavaエンジニアの駆け出し→中堅へステップを駆け上がっていく中で新装版でない古い方を読みました。内容が当時の自分にはまだまだ難しかった記憶がありますが、これも大きな学びになりました。

新装版　リファクタリング　既存のコードを安全に改善する

作者:ＭａｒｔｉｎＦｏｗｌｅｒ
発売日: 2017/07/15
メディア: Kindle版

　なんと第2版の翻訳が2019年に出て、こちらは採用言語がJavaScriptなんですね。今年のどこかで震えながら読もうと思っています。本書の感想でそういえば積読になってるリファクタリング第2版も読もう……なんてのがちらほらあって、本書を読むような方は皆さん同じこと思うんだなあと思ったり。

リファクタリング(第2版): 既存のコードを安全に改善する (OBJECT TECHNOLOGY SERIES)

作者:Fowler,Martin
発売日: 2019/12/01
メディア: 単行本

『達人プログラマー』『情熱プログラマー』

　エンジニアとしての思想やありかた、開発に取り組む姿勢なども含めて総合的に述べた名著。本書が主眼にしているプロセス回りの話題も入っていたかと思います。エンジニアにはこれらの本をお気に入りに上げる方がよくおられますね。僕も好きです。

新装版達人プログラマー職人から名匠への道

作者:Andrew Hunt,David Thomas
発売日: 2016/10/20
メディア: 単行本（ソフトカバー）

情熱プログラマーソフトウェア開発者の幸せな生き方

作者:Chad Fowler
発売日: 2010/02/26
メディア: 単行本（ソフトカバー）

『リーダブルコード』『良いコードを書く技術』

　そもそもまともに動くコードを書くこと自体をもっとうまくやれるようになりたい方には、この手の話題で頻出ですが約束のこれらの本があります。
『リーダブルコード』は名著なんですが2012年に出た頃はネットであまりに紹介されまくって、リーダブルコードをオススメする中身の超薄い記事→アフィブログ/ステマブログ認定、みたいな流れもありました。『良いコードを書く技術』はリーダブルコードの下位互換みたいな扱いをされることがあってちょっと可哀そう。