1. Dart 入門の次に来る「設計力」の壁
初心者コードと実務コードの決定的な違いは、以下の点にあります。
実務では「あとから直せる構造かどうか」が最重要です。
2. 変数・Class・Function命名を設計レベルで考える
命名は単なるルールではありません。設計意図の表現です。
変数命名の基準
悪い例:
問題:
・スコープを離れると意味が消える
・型から意図が推測できない
改善例:
「何のための変数か」が一読で分かることが基準です。
Class命名の禁止ワード
実務で避けるべき曖昧語:
・Manager
・Helper
・Util
・Common
・Handler
なぜ問題か。
責務が拡張し続け、巨大クラス化するからです。
改善例:
クラス名は単一責務を保証する装置です。
Function命名は副作用を示す
悪い例:
改善例:
動詞＋対象＋結果が分かることが重要です。
3. Formatting & Lintを“文化”として定着させる方法
ローカルルールでは意味がありません。CIで強制しなければ維持できません。
実務で必須にするLint例
・always_declare_return_types
・avoid_dynamic_calls
・prefer_const_constructors
・avoid_unused_parameters
・sort_constructors_first
理由:
・戻り値明示 → API設計の明確化
・dynamic排除 → 型安全確保
・const推奨 → 不変性と最適化
・未使用引数排除 → 設計の整理
フォーマット未適用コードはマージ不可にします。
これによりレビューは設計に集中できます。
4. DartにおけるClean Codeの具体基準
原則1: 依存方向を一方向にする
UI → ViewModel → Repository → DataSource
逆流を禁止します。UIが直接Repositoryを生成しない。
原則2: メソッドは抽象度を揃える
悪い例:
抽象度が混在しています。
改善例:
ログやAPI詳細は下位層へ隠蔽します。
原則3: 可変状態を減らす
悪い例:
改善例:
不変にできるものは不変にする。副作用を減らします。
5. 実務コード改善例
Before
問題点:
・build内副作用
・dynamic使用
・API直結
・テスト不能
・再利用不可
After
改善点:
・UIとロジック分離
・型安全
・DI可能
・テスト容易
・スケール対応可能
6. Flutterアプリでスケールする構造とは
小規模では問題にならない設計も、機能が増えると破綻します。
スケール可能構造:
層ごとの責務を守ることで、機能追加時の影響範囲を限定できます。
7. 美しいコードがチームワークと拡張性をどう支えるか
・新規参加者の学習時間が短縮
命名と構造が統一されていれば、コード自体が設計書になります。
・レビュー時間が減少
Lintとフォーマットが統一されていると、レビューは設計議論に集中できます。
・リファクタリング耐性が高い
型安全＋依存分離により、安全に変更できます。
・機能追加時の衝突が減る
責務分離が徹底されていると、同時開発が可能になります。
Dart 入門を終えた後に本当に重要なのは、文法ではなく設計基準の確立です。命名の明確化、Lintの強制、依存注入、null最小化、責務分離を徹底することで、Flutterプロジェクトは長期運用に耐える構造になります。美しいコードは見た目の問題ではなく、チーム効率と拡張性を支える戦略的資産です。プロのFlutter開発者は、最初の一行から将来の変更を想定して書いています。
