TypeScriptでプロジェクトを約25万行に変換して生き残った物語

2016年、静的に型付けされたJavaScriptが非常に人気があることが判明しました。 多くの企業は、これらまたはその他の手段を利用して、JSの動的な性質の欠点を排除しました。 また、私たちの設計で静的型付けの巨大な可能性を利用する見通しに魅了されました。


ツールを選択して、以前にTypeScriptとFlowに決めました。 これらのプロジェクトは異なりますが、同じ問題を解決することを目的としています。 つまり、データ型を制御できるようにすることで、純粋なJS、コード編成、リファクタリング機能の向上、プログラマーの迅速かつ確実な作業に比べて、より高度な機能を提供します。

Coherent LabsおよびTypeScript

私が取り組んでいるプロジェクトは、主にJavaScriptで記述されたHTMLゲーム用のビジュアルユーザーインターフェイスエディターで、コードが10万行を超えました。 エディターには多くの機能が搭載されているため、そのコードベースの保守とリファクタリングがより困難になっています。 それが、私たちがいくつかの研究を行い、直面している問題の解決策を見つけることにした理由です。

しばらくして、TypeScriptとFlowの2つのオプションに到達しました。 どちらもコード制御を改善するために静的型を提供することを約束しましたが、これだけでは十分ではありませんでした。 ES6と言語の将来のバージョンのフルパワーを使用したかったのです。 実際、フローは静的コードアナライザーです。つまり、すべてのES6コードにトランスパイラーを使用する必要がありますが、JavaScriptのアドオンであるTypeScriptを使用すると、静的タイプと最新のECMAScript機能のほとんどのサポートの両方が得られます。

上記を考慮すると、最終決定を下すことは難しくありませんでした。 TypeScriptに決めました。

静的に型付けされたJavaScriptの人気について

少し脱線して、静的型付けとは何か、そしてJavaScriptの動的な世界でどのように位置付けられたのかについて話しましょう。

静的型付け言語と動的型付け言語の主な違いは、データ型の検証方法です。 前者はコンパイル中にこれを行い、後者はプログラム実行中に行います。 言い換えれば、静的に型付けされた言語では、プログラマーが使用する前にデータ型を宣言する必要がありますが、動的に型付けされた言語ではこれは必要ありません。

JavaScriptは動的に型付けされた言語であるため、さまざまな操作でさまざまなタイプのデータを使用できます。 JavaやC ++などの静的に型付けされた言語からJSにアクセスする開発者にとって、これはほとんどの場合、完全に非論理的であり、奇妙にさえ見えます。 これは、大規模プロジェクトで深刻な問題につながります。 たとえば、プログラマーは、特定の変数がNaNであることが判明した理由を把握するだけで多くの時間を費やす必要があるかもしれません。

TypeScriptとFlowは、このような問題を解決するために作成されました。 過去2年間で人気を博し、タイプチェックのみに焦点を当てたサポートフローは、Facebookに従事しています。 一方、Microsoftが手がけたTypeScriptは、JavaScriptアドオンです。 つまり、型チェックをサポートするだけでなく、ES6およびES7の将来の機能を使用することもできます。 どちらにも、コードを純粋なJavaScriptに変換するコンパイラーがあり、任意のブラウザーで実行できます。

型付きJavaScriptを使用する利点の一部を次に示します。

• コードの可読性が向上します。
• エラーの早期発見に貢献します。
• より信頼性の高いリファクタリングの機会を提供します。
• IDEレベルでの言語サポートが向上します。

型付きJavaScriptを使用したプロジェクトの開発の可能性を決定する際には、次の質問を自問してください。

• あなたのビジネスにとってプロジェクトは重要ですか？
• プロジェクトは多くの複雑な部分で構成されていますか？
• ニーズに合わせてプロジェクトをリファクタリングする予定はありますか？
• 開発者がコードベースの研究と、それに関する独自の知識を最新の状態に維持するために費やす時間を最小限に抑える必要がある大規模なチームがありますか？
  

