1. レガシープロダクトを改善していくための戦い⽅
佐藤琢哉(nazo)

2. 今回伝えたいこと
レガシーコードとの向き合い⽅・⼼構え
プロダクト（業務）は必ず前に進めることができる
細かい⽅法はあまり話しません

3. こんなプロジェクト⾒たことないですか？
突然アサインされたものの…
テストが書かれていない
テストがほとんど通らない
CIがない
インフラが⼿作業で作られている
その他いろいろカオス
前任者が不在でノードキュメント

4. もうやだ作り直したい！
わかる
わかるー超わかるー
しかし本当にそれでいいのか？

5. なぜ作り直してはいけないのか
運⽤が始まっていると２ラインのプロジェクトが⾛る
２ラインでほぼ同じ実装をしないといけないため機能開発が⽌まる
そもそも思っているほど簡単じゃない
既存のデータは残さないといけないのでデータの変換などが必要
ビジネス（ロジック）ちゃんと理解してる？
現状で本当に問題あるの？（コード以外の部分）

6. 作り直してもいい場合
まだ運⽤が始まっていない/始まって間もなく、データ量が少ない
データ構造が単純で変換が簡単、あるいは変換する必要がない
独⾃フレームワークなど、根幹レベルで⼿がつけられず、今後メンテナンスすることが
不可能に近い状態
それでも部分的に作り直せないかとか検討すべき
⼀通りやることをやって、ビジネス部分は理解できた上で保守に限界を感じた場合

7. 動いているプロジェクトの特性
利⽤者がいる
⽌めることができない
開発が継続している
これらを踏まえた上でどうにかする

8. レガシープロダクトにおける最⼤の課題
悪い状態をこれ以上拡⼤させない
なるべく良いほうに少しずつ収束させていく

9. 悪い状態とは何か？
コードの秩序がない
読めない
テストがない
コードの正当性が担保されていない
⾃動化されていない
⼿作業が多くミスの原因になっている

10. なぜ悪いのか？
既存メンバー以外が⼊ってきた時に把握が難しい
環境を変化させることが難しい
システムを変化させることが難しい
事故が起きる可能性が⾼い
今は⼤丈夫でも将来的に
ビジネス規模が⼤きくなればなるほど被害が⼤きくなる

11. 悪い状態をこれ以上続けないために
CI/CDの整備
Lint導⼊
環境構築しやすい状態にする
テストを書ける体制作り

12. CI/CDの整備
テスト/Lintを⾃動で⾛らせて品質の確保
デプロイの⾃動化
⼤体⼿動デプロイだよねこういうの…
⼈間の⼿が⼊るところは事故の元なので、そこを極⼒減らす
CI/CDに対応した環境/インフラにする

13. Lint導⼊
基本的に後から⼊れるのはハードルが⾼い
全てこけるので
⾃動修正できる場合は⾃動修正してしまう
⾃動修正が完璧でない場合もあるので修正箇所は必ずチェック
特にrubocop
最初は全てスキップするように設定し、少しずつ厳しくしていく

14. （⾃動）テストを書ける体制作り
元々あるなら使おう
元々あるがFailが多すぎる場合は全部消そう
テストの修正は時間の無駄
テストがないプロジェクトの品質が上がることはない
テストがないプロジェクトの品質は誰にもわからない、とも⾔う

15. プロジェクトの途中からテストを書く
無理しない
なるべく新規のロジックや、⾃分が修正に関わったところを中⼼に⾏う
リファクタリングも並⾏して⾏う
コントローラーにロジックベタ書きだったりすると思うので、そういうのを切り出
してテストを⼀緒に書く
いわゆるe2eテストのようなものは「とりあえず通しておく」
200が帰ってきたらOKくらい
依存度の低いテストのほうが重要

16. TestSizesを意識する
https://testing.googleblog.com/2010/12/test-sizes.html
定義は⾃分たちで決める
Sサイズのテストが多くなるようにする
そうすることで⾃然に機能が分離され、良い設計になる

17. 環境構築しやすい状態にする
⼈の⼊れ替えの少ないプロジェクトで新しい⼈が⼊った時に環境構築に失敗する←ある
ある
環境構築⽅法が整備されているプロダクトは構造の⾒通しが良い
次⼊ってきた⼈が困らないように
Docker化など

18. データ構造の⾒直し
DB設計で事故っていると致命的な問題になることがある
必要なログがない
項⽬の増減ができない
イベントの発⽣時刻などがわからない
ビジネスの変更についていけない
DBを直すのはコードを直すのより⼤変なことが多い

19. イベントとリソースの分離
特定時刻に何か起こったことはイベントである
例えば「ユーザー」と「ブログ記事」があって、それを投稿するというのは「投稿
する」というイベントであって「ユーザーとブログ記事との関連」というわけでは
ない
イベントに対する更新は基本的に発⽣しないようにする（イミュータブル）
-nullはなるべく許可しない
リソースとイベントを明確にすることで業務の流れが明確になる
詳細はぐぐるなりDB設計系の書籍で

20. インフラ
（規模にもよるが）なるべく⼈の⼿が必要ない構成にする
Terraform等による構築⼿順の⾃動化
12Factorに寄せたアプリ構造にする
アプリ側も構造が分離され綺麗になる
どこを修正するとどこに影響があるのか明確にする

21. 最後は気持ちの問題
最初に⼀気にやる部分と、開発しながら少しずつ直す箇所を分ける
インフラ・CIなどは最初に⼀気に
テスト・Lint・データ構造などは開発しながら
ビジネスの成⻑を⽌めない
開発者の満⾜のために⾏っているわけではない
⽌めないといけない場所もあるが、後になるほど⼤変になることを理解してもらう
進んでいることを明確にする
最初にやって！！！

22. おわり