Kotlin/ネストが深い
Composableな関数でのレイアウト実装が進んできました。
setContent {
MyAppTheme {
NavHost {
composable("main") {
MainScreen {
ModalNavigationDrawer {
Scaffold {
Column {
...
こうしてみるとネストがじわじわ深まって、自分の現在地が分かりにくくなってきているのを感じます。関数の中身も関数で表現されているので、任意の場所で切り分けるのは簡単ですが、全部をバラバラにしてしまうとまとまりがなくなって逆にわかりにくくなりそうです。また、同じファイルにComposableをまとめる必要もないですね。
とりあえず、AIに聞いてみたら「再利用できるパーツになりそう」ならファイルを分けたら？とか、「ネストがある程度深くなったら」関数を外に出したら？とか、「ファイルが肥大化したら」ファイル分けてみたらとか、至極まともな返答をいただきました。うん、そうしようと思ってたよ。
機能で分割というのはやっていくとして、NavHost をみたときに、処理が分岐する部分も関数を分割する契機になるなと思いました。他にどんなシチュエーションで分岐するでしょうか？
あと、AIさんの提案に従うと、結構細かくファイルを分割するんですよね。「明確に意味のあるまとまり」で分けるといいよっていうことで、細かすぎるように見えても
- 保守性が上がる
- ソースの見通しが良くなる
- Previewで個別に確認できる
- 状態と見た目の分離がしやすい
- チーム開発でも担当しやすい（パーツごとに作れる）
こんなにメリットがあるそうです。これなんですよね～。あんまりチームで開発しないので抜け落ちてしまいがちな視点がちゃんと書かれています。でも、個人開発で設計が一人の頭の中で完結しているとき、必ずしも細かくファイルをわけられると、検索性の悪さと疎な繋がりが何やってるかわかんなくさせる気がするんですよね。反論があるのもわかるんですけどね。大規模な開発の時はよくないやり方になりうるし。Javaをいじってた時が多かったかな。PHPのとあるフレームワークをいじっていたときもあったかな。超マイクロサイズなコードをたくさん作る作業中に、これやんなきゃダメかなぁってひたすら思ったことがありまして、適切なファイル構成について悩むこともあるのでした。「意味のあるまとまり」の粒度が自分に近い人のソースは何となく読みやすかったりしませんかね？まぁ、粒度が違う人は見ているところが違うんですかね。保守性命な人ととりあえず動けばいい人とでは、大事なポイントも違うってことですかね。