これらの質問に対する回答のほとんどが肯定的な場合、プロジェクトをTypeScriptまたはFlowに移行することを検討する必要があります。

タイタンの永遠の衝突：TypeScriptとフロー

既に述べたように、FlowとTypeScriptはどちらもJS開発者に非常に重要な、そして私の意見では非常に必要な機能である型システムを提供します。

TypeScriptは、Anders Halesbergが最初のリリースをリリースしたときに、Microsoftの支援を受けて2012年に登場しました。 とりわけ、オプションのタイプ注釈とES6およびES7の機能をサポートしています。 彼は注釈を処理し、プレーンなJavaScriptでコードを生成するコンパイラーを持っています。

Flowは、Facebookが行う静的コードアナライザーです。 JavaScriptアプリケーションのエラーをすばやく見つけるように設計されています。 これはコンパイラではなく、アナライザです。 型注釈がまったくなくても機能し、変数型を導出するタスクで完全に表示されます。

簡単な例を見てみましょう。 次の関数があり、名前を取得すると挨拶が返されます。

function greet = function(name) {   return `Hello, ${name}!`; } 

TypeScriptとFlowの両方で、この関数は次のようになります。

 function greet(name: string): string {  return `Hello, ${name}!`; } 

関数パラメーターの後の「文字列」は、TypeScriptおよびFlowでタイプを設定する方法です。 タイプは単純または複合のいずれかです。 これは、指定されたものとは異なるタイプの引数を使用しようとすると、エラーメッセージが生成されることを意味します。 関数の使用例を考えてみましょう。

 const message = greet(43); 

引数として数値を渡すことにより、関数を呼び出しました。 コードをコンパイルすると、TypeScriptはエラーが発生したことを示すメッセージを表示します。

 Argument of type 'number' is not assignable to parameter of type 'string.' 

コンパイル中にそのようなエラーをキャッチすると、生産性や開発者の気分に非常に良い影響を与える可能性があります。 TypeScriptは、矢印関数、インポートとエクスポート、ジェネレーター、非同期/待機メカニズム、クラスなどの高度なJS機能もサポートしています。 最終的に、TypeScriptはJavaScriptアプリケーション開発の優れたエコシステムを構築することを可能にします。

それでは、20万行を超えるコードを含むプロジェクトをTypeScriptにどのように変換したかについてお話ししましょう。

ステップ1-テクノロジーの選択

私たちのプロジェクトは急速に発展しており、時間の経過とともにコードベースの量はほぼ指数関数的に増加しました。 当時、TypeScriptと静的に型付けされたJavaScriptの人気が高まりました。 このすべてにおいて、私たちは逃してはならない機会を見ました。 いくつかの調査と数回の会議の後、2つの可能な旅行に落ち着きました。

• FlowとBabelを使用してES6をトランスパイルします。
• ES6 / ES7のコンパイルには、TypeScriptとそのコンパイラーを使用します。

いくつかの理由でTypeScriptを選択しました。

• 当時、TypeScriptにはより広いコミュニティがあり、より多くの資料がありました。
• アプリケーションの構築プロセスを複雑にしたくはありませんでしたが、これはすでに非常に困難でした。 Flowの使用時にさらに2つのステップを追加すると（FlowのコンパイルとBabelのトランスコンパイル）、処理がさらに遅くなります。 TypeScriptを使用すると、追加のアセンブリ手順を1つ追加するだけで十分に対応できるようになりました。
• TypeScriptは統合開発環境をよりよくサポートします。 私たちのチーム全体がWebStormを使用しています。これは、優れたTypeScriptサポートを提供します。
• ES5サポート。 私たちのシステムの中核はWebKitとJavaScriptCore上に構築されており、特定の制限があります。 ES5の標準機能の一部はサポートされていません。 その結果、TypeScriptの機能は、最終決定を下す上で主要な役割を果たしました。

6か月の作業の後、TypeScriptを選択することが正しい決定であったと正直に言うことができます。 プロジェクトを移動するプロセスのすべてがスムーズに行われたわけではありませんが、あまり複雑なことはありませんでした。

