6万行の TypeScript 移行とその後

1
Copyright (C) 2021 Studist Corporation. All Rights Reserved
6万行の TypeScript 移行とその後
株式会社スタディスト笹木信吾 @s_sasaki_0529
Tech Stand #6 TypeScript
2021.11.10

2
自己紹介

3
笹木信吾 (@s_sasaki_0529)
● 株式会社スタディスト開発部技術支援ユニット
● 主に Webフロントエンドのリードがお仕事
● TypeScript が好き。IEが嫌い。
デグー (学名: Octodon degus) を多頭飼い

4
趣味: 健康でいること

5
本日はテックブログでも書いた話をします

6
Q. どんなサービスを作ってる？

7
引用元スタディスト会社案内

8

9
本日はこちら

10
これまでの TeachmeBiz の技術構成
JavaScript vue 2.x
vuex 3.x
vue-router
webpack 5.x Jest
eslint
Storybook reg-suit
babel

11
これまでの TeachmeBiz の技術構成
vue 2.x
vuex 3.x
vue-router
webpack 5.x Jest
eslint
Storybook reg-suit
babel
JavaScript
TypeScript に差し替えたい

12
Q. なぜ TS 移行を決意した？

13
A. JavaScript では型が見えず、
多くの問題が潜んでいたため

14
JavaScript では型が見えず、多くの問題が潜んでいる
危険非効率
無秩序暗黙知

15
問題1: 危険
● 値に Null が入る可能性があるか判断できない
○ 必要なチェックを怠ると障害へ
○ 不要なチェックをやりすぎると冗長に
危険非効率
無秩序暗黙知

16
問題2: 無秩序
● 型情報がないと自由度が高まり、一貫性のないコードが量産されてしまう
○ 同じようなデータ構造が至るところで定義されている
○ 守られないアーキテクチャ
危険非効率
無秩序暗黙知

17
問題3: 非効率
● 型情報がないとエディタが型推論できず、開発生産性が下がる
○ 関数名や定数名の補完が効かず、参照先のファイルからコピペなどが必要
○ タイポなどの凡ミスも実行時まで気づけない
危険非効率
無秩序暗黙知

18
問題4: 暗黙知
● コードに関する情報が得づらい
○ データモデルにはどんな情報が入ってくるかは経験則でしか得られない
○ 関数の使い方は実装を読み込まないとわからない
危険非効率
無秩序暗黙知

19
4つの問題は、サービスがスケールするほどに顕著になる
危険非効率
無秩序暗黙知

20
TypeScript 移行で解決する
危険非効率
無秩序暗黙知

21
Null 安全化非効率
無秩序暗黙知

22
Null 安全化非効率
厳密な型定義によるアー
キテクチャの保護暗黙知

23
Null 安全化
型定義によってエディタのパ
ワーを最大限に引き出す
キテクチャの保護暗黙知

24
Null 安全化
型定義によってエディタのパ
ワーを最大限に引き出す
型がそのままドキュメントに
キテクチャの保護

25
Q. 誰が移行作業する？

26
A. 一人専任

27
技術支援ユニットの責務として、一人で実施
技術支援ユニット
Web App 1U Web App 2U Web App 3U Web App 4U

28
技術支援ユニットの責務として、一人で実施
技術支援U
機能A担当機能B担当機能C担当機能D担当

29
チーム横断の技術支援ユニットが行うことで、機能開発を止めず
に移行作業を並走できる
技術支援ユニット
チームを横断した技術的な課題解決を担当
フロントエンドが得意な人バックエンドが得意な人

30
Q. TypeScript に詳しい人は居た？

31
A. いなかった

32
まずは自分がリードできるようになろう

33
社内輪読を通じて開発メンバーに布教しよう

34
Q. 移行対象は？

35
A. 全ての .js ファイル (≠ .vue)

36
全ての JS ファイルを厳しいルールで移行する
● strict: true
● @ts-ignore 禁止
● 明示的な any は許可
● ファイル内の一部のみの移行は禁止

