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

by bun

Slide 1

Slide 1 text

とあるOSSを継続可能にするための取り組みについて JaSST nano vol.40 bun913

Slide 2

Slide 2 text

本当はこういうタイトルにしたかった

Slide 3

Slide 3 text

超偉い！OSSを継続可能にするために頑張ったこと〜誰か俺を褒めてくれ〜仮題です

Slide 4

Slide 4 text

大人なので自重しました

Slide 5

Slide 5 text

自己紹介 bun913 ● 職種: SDET  ○ Software Development Engineer in Test  ● ISTQB AL TA/TTA/TM 取得   ● AWSと開発も少しだけできる   ● 英語猛烈学習中 

Slide 6

Slide 6 text

とあるOSSライブラリがありました

Slide 7

Slide 7 text

どんなツールか？ ● Postman によるAPIテストの結果を TestRail に取り込むツール  ● Postman  ○ APIテスト実行できる  ● TestRail  ○ テストマネジメントツール。 API連携で色々できて便利  ● TestRailでテストケースを管理。そのテストケースに対する結果を自動で取り込むイメージです。  そのツール APIテスト実行結果を加工結果を送信（保存）

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

とても便利なのですが・・・

Slide 10

Slide 10 text

本家のリポジトリがアーカイブされていた ● もうこのリポジトリを更新することができない  ○ 機能追加はもちろん、脆弱性対応などもできない   ● TestRailは企業組織に利用されることが多そうだし、あまり良くない  ○ 利用料金のプランから見て OSSプロジェクトなどでの利用よりも、企業組織から利用されることが多そうという安易な推測   

Slide 11

Slide 11 text

じゃあこれをもとに私がパッケージを公開するか・・・

Slide 12

Slide 12 text

GitHub リポジトリ npmパッケージ

Slide 13

Slide 13 text

これを改良していったステップをお話しします

Slide 14

Slide 14 text

改良のための具体的なステップ

Slide 15

Slide 15 text

取り組んだステップ ● Step1: 現状を把握する  ● Step2: メインとなる機能のテストを追加  ● Step3: 一旦パッケージを公開する  ● Step4: リファクタリングのためにテストを追加  ● Step5: リファクタリングを実施  ※ その時の気持ちや経過をZennにまとめる 

Slide 16

Slide 16 text

● まだオリジナルのツールのソースを移植しただけの段階  ● テストコマンドがあったのでテストを実施するも、テストが一つも通らない状態  ○ テストは過去にあったが、メソッド名が変わって「そんなメソッドないよ」みたいなエラーが出ている状態   ○ またテストはメインとなる機能の一部の処理に対してのみ書かれていた模様   ● ソースコードも結構複雑で継続的開発が難しそうな印象（すばらしいツールなのは強調したい）  Step1: 現状を把握する

Slide 17

Slide 17 text

この時の気持ち: 何をするにしてもテストが必要

Slide 18

Slide 18 text

● 動かなくなっていたテストをもとに、メイン機能のユニットテストを追加  ● また、Codecovというというサービスでいやでもカバレッジが目に入るようにした  Step2: メインとなる機能のテストを追加

Slide 19

Slide 19 text

● ブランチカバレッジは60%くらい  ● コードカバレッジが全てではないが、このくらいのツールとして60%はちょっと心許ない（規模が小さい故にもう少し網羅して安心したい）  ● ともあれ手動テストも含めて動作は確認できたし、仕様もわかってきた  この時の状態

Slide 20

Slide 20 text

この時の気持ち: テストを書きやすくするためにコードを変えたくて仕方がない

Slide 21

Slide 21 text

● ともあれ動作を確認できたので、npmパッケージとして公開  ● ブログも執筆して公開  Step3: 一旦パッケージを公開する

Slide 22

Slide 22 text

テストもリファクタリングも未完了なのになぜ公開したの？

Slide 23

Slide 23 text

● 福田さんという有名なOSSコントリビューターに強く影響を受け  ● 「今この瞬間に困っている」人がいるかもしれない。完璧じゃなくても、存在さえ知れば「俺がやるよ」という方もいるかもしれない  Better than Nothing という考え方引用: https://www.youtube.com/watch?v=bnfPUrJQh1I

Slide 24

Slide 24 text

この時の気持ち: 一旦すっきりした。最低限のことはしたぞ。

Slide 25

Slide 25 text

● 内部構造が複雑で関数やクラスも大きいのでテストも追加しにくいのでリファクタリングしたい  ● リファクタリング  ○ 「システムや機能の振る舞いを変えずに内部構造を改善する」   ○ 変えてないことを保証するためにもテストが欲しいというジレンマ   ● 「友達を作るための服を買いに行く服がない」のような状況    Step4: リファクタリングのためにテストを追加

Slide 26

Slide 26 text

● ブランチカバレッジ  ○ 63% → 81.73%  ● 本来は機能の振る舞いを検証したいが、テストがちょっとしにくい構造であるため「この関数をこの引数で呼んでいる」といったテストも許容しながら追加していく  ● 仕様の理解が深まっていく  ○ 「この環境変数を設定した時の挙動はこうなのか」   ○ 「まさか Logger というクラスが結果に影響を与えるとは思っていなかったぜ」   ● リファクタリングをしていく自信がついた      1週間の進捗

Slide 27

Slide 27 text

カバレッジはこんな状態でした

Slide 28

Slide 28 text

● 活動の尊さは以下の画像だけでも感じられるかも？  Step5: リファクタリングを実施

Slide 29

Slide 29 text

● 一つの巨大なクラス、その中の2つの巨大な関数を小さく分割した  ● イメージ図  やったこと

Slide 30

Slide 30 text

● リファクタリングに取り組むステップ  ○ まずは大きな関数の一塊の意味を持つ処理を自分のクラスの小さな関数として切り出す   ○ 既存のテストの結果を確認しながら、切り出した関数のテストを書く   ○ ある程度切り出しが終わったら「特定の責務を持つクラスとして切り出しができないか」検討して、クラスを分ける  ○ 既存のテストの結果を確認しながら、切り出したクラスのテストを書く   ● プロダクションコードとテストコードに「意図」を持たせる  ○ 例: なぜ文字列を `C` の後の任意の数字を持つ部分とそうでない部分で分割するの？   ○ → テストケースのIDをタイトルから取得して TestRailに送信するためのデータを準備するため   ○ そういった「一塊のプロセス」に名前をつけながら、意図をわかりやすくしていく   取り組み方針

Slide 31

Slide 31 text

● 250行以上あったメイン処理を50行程度に削減  ● 小さく「機能の振る舞い」をテストしやすくなった  ● ある程度意図を持たせたクラスに分割したので、私以外の人でも何とか変更できる（と思う）  取り組み後の効果

Slide 32

Slide 32 text

こんな感じのことを2週間くらいで趣味でやっていました

Slide 33

Slide 33 text

● SDET（Software Development Engineer in Test) として、開発ができる（はずの）「テストマン」として、自分が一番やるべきだという使命感から始まった活動でした  ● プライベートでリファクタリングをするのは貴重な体験でした  ● もっと大きなOSSのコントリビューターの方々への感謝が増大しました  ● みなさん「いいな」と思ったらGitHubにそっとスターをつけましょう。きっと大きなモチベーションになりますよ  やってみて思ったこと