「実行」の前に「予行」を。DartとFlutter開発における--dry-runの流儀 ~ Dev.

コマンドを一つ実行した直後、背筋が凍るような感覚を覚えたことはありませんか？タイプミスで意図しないプロジェクト名が生成されたり、予期せぬパッケージのメジャーアップデートがビルドを破壊したり、あるいは重要な設定ファイルが上書きされたり。開発者であれば、誰しも一度は「実行する前に確認できたら…」と願ったことがあるはずです。DartとFlutterのコマンドラインインターフェース（CLI）には、まさにその願いを叶えるための強力な安全装置が組み込まれています。それが--dry-runオプションです。

このオプションは、単なる便利なフラグではありません。それは、開発プロセスにおけるリスクを管理し、コマンドの動作を深く理解し、チームとの円滑なコミュニケーションを促進するための「哲学」とも言えるものです。この記事では、--dry-runオプションの基本的な使い方から、その真価を最大限に引き出すための高度なテクニック、そして開発ワークフロー全体にポジティブな影響を与えるための考え方まで、包括的に探求していきます。--dry-runを単なるコマンドの末尾につけるおまじないではなく、意識的に使いこなす「流儀」として身につけましょう。

--dry-runとは何か？- コマンドの「シミュレーションモード」

--dry-run（ドライラン）は、直訳すると「乾いた走行」、つまり「本番ではない、予行演習」を意味します。ITの世界では、実際の変更を伴わずに操作の結果をシミュレートするモードを指す言葉として広く使われています。DartとFlutter CLIにおける--dry-runオプションも、まさにこの役割を果たします。

このオプションを付けてコマンドを実行すると、CLIツールは以下の動作を行います。

通常通りの処理を実行: コマンドは、オプションなしで実行された場合とほぼ同じ内部ロジックをたどります。設定を読み込み、引数を解釈し、依存関係を解決し、生成するファイルリストを作成します。
最終的な書き込みをスキップ: 最も重要な違いは、ファイルシステムへの書き込み、ファイルの変更、削除、ネットワーク越しのパッケージダウンロードといった「永続的な変更」を一切行わない点です。
実行結果のレポート: 変更を行う代わりに、「もし実行されていたら、どのような変更が行われたか」を詳細にコンソールへ出力します。どのファイルが作成され、どのパッケージが更新され、どのディレクトリが生成されるかといった情報が、人間が読みやすい形式で表示されます。

これをパイロットのフライトシミュレーターに例えると分かりやすいでしょう。パイロットは、実際に飛行機を飛ばす前に、シミュレーターであらゆる状況を試し、操作の影響を安全に確認します。同様に、開発者は--dry-runを使って、プロジェクトという「飛行機」に影響を与えることなく、コマンドという「操作」の結果を正確に予測し、安全を確認できるのです。これは、推測や勘に頼った開発から、確信に基づいた開発へと移行するための重要なステップです。

なぜ--dry-runが不可欠なのか？- 開発ワークフローを変える4つの利点

--dry-runの価値は、単にミスを防ぐことだけに留まりません。意識的に活用することで、開発ワークフロー全体をより堅牢で、効率的で、協力しやすいものへと変革させる力を持っています。

1. 破壊的な変更を防ぐ「安全網」

これが最も直接的で分かりやすい利点です。特に影響範囲の大きい操作において、--dry-runは不可欠な安全網となります。

依存関係の更新: flutter pub upgradeは、時に破壊的な変更をもたらす可能性があります。あるパッケージのメジャーバージョンが上がることで、APIの互換性がなくなり、コンパイルエラーが大量に発生することがあります。--dry-runを使えば、どのパッケージがどのバージョンに更新されるのかを事前にリストアップし、変更履歴（Changelog）を確認して影響を評価する時間的余裕が生まれます。
ファイルの上書き: 新しいプロジェクトやモジュールを作成する際、既存のディレクトリ名と重複してしまうと、意図せずファイルが上書きされる危険性があります。--dry-runは、作成されるファイルとディレクトリのリストを示すため、このような衝突を未然に防ぎます。
CI/CDパイプラインの保護: 自動化された環境では、一つのコマンドの失敗が全体のデプロイメントを停止させる可能性があります。本番環境に変更を適用するスクリプトに--dry-runのステップを組み込むことで、実際のデプロイ前に潜在的な問題を検知できます。

2. コマンドのブラックボックス化を防ぐ「透明性」

