【レガシーコードからの脱却】を読んでみた
はじめに
今日は、こちらの本を読みましたので簡単に重要なところを残しておきたいと思います。
レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
- 作者: David Scott Bernstein,吉羽龍太郎,永瀬美穂,原田騎郎,有野雅士
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/09/19
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
この本は、第１部と第２部に分かれています。特に第２部に焦点を当てて見ていこうと思います。
第１部 : レガシーコードの危機
第２部 : ソフトウェアの寿命を延ばし価値を高める９つのプラクティス
ソフトウェアの寿命を延ばし価値を高める９つのプラクティス
① やり方より先に目的、理由、誰のためかを伝える
実装の詳細の前に、目的や制約を説明するために、やり方の前に、目的、理由、誰のためかを口に出す。どうやって作るかを言わなくて良いので、何を作るかを口に出す。開発者にやり方を発見させ、やり方になってしまっているものは目的で抽象化する。これによって実装の詳細は隠れ、コードはシンプルで、拡張するためのコストも低いものになる。
- ソフトウェアがどう作られるよりも何をすべきかに注目することにより、開発者は自由に最良の実装を発見できる。
- 目的、理由、誰のためかを表現するために、実装の詳細を説明することを捨て、機能を定義するための極めて重要な会話に代えていくことで、開発が発見のプロセスになる
- 効率的に機能を作って、開発に当てる時間を全体の1/3までにする
* 実装を詳細に説明して要求をドキュメント化するのはやめる。機能の目的、理由、誰のためにかを口に出す。そうやって機能を定義する方法を変え、プロダクトオーナーと開発チームとの間で想像的に協調する。
② 小さなミニバッチで作る
小さなミニバッチを作る。そうすれば全てのタスクは短い時間(理想的には４時間)で終わるようになる。タスクが受入基準を満たすようにするか、最低限、観察可能な結果が見えるようにしよう。そうすれば、タスクがシンプルなものになり、見積もるのも、完成させるのも、評価するのも簡単になる。
- 納期がソフトウェア開発プロセスを決定すること
- 自分の時間をもっとコントロールするにはどうしたら良いか
- 小さなタスクほど、見積もりもテストも簡単で、扱いやすいこと
- 機能を観察可能な振る舞いに分割する方法
- タイムボックスで進められるようになったら、スコープボックスを習得すること。スコープボックスとは、タスクを小さくて扱いやすいものに分割すること
* リリースサイクルのリズムがプロセスを制御する。リリース可能なソフトウェアを作る間隔が短ければ短いほど、ソフトウェア開発プロセスは効率上がる。小さく作ることで、タスクは扱いやすくなり、オーバーヘッドが劇的に減る。
③ 継続的に統合する
継続的に統合すること。ストーリーは完了の完了の完了になるまで完了しない。ストーリーを可能なかぎり早く完成させることがゴール。そのためには、健全なプロジェクトの鼓動である自動ビルドが必要。
- コードを書くたびに統合することで、ソフトウェア開発に伴うリスクを軽減
- 統合が苦痛になるため、ウォーターフォールでは統合を延期し、リスクと変更のコストが増大する
- リリース候補の検証を自動化することで、リリース直前の変更にかかるコストを無視できる
- フィードバックサイクルを短くする事で、開発者の行動の結果がすぐに把握できるようにする
- 継続的にデプロイできることの重要性を理解すれば、タスクの自動化方法を探し、機能の相互作用について即座にフィードバックを得るために継続的インテグレーションを活用することになる
* コードを書くたびに統合することで、ソフトウェア開発に伴うリスクが減り、開発者が豊富なフィードバックサイクルが短縮されて、システムがいつもデプロイ可能な状態になる。
④ 協力しあう
質の高いコミュニケーションを作り上げ、知識をグループに広げるために一緒に協力しよう。
- 質の高いコミュニケーションとチームへの知識拡散のために、適切なテクニックをすぐに使う
- ペアリング、スパイク、スウォーミング、モブなどの様々な協働スキルを使う
- 未知の探究、学習の増幅、知識の伝搬に、協働スキルは役立つ
- コードレビューとレトロスペクティブからフィードバックを受け、フィードバックを活かして行動しよう
- 常にメンターであり、メンティーであれ。自分とチームのスキルを上げていこう
* 私たちの最大のリソースはお互いである。一緒に働くためのテクニックや構成を知っておくと、協働を最大化するのに役立つ。
⑤ 「CLEAN」コードを作る
「CLEAN」なコードを書こう。凝集性があり、疎結合で、カプセル化されており、断定的で、非冗長なコードだ。CLEANコードは高品質なコードだ。
⑥ まずテストを書く
最初にテストを書き、次にテストに合格するのに必要なコードだけ書く。これによって、開発するソフトェアの焦点を絞り、テスト可能にする。テストは安全にリファクタリングするのを助ける。テストコードはプロダクションコードと同じように「CLEAN」に保つ。
- テストファースト開発の方法と、それをする理由
- あまりにも多くのテストを書いたり、実装依存のテストを書いたりすると、テストファーストの開発は簡単に失敗する
- テストはコードのリファクタリングをサポートする必要があり、振る舞いを表す必要なテストだけ記述する
- テストファースト開発はQAに役立つが、QAに変わるものではない
- テストファースト開発は失敗するテストを作成し、合格するのに十分なコードを書くことで機能を作る。そのあと、必要に応じてリファクタリングし、失敗する別のテストを書くことを繰り返す
* テストファースト開発を正しく行えば、開発者が保守可能でテスト可能なコードを作成する助けになる。やり方が良くないと、テスト駆動開発は資産よりも負担になる。
⑦ テストで振る舞いを明示する
生きた仕様を作るには、テストに振る舞いを記述する。開発者がテストファースト開発を行う利点を理解すれば、テストの魅力に取り憑かれ、全ての開発をテストファーストで行うたいと考えるはずだ。
- テストスイートを使用して、振る舞いを記述し確認する方法
- テストを活用することで、目的を明確に説明できるようになるとともに、それらが生きた仕様になること
- ふるまいのテストを書くことで、書くべきテストの種類と数を常時把握できること
⑧ 設計は最後に行う
設計を最後にして、意図を示すプログラミングを行うことで、複雑さを減らし、変更を容易にできる。
- 品質は保証できない。品質は作り出すものだ。品質を検証するのではなく、作り込むことに集中しよう
- 読みやすく理解しやすいコードが、柔軟で、変更しやすい
- 意図を示すプログラミングは観点の凝集につながる。抽象のレベルがそろい、読みやすく、理解しやすくなる
- オブジェクトの生成と利用を分離することで、テスト容易性を改善し、依存性を下げよう
⑨ レガシーコードをリファクタリングする
コードを変更する場合は、必要に応じてレガシーコードをリファクタリングする。
*リファクタリングとそれをするスキルは、レガシーコードをクリーンアップする上で重要だ。既存のレガシーコードを変更する前に、最初にやるべきステップはリファクタリングだ。そして、新しいコードも、レガシーコードにならないようにクリーンアップする。リファクタリングは、既存のコードベースを学ぶための、非常に効率的な方法である。
