こんにちは。エンジニアの nishida です。giftee Point Base というポイントシステムのプロダクトを開発しております。
今回、会社の dev training 制度を使用して TSKaigi Kansai 2024 に参加しましたので、特に印象に残ったセッションについて書こうと思います。
セッションレポート① 型チェック 速度改善 奮闘記⏳
Kenta TSUNEMI さんによるセッションです。
セッションの内容は、とあるプロダクトにおいて型チェックに数十秒かかっている状況を半減させたというものでした。 （特に Naming Complex Types を考慮することが一番のパフォーマンス改善につながったとのことです。）
また、調査プロセスについても細かく発表がありました。
- tsc での型チェックのタイミングで、
--noEmit--extendedDiagnostics--generateTraceオプションを使用して詳細な実行ログを取得 - 作成した trace.json ファイルを speedscope というツールを利用して時間がかかっている部分を特定
- ソースコード上で特定するために types.json を使用してより具体的な修正箇所を洗い出し
実際の業務だとついつい後回しにしてしまうような「パフォーマンス改善」に先んじて取り組まれているところが良いなと感じただけでなく、技術的な内容についても大変勉強になりました。
セッションレポート② テストコード品質を高めるためにMutation Testingライブラリ・Strykerを実戦導入してみた
Kanon さんによるセッションです。
ご登壇者の資料はこちらにあります。
Mutation Testing の概要とその導入方法についての説明がありました。
Mutation Testing とは、テストコードそのものの品質をみるためのテストで、プロダクションコードを意図的に変えてみてテストコードが期待する結果（失敗）になるかを確認するテストだとのことです。 このセッションは Mutation Testing についての説明と Stryker という Mutation Testing を勝手にやってくれるライブラリを用いた実践例と工夫（CI への組み込み、および Stryker Dashboard がプライベートリポジトリで使えないのでその代替案の模索）についての発表がありました。
CI への組み込みについては、テストの差分実行オプション incremental : true の指定とテスト実行時に書き換えられるプロダクションコードの場所を少なくすることで、普通に実行すると 2時間くらいかかってしまうものを数十秒程度まで抑えることができたとのことです。
プライベートリポジトリだと Stryker Dashboard が使えない点については、Google Cloud Storage に HTML 形式のレポートを送るように設定し、閲覧のための URL を Slack で通知することで、テストの実行結果をより確認しやすくしたとのことでした。
私自身そもそもテストコード自体の品質について考えたことがなかったため、新鮮な気持ちでセッションを聞くことができただけでなく、試しに動かしてみて終わり！にはせず実際に使われる形で導入し切ったところが素敵だなと思いました。
まとめ
セッションは全て面白く学びになるようなものばかりでした。 また、僕は TSKaigi 2024 にも参加していたのですが、関東開催の時にお会いしなかった企業様とも交流することができたのでとても楽しかったです。
末筆になってしまいますが、ギフティではこのように交通費がかかるような遠方のカンファレンスに行く時も dev training 制度を使用して会社負担で参加することができます。今回 nishida はカンファレンスのチケット代および新幹線代を会社負担にさせていただきました。（ありがとうございます！）
もしギフティの制度について気になる方は、以下の記事をお読みいただければと思います！
ギフティの労働環境ってぶっちゃけどうなの？
また、ギフティでは一緒に働く仲間を募集しておりますので、もしご興味がおありの方は是非カジュアル面談にお越しいただければと思います！
カジュアル面談について知る
