こんにちは。谷口です。
先日、オライリー社から『レガシーコードからの脱却――ソフトウェアの寿命を延ばし価値を高める9つのプラクティス』が発売されましたね。
弊社でもすぐ購入し、読みまくり、「これはリーダブルコードのように次世代のエンジニアのバイブルになる予感…」と言っているエンジニアもいたので、今回は本書の概要紹介と感想について書きたいと思います。
私の本書はすでに画像の通りふせん貼りすぎ下線ひきすぎ読みすぎでボロボロです。
レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
- 作者:David Scott Bernstein
- 発売日: 2019/09/19
- メディア: 単行本(ソフトカバー)
概要について
本書はどんな内容の書籍なのか、まずオライリー社公式サイトにはこう書かれています。
本書では、ソフトウェア開発において、初めからレガシーコードを作りださないためのプラクティスを9つ挙げて解説します。プロダクトオーナーは目的を語り、やり方は開発者に任せること、小さなバッチで開発を進めること、継続的に統合すること、チームメンバーで協力することなど、日々の開発に取り入れる考え方と具体的な実践について各章で分かりやすく解説します。
エンジニアの方であれば、特定のパターンしか考慮されていなくて機能追加がしづらいとか、動いてはいるけど書き方が冗長になっていて修正するには膨大な時間がかかるとか、バグが含まれているとか…なんらかのレガシーコードに悩まされた経験は少なからずあると思います。(なお、本書ではレガシーコードとは「理由はなんであれ修正、拡張、作業が非常に難しいコード」と定義されています)
なぜそのようなレガシーコードに悩まされ、貴重な時間を既存のコード解析や修正に当てなければならないのでしょうか。
そもそも自分たちの組織に「レガシーコードは作らない」というルールが浸透していれば、そんな目にあわずに済んだ(もしくはもっと短時間の対応で済んだ)はずなのに…。
本書では、そんなレガシーコードを作り出さないための9つのプラクティスについて解説されています。
プラクティス1 やり方より先に目的、理由、誰のためかを伝える
プラクティス2 小さなバッチで作る
プラクティス3 継続的に統合する
プラクティス4 協力しあう
プラクティス5 「CLEAN」コードを作る
プラクティス6 まずテストを書く
プラクティス7 テストでふるまいを明示する
プラクティス8 設計は最後に行う
プラクティス9 レガシーコードをリファクタリングする
この9つのプラクティスももちろんすばらしいのですが、実際に読んでみて、私はプラクティスの解説に入るまでの「第I部 レガシーコード危機」がかなりよいと感じました。
第I部ではプラクティスの紹介に入る前に、ソフトウェア業界や従来のソフトウェア開発手法が直面している問題(≒レガシーコードが生まれてしまう背景)について、かなりわかりやすく書かれています。
もう少し具体的に言うと、「そもそもレガシーコードがなぜ生まれてしまうのか、その背景に何があるのか、なぜウォーターフォールの開発プロジェクトは計画通りに進まずに失敗するのか…」などといった話ですね。これ、たぶん開発者にとっては当たり前の話ばかりなのですが、マネジャーの人やこれから開発者を目指す人、あと時間がなくて全部読めない人は、まず第I部を読んでみてほしいと思います。
読んだほうがいい人について
対象読者については、冒頭で「本書は、以下の5種類の読者がソフトウェア開発についての共通理解を得られるように設計されている」とした上で、
- ソフトウェア開発者
- ソフトウェア開発とITのマネージャー
- ソフトウェア関係者
- さまざまな業界のプロダクトマネージャー、プロジェクトマネージャー
- この欠くことのできない技術に興味を持つ人すべて
の5種類があげられています。
私は中でも最初の二者、まぁ「ソフトウェア開発者」は当然として、同じくらいかそれ以上、「ソフトウェア開発とITのマネージャー」に本書を読んでもらいたいと感じました。
「レガシーコードを作らないプラクティス」と言われると、一見開発者向けのテクニック的な書籍で、マネジャーには特に関係ないように思えますが、マネジャーにこそ読んでもらいたい。(大事なことだから2回言いました)
なぜなら、レガシーコードが生まれ、エンジニアの作業時間がコーディング以外の修正や解析に圧迫され、プロジェクトが計画通りに進まない背景には、そもそものソフトウェア開発業界が抱えているリスクや、従来のウォーターフォールプロセス、プロジェクトのマネジメント方法などの問題があるからです。それを理解し、正しく改善していかないことには、いつまでたってもレガシーコードは増え続け、それによってエンジニアの無駄な仕事も増え続け、プロジェクトは遅れ続けてしまいます。だからマネジャーにこそ読んでもらいたいのです。(3回目)
もちろん、実際に開発をするエンジニアの方に学びや共感できるポイントはかなりあるかと思います。
9つのプラクティスについて、すべて当たり前に実践できている現場もあれば、まったくひとつも実践できないまま、今でもレガシーコードを生み出し続けている現場もあるでしょう。
だから、読んだ人によっては「当たり前のプラクティスばかりで全然勉強にならなかった」と思ったり、逆に「レガシーコードが生まれる背景のような環境が当たり前だと思っていた、なんて画期的な本なんだ」と思ったり、感想は全然異なると思います。
ただ、おそらく大半の人は「共感できるし実践できているプラクティスもいくつかあるけど、できていないプラクティスもいくつかある」といったところではないでしょうか。
チームによっては、いきなり本書のプラクティスすべてを取り入れるのは難しいかもしれません。ただ、チーム内で「現状何が問題なのか、すぐには無理でも何をすれば解決に近づけるか」といった共通認識が持てるだけでもだいぶ違うと思いますから、まずはそのために本書をチーム内の課題図書にしてしまうのがよいかと思います(?)。
また、私は本書をおすすめしたい人に
- ソフトウェア開発者を目指している人
も追加したいと思います。
プラクティス後半になってくると実務的な話も増えてきますが、前半はエンジニアを目指す人(具体的に言うとこれから就活を始める学生の方や、周辺領域や異業種から転職を目指している方)が、ソフトウェア開発業界について知り、理解をする手助けにもなるはずです。
まとめ
というわけで、本書で紹介されている9つのプラクティスが、どこでも当たり前に実践されている(=レガシーコードがこれ以上増えない)世の中になってほしいと思いますし、そのためには多くの人に本書を読んでほしいという思いで、この記事を書きました。
本当に、現役のエンジニアの方はもちろん、マネジャーの方や、これからそれらの職種につこうとしている方々にも読んでいただきたい一冊です。
最後に、本書の好きな部分(たくさんあるのでほんの一部ですが…)をいくつか引用して終わります。
ソフトウェア開発にはリスクがある。うまくいくことはめったになく、書いた瞬間から時代遅れになる。
(p.17)
レガシーコードがさまざまな方法で生み出された理由は、コードの品質は重要ではなくソフトウェアが何をするかだけが重要だと考えてしまったことにある。
だが、この認識は間違いだった。実際に使われているソフトウェアは変更が必要になる。つまり、ソフトウェアは変更可能なように書かれていなければいけない。
(p.48)
必要な変更をすべて予測するよりも、必要となったときに対応できるエンジニアリングプラクティスを身につけたほうがよい
(p.60)
ソフトウェアがどう作られるかよりも何をすべきかに注目することによって、開発者は自由に最良の実装を発見できる
(p.78)
技術的負債以上に、開発を遅くし見積もりを狂わせるものはほかにない。
(p.155)
コードは書き手(自分自身)のためではなく、読み手(ほかの人たち)のために書くのだ。ソフトウェア開発は「1回書いたら終わり」の作業ではない。ソフトウェア開発は「何回も書き直す」職業で、コードは継続的に拡張され、クリーニングされ、改善される。
(p.210)
レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
- 作者:David Scott Bernstein
- 発売日: 2019/09/19
- メディア: 単行本(ソフトカバー)
「paizaラーニング」では、未経験者でもブラウザさえあれば、今すぐプログラミングの基礎が動画で学べるレッスンを多数公開しております。
詳しくはこちら
そしてpaizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。
スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。
詳しくはこちら