「レガシーコードからの脱却」を読んだのでまとめ②（レガシーコード危機~プラクティス4 - 協力し合う - まで）

第3章はアジャイル開発と言うものの最近の情勢に関わることが書かれており、ある意味で文学的なものなので、実際に文字で読んで感覚的に感じたものを自分の中に残しておくことにした。

第4章

この章から実際にプラクティスに入る。序文では、今のソフトウェア業界はまだ歴史が浅く、例えるなら数百年前の医学界（むかし岡田斗司夫ゼミで医者は魔女と呼ばれていたと聞いたことがあるが、細菌学さえもなく、その混沌とした雰囲気は何となく感じられる）のようなものだと言っている。

細菌学のない世界においては、手術前に手を洗うことの必要性が理解できない。ただし、今では手術の前に手を洗い、または手袋をし、器具を洗浄するのは必要で当たり前の作業だ。

つまり、この「手を洗う」と言う作業こそがプラクティスであると著者は言っている。

また、正しくプラクティスを習得する方法として合気道の守破離に言及し、理論を理解する前に型を徹底して覚えることを推奨している。

第一原理

この章では、ソフトウェア開発には黄金律のような第一原理が存在しないとしつつも、一例として「単一責務の原則=クラスを変更する理由は1つでなければならない」を紹介している。この訳だとわかりにくいが、１つのクラスが単一の責務を果たすように設計されなければいけないということだ。

プラクティスとは

第一原理の解説の後、プラクティスとは何かという定義づけに移行している。プラクティスとは、原則を実現する方法であると説明されている。また、チームの中でワークする条件として、多くの場合に価値がある、学ぶのが簡単である、教えるのが簡単である、考えなくてもやれるくらいシンプルである、などをあげている。

また、プラクティスの背後にある原則を同時に理解することが重要であるとも書いている。

9つのプラクティス

「良いコードとは何か」の普遍的な合意はないとしつつ、ROIと内部品質にだけ言及している。そしてより良いソフトウェアを作るための9つのプラクティスがここで紹介される。各項目を極限まで簡潔に（2020年現在の開発に落とし込んで）して短い説明を追記する。

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

クライアントは開発者に対して、「やり方」を伝えてはいけない。その代わりに、「何を、なぜ、誰のために作るのか」を伝えなければいけない。さらに、仕様書の代わりにストーリーを作成する。ストーリーを記述する75mm x 125mmの小さなカードをストーリーカードと呼んだりもする。

2020年現在で適用する方法としては、GithubのIssueやZenhubのEpicをストーリーベースに制約することが挙げられる。

また、受け入れテストに明確な基準を設定し、自動化することを推奨している。=E2Eだろう。Railsだったらブラウザ系やRspecでもok?。ReactNativeではDetox。

2. 小さなバッチで作る

これはイテレーションを前提にタスクを細かく分けるという話。また、リリースサイクルが短いほどプロセス効率が上がり、理解しやすくなり、見積もりしやすくなり、実装しやすくなり、テストしやすくなる。

小さなバッチで作り続けるための具体的な話として、以下のような施策があった。

・ビルドを高速化すること

・細かいフィードバック（A/Bテストも含む）に対応し続けること

・MMFを加味したバックログを作ること

・ストーリーをタスクに分割すること

・スコープを管理する（カンバン）

スコープの管理は、「ストーリーの完成」を明確に管理することであり、シュレディンガーの猫を持ち出して、箱を開けることをストーリーが完成して動かすことと換喩している。

最後にソフトウェア開発の品質を評価するために行う計測が紹介されていて、価値実現までの時間の計測、コーディング時間の計測、欠陥密度（コード1000行あたりのバグ数）の計測、機能ごとの顧客価値の計測、機能を提供しない場合のコストの計測、フィードバック=>改善までのフィードバックループの効率の計測が紹介されている。

3. 継続的に統合する

継続的インテグレーションの話。もちろんavoidよりもintegrateだが、完了の完了の完了を担保するために実際に必要なことはビルドサーバーを用意すること、継続的にデプロイ可能であること、ビルドを自動化することが挙げられている。

サーバーであればCircleCI、アプリであればFastlaneが対応するツール。

4. 協力し合う

ここではペアプロ、バディプログラミング（少時間のコードレビュー等）などについて書かれている。リモートが入るチームだとペアプロは面倒だと思うので、バディプログラミングは良さげ。また、有事にはスウォーミング・モブなどみんなで同じストーリーに対応するのも使いそう。

また、コードレビューとレトロスペクティブはスケジュール化した方が良いという風にも言っている。

残りのプラクティスについては次回の記事で。