とあるOSSを継続可能にするための取り組みについて / OSS Refactoring Process

JaSST nano vol.40(https://jasst-nano.connpass.com/event/328652/) にて発表させていただいた資料です。

私の自己承認欲求がリファクタリングに向かい、まっとうなプロセスでリファクタリングをしていきましたので手順などをご紹介します

Transcript

1. とあるOSSを継続可能にする ための取り組みについて JaSST nano vol.40 bun913
2. 本当はこういうタイトルにした かった
3. 超偉い！OSSを継続可能に するために頑張ったこと 〜誰か俺を褒めてくれ〜 仮題です
4. 大人なので自重しました
5. 自己紹介 bun913 • 職種: SDET
 ◦ Software Development Engineer in Test
 • ISTQB AL TA/TTA/TM 取得 
 • AWSと開発も少しだけできる 
 • 英語猛烈学習中

6. とあるOSSライブラリがありました
7. どんなツールか？ • Postman によるAPIテストの結果を TestRail に取り込むツール
 • Postman
 ◦ APIテスト実行できる
 • TestRail
 ◦ テストマネジメントツール。 API連携で色々 できて便利
 • TestRailでテストケースを管理。その テストケースに対する結果を自動で取 り込むイメージです。
 そのツール APIテスト実行 結果を加工 結果を送信（保存）
9. とても便利なのですが・・・
10. 本家のリポジトリがアーカイブされていた • もうこのリポジトリを更新することができない
 ◦ 機能追加はもちろん、脆弱性対応などもできない 
 • TestRailは企業組織に利用されることが多そうだし、あまり良くない
 ◦ 利用料金のプランから見て OSSプロジェクトなどでの利用よりも、企業組織から利用されることが多そう という安易な推測
 

11. じゃあこれをもとに私がパッケージを公 開するか・・・
12. GitHub リポジトリ npmパッケージ
13. これを改良していった ステップをお話しします
14. 改良のための 具体的なステップ
15. 取り組んだステップ • Step1: 現状を把握する
 • Step2: メインとなる機能のテストを追加
 • Step3: 一旦パッケージを公開する
 • Step4: リファクタリングのためにテストを追加
 • Step5: リファクタリングを実施
 ※ その時の気持ちや経過をZennにまとめる

16. • まだオリジナルのツールのソースを移植しただけの段階
 • テストコマンドがあったのでテストを実施するも、テストが一つも通らな い状態
 ◦ テストは過去にあったが、メソッド名が変わって「そんなメソッドないよ」みたいなエ ラーが出ている状態 
 ◦ またテストはメインとなる機能の一部の処理に対してのみ書かれていた模様 
 • ソースコードも結構複雑で継続的開発が難しそうな印象（すばらしい ツールなのは強調したい）
 Step1: 現状を把握する
17. この時の気持ち: 何をするにしてもテストが必要
18. • 動かなくなっていたテストをもとに、メイン機能のユニットテストを追加
 • また、Codecovというというサービスでいやでもカバレッジが目に入るようにした
 Step2: メインとなる機能のテストを追加
19. • ブランチカバレッジは60%くらい
 • コードカバレッジが全てではないが、このくらいのツールとして60%はちょっと心 許ない（規模が小さい故にもう少し網羅して安心したい）
 • ともあれ手動テストも含めて動作は確認できたし、仕様もわかってきた
 この時の状態
20. この時の気持ち: テストを書きやすくするためにコードを 変えたくて仕方がない
21. • ともあれ動作を確認できたので、npmパッケージとして公開
 • ブログも執筆して公開
 Step3: 一旦パッケージを公開する
22. テストもリファクタリングも未完了なのに なぜ公開したの？
23. • 福田さんという有名なOSSコントリビューターに強く影響を受け
 • 「今この瞬間に困っている」人がいるかもしれない。完璧じゃなくても、存在さえ知 れば「俺がやるよ」という方もいるかもしれない
 Better than Nothing という考え方 引用: https://www.youtube.com/watch?v=bnfPUrJQh1I
24. この時の気持ち: 一旦すっきりした。最低限のことはしたぞ。
25. • 内部構造が複雑で関数やクラスも大きいのでテストも追加しにくいのでリファクタ リングしたい
 • リファクタリング
 ◦ 「システムや機能の振る舞いを変えずに 内部構造を改善する」 
 ◦ 変えてないことを保証するためにもテストが欲しいというジレンマ 
 • 「友達を作るための服を買いに行く服がない」のような状況
 
 Step4: リファクタリングのためにテストを追加
26. • ブランチカバレッジ
 ◦ 63% → 81.73%
 • 本来は機能の振る舞いを検証したいが、テストがちょっとしにくい構造であるため 「この関数をこの引数で呼んでいる」といったテストも許容しながら追加していく
 • 仕様の理解が深まっていく
 ◦ 「この環境変数を設定した時の挙動はこうなのか」 
 ◦ 「まさか Logger というクラスが結果に影響を与えるとは思っていなかったぜ」 
 • リファクタリングをしていく自信がついた
 
 
 1週間の進捗
27. カバレッジはこんな状態でした
28. • 活動の尊さは以下の画像だけでも感じられるかも？
 Step5: リファクタリングを実施
29. • 一つの巨大なクラス、その中の2つの巨大な関数を小さく分割した
 • イメージ図
 やったこと
30. • リファクタリングに取り組むステップ
 ◦ まずは大きな関数の一塊の意味を持つ処理を 自分のクラスの小さな関数として切り出す 
 ◦ 既存のテストの結果を確認しながら、切り出した関数のテストを書く 
 ◦ ある程度切り出しが終わったら「特定の責務を持つクラスとして切り出しができないか」検討し て、クラスを分ける
 ◦ 既存のテストの結果を確認しながら、切り出したクラスのテストを書く 
 • プロダクションコードとテストコードに「意図」を持たせる
 ◦ 例: なぜ文字列を `C` の後の任意の数字を持つ部分とそうでない部分で分割するの？ 
 ◦ → テストケースのIDをタイトルから取得して TestRailに送信するためのデータを準備するため 
 ◦ そういった「一塊のプロセス」に名前をつけながら、意図をわかりやすくしていく 
 取り組み方針
31. • 250行以上あったメイン処理を50行程度 に削減
 • 小さく「機能の振る舞い」をテストしやすく なった
 • ある程度意図を持たせたクラスに分割し たので、私以外の人でも何とか変更でき る（と思う）
 取り組み後の効果
32. こんな感じのことを2週間くらいで 趣味でやっていました
33. • SDET（Software Development Engineer in Test) として、開発ができる （はずの）「テストマン」として、自分が一番やるべきだという使命感から始まっ た活動でした
 • プライベートでリファクタリングをするのは貴重な体験でした
 • もっと大きなOSSのコントリビューターの方々への感謝が増大しました
 • みなさん「いいな」と思ったらGitHubにそっとスターをつけましょう。きっと大き なモチベーションになりますよ
 やってみて思ったこと
34. 超偉かった！ ご清聴ありがとうございました