Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
Introduction to TypeScript
Ken Wagatsuma
March 08, 2019
Programming
0
630
Introduction to TypeScript
Ken Wagatsuma
March 08, 2019
Tweet
Share
More Decks by Ken Wagatsuma
See All by Ken Wagatsuma
Pregel Graph Compute Engines - Supersteps Exampls
kenju
1
88
Kafka on Kubernetes with Strimzi
kenju
1
68
AWS DynamoDB Accelerator (DAX) 101
kenju
3
6.1k
Moden browser introduction
kenju
1
290
Cookpad summer internship 2019 - API
kenju
0
9.5k
Introduction to Design Patterns
kenju
0
9
GraphQL Asia 2019 "Re-architecture of a decade-old app with BFF/GraphQL"
kenju
0
8.6k
Introduction to Programmatic Ad
kenju
0
100
社内管理システムのための技術選定
kenju
0
690
Other Decks in Programming
See All in Programming
低レイヤーから始める GUI
fadis
18
9.4k
23年のJavaトレンドは?Quarkusで理解するコンテナネイティブJava
tatsuya1bm
1
120
OIDC仕様に準拠した Makuake ID連携基盤構築の裏側
ymtdzzz
0
560
データドリブンな組織の不正検知
fkubota
0
260
Amazon QuickSightのアップデート -re:Invent 2022の復習&2022年ハイライト-
shogo452
0
230
tidy_rpart
bk_18
0
600
Glance App Widgetでウィジェットを作ろう / MoT TechTalk #15
mot_techtalk
0
120
AWSとCPUのムフフな関係
cmdemura
0
470
子育てとEMと転職と
_atsushisakai
1
410
Enumを自動で網羅的にテストしてみた
estie
0
1.3k
Swift Concurrency in GoodNotes
inamiy
4
1.3k
ECS Service Connectでマイクロサービスを繋いでみた
xblood
0
550
Featured
See All Featured
XXLCSS - How to scale CSS and keep your sanity
sugarenia
236
1.1M
StorybookのUI Testing Handbookを読んだ
zakiyama
8
3.2k
Navigating Team Friction
lara
177
12k
Statistics for Hackers
jakevdp
785
210k
It's Worth the Effort
3n
177
26k
Facilitating Awesome Meetings
lara
33
4.6k
Agile that works and the tools we love
rasmusluckow
320
20k
Writing Fast Ruby
sferik
613
58k
Three Pipe Problems
jasonvnalue
89
8.9k
The Invisible Side of Design
smashingmag
292
48k
From Idea to $5000 a Month in 5 Months
shpigford
374
44k
Large-scale JavaScript Application Architecture
addyosmani
499
110k
Transcript
Introduction to TypeScript March, 2019 Kenju Wagatsuma Cookpad Inc.
Why “TypeScript”?
なぜ TypeScript を導入するのか 目的 ・静的型付けを導入し、アプリの品質を向上させるため ・静的型付けを JavaScript の世界に導入する中で一番妥当な選択肢が、TypeScript 前提 開発基盤やテスト環境は昨年一年間を通して大きく整備してきた、残りのピースが静的型付け
・依存ライブラリの取捨選択および最新版へのアップデート ・副作用のある DOM テストの疎結合化および Coverage の向上 ・JSHint -> ESLint や Phantomjs -> Headless Chrome などのツールチェーンの移行
アプリの品質を高めるためのベース ドメイン知識 (業務フローへの理解 / 知見共有会 / ビジネス目標の浸透) 静的型付け (TypeScript Compiler)
静的解析 (ESLint) 可読性 (DefinitelyTyped / 独自の型定義) 単体テスト・結合テスト (Karma / Jasmine) デプロイ自動化 ライブラリの 定期アップデート リファクタリング のチーム文化醸成
なぜ社内広告 SDK から導入するのか 課題 前提となるドメイン知識が広く求めれる ・Programmatic Advertising / Header Bidding
/ 社内配信フロー ・したがって、品質担保のみならずコードの可読性も求められる ・JSDoc によるドキュメントの保守性が限界 3rd Party Librariesが多い ・Header Bidding だけでも apstag / googletag / pbjs などの 3rd Party Libraries に依存 ・その他動画広告 SDK や第三者配信タグ
なぜ facebook/flow ではないのか エコシステムの優越性 ・エディター拡張機能などの周辺ツールチェーンが TypeScript より未熟 ・世間的にも TypeScript 導入企業が増えてきて、ユーザーボリュームも
Flow より多い 持続的開発性 ・Microsoft で開発されている TypeScript の方が安心材料が多い メンバーのスキルメリット ・技術選定者がプロダクションでの TypeScript 導入に知見がある
なぜ静的型付けで品質があがるのか 参考)拙書『なぜチーム開発において型が好ましいとされるのか』 https://itiskj.hatenablog.com/entry/2019/02/04/102731 > オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング
) で紹介されている静的型付けの導入メリットは、以下の三点です。 ・信頼性 ・可読性 ・生産性
エラー修正コストと発見タイミング 仕様のエラーが発見された時間とエラー修正 にかかったコストをプロットした Boehm の有 名な研究によれば、発見が遅れれば遅れるほ ど、エラー修正のコストが膨れ上がる 発見タイミング (t) 修正コスト
Who does “TypeScript”?
TypeScript 世間の評判 https://insights.stackoverflow.com/survey/2018#most-loved-dreaded-and-wanted
TypeScript 世間の評判 https://octoverse.github.com/projects#languages
TypeScript 世間の評判 https://octoverse.github.com/projects#languages
TypeScript 世間の評判 https://www.bizreach.co.jp/pressroom/pressrelease/2018/0807.html
How to “TypeScript”?
TypeScript Compiler の役割 https://github.com/Microsoft/TypeScript/tree/master/src/compiler ・静的型の検査(型違反の検出) ・JavaScript コンパイル時に型定義の除去(実行可能な JS を出力) ・ES6+
から ES5 等のソースコード変換
型を当てなくても得られるメリット TypeScript Compiler が型違反検出以外に持つ機能 ・未到達リターンの検出( --noImplicitReturns) ・nullify の検出(--strictNullChecks) ・未使用引数など dead
code の検出(--noUnused{Locals|Parameters}) ・ES5 への変換(場合によっては Babel などのトランスパイラが不評) ref. https://www.typescriptlang.org/docs/handbook/compiler-options.html
型を当てると得られるメリット ・型違反の検出 ・Editor による補完(typescript-language-server) ・可読性の向上による保守性の向上
TypeScript 導入のデメリット ・学習コスト ・型定義のメンテナンス ・ビルドツールのメンテナンス
TypeScript 導入のリスク TypeScript のメンテナンスが停止する ・コミュニティ全体で何らかの移行パス・ツールが提供される期待は高い ・TypeScript がコンパイルした結果は「動く JS」 ・最悪の場合、コンパイル結果自体をメンテナンス対象とできる
どう TypeScript を導入するのか 徐々に型定義を当てていくことで漸進的移行が可能 ・noImplicitAny: false を許容する ・型推論と DefinitelyTyped で提供される型定義でかなりカバーできる
・最悪全て any でも生 JavaScript より圧倒的に品質担保可 ・「がんばらない TypeScript」
Recommended TypeScript Migration Roadmap 【導入期】まずは TypeScript Compiler を Build Pipeliens
に組み込む 【初期開発期】DefinitelyTyped ですぐ利用可能な型情報を組み込む 【漸進的運用期】徐々に独自の型定義を当てていく 【移行完了期】noImplicitAny=false に変更し、他の strict オプションも有効にする 【安定運用期】楽しい TypeScript Life を
TypeScript の主な機能 ref. https://www.typescriptlang.org/docs/handbook/basic-types.html ・Interfaces ・Generics ・Enums ・Namespaces ・Type Inference
その他多数
Build Pipeline 【静的解析】ESLint でスタイルガイドに沿わないコードを検出する 【ユニットテスト】仕様に沿わないコードを検出する 【コンパイル】TypeScript Compiler で ES5 にコンパイルし、型違反を検出する
【トランスパイル】Babel Transpiler でサポートブラウザ対応を行う 【その他諸々】Webpack で難読化 / Tree Shaking / Chunk Merging / Bundlize を行う
Babel との使い分け ・サポートブラウザが存在するため ES5 にビルドするだけでは不十分 ・TypeScript は ES5 にビルドし、Babel がサポートブラウザを意識し
Polyfills 注入などを担当する
Lint ・ECMAScript 6+ の書き方をメンバーにも浸透させるため、型定義に加えて静的解析も必要 ・TypeScript チームは TSLint ではなく ESLint をメンテナンスしていく方針にアナウンス(Jan,
2019 ) ・https://eslint.org/blog/2019/01/future-typescript-eslint ・typescript-eslint のプロジェクトが今後の開発対象 ・https://github.com/typescript-eslint/typescript-eslint ・ルールは ESLint で書き、@typescript-eslint/parser を用いることが今後の標準 ・JavaScript -> TypeScript への移行時も静的解析ツールの移行コストは最低限
Appendix
Good References ・mizchi’s blog 『TypeScript入門以前ガイド』 ・角待ちは対空『がんばらないTypeScriptのはじめ方』
Thank you!