はじめに

これまでの記事では、SLXの4階層構造を

Collection
 └ Genre
     └ Title
         └ Item

として紹介してきました。

これは、当時のSLXで実際に採用していた内部名称です。

その後、開発を進める中で保守性や分かりやすさを見直し、

現在は

Collection
 └ Folder
     └ Category
         └ Title

という構成へ変更しています。

今回の記事は、そのリファクタリングに至った経緯について書いてみようと思います。

なお、次回以降の記事では現在の内部名称である

Collection → Folder → Category → Title

を使用して話を進めていきます。

途中からシリーズを読まれた方は、

「あれ？」

と思われるかもしれません。

そのため、今回は名称を変更した理由について整理してみようと思います。

最初は特に違和感はありませんでした

開発を始めた頃は、

Genre。

Title。

Item。

この名前に特に違和感はありませんでした。

ゲームでも、

本でも、

DVDでも、

何となく意味は通じます。

実際、当時はそれで困ることもありませんでした。

最初は表示名だけ変更していました

実は、最初から全面リファクタリングを考えていたわけではありません。

SLXをテストしていただいた方から、

「Genreという名前は一般的ではないですね。」

というフィードバックをいただきました。

確かに、

ゲームならGenreでも自然です。

でも、

コレクション管理アプリとして考えると、

少し用途が限定される名前でした。

そこで当時は、

画面に表示する名称だけを変更することにしました。

内部ではGenre。

画面ではFolder。

利用者にはFolderとして表示されるので、

当時はそれで十分だと考えていました。

表示名だけでは解決しませんでした

ところが、

開発を続けるにつれて問題が出てきました。

画面ではFolder。

コードではGenre。

画面ではCategory。

コードではTitle。

画面とコードで呼び方が違うため、

機能を追加したり、

既存機能を修正したりするたびに、

「これは内部では何という名前だったかな。」

と考える場面が増えていきました。

利用者は迷いません。

でも、

開発者である私が迷うようになってしまったのです。

Titleも、本当はタイトルではありませんでした

もう一つ気になっていたのがTitleです。

当時のTitleは、

実際には分類を表す役割でした。

今でいうCategoryです。

一方、

実際に管理したかったものはItemでした。

例えば本なら、

利用者が管理したいのはタイトルです。

でも内部ではItem。

コードを書いている自分自身が、

「これはTitleなのか。」

「それともItemなのか。」

そんなふうに迷う場面が少しずつ増えていきました。

思い切って全面リファクタリングしました

もちろん、

このままでもアプリは動きます。

利用者が困ることもありません。

それでも変更を決断しました。

規模としてはかなり大きな変更でした。

Entity。

DAO。

Repository。

ViewModel。

Navigation。

Compose。

関連するクラス名やメソッド名まで、

ほぼすべて変更しています。

途中で何度も、

「このままでも動くのでは。」

と思いました。

それでも、

これから先も保守し続けることを考えると、

今しか直せるタイミングはありませんでした。

そう考え、

思い切って全面リファクタリングに踏み切りました。

新しい内部構造

現在は、


Collection

 └ Folder

     └ Category

         └ Title

という構成になっています。

Folderは、

コレクションの中を大きく分ける場所。

Categoryは、

さらに細かく分類するためのもの。

Titleは、

実際に管理したい対象です。

以前よりも、

役割が名前から自然と伝わるようになりました。

もちろん、

利用者がこの名前を意識することはほとんどありません。

これは開発者側のための設計です。

名前も設計の一部でした

以前の私は、

名前は後からでも変えられるものだと思っていました。

でも実際に保守を始めると、

名前一つでコードの読みやすさが変わります。

設計の意図も変わります。

未来の自分が迷わない。

他の人がコードを読んでも意味が伝わる。

そういう状態を作ることも、

設計の一部なのだと感じるようになりました。

おわりに

今回のリファクタリングで変わったのは、

画面ではありません。

内部名称だけです。

利用者から見ると、

ほとんど気付かない変更だったと思います。

でも、

開発する側にとっては、

これから先の保守や機能追加を考える上で、

とても大きな変更でした。

以前の記事で、

私は、

データ構造は強く、利用体験はシンプルに。

という考え方にたどり着いたと書きました。

その考え方は、

利用者に対してだけではありません。

開発者にとっても、

理解しやすく、

迷わない設計であること。

今回のリファクタリングを通して、

名前も設計の一部なのだと改めて感じました。

もし今回の記事が面白いと感じていただけたら、

ここまでの経緯を書いてきた過去の記事も読んでいただけると嬉しいです。

シリーズ

このシリーズでは、個人開発しているコレクション管理アプリ SLX（StockLedgerX） の設計思想が、どのように変化していったのかを時系列でまとめています。

シリーズ一覧はこちらです。

▶ SLX開発録〜設計思想ができるまで〜

次回は、この考え方をさらに一歩進めて、

「データ構造は強く、利用体験はシンプルに」

という設計を、実際にどのようにアプリへ落とし込んでいったのかについて書いてみようと思います。