ステップ2-始まり

チーム全体が参加した移行プロセスの長い議論の後、小さなモジュールから始めて書き直すことにしました。 最初は、.jsファイル拡張子を.tsに置き換えることです。

次に、 grunt-tsを使用してアセンブリツール（Grunt）をセットアップし、約1日半後に、最初のTypeScriptモジュールの準備が整いました。 そのときの主な難点は、グローバルモジュールと外部モジュールを扱うことでした。 TypeScriptには厳密な入力規則があります。 その結果、TypeScriptコンパイラは、jQueryやKendo UIなどの補助ライブラリとそのメソッドを認識しません。 これによりすぐに200以上のコンパイルエラーが発生し、TypeScriptが$型の変数を見つけられなかったことを示しています。 解決策は非常に簡単でした。 declare命令を使用しました。

 declare var $; declare var kendo; ... 

declareキーワードは、いわゆるサラウンド広告を作成するために使用されます。 これらは、TypeScriptに、TSファイルではないデータ型に関する他のライブラリに関する情報を提供するために使用されます。 その状況では、これは完全に受け入れられるソリューションであることが判明しました。
この段階で、最初のモジュールをTypeScriptに正常に転送し、プロジェクト全体をTypeScriptに変換する準備を整えました。

ステップ3-移行

次のステップは、他のすべてのモジュールをTypeScriptに変換することでした。 それらのいくつかは高度に相互接続されており、それらを迅速に機能させる方法を考え出す必要がありました。 いくつかの追加調査と数時間のブレインストーミングの後、比較的単純な戦略を思いつきました。

まず、すべてのファイルの名前を変更して拡張子.tsを付けたところ、突如としてコンパイルエラーが発生しました。 次に、必要なTypeScript宣言を追加し、 Anyデータ型をいくつかの変数に割り当てました。 これにより、さまざまなタイプのデータを変数に書き込むことができます。 このようにして、文字列、数値、論理値など、さまざまなタイプのデータを格納できる変数が宣言されました。

型と宣言との2日間の闘争の後、最初の完全なTypeScriptコンパイルに至りました。 しかし、まだ多くの仕事がありました。 型チェックを改善し、外部ライブラリに適切な宣言を追加し、ES5コードをES6標準に準拠させる必要がありました。

アナウンスメントファイルには、ライブラリデバイスが記述されています。 それらを使用すると（.d.tsファイルとも呼ばれます）、ライブラリの誤用を回避し、コードエディターでのコマンド補完などの利便性を得ることができます。 TypeScript 1.8を使用する場合、新しい宣言ファイルを追加するには、個々のnpmパッケージをグローバルにインストールし、特定のライブラリの宣言ファイルを見つけ、すべてのライブラリ記述ファイルを「typings」フォルダーに保存する必要があります。 正直なところ、この決定は最もエレガントではありませんでした。 TypeScript 2.0には、npmレジストリを使用して、ライブラリ宣言を管理する新しい方法があります。 これはすべて、いくつかのチームで現在行われています。 最初のインストールは次のとおりです。

 npm install --save @types/jquery 

次に、必要な場所にインポートします。

 import * as $ from 'jquery' 

その結果、ファイルやフォルダに飽き飽きすることはなくなりました。
そこで、外部ライブラリを見つけました。 次のステップは、 Any型のすべての宣言を適切なデータ型に変更することでした。 このタスクには数日かかりました。 急いでコードを段階的に廃止しないことにしました。 特に、ES6のリファクタリングとタイプ変更が実行されました。 数週間後、コードの80％を段階的にES6に転送し、意味のある型注釈を付けました。 この段階で、作業の次の段階であるテストに進むことができました。

テストとTypeScript

私たちの開発環境は理想に近く、プロジェクトの次の大きな段階であるエンドツーエンド（E2E）テストの準備ができていました。 JavaScriptを使用することにしました。 私たちの武器は、Mocha、Chai、Selenium、およびWebDriver Seleniumです。 テストコード（Seleniumフレームワーク、テスト、およびすべての依存関係）を分離し、個別のtsconfig.jsonを提供しました。

