こんにちは。コードレビューで「なぜその書き方では将来的にバグを生むのか」を論理的に説明し、チーム全体の型安全性を引き上げるのが私の一番の仕事だ。
フロントエンド開発、特にFlutterを用いたコンポーネント設計や、複雑な非同期APIのステート管理において、最も恐ろしいバグは何だと思うかね？
それは、「仕様変更でAPIのレスポンスや状態（Enum）が増えたのに、UI側のハンドリング漏れが実行時まで発覚しないこと」だ。
今回は、Dart 3で導入されたswitch式（Switch Expressions）と、コンパイラによる網羅性チェック（Exhaustiveness Checking）を武器に、将来の改修漏れによるプロダクション障害を完全に根絶する設計手法を伝授しよう。ネットのチュートリアルをなぞっただけのコードとは違う、「Dart VMの型システムを知り尽くした者」のコードレビューの視点をインストールしてほしい。
—
1. ありがちなアンチパターン：なぜ `if-else` や `default` は悪なのか
APIから送られてくるユーザーの権限や、非同期処理のロード状態をハンドリングする際、次のようなコードを書いていないだろうか？
// 【アンチパターン】保守性をドブに捨てる古い書き方
enum UserRole { guest, member, admin }
String getDashboardTitle(UserRole role) {
if (role == UserRole.guest) {
return ‘ゲスト画面’;
} else if (role == UserRole.member) {
return ‘メンバー画面’;
} else {
return ‘管理者画面’; // ここに落とし穴がある！
}
}
このコードの何が問題か？
もし将来、プロダクトの成長に伴って `UserRole.superAdmin` が追加されたとする。その時、この関数の最後の `else`（あるいは `default`）は、何もコンパイルエラーを出さずに `管理者画面` という文字列を返し続ける。これが「サイレント・バグ」の正体だ。開発者は気づかないままリリースし、最悪の場合、権限昇格に関する致命的なセキュリティインシデントに繋がる。
「そんなのテストを書けばいい」と思うかね？
甘い。コンパイラが静的に検知できるエラーを、人間のテストやレビューに頼る時点でエンジニアリングの敗北だ。
—
2. Dart 3 パターンマッチングと網羅性チェックの極意
Dart 3以降、`switch` は単なる制御構文（Statement）ではなく、値を返す式（Expression）として機能するようになった。そして、Dartの静的型チェッカー（CFE: Common Front End）は、入力された型のすべてのケースが網羅されているかをコンパイル時に厳密に検証する。
先ほどのコードを、Dart 3のswitch式を使って書き換えてみよう。
// 【プロダクション品質】コンパイラに守られた堅牢なコード
enum UserRole { guest, member, admin }
String getDashboardTitle(UserRole role) => switch (role) {
UserRole.guest => ‘ゲスト画面’,
UserRole.member => ‘メンバー画面’,
UserRole.admin => ‘管理者画面’,
// ここに ‘UserRole.superAdmin’ が追加された瞬間、
// コンパイラが「The type ‘UserRole’ is not exhaustively matched…」とエラーを吐く。
};
これが網羅性チェック（Exhaustiveness Checking）だ。
`default` 句やワイルドカード（`_`）を安易に置かないこと。これが極限までバグを防ぐコードを書くための鉄則である。すべての可能性を明示的に列挙させ、未来の自分が（あるいは別のメンバーが）Enumに要素を追加した際、「コンパイルエラーを直すまでビルドできない状態」を強制するのだ。
—
3. 【実践】非同期API連携とコンポーネント設計への応用
では、実務のフロントエンド開発でこれをどう応用するか。
よくある「非同期APIのステート（未取得、ローディング、成功、エラー）」を表現する Sealedクラス（または Enum）と、UIコンポーネントをマッピングする例を見てみよう。
以下のコードは、そのままプロダクションのコードベースにコピーして、その堅牢性を体感してほしい。
import ‘package:flutter/material.dart’;
// 1. 状態を表現する Sealed Class（または Enum）
sealed class ApiState
const ApiState();
}
class ApiInitial
const ApiInitial();
}
class ApiLoading
const ApiLoading();
}
class ApiSuccess
final T data;
const ApiSuccess(this.data);
}
class ApiError
final Object error;
const ApiError(this.error);
}
// 2. ウィジェットを返すビューコンポーネント
class UserProfileView extends StatelessWidget {
final ApiState
const UserProfileView({super.key, required this.state});
@override
Widget build(BuildContext context) {
// switch式を用いて、すべての状態を完全に網羅してUIに変換する
return switch (state) {
ApiInitial() => const Text(‘データを取得していません’),
ApiLoading() => const CircularProgressIndicator(),
ApiSuccess(data: final userName) => Text(‘ようこそ、$userNameさん！’),
ApiError(error: final err) => Text(‘エラーが発生しました: $err’),
// ※もし将来 ApiMaintenance（メンテナンス中）という状態が追加された場合、
// このswitch式がコンパイルエラーになり、対応漏れを完全に防げます。
};
}
}
チーフアーキテクトからの設計上のアドバイス
1. `default` や `_` を逃げ道にしない
`_ => …` を使いたくなる衝動に駆られる時があるだろう。しかし、EnumやSealed階層のハンドリングにおいて `_` を使うのは、「新しい仕様追加時にバグをスルーする権利」を買うようなものだ。例外的なケースを除き、すべてのサブタイプを明示的に書くこと。
2. パターンマッチングのパフォーマンス
Dartのswitch式は、Dart VMの最適化フェーズにおいて非常に効率的なジャンプテーブルやインラインキャッシュにコンパイルされる。`if-else` の連鎖による $O(N)$ の評価よりも高速に動作する場合が多く、パフォーマンス上の懸念は一切ない。安心して型安全の恩恵を受けたまえ。
—
結び
コードの品質は、「いかに天才的なコードを書くか」ではなく、「凡人が間違えようのない仕組みをどう構築するか」で決まる。
Dart 3のswitch式と網羅性チェックは、あなたのチームから「仕様変更に伴うUIの表示漏れ・クラッシュ」という無駄なバグを永遠に駆逐する強力な武器だ。
今日のコードレビューから、`default` が書かれたswitch文を見つけたら、こう指摘してあげてほしい。
「おい、コンパイラに仕事をさせていないぞ。すべてのケースを明示的に網羅しろ」と。