レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
- オライリージャパン (2019年9月19日発売)
- Amazon.co.jp ・本 (300ページ)
- / ISBN・EAN: 9784873118864
作品紹介・あらすじ
より良いソフトウェアを作り出すための考え方、テクニック、スキルを詳述!
保守性の高いソフトウェアを構築する上で、リファクタリングやテストファースト開発などの技術的な実践がなぜ重要なのかについて具体的なアドバイスと一緒に解説します。
感想・レビュー・書評
-
リファクタリングに関する書籍かと思いきや、ソフトウェア開発者かくあるべし、まで取り扱う
業界歴30年の筆者による、より良いソフトウェア開発者になるための指南書 とても学びが多かった
引用や抜粋はこちらからどうぞ
https://chuckwebtips.hatenablog.com/entry/2020/04/19/101726詳細をみるコメント0件をすべて表示 -
多くの気づきを得られた本。
基本的にはアジャイル手法をお勧めしているが
心に響く文がいくつも記載されていた。
1.1 レガシーコードとは何か
→未経験のことをやるのに必要な時間、コスト、プロセスを
見積もることがどれほど難しいか、そしてソフトウェアエンジニアリングが
ほかのエンジニアリングとどのように異なるのか
→テストのないコードをレガシーコードと定義
優れた自動ユニットテストに高い価値を置いている
1.2 ウォータフォールに流される
→ウォータフォールモデルは橋の建設や部品の製造では理にかなっている。
機能の要求をリリース単位でまとめたほうが効率的だからだ。だが、
ソフトウェア開発は製造プロセスではない。ソフトウェア開発者は
あらかじめ出来上がった部品を組み立てるわけではないのだ。
確かに、一部の部品は事前に用意できるかもしれない。だが、
必要としている部品の大部分は、自分たちで開発、修正、
そして発明しなければいけない。その上、何を作り、何を修正し、
何を発明しなければいけないかは、その場になってみないと分からないことが
ほとんどだ。それでも、しっかりとしたアーキテクチャにしなければいけないのだ。
1.4.1 レシピと公式
→プログラミングは指示に従って進めるだけのような活動ではない。
ソフトウェア開発ではある状況で「正しい」アプローチが、別の状況では
間違ったアプローチになるようなことが数多くある。
1.6 ガチガチのマネジメント
→「正しいこと」とは何だろうか?
上記の質問に対してプロセス追加で答えようとすると事態は悪化する
プロセスは創造性に影響しないからだ。ソフトウェア開発は基本的に
創造的なプロセスである
4.3 第一原理
→ソフトウェア開発における第一原理の例は、単一責務の原則だ。
クラスを変更する理由は1つでなければいけないというものである。
第一原理のほかの例として、オープンクローズドの原則がある。
ソフトウェアのエンティティ「クラス、モジュール、関数など」は
拡張に対して開いており、変更に対して閉じていなければいけないというものだ。
既存のコードをあまり変更せずに、簡単に機能を拡張できるように
作らなければならない
4.5プラクティスとなるために
→ほとんどの場合に価値があるものである
学ぶのが容易である。教えるのが容易である
実施がシンプルである。考えなくてもやれるくらい
4.8良いソフトウェアを定義する
→ソフトウェアの品質を外部指標で特徴づける人は多い。
正しいことをする、バグがない、早い、などだ
だがそれらはより深い原因の症状に過ぎない。
本書で説明するソフトウェアの品質は内部品質である。
内部品質を作りこんだ結果として、外部品質として定義される特性の実現に近づくことができる
4.9 9つのプラクティス
→やり方より先に目的、理由、だれのためかを伝える
小さなバッチで作る
継続的に統合する
協力し合う
「CLEAN」コードを作る
まずテストを書く
テストでふるまいを明示する
設計は最後に行う
レガシーコードをリファクタリングする
5.2 やり方を目的に転換する
ソフトウェア開発者として、プロダクトオーナーと顧客が何を欲しいのか、
なぜほしいのかを知りたい。誰のためのものなのかを知りたい。
どうやってやるか教えてほしくはない。それは私たちの仕事だからだ。
そこがソフトウェア開発者の住む世界だからだ。
5.4ストーリーで目的、理由、誰のためかを語る
→仕様書に代わるものとして、ストーリーで上記を1文で表す
6.2 柔軟に進める
→スコープと日付は柔軟にできなければいけない
リソースという単語は人間に適用できない。
人間はスケーラブルではない。ソフトウェア開発で大量の要求が来て、
生産性を倍にしなければいかない場合に、
人の数を倍にすると何が起きるだろうか?
速度は落ちるか、完全に止まってしまうかだ。
ソフトウェア開発は製造とは違う。
6.4 小さいことは良いこと
→理解しやすい
見積もりやすい
実装しやすい
テストしやすい
9 CLEANコードを作る
→Cohesive(凝集性)
Loosely Coupled(疎結合)
Encapsulated(カプセル化)
Assertive(断定的)
Nonredundant(非冗長) -
ソフトウェア開発手法の全て。レガシーコードから脱却するための9つのプラクティス。やることはたくさんある。1つ1つ実践していくしかない
●感想
この本は「プログラマとして今後学び、実践するべき開発手法の航海図」である。私はレガシーコードが散見されるシステムの改修・開発に日夜携わっている。そのため、この本で書いてあることほとんど全て耳が痛いし、「ちょっとずつでも実践しないと」と思わされる。この本が示すプラクティスは9つあり、どれも深く学ぶ価値があるものばかりだ。それぞれのプラクティスだけをテーマにして本がたくさん出ている。9つプラクティスをいかに書く。
*ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
1.やり方より先に目的、理由、誰のためかを伝える
2.小さなバッチで作る
3.継続的に統合する
4.協力しあう
5.「CLEAN」コードを作る
6.まずテストを書く
7.テストで振る舞いを明示する
8.設計は最後に行う
9.レガシーコードをリファクタリングする
どれも概念としては理解できる。ただ、明日から自分がすべて実践できるほど容易ではない。テストコーディングの技術、フレームワークへの習熟。テストできる優れた「オブジェクト指向」らしいプログラム設計・デザインパターンを理解する。マネージャーや開発チームをより巻き込むチーム力、人間力など...。プログラマとして、今後学んでいくことの多さと可能性に気づける書であった。定期的に読み返し、現状の開発チーム・自身の伸びしろに気づけるだろう。
オライリー本を読むたびに、「いつか英語で原著を読む習慣」をみにつけたいなぁ、と思う。本書の英語版の発行は2015年である。一方、翻訳版である本書の発行年は2019年だ。最新のまとまった知見は常に英語でリリースされる。ある程度、日本語発行本を読めば、英語での学習が主になるだろうな。
●本書を読みながら気になったこと
・テストは仕様である。テストが振る舞いを示すドキュメントとして扱う
・まずテストを書くから、そのときは「テスト」ではない。先にテストを書くことでそのコードが「仮説」となる
・テストはふるまいを表す。ふるまいを検証するのではない
・ユニットテストは構文エラーと概念的エラーのギャップを埋めるものだ。
・コードの綺麗さとコードを書く速さは相関するコードを綺麗にしているほど、コーディングの速度は上がる
・循環複雑度を減らす
・「理想主義者として、私は自分のコードが生み出すふるまいを100%網羅するように務めている。私の場合は、コードを書く前にテストを書くので、コードカバレッジが高くなる傾向にある。しかし、最初にテストを書かずに、途中で一定のコードカバレッジが必要になった場合に、ゲッターやセッターのような簡単なコードのテストを書き、カバレッジに関係なく自動テストが必要となるような非常に難しい箇所を放置しているのも珍しいことではない。」
*スタブとは??
>>テストを書くときは他のオブジェクトの実装に依存しないテストを作るべきです。このために使うのが「スタブ」です。
>>雑に言うとスタブはテストで注目しているオブジェクトが依存するものを、決まりきった動きしかない偽物に置き換え、テストの合否が注目しているオブジェクトの実装の正しさだけに依存するようにすることです。
→つまり、引数は仕様上正しい値を与えたときに、期待した通りの値を返すか判断するのに使うのがスタブ
>>モックの方は、引数の検証や回数の検証といった機能が必要になってきます。なので、テストフレームワークの機能を使わずに自分で作るのは難しいでしょう。
>>送信のメッセージのテストをするときはメッセージの受け手を偽物にすり替えておき、この偽物にメッセージの引数や呼び出し回数が想定通りか検証させる。これをモックという。
>>スタブはテストそれ自体とは無関係だが、モックはテストの一部である。
※参考リンク
https://qiita.com/k5trismegistus/items/10ce381d29ab62ca0ea6
..つまり、スタブは基本のメソッドの返り値を検証して、正しく動くよね、ということを検証する。簡単なテストである。モックは、「あるメソッドによって正しくメッセージが届いたか」を検証することになる。例えば、DBに、10回、入力値に合わせたデータが登録されているかをテストしたい。この場合、実際にDBとの接続を行うわけにはいかないので、フレームワークを使用して、DBを疑似的にモックとして作る。このモックに対して、正しくメッセージが届くかを検証する。つまり、メソッドを抜ける時点での引数が正しいとしても、それはメソッドの中の検証だけは分からない。そのため、モックが必要になる。別の具体例を示そう、チャットアプリで「こんにちはー」ということを友人エリックさんに送るメソッドがあるとする。このとき、入力値は「こんにちはー,私からみたエリックさんのチャット画面」となるが、実際にエリック側のチャットに「こんにちはー」と来ているかどうかを検証したいなら、モックが必要になる。「エリックさん側のチャットフィード」は、現在のメソッドとは別クラスになる。したがって、「エリックさん側のチャットフィード内容」を疑似的に設定できるモックが必要になる。
*モックとは?
>>mockとは、一言でいうとテストに必要な部品の値を疑似的に設定するものです。
>>テストを行うクラスが他のクラスのメソッドの戻り値を使用しているとき、mockを使うことで他クラスをいじらずに、その戻り値のみを自由に設定することができます。
※参考リンク
https://qiita.com/Fudeko/items/301f8a80963dfcaafb80
>>Mockとは、簡単に言うとクラスの動作をシミュレートするためのオブジェクトです。テスト対象クラスが呼び出している(=依存している)クラスをMockで差し替え、Mockの動作内容を定義することで、望むテスト条件を容易に作ることができます
※参考リンク
https://techblog.gmo-ap.jp/2017/03/13/mock%E3%81%A7%E3%83%A6%E3%83%8B%E3%83%83%E3%83%88%E3%83%86%E3%82%B9%E3%83%88%E3%82%92%E7%B0%A1%E5%8D%98%E3%81%AB%E3%81%97%E3%82%88%E3%81%86%EF%BC%81/
*アサーションとは?
>>「アサーション」は、プログラムに関する前提をテストできる Java TM プログラミング言語の文です。 たとえば、粒子の速度を計算するメソッドを記述した場合に、計算される速度が光速よりも遅いことを前提とすることがあります。
各アサーションは、アサーションが実行されたときに true になると想定される boolean 式を含んでいます。 true にならない場合は、システムによってエラーがスローされます。 アサーションは、boolean 式が true であることを確認することによって、プログラムの動作に関する前提を検証します。これによって、プログラムにエラーがない可能性が高くなります。
プログラミング中にアサーションを記述すると、すばやくかつもっとも効果的にバグを発見して修正できることが経験的に実証されています。 さらに、アサーションはプログラムの内部的な動作の文書化に役立つので、保守が容易になるという利点もあります。
※参考リンク
https://docs.oracle.com/javase/jp/1.4/guide/lang/assert.html -
後半のプラクティスに関する話に至るまで前置きが長いなと思ったけど、プログラマ以外の職種の人にも、開発やレガシーコードを産まないための運用開発がどれだけ重要なのかを知ってもらうために見てもらいたい本だと思った。
テストの重要性とか、達人プログラマーにも書いてあった内容があったり、類似書籍を見たことある人だったらあんまり真新しいことは書いてない気がしたけど、書斎の本棚において何度も読み直したいと思う一冊だった。
個人的に「原則をしっかり理解した上で、プラクティスを活用していくことが重要」という観点は、たしかに大事だなと思った。 -
継続的に開発が続けられる保守性の高いコードにするためのプラクティスがまとめられている。
プラクティス自体はアジャイルやXPでは馴染みのあるものが多い。そしてそのプラクティスがなぜ有効なのかを、保守性の低いコードが出来上がってしまう原因から丁寧に紐解きながら説明してくれている。レガシーコードの改善を進めるときにはもう一度読み直したい。 -
図書館で借りた。
オライリーのより良いコードを書くための本。この手の本はいくつも見ているが、コーディング中心というより、比較的ソフトウェア工学・ソフトウェアエンジニアリングに寄った本だ。アジャイル開発の入り口でもあると思う。
オライリー本としては比較的薄くて読みやすいのが本書の特徴。同じオライリーの『Googleのソフトウェアエンジニアリング』も分野としては同じだが、あちらは特大で分厚かった。また、同じオライリーの『リーダブルコード』は新人プログラマーでも分かる、「コードを書く」「どんなコードを書くか」に特化していたが、本書はレガシーコードというテーマだけあってチームビルディングや開発プロセス的な側面が強い。
私自身、レガシーコードを触り続けるのが職務となっていることもあり、何度も読み返して身につけたいところだ。 -
斜め読みですが、背筋が伸びました。
各章のまとめが綺麗だから、斜め読みができたと思ってます。
各章、当たり前だけど現実追いつけてないことが語られていて、耳が痛いが再認識しておきたいという内容でした。
人によってはもう実践してるって事が書かれていると思うので、
各章まとめ読み→なんか引っかかるな?→章本文読む の流れで読むと良さそうと思いました。
背筋を正すために何度も読みたい本です。 -
教えとしてが良いのは当然ながら、例や表現の切れ味が良い
コードにコメント入れ過ぎる弊害について「地獄への道は善意で舗装されている」と表現してたの最高すぎてびびった
コード適当に書くやつに教えを伝える時に使えそう -
●ざっくり感想
タイトルが『レガシーコードからの脱却』になっているので、既にあるレガシーコードをどうしていくかの話が書いてありそうに思えますが、レガシーコードを作らないためにどうしていくかがメインで書かれています。
基本的にはアジャイルの考え方が推されており、レガシーコードやこれまでの開発方法を改善していこうという話と、良いソフトウェアを開発するための9つのプラクティスが紹介されています。著者のソフトウェア開発や業界をよくしていこうという熱い思いが伝わってきて、プラクティスを実践する気にさせてくれました。但し紹介されている内容は開発の進め方に関する紹介が多く、1人のエンジニアが「やりましょう!」といってもチームに導入するのはなかなか難しいと思います。全部がそうではなく意識すれば1人で実践できることも書かれています。
ソフトウェア開発未経験者が読もうと思うような類の本ではないとは思いますが、ソフトウェア開発のプロジェクトに関わった経験や、進め方をある程度理解していないと、読んでもピンとこないことも多いかもしれないので注意が必要です。開発経験のある人、特にチームをマネジメントやリードしていくポジションの人には是非知っておいていただきたい内容が詰まっている本だと思います。
翻訳者の吉羽龍太郎さんが本書についてAWS DevDayで発表した時の資料を公開してますので、読むかどうか迷っている人は一度目を通してみると参考になると思います。
https://www.ryuzee.com/contents/blog/7149
ーーーーー
自分のブログから引用
https://kwn1125.hatenablog.com/entry/2023/09/03/180000