37
Q. なぜ .vue を含まない？

38
A. Vue 3 への移行を見据えるため

39
将来的な Vue 3 移行を見据えると、TS化は二度手間に
● <script setup> など、 composition API でのコードの書き換えが発生する
● vuex との繋ぎ込み (eg. mapActions) を型安全にするのが不可能
● 型安全を必要とするロジックはコンポーネントから切り出すべき

40
Q. 移行時にリファクタはするのか？

41
A. 全力でする

42

43
素直に既存コードのまま型を付けるとカオ
スな型が出来上がりそう

44
リファクタリングと型定義を同時に行い、クリー
ンなコード、シンプルな型
にしてこそ価値が生まれる

45
TS移行とリファクタを同時に行うことは
アンチパターンとされるとも
引用元

46
アンチパターンとする主な理由
● 変更差分が大きくなり、通常の機能開発とのバッティングが起こりやすい
● レビューの観点が二重になる
● TS移行はデグレが起こらないが、リファクタリングはデグレが起こる
● 時間がかかりすぎる

47
開発組織によっては大した問題ではない
● アジャイルがそこそこ出来てるので、コードの合流が小さく早い
● 単体テスト、E2Eテスト、VRT が成熟しており、多くの問題は事前に拾える
● 技術支援Uという、機能開発を行わない専門チームであるため、時間をしっかりかけられる

48
Q. 移行期間は？

49
A. 半年で7割以上の移行完了

50
2021/03 - 2021/08 笹木の稼働時間の 4割 ≒ 2.4人月
約6ヶ月間の TypeScript 移行 + リファクタ期間を設ける

51
Q. どのように進める？

52
A. 関連するファイルの塊単位で
移行して本番リリース

53
移行順序
1. 副作用のない、ドメインに依存しない汎用ロジック
2. 副作用のない、ドメイン知識をもったロジック
3. ドメインと密接なデータモデル
4. Vuex ストア, VueRouter, Vueプラグイン
5. テストコードなど

54
105 PR (全てレビュー、本番リリース済み)

55
× 105

56
Q. 進捗をどう管理した？

57
A. 各コミット時点での移行率を可視化

58
移行率を毎コミットで計算

59
進捗率を可視化

60
Q. 移行して良くなった？

61
A. まだわからない！

62
移行が完了して開発に変化は起き始めた
● 各開発チームが新規コードを書く場合は必ず TypeScript を使うようになった
● データの型を意識した設計が求められるようになり、丁寧なコードを書くようになった
● エディタ上での補完が強力になり、開発効率が高まった

63
Q. なぜ移行が上手く行った？

64
TypeScript 移行が上手く行った理由
● 技術支援ユニットという、機能開発から独立した部隊が存在すること
● 各社の事例分析や TypeScript の学習を重ねる準備期間を充分に設けたこと
● 期間と範囲を決め、トラッキングしながら集中対応したこと
● CI/CD によって、自動テスト/手動テストのための仕組みが揃っていた

65
Q. 移行で上手く行かなかったことは？

66
TypeScript 移行における反省点
● TypeScript 強者が欲しかった
○ いくら事前準備したとはいえ、付け焼き刃な面も少なからずあり不安
● やっぱりデグレは起きた (3回)
○ いずれも軽微な問題だったので即日修正、テスト強化済み

67
まとめ

68
まとめ
● Teachme Biz では、(ほぼ) すべての JS ファイルの TypeScript 移行を行った
● 移行はリファクタリングを同時に行い、技術支援ユニットのメンバー一人で半年間行った
● CI/CD が整備されていたため、いくつかのファイルの塊ごとに移行し、すぐに本番反映した
● 移行により、コードが堅牢になったり、補完が効くようになったりと効果が見えてきた

6万行の TypeScript 移行とその後

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 6万行の TypeScript 移行とその後

Similar to 6万行の TypeScript 移行とその後 (20)

Recently uploaded

Recently uploaded (10)

6万行の TypeScript 移行とその後