静的型チェックを行うTypeScriptで品質を担保しよう

基礎からはじめるReact Native入門 第12回

　ソースコードが大規模になってくると、データ型を定義して静的型チェックを行うツールを重宝するようになります。React Nativeでは、Microsoftが提供しているTypeScriptというプログラミング言語を利用することで、JavaScriptコードの中に型を記述することができます。Propsや変数、引数などに、どのように型を定義するのか、型を定義することでどんな恩恵が得られるのかを見ていきましょう。

対象読者

• JavaScriptとWeb開発の基礎に理解がある方
• Reactを用いたJavaScriptアプリケーション開発の未経験者

前提環境

　筆者の検証環境は以下の通りです。

• macOS Catalina 10.15.4
• Node.js 14.2.0／npm 6.14.4
• expo-cli 3.20.9
• expo 36.0.2（React Native 0.61）
• React 16.9.0
• TypeScript 3.9.2

複数人で開発を行う難しさ

　仕事としてアプリを作る場合、分業や引き継ぎなどをしていく内に、1つのコードベースに複数の人間が関わることになるのは、珍しいことではありません。後から入ってきた人でも作成の意図が読み取れるコードもあれば、なかなか意図が読み取れないコードもあるかもしれません。

　単独のコードでは意図が読み取りづらい例を見てみましょう。前回のメモアプリでデータの保存に使っていたsave関数は、リスト1の通りに定義されていました。

［リスト1］第2引数の型はDateかnumberかstringか

const save = async (text, createdAt) => {
  // (略)
};

　第2引数のcreatedAtには、どんな型の値が渡されるでしょうか。名前から日時を表していることは分かりますが、日時はDateでもnumberでもstringでも表現できます。どれが正しいかはこの関数の実装を読み、呼び出し元でどんな値を渡しているのかを見に行くことで、調べることができるでしょう。実装次第では少し広い範囲を調べることになるかもしれません。

　string型であることが容易に想像できる、第1引数のtextにも罠があります。呼び出し元の実装次第では、nullやundefinedが渡されてくるかもしれません。呼び出し元の実装を熟読するか、この関数の中で丁寧に条件分岐を行い、文字列ではない値に対処できるようにしておく必要があるでしょう。

　コードベースが大きくなればなるほど、こういった手間はじわじわと開発効率や品質に影響を及ぼします。常に修正箇所の周辺コードを正しく読解できれば良いのですが、実際には、先入観や体調不良による見逃しがあったり、メンバーの経験不足があったりして考慮漏れは発生します。

静的型チェックでコードの意図を伝える

　こういった課題への対策の1つとして有効なのが、型注釈を追記したコードに対して実行前にスキャンをかけて、データ型の齟齬を発見しようとする仕組みである、静的型チェックという分野です。型注釈の例を挙げてみましょう（リスト2）。

［リスト2］型注釈でコードの意図を明示する

const save = async (text: string, createdAt: number) => {
  // (略)
};

　リスト1との違いとして、引数の右側にコロン区切りで : stringや: numberといったデータ型を明示しています。これが型注釈です。この型注釈の記述を頼りに、静的型チェックのツールでは「関数内でtextはstring型として扱われているか」や「save関数を呼び出すとき、第2引数にnumber型を渡しているか」などのチェックを行います。

　こういったチェックをコードベースの一部ないし全体に行うことで、人間が目視で確認するべきコードの量を減らし、効率化や品質の向上を目指すことができます。