2018/12/15 DevLOVE関西『現場でレガシーコードに立ち向かっている者達の話』で発表しました。 https://devlove-kansai.doorkeeper.jp/events/83358 <概要> レガシーコードで育ってきた私が、テストコードの力を体感し、テストが必要だと認識し、テストの導入に挑戦しはじめた体験についてお話します。 テストを書くという行為を「知らない」から「知ってる」にステップアップしたのは、どんな体験を通じてか、その時どんな気付きがあったのかということを考えたいと思います。

1. レ ガ シ ー コ ー ド に
向 き 合 っ て み た 話
市原 功太郎
Ichihara Kotaro 2018.12.17 DevLOVE関西
現場でレガシーコードに立ち向かっている者達の話

2. ABOUT ME 2
Ichihara Kotaro
市原 功太郎
MonotaRO Co., Ltd
データマーケティング部門 APIグループ
エンジニア歴3年目

3. ABOUT OUR COMPANY 3
基幹システムからWebサイトまで自社開発
主要言語は Python など
年率20%超の成長中

4. レガシーコード？ 4
レガシーコードとは
テストコードのないプロダクションコード
今日はレガシーコードに単体テストを導入していったお話

5. 今日の内容 5
どんな状況だったか
チームがどのように取り組んだか
自分の話:
どのようにテストに目覚めたのか

6. どんな状況だったのか

7. こんな状況 7
15年以上成長し続けてきたコードベース
施策に合わせて追加される「業務仕様」
当然存在していない単体テスト
機能追加のテストは、E2EのExcel仕様書中心

8. 疑問 8
どうしてこんなことに？

9. 要因のひとつは 9
A. 事業会社だから

10. 7
会社の成長を支えているもの
- すばやく施策を打って、仮説検証すること
- スピードが優先されがち
商品販売で収益を得るビジネス
- ソフトウェアそのものは商材ではない
※ もちろん要因の全てではない
重視されること 10

11. 競争力の源泉は 11
つまり！
利益の最大化 ≠ ソフトウェア品質の追求
ある程度の品質ですばやく出すことが求められた
ところが→ →

12. 事情が変わってきた 12
会社の成長
→ 機能の増大・複雑化
→ ソフトウェアの巨大化！

13. ソフトウェアの巨大化 13
従来のテスト手法では成長に追いつけなくなってきた
- 手仕事によるテスト実施
- E2E視点中心
- デグレの防止= レビューアの勘と経験
- リリースごとに使い捨てのテスト仕様書
= 遅い・手戻り・不安定

14. 求められたのは 14
要求をすばやく実現するため
再現性の高い品質担保方法で開発したい
という需要が大きくなってきていた

15. チームが
どのように取り組んだか

16. ミニマムにはじめる 16
CIでコンパイルするだけのテストを開始した
Git Commit時に ✔ or ❌がみえる
CIの結果の見方を学んだ

17. 既存の単体テストの「復活」 17
いにしえのユニットテストをCIにのせた
かつてごく一部だけ書かれていたユニットテストを発掘
（あまりメンテされてないものだったけど）
とにかく単体テストが動き始めた

18. リリース要件 18
ユニットテスト通過がリリース要件になった
既存CIの結果がグリーンじゃないとリリースできない
テストコードの品質を維持する動機に

19. 実行環境 19
単体テストができるローカル環境を構築
アプリが動作する環境をVagrantとAnsibleで定義
それまでは共用サーバでの開発が中心だった
開発で気楽にテストできるようになった

20. テストの増やし方 20
追加・改修部分だけ単体テストを書く
いきなり全部は無理でも、やったことだけならまあ書ける
テストが徐々に増えてきた

21. なんということでしょう 21
テスト文化が徐々に変わりつつある
開発時にはテストプログラムが作成される
それらはコミットごとにCIで実行される
通過したものだけがリリースされる

22. 自分の話:
どのようにテストに目覚めたのか

23. 自分の話 23
入社してはじめてITを学んだいわゆる「文系エンジニア」
現在の現場が一社目
会社のシステムに使った時間
≒ エンジニアとしてすごした時間

24. こうなりがち 24
今やっているやり方がすべて
Excelテストが大変でも、別に困らない
むしろテストコードとかめんどくさい

25. 大変なのに、困ってない？
テスト書くことはめんどくさい？
何故 25

26. 知らないから 26
今やっているやり方がすべて
→ 他のやり方を知らないから
Excelテストが大変でも、別に困らない
→ 大変だということを知らないから
むしろテストコードを書くのがめんどくさい
→ テストの効能を知らないから

27. どうやって気づいたのか 27
とあるAPI新規開発案件で
新規プログラム全てに単体テストを書いた
書いてるときはちょっと面倒だったが……

28. 衝撃 28
数秒で実行できる！
テストが失敗するところだけ直せば良い！
すぐにデグレに気付ける！

29. やばい、テスト書いたら超楽じゃん

30. 続・どうやって気づいたのか 30
体験に勝る気づきはない
まわりのエンジニア達の「つらい」にやっと共感できた
（質のいいテストを書く大変さも実感できた）
この速度感と安心感を味わったら、もう戻れない

31. というわけで、こんな取組みを 31
テストを走らせる環境の定義
前述のローカル開発環境構築を主導して実現した
個人PC上で共通環境を再現可能
気軽に実装・テスト実行・コミットが可能な状況をつくった

32. それからどうした 32
みんなでテストを書きまくっていたら、
チーム全員がテスト推進派に
単体テストの無いPullRequestがなくなっ
た

33. これからどうしたい 33
メンテナンスしやすいシステムに再設計
秘伝の継ぎ足しコードなので、テストしづらい
既存コードの単体テストを増殖させる
現在は主管システムxx万行中 xx %
テスト実装力を上げたい

34. まとめ 34
テストの大切さは知らなければ気づけない
実体験で最大の気づきを得られた
テストのあるコードはよいものです

35. ご静聴ありがとうございました。