Flutter - リファクタリング方針の決定

概要

ソフトウェア開発において、最初から全てが順調にいくことはありません。
Flutter開発を始めた時は楽しい日々を過ごしていても、リリースが近づくにつれて不具合やその報告が頻繁になり、次第に焦りからその場しのぎのコードを書いてしまいがちです。
躓いてしまうことやトラブルが起きる原因はいくつか考えられます。

1. 参加する開発者のレベルが違うことから生まれる問題

   • Flutterにおいても例外ではなく、ウィジェットが書けるレベルの人からiOS/Androidと連携するプログラムをかけたり、Flutter開発のアーキテクチャを十分に理解していたりするレベルの人までいることでしょう。参加するFlutterエンジニアやモバイルエンジニアのレベルがもし大きく離れていると、勉強会や自学を促すことでレベルを整えていく必要がある。

2. 設計手法や哲学が一貫していないことから起きる問題

   • 例えば、状態管理においてProviderで書きたいという開発者と、何でもかんでもStatefulWidgetで良いではないかという開発者が同じプロジェクト内にいると、将来的に問題が起きる可能性は高まっていくでしょう。お互いのコードをメンテナンスする気力は薄れ、プロジェクトは次第に属人化していきます。

教育も設計手法も万全に整った状態を築けたとします。最後に襲いかかってくるのが誘惑という敵です。Providerで書いているうちに、Riverpodが魅力的に感じ心移りするかもしれません。
中には合理的な理由があって変えることがあるかもしれませんが、基本的には強靭な意志を持ってプロジェクトをリリースまで進めることに注力すべきでしょう。

チームメンバーを知ること

チームメンバーを知ることはメンバー間で連携して一つの大きなプロジェクトを完成させるために重要な課題となっていきます。それぞれの技術スタックと経験値、モチベーションなど、メンバーごとに異なるパラメータを持っているでしょう。その中で、協調して明日から一緒に設計やコードを書いていくことになります。

設計方針の決定

Flutterアプリケーションの開発は

1. レイアウトの設計から始まり、
2. 状態管理やネイティブ連携など

設計が必要となります。
設計をするためには、その上位概念である要件を知ることから始める必要があります。要件と言えばどのようなアプリケーションを作るのかという話になりそうですが、もう少し広く見ておくと良いでしょう。具体的には次のようなものを考えておきましょう。

• 背景
• 課題
• 目的
• 方針
• 体制図
• システム構成図
• システム化の範囲
• 機能一覧
• 業務フロー
• リリースまでのスケジュール
• リリース設計

このリストは、筆者がアプリケーションを構築する際に、チームで共有する内容となります。このような前提なしに、いきなりデザインや仕様を設計や実装に落とし込んでいってしまうと、開発者が優先度や重要度を認識できず、場当たり的な設計やコードを生成していくことにつながります。速度を重視すべきところに時間を長く使うということもありえます。将来どういうことを想定しなければいけないのかを含め、上流のところを把握した上で設計に入っていくと良いです。

例えば、もし今回作成するアプリケーションがリリースしてから1ヶ月~3ヶ月など短い期間で閉じるものであれば、アーキテクチャはそこまで凝らなくても良いのでスピード感が求められているかもしれません。また、定期購読やオークションといった決済が発生するアプリケーションだと、最初の設計を間違えて構築してしまうと致命的なものとなり、将来的に自分たちの首を絞めてしまうかもしれません。そのプロジェクトで作るものを記述した仕様からではなく、未来まで想定した内容で要件定義を定めて方針を決めていくと良いでしょう。