flutter createやdart run build_runner buildのようなコマンドは、内部で非常に多くの処理を行っています。これらのコマンドを、何が起きているか分からない「魔法の呪文」として使っていると、問題が発生したときのトラブルシューティングが困難になります。

--dry-runは、このブラックボックスに光を当て、内部で何が行われているのかを可視化します。flutter createがどのようなディレクトリ構造を作り、どのような設定ファイル（.gitignore, analysis_options.yamlなど）を初期状態で生成するのか。build_runnerがどのソースファイルを監視し、どの.g.dartファイルを生成・更新しようとしているのか。これらの詳細を把握することで、ツールの動作原理への理解が深まり、より高度なカスタマイズや問題解決能力が身につきます。

3. 恐れずに試せる「学習ツール」

特にDartやFlutterを学び始めたばかりの開発者にとって、CLIは威圧的に感じられるかもしれません。「このオプションを付けたらどうなるんだろう？」という好奇心はあっても、プロジェクトを壊してしまう恐怖から試すことをためらいがちです。

--dry-runは、この恐怖を取り除く完璧な学習ツールです。サンドボックスのように、何度でも、どんなオプションの組み合わせでも、リスクゼロで試すことができます。

flutter createの様々なテンプレート（--template=app, --template=package, --template=plugin）がどのような違いを生むのか。
--orgフラグがiOSのBundle IDやAndroidのPackage Nameにどう影響するのか。
--platformsフラグで特定のプラットフォーム向けファイルだけを生成できること。

これらの知識を、ドキュメントを読むだけでなく、実際に自分の目で確かめながら能動的に学ぶことができるのです。

4. 変更意図を明確にする「コミュニケーションツール」

チーム開発において、なぜその変更を行ったのかを伝えることは非常に重要です。特に、依存関係の変更やプロジェクト構造に関わる変更は、他のメンバーに大きな影響を与える可能性があります。

--dry-runの出力を活用することで、コミュニケーションがより明確かつ効率的になります。例えば、Pull Request（PR）やMerge Request（MR）の説明文に、flutter pub upgrade --dry-runの出力を貼り付けることで、レビュアーはコードの変更だけでなく、どの依存関係がなぜ更新されたのかを一目で把握できます。

「providerを6.0.5から6.1.1に更新します」というテキストだけでなく、ドライランの出力を見せることで、「この更新はflutter_lintsのバージョンアップに伴う推移的な依存関係の解決によるものです」といった背景情報まで含めて、変更の意図と影響範囲を正確に伝えることができます。

実践編: --dry-runを使いこなす具体的なシナリオ

理論を学んだところで、次は--dry-runが実際にどのように機能するのか、具体的なシナリオを通じて見ていきましょう。

シナリオ1: `flutter create` - プロジェクトの設計図を事前に確認する

新しいFlutterプロジェクトを開始する最初のステップであるflutter createは、--dry-runの恩恵を最も受けやすいコマンドの一つです。

基本パターン

まず、最もシンプルな使い方です。


$ flutter create --dry-run my_awesome_app

このコマンドは、ファイルシステムにmy_awesome_appディレクトリを作成しません。その代わりに、以下のような出力を表示します（バージョンによって細部は異なります）。


Running "flutter create" in my_awesome_app...
Target directory "my_awesome_app" does not exist.
  (✓) my_awesome_app/
    (✓) my_awesome_app/.gitignore
    (✓) my_awesome_app/.metadata
    (✓) my_awesome_app/analysis_options.yaml
    (✓) my_awesome_app/pubspec.yaml
    (✓) my_awesome_app/README.md
    (✓) my_awesome_app/lib/
      (✓) my_awesome_app/lib/main.dart
    (✓) my_awesome_app/test/
      (✓) my_awesome_app/test/widget_test.dart
    (✓) my_awesome_app/android/
      ... (android related files)
    (✓) my_awesome_app/ios/
      ... (ios related files)
    (✓) my_awesome_app/web/
      ... (web related files)
...
Would create project "my_awesome_app".

この出力から、プロジェクト名、ディレクトリ構造、主要なファイルが意図通りに生成されることを確認できます。もしプロジェクト名をmy-awesome-app（ハイフン区切り）のように間違えて入力した場合、Dartのパッケージ命名規則に関する警告が表示され、ミスに気づくことができます。

応用パターン: オプションを組み合わせて効果を確認する

