本職はFF14でララフェル族の光の戦士(白魔道士)をやっているYoshihisaです。
先日開催されたShibuya.apk#26にて、『Android Architecture Components(AAC)を使ってリファクタリングした話』と題して泥臭く地道にリファクタリングしていった話をさせていただきました。
P.4からP.11ではそこはかとなくやばい香りがするだけでまだマシだったActivityが度重なる機能追加などにより地獄へと変貌していく様子が手に取るようにわかると評判（？）でした。
ヤバさがひと目でわかる #shibuya_apk
— 菊池紘 (@kikuchy) 2018年6月26日
地獄だ #shibuya_apk
— asmz (@starmAIne777) 2018年6月26日
ああ〜〜〜〜〜〜〜〜〜〜😇😇😇😇#shibuya_apk
— Takako (@ktkt_fire) 2018年6月26日
この地獄を縮小すべく取った手段がAAC ViewModel(VM) + LiveData でした。
AAC VMとLiveDataでステートマシンを実装しActivityと各Fragmentでロジックと状態を共有、表示状態の決定をそれぞれで行うようにすることでFat Activityから脱却しました。
またリファクタリングの大事なポイントも合わせて紹介しました。
最後に会場で質問をいただいたのでその内容と回答を書いておきます。
Q. この作業にかかった時間は？
A. 最後に入れた送信機構以外の部分も含めて実作業時間は1週間程度です。(実際はQA等でリリースまでにはさらにもう1週間ほどかかっています)
送信機構とプロフィールやメッセージ履歴を取得する機構は独立していてロジックは単純だったこと、コールバックを追いかけるのに時間がかかった程度です。
Q. JavaをKotlinに書き直すことと、このようなリファクタリングどっちを優先する？
A. リファクタリング優先です。書き直すにも責務を抱えすぎているものをそのまま書き直すには高コストですので…まずはダイエットして責務を適切に分割してスッキリさせてから書き直す作業に入れば安全に進められるでしょう。またJavaで書かれているものを必ずしもKotlinで書き直す必要はないので「気が向いたら」で良いと個人的には考えています。
はじめて(少し早めに終わりましたが)15分話したので発表寸前まで緊張で胃が痛くなっていました。
また「こんな話してもウケんのかなぁ」と心配でしたが終わってみると皆様同じような悩みを抱えているようで少しはお役に立てている様子で安心しました。
資料を共有したツイートには過去最高の「いいね」をいただきました！ありがとうございます！
本日の発表資料でした https://t.co/LEcQ6ua3RN #shibuya_apk
— Yoshihisa Takeda (@bomneko_attack) 2018年6月26日
弊社に興味を持っていただいた方は、@bomneko_attackまたは他の弊社エンジニアへお気軽にDMやリプライをください！
