アジャイル開発の基礎となる知識が学べる / レガシーコードからの脱却を読んだ

「ITエンジニア本大賞2020」の技術書部門大賞に選ばれたレガシーコードからの脱却を読みました。

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

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

www.danshihack.com

本書はレガシーコードを作らないための9つのプラクティスが紹介されています。紹介されているプラクティスはスクラムとXP(エクストリームプログラミング)から抽出されていて、アジャイルが好きな方々には馴染みのある内容になっています。

プロセスやチーム、設計、テストなど幅広くカバーされていて、幅広い分、本書だけでは物足りなく感じる部分も出てくると思います。まずは本書と自分の開発のDiff(差分)を取って足りない部分や強化したい部分を見つけて、実践し、さらに別の書籍などで深く学んでいくスタイルが良いと思います。

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

第Ⅰ部はレガシーコードが生まれる背景とレガシーコードによるリスクやコストについて、そしてそれを解決するために生まれたアジャイルについて紹介されています。

第Ⅱ部はレガシーコードを生まないためのプラクティスが紹介されています。プラクティスは1つずつ紹介されていますが、それぞれに関係性があります。

プラクティス同士の関係性

f:id:iucstscui:20200402013216p:plain
上記の図は僕が本書を読んで読み取ったプラクティス同士の関係性です。協力しあうはチームでの働き方のプラクティスなので開発の土台です。また、継続的に統合するは設計、実装、テストを支えるプラクティスです。
やり方より先に目的、理由、誰のためかを伝えると小さなバッチで作るはスクラムだとPO(プロダクトオーナー)が中心となるプラクティスです。
それ以外はスクラムの開発チームが中心になるプラクティスです。

テストに関するプラクティスは他のプラクティスと相互関係が多いため、重要なプラクティスだと感じました。

それでは、本書で特に気になった部分を紹介していきます。

「CLEAN」コードを作る

新規で機能を作るときはきれいに書けても仕様変更や機能追加などで徐々に崩れてレガシーコードになってしまいます。僕も何度もそういうコードを書いてしまいました。

CLEANコードのプラクティスはこの問題(修正による修正でレガシーコードになる)を解決する設計を学べます。CLEANは設計する際に有効な5つの原則の頭文字です。

CLEANコード

C ohesive（凝集性）

L oosely Coupled（疎結合）

E ncapsulated（カプセル化）

A ssertive（断定的）

N onredundant（非冗長）

オブジェクト指向の設計の原則と言えばSOLIDの原則も有名です。似ている原則もあるので合わせて学ぶと良いですね。
SOLIDの原則

S ingle Responsibility Principle（単一責任の原則）

O pen/closed principle（オープン/クロースドの原則）

L iskov substitution principle（リスコフの置換原則）

I nterface segregation principle（インターフェース分離の原則）

D ependency inversion principle（依存性逆転の原則）

CLEANコードもSOLIDの原則もクラスの凝縮度を高めて、クラス間の結合度は下げようと紹介しています。そうすることで、変更があっても影響範囲を狭められますし、拡張に強い設計になります。本プラクティスはテストコードを書くためにも必要ですし、他の人が理解しやすいコードを書くためにも必要です。個人的には本書の中でも外せないプラクティスの1つだと思います。

小さなバッチで作る

小さなバッチで作るの章では機能開発の着手から評価までのフィードバックサイクルを早くする方法が学べます。フィードバックサイクルが早くなると手戻り工数が少なくなり開発プロセスの効率が上がります。最小市場化可能機能セット(MMF)の分割やビルドの高速化など多くの手法が紹介されていていました。

フィードバックサイクルを早くする理由は分からないことを減らすためです。そのため、本書で紹介されている「複雑なストーリーを扱う場合には、既知のことと未知のことを分離する」の考えは1つの指標になりますね。

小さなバッチで作り続けるためにはソースコードを何度も修正することになるので、CLEANコードを理解して拡張性の高い設計が必要になります。

設計は最後に行う

目次で一番気になっていたプラクティスです。
実装前に設計しないわけではなく、開発して行く中で分かったことや変わったことをふまえて再設計しましょうという内容です。小さく分割した機能を繰り返し開発していると全体の設計に影響が出始めます。そのときに全体を再設計、リファクタリングして、開発しやすい状態を維持してレガシーコードを防ぐのです。このような設計を創発設計と呼びます。

牛尾さんのブログでもアジャイル開発するうえで進化型設計が重要だと紹介されています。言葉は違いますが、初めに設計を固めるのではなく、少しずつ設計も進化させていきましょうと紹介されています。
simplearchitect.hatenablog.com

本書と牛尾さんのブログに書かれていますが、本プラクティスはテストコードがないと安心して実施できません。プロジェクトが大きくなればなるほど、修正による影響範囲が把握しきれなくなります。テストコードで既存の動作を守った上で再設計に取り掛かりましょう。

まとめ

とりあえずアジャイル開発を始めて有名なスクラムを採用したけど、開発がうまく進まないチームにはとても有用な書籍だと思います。スクラムガイドだけではどうやって作るかは紹介されていません。継続的に開発するには本書で紹介されているプラクティスを実践し、レガシーコードを作らないことが大切です。
本記事の冒頭でも書きましたが、本書でアジャイルを実現する開発手法を知り、より詳しい部分は別の書籍などで学ぶと安定した開発ができると思いました。