flutter createには多数のオプションがあります。--dry-runと組み合わせることで、これらのオプションの効果を安全に試せます。


$ flutter create --dry-run --org dev.mycompany --platforms=ios,android --description "A new awesome app." my_platform_specific_app

このコマンドを実行すると、ドライランの出力には以下の変化が見られます：

pubspec.yamlのdescriptionフィールドに指定した文言が含まれること。
Androidのbuild.gradle内のapplicationIdがdev.mycompany.my_platform_specific_appになること。
iOSのproject.pbxproj内のPRODUCT_BUNDLE_IDENTIFIERがdev.mycompany.myPlatformSpecificAppになること。
web, linux, windows, macosの各ディレクトリが生成されないこと。

このように、実際にプロジェクトを生成して、中のファイルを開いて確認するという手間をかけることなく、コマンドライン上だけで設定が正しく反映されるかを検証できます。

シナリオ2: `flutter pub` - 依存関係の海を安全に航海する

pubspec.yamlに記述される依存関係の管理は、プロジェクトの健全性を保つ上で極めて重要です。flutter pubコマンド群は、--dry-runが真価を発揮する代表的な場面です。

`flutter pub upgrade --dry-run`

おそらく最も使用頻度が高いであろうユースケースです。プロジェクトの依存関係を更新する前に、どのような変更が発生するかをプレビューします。


$ flutter pub upgrade --dry-run

出力は以下のようになります。


Resolving dependencies...
...
> analyzer 5.13.0 (6.2.0 is available)
> args 2.4.1 (2.4.2 is available)
> collection 1.17.2 (1.18.0 is available)
! http 0.13.6 (1.1.0 is available)  <-- Major version change!
> intl 0.17.0 (0.18.1 is available)
...
Would change 32 dependencies.

この出力から多くの情報を読み取れます。

>: マイナーバージョンまたはパッチバージョンの更新。通常は安全ですが、変更内容を確認するに越したことはありません。
!: メジャーバージョンの更新。これは破壊的変更を含む可能性が高いことを示唆しています。この行を見たら、httpパッケージのマイグレーションガイドやChangelogを必ず確認すべきです。
+: 新しく追加されるパッケージ（推移的依存関係）。
*: 変更のないパッケージ。

このプレビューにより、無計画なアップグレードによるビルドエラーや実行時エラーのリスクを劇的に低減できます。

`flutter pub add --dry-run`

新しいパッケージを追加する際にも--dry-runは有効です。特に、そのパッケージが他の多くのパッケージに依存している（推移的依存関係を持つ）場合に役立ちます。


$ flutter pub add firebase_core --dry-run

このコマンドは、pubspec.yamlを実際には変更しません。代わりに、firebase_coreを追加した場合に、他にどのパッケージが自動的に追加されるのか、そして既存のパッケージとのバージョン競合がないかを表示します。これにより、「たった一つパッケージを追加しただけなのに、なぜかプロジェクトが肥大化した」といった事態を事前に把握し、依存関係の構成をクリーンに保つ一助となります。

`flutter pub remove --dry-run`

パッケージを削除する場合も同様です。他のパッケージが削除対象のパッケージに依存している場合、単純に削除すると問題が発生します。--dry-runを使えば、削除操作が他にどのような影響を及ぼすかを事前に確認できます。

シナリオ3: `dart run build_runner build --dry-run`

json_serializable, freezed, riverpod_generatorなどのコード生成ツールは、大規模プロジェクトでは不可欠です。しかし、ビルドには時間がかかることが多く、設定を間違えると意図しないファイルが生成されたり、必要なファイルが更新されなかったりします。


$ dart run build_runner build --dry-run

このコマンドは、実際のコード生成プロセス（数秒から数分かかることもある）を実行しません。代わりに、build_runnerがどの入力ファイルを検知し、それに基づいてどの.g.dartや.freezed.dartファイルを生成または更新する予定かを即座に表示します。

これは、以下のような場合に非常に便利です。

新しいモデルクラスにアノテーションを追加したが、正しくビルド対象として認識されているかを確認したい。
build.yamlでビルド設定をカスタマイズし、その設定が正しく反映されているかを素早くテストしたい。
ビルドがなぜか失敗するときに、どのファイルが問題を引き起こしているかのヒントを得たい。

時間のかかるビルドプロセスを何度も試行錯誤する代わりに、--dry-runで瞬時にフィードバックを得ることで、開発サイクルを大幅に短縮できます。

