マルチモジュール勉強会に出て学んだこと
少し遅くなったが。マルチモジュール勉強会にでたので個人的に参考になったポイント。
詳細設計レビューで新規開発時にルールを徹底させる
普段詳細設計レビューすることがない。というのもそこのレビューのコストを重く見てしまっているのだろうと思う。 レビューしないことによる手戻りも考えられるため、1つ検討しても良いかも知れない。 選択肢として持っておけば、場合に応じて使えるようになる。
クイズ
クイズでこういうケースでモジュールするか？みたいなのがあり、発表者の方はモジュール化導入したほうがよいのでは、と言ったケースでも参加者からは割とどれも導入しないなーとなっていた。 これは発表者・参加者の実際の経験からくるマルチモジュールの評価の違いかな、と感じた。 発表者の方は既にマルチモジュール化しているのでメリットのほうを高く評価していて、参加者からは(おそらく)マルチモジュールしていないのでコストの部分を高く評価しているのかも。
僕もよっぽどじゃないとマルチモジュール化はしないかな・・・(今は進めてるけど)
legacyモジュールの解体作業を進めるよりも新しい機能を別モジュールで作りやすくするという部分に注力
僕も解体作業を進めているところだが、心の底でlegacyモジュールを完全に解体しなきゃいけないんか？という気にはなっていたのでこう言われて心が楽になった。 リファクタリングでやらなきゃいけないものって結構しかかりの物が多く(Kotlin化とかCoroutine化とか) 、同時並行で進んでるものが溜まっていく印象で、なるべく早くやりきりたい気持ちもある。
やりきることにより、古い実装がまるっとコード・アプリ内・頭の中から削除出来る。 ただそこまですることによるメリットをあまり感じられないとあんかなｋ進められない。
例えば殆ど触っていないようなクラスをKotlin化したからといって、うれしくなるわけではない。
モジュール構成や思想をドキュメントにしておく
ドキュメントを書く時になぜそうなのか？は残すべきところだなーと感じる。コードのコメントに何残すか？と似ている。 結局やったことはそのまま残るから、意図を残しとこうねってやつ。
デモアプリ
良い。その画面に至るまでの色々をすっとばせる。この色々には画面もあるが、ログインまでのフローも含まれるのでそこをすっとばせると非常にありがたい。更にいうとUIテストやるとき。
クックパッド Android アプリのマルチモジュール化とデモアプリの活用 - Speaker Deck デモアプリのStub Injection について、発表時は理解できてなかったけど後から理解した。
BindsOptionalsOfをつけた宣言にはOptional