ディレクトリにtsconfig.jsonファイルが存在することは、そのディレクトリがTypeScriptプロジェクトのルートであることを示しています。 このファイルは、ルートファイルとコンパイラオプションを設定します。

プロジェクト自体用にこのようなファイルを1つ作成し、さまざまな構成ファイルを正しく使用するためにGruntタスクをリファクタリングする必要がありました。 これで、Seleniumフレームワークの使用を開始する準備が整いました。

フレームワーク構造は、7つのメインモジュールと5つの補助モジュールで構成されています。 主なモジュールは次のとおりです。

• Seleniumを開始および停止し、タイムアウトを管理するドライバーハンドラー。
  
• テストで使用されるすべての要素を含むセレクターモジュール。
• メインアクションファイル。アプリケーションのさまざまな部分で作業を整理し、マウスクリック、要素の選択、データの入力など、アプリケーションとの対話を実行します。
• リソースをエクスポートおよび削除するためのモジュール。
• ロギングモジュール。
• テストが失敗するたびにスクリーンショットを撮るスクリーンキャプチャモジュール。
  
• バックエンドAPIをシミュレートするためのモジュール。

サポートモジュールはテストカテゴリに分類されます。 そのため、JavaScriptランタイムモジュール、プロパティパネルモジュール、タイムラインパネルモジュールなどがありました。 それらのすべてには、特定のタスクを実行するためのメソッドがあります。

さらに、レポート作成ツールmochawesomeを追加しました。これは、すべてのテストの完了後に完全なレポートを表示しました。

TypeScriptのおかげで、 async / await機能をプロジェクトで使用できるようになりました。その結果、よりクリーンで優れたコードになりました。

今後の計画

実際、私が話したことはほんの始まりにすぎません。 TypeScriptへの切り替えは、バケットにドロップするだけです。 まだやることがたくさんあります。 計画の一部を次に示します。

• プロジェクトアーキテクチャ全体をリファクタリングします。
• 3D選択および境界ボックス、要素のデータバインディングへの視覚的ポインターなどの新機能を追加します。
• 全体的なテスト実行時間を改善します。 現在、440のテストを完了するのに約30分かかります。

さらに、ReactやInfernoJSなどの仮想DOMをサポートするライブラリを実験しています。 どちらもTypeScriptを非常によくサポートしているため、プロジェクトは仮想DOMで機能するパフォーマンスの向上から大きな恩恵を受けることができます。
TypeScriptの開発を密接に追跡しています。 最近のリリースでは、オブジェクトを操作するためのタイプマッピング、スプレッドおよびレスト演算子、ES3およびES5でのコンパイル時の非同期関数のサポートなどの新機能が提供されます。 将来のリリースでは、ES3 / ES5のジェネレーターのサポート、一般的なプログラミングツールの改善、非同期イテレーターが予定されています。

まとめ

私たちのプロジェクトでTypeScriptを使用するという決定は正しいことが判明し、多くの良い結果をもたらしました。 特に、これは労働生産性の向上、コード管理の改善、およびES6サポートです。 当初、私はTypeScriptに不信感を持っていましたが、TypeScriptを使用した後、非常に長い間行方不明になっていたと言えます。

TypeScriptを試して実験することを強くお勧めしますが、独自のプロジェクトをTypeScriptに変換することを検討する際には、すべての詳細を考慮する必要があります。 コードベースの処理に必要な時間、プロジェクトの機能、リファクタリングの必要性、そして最も重要なこととして、TypeScriptに関する開発チームの意見を考慮する必要があります。

最後に、もちろん、TypeScriptは重要な現象と見なすことができ、JavaScriptの世界への影響はそれを改善するでしょう。

開発者の皆さん！ JavaScriptの静的型付けについてどう思いますか？ 大規模なJSプロジェクトを作り直す場合、何を選びますか？