どの地点にいつ、どのくらいの雨が降るのか、わかりやすくアップデート
今回大幅アップデートを行った開発経緯は、スマホの大画面化や高性能化でよりリッチな表現が可能となり、快適で使い心地のいいUI表現が可能になってきたことだと大前氏は語る。
雨雲の情報をマップ上に表示する雨雲レーダーの機能は従来もあったものだが、これまでは雨雲がどこにあるかを地図上に表示し、それをユーザーに読み取ってもらう必要があった。それらの情報を計算によって整理。どの地点にいつ、どのくらいの雨が降るのか、必要な情報をわかりやすく伝えることを心がけたという。
「1mmの雨が降りますと言われても、具体的にどのぐらいの雨なのかわかりにくい。そこで、『ポツポツ』や『ザーザー』、『しばらく雨が続きます』というように、いつまで雨が続くのかの表現や雨量変化のグラフを表示し、ひと目でわかるようなUIにしました」
リファクタリングすべきは今！ リアクティブプログラミングを導入
この雨雲レーダーはもともと十分に多機能な状態で、凡例表示やモード切り替えボタン、雨雲を表示するマップ、タイムシーク、SNSシェア、APIアクセス、さらに雨雲や雷、雪、台風の状況を表示するレーダーなど、さまざまなモードを持っていた。ほぼ全ての機能が一つのクラスで実装され、機能の全容が見えない巨大オブジェクト状態を、大前氏は「FatActivity」アンチパターンにおける神のオブジェクトと表現した。
一つのクラスにまとまっているため、機能の密結合が発生する。各機能が複雑に絡み合って、簡単にはがせない。継ぎ足し開発の限界が来ていた。だが大前氏は、このような設計が必ずしも悪かったとは言えないという。
「最適な設計とは時代背景や、機能の規模によって変わってくるもの。その時代や機能の規模に合わせて、リファクタリングをする必要があります。先延ばしにしてもレガシー構造に引っ張られるだけなので、一時的にスケジュールを遅延させてでも、リファクタリングすべきは今だと決断しました」
完璧を目指しすぎるとコストは無限に跳ね上がってしまう。大前氏は費用対効果を考え、適切な妥協点を設定することにした。その方針は以下3つとした。
- 機能ごとにいくつかの単位に分割する
- リアクティブプログラミングの導入
- 雨雲レーダーの範囲に限定する
実際に進めてみると、想像していたよりも容易に分割できた。これは機能的に独立していることに加え、これまでも改善に向けて努力してきた背景があったのではないかと大前氏は語る。分割することで見通しが良くなり、作業効率がアップした。案ずるより産むが易しと、やってよかったと振り返る。
リアクティブプログラミングはネットワーク周りでは使っていたが、今回は複雑になってしまったUI部分にも導入することにした。コールバックの制御では、モード変更ボタンが押されたらどんな処理を行うかをプログラミングしていく。機能があちこちに分散するという弊害もあるため、モード変更ボタンが押されたときのイベント発行と各モジュールが自律的に動くようにプログラミングすることで、処理がまとまり、見通しがしやすい形でリファクタリングを行った。
ライブラリはViewModelとLiveDataを採用。ほどよくこなれたモダンな技術で使いやすかったという。最初の1週間はリファクタリングに時間を割いたが、その遅延分は開発ブーストで返済。リファクタリングの結果、レガシーコードに足を引っ張られることなく、新機能の実装やブラッシュアップに集中して時間を使うことができた。