--dry-runを超えて: 高度な活用と関連する考え方

--dry-runの哲学は、Dart/Flutterの標準ツールだけに限定されるものではありません。この「プレビューしてから実行する」という考え方は、より広い開発プラクティスに応用できます。

カスタムスクリプトへの応用

プロジェクト固有のタスクを自動化するためにシェルスクリプトを書くことはよくあります。例えば、アプリのバージョン番号を更新し、ビルドを実行し、成果物を特定の場所にコピーする、といった一連の作業です。このようなカスタムスクリプトにも、--dry-runの概念を導入することをお勧めします。

スクリプトに--dry-runフラグ（あるいは-nや--simulateなど）を実装し、このフラグが指定された場合は、実際のファイル変更コマンド（sed, mv, cpなど）を実行する代わりに、実行されるであろうコマンドをechoで表示するようにします。これにより、自作のスクリプトも安全にテストでき、他のチームメンバーも安心して使えるようになります。

CI/CDパイプラインへの統合

継続的インテグレーション/継続的デリバリー（CI/CD）パイプラインに--dry-runを組み込むことで、パイプラインの安定性を高めることができます。

依存関係チェック: Pull Requestが作成されるたびにflutter pub upgrade --dry-runを実行するジョブを追加します。もし更新可能なパッケージがあれば、その結果をPRのコメントとして投稿したり、ビルドを警告状態にしたりすることで、依存関係を最新に保つことを促します。
デプロイ前検証: 本番環境へのデプロイメントスクリプトの最初のステップとして、常にドライランモードで実行します。ファイルパスや環境変数の設定ミスなど、致命的な問題につながる可能性のある設定不備を、実際の変更が加わる前に検出できます。

Gitにおける同様の概念

--dry-runの考え方は、バージョン管理システムGitにも見られます。

git add -p (patch mode): ファイル全体の変更をステージングするのではなく、変更箇所（ハンク）を一つずつ確認しながら選択的にステージングできます。これは、変更をコミットする前の「プレビュー」と言えます。
git clean -n: 追跡されていないファイルを実際に削除する前に、どのファイルが削除対象になるかをリストアップします。-nが--dry-runに相当します。
git diff --staged: コミットする直前に、ステージングされた変更内容を最終確認できます。

これらのコマンドを使いこなすことは、--dry-runを常用することと同じく、「何を変更しようとしているのかを正確に把握し、意図しない変更を防ぐ」というプロフェッショナルな開発習慣の一部です。

常に最新情報を得るために

DartとFlutterのツールは常に進化しています。特定のコマンドで--dry-runが利用可能か、あるいは他の便利なオプションがないかを確認する最も確実な方法は、組み込みのヘルプ機能を活用することです。

コマンドの末尾に--help（または-h）を付けると、そのコマンドで利用可能なすべてのオプションと、その説明が表示されます。


$ flutter create --help
$ flutter pub upgrade --help
$ dart run --help

また、より詳細な情報や背景知識については、公式サイトのドキュメントが最も信頼できる情報源です。

まとめ: --dry-runを開発文化の一部に

--dry-runオプションは、単なる技術的な機能ではありません。それは、慎重さ、明確さ、そして継続的な学習を重んじる開発文化を育むための触媒です。

この記事を通じて、--dry-runがもたらす4つの主要な利点を探りました。

安全性: 破壊的な変更を未然に防ぐ最後の砦。
透明性: 複雑なツールの内部動作を解明する鍵。
学習効率: リスクなく実験と探求を可能にする教育ツール。
コミュニケーション: 変更の意図と影響を明確に伝えるための補助線。

flutter create, flutter pub, dart run build_runnerといった日々の開発で頻繁に使うコマンドにこそ、--dry-runを組み込む習慣をつけましょう。最初は少し手間に感じるかもしれません。しかし、この小さな「予行演習」の習慣が、将来の大きな問題を防ぎ、あなたのコードとプロジェクトの品質を確実に向上させ、そして何より、あなた自身をより自信に満ちた熟練の開発者へと成長させてくれるはずです。

「実行」の前に、一呼吸おいて「予行」する。その一手間が、あなたの開発体験をより安全で、生産的で、そして楽しいものに変えることでしょう。

Tuesday, August 8, 2023

「実行」の前に「予行」を。DartとFlutter開発における--dry-runの流儀