00:01
では、TimeTreeTechTalk 第N回、分からないです、もう何回目かやっていきたいと思います。よろしくお願いします。
お願いします。
お願いします。
お願いします。
お願いします。
お願いします。今回は、iOSのテーマになっておりまして、RestKitというライブラリーがあるんですけれども、それをやめたという話です。
いかにして、RestKitは詳しい話は後であると思うので、僕から省略しますけれども、結構、いろんなところに使われていたライブラリーで脱却するの大変だというところなんですけど、その辺の苦労について聞いていければなと思います。
その辺をやってくれたメンバー2人を呼んで、話を聞いてみたいと思います。
じゃあ、シオンとガッツですね。よろしくお願いします。
よろしくお願いします。
お願いします。
お願いします。
それぞれ、シオン、ガッツの順番で自己紹介をお願いしてもいいでしょうか。
はい。iOSエンジニアのシオンです。2016年からTimeTreeでiOSアプリの開発をしています。よろしくお願いします。
お願いします。続いて、ガッツお願いします。
iOSエンジニアのガッツです。僕は去年の11月、2023年の11月からTimeTreeでiOSエンジニアとして働いています。
その前は3月から業務委託で入っていて、11月から正社員という感じで働いております。よろしくお願いします。
よろしくお願いします。ここまで来て、自分の自己紹介するの忘れてたなって毎回思うんですけど、
今回もスコットがお送りしたいと思います。よろしくお願いします。
それでは、僕があまり詳しくないiOSのレストキット周りの話を、シオンに歴史を説明していただこうかなと思います。お願いします。
今回の話は、おそらくTimeTreeのiOSアプリ史上最大の負債返却を成し遂げたっていう話かなと思っていて、
まずレストキットが何かっていう話をしていくんですけど、
これはAPIに対してのネットワークアクセスとモデルオブジェクトへのマッピング及び映像化を担ってくれるオープンソースのライブラリというもので、
特徴としては、コアデータっていうiOS標準のフレームワークを使っていて、映像化の部分はコアデータを使っているということですね。
03:06
APIのエンドポイントとモデルへのマッピング定義が1000言的に記述できて、結構当時としてはイケてるライブラリだったのかなっていうふうに思ってます。
僕もちょろっとだけ全職でiOSの開発してたときに触ったことはあるかもしれなくて。
なんですけど、いかんせんObjective-Cで作られたもので、最終リリースバージョンが出たのが2017年とかなんで、もう6年以上前に止まっているということで、
こいつはちょっとどうにかしないとやばいぞっていう話で脱却するっていう話が始まったっていうことなんですけども、
タイムツリーアプリ自体の歴史を振り返ると、タイムツリーは2014年から開発が始まってて、2015年にリリースしてるんですね。
Swiftが2014年のWWDCで発表されたばかりっていうタイミングだったんで、この時点でSwiftの採用っていうのは結構非現実的だったと思うんで、
タイムツリーアプリの最初のバージョンObjective-Cで書かれていて、そういう面でもRESTキットを採用するっていうのは当時としては悪くない判断かなとは思ってます。
2014年に発表されて、開発してたのがその時期ってことですもんね。
そうですね。その後、iOS開発の主流がどんどんSwiftに移行していったので、タイムツリーも徐々にSwift化っていうのを始めていきました。
このままRESTキットに依存していくのは結構リスクが高いよねっていうことで、RESTキットに代わるSwift製の独自のフレームワークを作ろうというふうな動きがありまして、
2017年にタイムツリーコアっていう内製のRESTキットに置き換わるものを作るっていうのが始まりましたと。
そこから新規開発になる部分っていうのは基本的にはタイムツリーコアの方で実装していって、徐々に全体をタイムツリーコアに置き換えていくっていう計画を立ててたって感じですね。
タイムツリーコア作った当初は予定単位共有っていう、今はない機能なんですけども、この辺のAPIからタイムツリーコアで実装を始めていったっていう歴史がありますね。
06:00
置き換え始めたときに過去のプルリクを見に行って、なるほどこんなのがあったんだっていうので、でも今はもうコードがないんだなって思ったのを思い出しました。
新規開発部分はいいとして、既存の実装の置き換えっていうのがやっぱり大変でしたっていうことなんですけど、2021年にRESTキット脱却っていう一周が経ちまして、
その時点でまだこのRESTキットに依存しているエンドポイントがリストアップされて、みんなで頑張ってこれを一個ずつ置き換えていこうねっていうふうに進めていったって感じですね。
三年前ですね、今からするとね。
そうっすね。
だから放送が始まってから、しかも1月だから本当3年、丸3年以上だったんですね、辞めるまでにね。
これ以来結構脱却っていうのを使いがちですけどね。
いろいろ古くなったものを脱却していこうって。
脱却。
これはゴロがいいですよね。僕も気に入ってる。
一周は経ったけど、結構みんなやっぱり普段関わってるプロジェクトのタスクで、基本的には一杯一杯なんで、なかなか手をつける時間が取れずに時間が過ぎていくっていう感じで、
一時期毎週決まった時間にMobProでみんなでこのRESTキット脱却のタスクをやっていくみたいなことを試した時期があったんですけど、結構個人的にはこれMobProとあんまり相性が良くなかったなって思ってて、
というのも変更の影響範囲がめちゃめちゃでかいので、すごく慎重に腰を据えて影響範囲を調べながら進めていくっていうことが必要で、
MobProってみんなでコード見ながらワイワイ進めていくんですけど、その場のノリで大丈夫だよねみたいな感じで進んじゃって、実際に考慮不十分で不具合が出ちゃうみたいなことがあったんで、
MobProのやり方もあるんだとは思うんですけど、ちょっと我々にはこれを進める上では向かなかったかなっていうのは反省としてありましたね。
確かにこれは面白い知見かもしれないですね。こういう影響範囲が大きいものっていうのはMobProでやった方がいろんな知見が寄っていいんじゃないかみたいなのもあるかもしれないんですけど、
今聞いた話だとワイワイするから、要はその場で意思決定しちゃってみたいな感じになっちゃうんですかね。
そうですね。
なるほど。これは確かに集中してしっかり取り組んだ方が、いわゆるデグレしないみたいな意味で言うといいのかもっていうのは確かに面白い知見かもしれないですね。
09:13
それでなかなか進んでなかったっていうことがあったんですけど、ここでガッツに登場いただくんですけど、
もともとガッツは自分は全職で一緒に働いたことがあって、結構僕がタイムツリーに来た初期からずっと一緒にやらないかっていうお声掛けはさせていただいてたんですけど。
ありがとうございます。
それで業務委託で関わっていただけそうという話を提案されたときに、ガッツだったらこれいけるんじゃないかと思って、
レストキット脱却のタスクを業務委託っていう形でお願いするっていうのを始めたっていう感じですね。
ガッツならいけるという信頼がすごいですね。
そうですね。
それもあるし、一人で腰を据えてやったほうがいいねっていう振り返りみたいなのもあって、ガッツにお願いするみたいな感じになって。
そうですね。そこで専任でやっていただけると良いのかなっていう感じでした。
なるほどですね。
あと自分も業務委託の話をしてたときに、当時働いてたところで大きなリファクタリングをやっていたってところもあって、
あと業務委託って形だとメインストリームよりもリファクタリングとかのほうが価値発揮がしやすいってこともあって、
リファクタリングとかって話をしたらマッチしたみたいなのがありましたね。
ちょうど確かに。
結構ある種作業が独立してるっていうのもあるし、ちょうど良かったんですよね。タイムのコントロールみたいなのもやりやすかったでしょうし。
この後、ガッツのほうにどういうことをやっていったかっていうのをお話していただきたいと思うんですけど、
ウエストキットってアプリのすごい根幹の部分のことをやってる部分なんで、
業務委託で入ってくれたガッツが誰よりもタイムスリーアプリの根本の基礎部分を熟知してるっていう状況になってたっていう。
なるほど。
次のガッツが入社の経緯だったり、ウエストキット脱却、何が大変だったとか、どういうことをやったのかみたいなことを紹介していただくっていうのにいきますかね。
12:07
軽くガッツ、自己紹介と何やってたかみたいな話していただいていいですか。
はい、そうですね。自己紹介。
シオンは2010年頃に同じ会社でiOSエンジニアとして働いてて、それから僕は違う会社に転職してiOSエンジニアを続けていて、
シオンからずっと声かけてもらっててっていう経緯でいました。
ちょうど毎年1回ぐらい声かけてもらってたんですけど、その頃に業務委託やってみようかって話になって、3月ぐらいから始めました。
その当初からウエストキットっていうのがあって、それを置き換えるのをやってほしいっていう話でまず入ってきましたね。
ただ、さっきシオンも言ってくださったようにすごくこのタイムツリーっていうアプリの根幹の機能、場所でもあるし、
タイムツリー自体も2023年だから9年ぐらい経ったプロジェクトでも非常に巨大なんですよね。
いきなりウエストキットに取り掛かるのは厳しかろうということで、簡単なバグを倒すってところから入っていきました。
最初ジャブ的なやつをちょっと処理したって感じですね。
そうですね。でも最初にプロジェクト開いたときも結構どういうものかというと、めちゃくちゃいっぱいフォルダがあると思って。
それを検討していくと、それぐらいになっちゃいますよね。
バグをいくつか倒したりとか、当時のRx Swiftっていうのに依存してそれを剥がすみたいなこともやって、
プロジェクトの作りの知見がたまってきたところの5月ぐらいからウエストキット脱却に本格入っていきました。
予定情報とかのデータをサーバーと同期する仕組みの土台を置き換えていくぞっていうところで、
イシューを共有してもらったり、ウエストキットって何みたいなところから説明してもらったりしてましたね。
確かウエストキット脱却のイシューに倒さないといけない対象のリストがあって、めっちゃいっぱいあったのを覚えてなかった。20個ぐらいあったと思う。
15:02
クリストにすげえチェックがあって、バーって縦になかったっていう。
そうですね。これを淡々と進めていったって感じではあるんですけど、
工夫した点としては簡単なことからやっていこうみたいなことをやってました。
さすがにいきなり予定情報みたいなところを置き換えていくとヘビーが過ぎるって感じで。
予定に色を付けられるんですけど、その色を置き換える。
その色の情報っていうのをAPIから取ってきてクライアントに属化してるんですけど、そのあたりのところから置き換えていくっていうのをやっていきましたね。
通信周りみたいなところでいうと、デバッグっていうか、開発中単体で完結しないところだと思うんですけど、どうやって工夫してたとかってありますか?
そうですね。このあたり、リファクタリングのセオリーというか、レガシーコード改善ガイドみたいなところにもあるところなんですけど、
一個はインターフェースを壊さないようにするところで、自動テストを厚く書くっていうのを一つ工夫していましたね。
大事ですね。
このリクエストを飛ばしたときに、結果的にクライアントの状態がこうなっているってところを既存の挙動をめっちゃ細かく見ていって、
自動テストに落として壊れないようになるまで実装続けるとやってました。
その際、役に立ったのがProxymanっていうソフトウェアがあって、これがHTTPリクエストを除くことができるソフトなんですよね。
ワイヤーシャークみたいなやつですかね。
そうです、そんなやつです。それがもうちょっとモダンになったみたいなのですね。
コアではあるんですけど、やってることっていうのはAPIを叩いてそれをローカルに保存するっていうところで、
ここの形さえ壊さなかったらデグリしないだろうっていう、既存の実装を叩いて、
なるほど、こうやったらこのリクエストが飛ぶぞみたいなのを見て、そこを崩さないような感じでやってました。
それにいつも役に立ったのがProxymanでしたね。
Proxyman、ちょっと後で概要のところにリンク貼っておいてもらいましょう、スティーブも。
18:02
そうですね、実際やってみて大変だったみたいなことってどういうのがありました?
実際今話してたところで言うとテスト書いたりとかっていうのは分かるんですけど、
実際やってみることと大変さが違うのかなみたいなのがあるんですけど、
やってみてやべえみたいな思ったことってありますか?
あれはやってみて、API叩いて置き換えるだけって言ったんですけど、
やってることの広さがすごかったんですね、リストキットって。
最初にしおんが紹介してくれたみたいにAPIも叩くし、
モデルオブジェクトのマッピングもするし、そのディスクに保存までしてくれる。
確かに何でもやってくれる。
何でもやってくれるってことの、
これが具体的に何をどうしてやってるんだみたいなところがやっぱりすごい大変でした。
例えばローカルのデータってコアデータってSQLite、中身SQLiteなんですけど、
SQLに入ってて、モデル間にリレーションっていうかが貼られてるんですね。
その辺りのこのモデルを使って、
その宣言が書いてあって、その宣言を元にリストキットがリレーション貼ってくれてるんですけど、
その宣言をどうリストキットが解釈して、
具体的にリレーションを貼るっていう処理に落としていくかっていうのが、
結構大変だったんですよね。
けっこうリストキットのソースまで、
これがなんていうのかわからないんですけど、
っていうのも、
本当に難しいんですけど、
そこからリストキットがリレーションを貼ってくれてるんです。
そのリレーションを貼るっていうのは、
実際に実際にリレーションを貼ってくれるっていうのは、
結構ひどいんですよね。
おだしょー 結構RESTキットのソース まで読みながらやってくれてました
よね
三沢 やってましたね
おだしょー それはついどう 大変そうだな
三沢 すごい
三沢 あとコアデータってやつが また癖のある仕組みで 違うスレッド
から操作したりすると 結構すぐ こう壊れるんですよね このあたり
にもRESTキットがうまく壊れない ような仕組みを厚く作ってやって
たから うまく動いてたっていう ところも結構あって じゃあそれを
Time's ReCoreのほうに持ってきたら どうしたらいいんだみたいなとか
も結構苦労しちゃった この一つ か
おだしょー なるほどね その辺も じゃあ今Time's ReCoreに入っている
っていう感じ
三沢 入っていますね
おだしょー ですね
三沢 です
おだしょー RESTキットがやって たことをほぼやるみたいな
三沢 そうですね RESTキットがやって たことを大体やるみたいなの
21:02
おだしょー 大体やるみたいな なんか公開できそうじゃないですか
そのライブラリー
三沢 ちょっとそこまではまだ整理 できてないんで ちょっと今後の
課題に
おだしょー そういうもんですよね 公開するってなると ちょっとまた
レベルというか求められるもの が上がりますね
三沢 そうですね あとはもう1個 やっぱりその影響範囲ですね シオン
も言ってたみたいにやってたら 事故っちゃったみたいなのあった
と思うんですけど 予定の更新とか になると 影響範囲がほぼ全ての
画面に波及してくるっていうところ がすごい大変でした 1個 更新が
入るとピタゴラスイッチっていう と聞こえが悪いんですけど ピタゴラ
スイッチのようにイベントが飛ん で あちこちの画面が更新される
みたいなところ この処理は一体 どの画面からどう叩かれて その
結果どの画面に何が起こるんだ みたいなのを1個1個洗い出して
いくっていうのが大変でしたね
おだしょー いや それは大変そう 聞いてるだけで頭が痛くなる
僕みたいなサーバーサイドのエンジン だとかだと そんなにたくさんイベント
飛ぶみたいなのって あんまり 特に1つのプロセスの中であんまない
ので なかなかパラダイムが理解 しづらいところもあるんですけど
それ聞いてるだけで頭痛いですね
おだしょー そうですね ちょっと 辛い話ばっかりになってますけど
おだしょー いや でもそれらを全て 調整してみたいな意味で言うと すごく
スキルというか 理解力が要求される とか 概要を理解するみたいな力
がいりますよね
おだしょー そうですね この行動 は何の意味があるんだみたいな
のは結構1個1個見ながらやりました し その結果をXeonとか スラックの
部屋に貼ったりして これで合って ますかねとか これどうなってます
かみたいなのを質問しながらとか もやってました
おだしょー なるほど 考古学力 というか 地層を掘る力みたいな
のは結構求められたかもしれない ですね
おだしょー 確かに そうですね 実装 の背景とか そういうのを理解
しながらやっていく と思います ちょっと最後のほうに 2人に聞いて
みたいんですけど リベストキット 脱却してTime Tree Coreに全部移行
しましたっていうので 変わった こととかっていうのはどういう
のがありますか やってどうなった みたいな
おだしょー 1つあるのが 結構この 脱却を成し遂げたことによって
パフォーマンス改善したところ がいくつかありまして というのも
今まで結構Blackboxになってた部分 が こちら側で 実装把握している
24:03
し チューニングもできるっていう 状態なので それによって今まで
どうしてもメインスレッドでしか 動かせなかった部分が バックグラウンド
スレッドに回せるようになって パフォーマンスが改善するみたいな
ところもありましたね
おだしょー その辺はもうこっち 側で全部実装してるから いろいろ
コントロールできるし 細かいニーズ にもチューニングできるっていう
感じですね Gutsはどうですか
おだしょー そうですね パフォーマンス のところはやっぱり一番大きかった
んですけど あとは開発効率みたいな ところで言うと レッドキット
でどうしてもオブジェクティブC だったので Swiftを100パーセント
活用して その周りの処理を書く っていうのは どうしても難しかったん
ですよね それがTime Tree Coreにきて 全部Swiftになったんで Swiftの型
システムのパワーっていうのを 結構使いやすくなったっていう
のはあるかなと思います
おだしょー それはもうだいぶ開発 効率に影響してきそうですね
おだしょー そうですね
おだしょー なるほど ありがとうございます こういう 特に古いライブラリー
に依存して 開発効率だったり パフォーマンスとか ブラック
ボックスになっちゃっていじれない みたいなところは往々にしてある
ので こういう直接的な機能じゃないん ですけど いわゆる非機能要件
っていうのも改善していくこと によって ユーザーさんに届ける
価値が変わってくるみたいな すごく いい例なのかなって思いました
2人だけじゃないと思うんですけど iOSのチームのみんな お疲れさまでした
と
おだしょー そうですね ほぼほぼ みんな関わってた一瞬ですね
おだしょー そうですね いろんな 人の名前があって
おだしょー 今回はこんなところ かな すごく巨大なものを何とか
倒したという話もあるし それで 結果的に ユーザーさんにも新しい
価値というか 届けやすくなった りとかいうところもあるんで すごく
いい学びのある実践だったんじゃない かなと思います
おだしょー これをやらせてくれて たっていうのも すごいいい話だな
と思ってて こんなに時間のかかる リファクタリックって なかなか
今やらないといけないみたいな 話になりがちなんですけど 僕が
11月に正社員になって やらせてほしい っていうお願いもしてたのがあったん
ですけど それをそのままやらせて ちゃんと脱却終わるまで持たせて
くれたっていうのは すごくありが たかったし ならではというか すごく
いいことだなと思いました
おだしょー その辺に関しては すごく 経営メンバーも含めて みんな
理解があるというか 会社のいわゆる PDMのメンバーも その辺に関して
理解があるので しっかり話せば ちゃんと対話してくれるっていう
27:00
んですかね そういう環境を整 ってる組織かなと思うのも すごく
我々にとってもありがたいですし ユーザーにさらに 我々もこういうこと
をすることによって ユーザー さんに価値が届くと信じてる
ところがあるから そういうことを 要は議題の皿に乗せられるみたいな
すごくありがたい組織だと思いますし すごいカルチャーがあるっていう
のはいいことですよね
おだしょー 素晴らしい
しばやん はい ということで Time Tree Tech Talk第N回
iOSレストキット脱却の会話 以上 でまとめたいなと思います
しおんとかつ ありがとうございました
おだしょー ありがとうございました
しばやん ありがとうございました
