← 開発ノート一覧
📓 開発ノート
```html 開発ノート

【かもちゃん】フロントエンドの構造化作業:巨大なapp.jsとの対話

2026-06-30

今日は、本当に大きな整理整頓の日だった。

「断酒でGO!!」のフロントエンド部分、特にJavaScriptが抱える構造的な問題に向き合った。プロジェクトが進むにつれて機能は増えていくけれど、その分、メインとなるapp.jsというファイルがどんどん肥大化していくのは避けられないことだ。

正直なところ、この前までなんて、あのファイルを開いた瞬間から「どこに何があるんだろう」って途方に暮れたのを覚えている。行数が1098行を超えていて、「ここが新着タブの処理か?それともメニューの初期化か?」と、まるで巨大な迷路の中を歩いているような感覚だった。

このままでは、誰かが新しい機能を追加するときに、どこから手をつけたらいいのか全く見通しが立たなくなってしまう。だから、「安全に戻せる単位」で機能を切り出すというアプローチを取ることにしたんだ。

作業の進め方自体も工夫した。まず「1つの機能だけを切り出す→構文チェック・簡易動作確認→コミット→push」というサイクルを徹底することにした。こうすることで、もし何か致命的なバグが起きても、「このコミットまでは問題なかったから、ここに戻れば大丈夫だ」と、安心してロールバックできる仕組みを作ることができたんだ。

最初に手を付けたのは、新着タブの関連関数たちだった。loadNewsTab()とか、記事カードを作るためのbuildEventCard()など、複数の機能が混在していた。これらをまとめて js/news-tab.js として独立させることにしたんだ。

ファイルとして分離したら、読み込み順序の調整が必要になったから、app.jsより前に読み込むように修正した。構文チェックは問題なかったし、実際にニュースJSONを使った単体実行でHTMLが生成されることも確認できたので、ひとまず大きな山を一つ動かせた感覚があった。

次に「かもちゃんタブ」の挙動の統一に取り組んだ。以前、「かもちゃん」ボタンを押した時だけは特別な関数 openKamo() を呼び出し、他のタブ(マップや日程)の場合は共通の switchTab() 関数を呼ぶという、ちょっと不均一な状態だったんだ。

これを「すべて switchTab('kamo') に統一する」という方針に切り替えた。その結果、元々特別な役割を持っていた openKamo() は、「iframeを初回だけ作る」という最小限の役に縮小することができたんだ。

コードがシンプルになることで、「あ、このタブはこういう処理をするんだな」という理解がすごく深まった気がした。これは単なるリファクタリングを超えて、設計思想を統一する作業だったのかもしれない。

そして最後に右下メニューの部品たち、PWA追加案内の案内や共有機能など、それらを js/menu.js として切り出したんだ。ただ、このファイルは少し注意が必要だった。なぜなら、setMode() という関数がまだメインの app.js の中に残っている必要があったからだ。

読み込み順序を慎重に考えた結果、menu.jsapp.js が実行された「後」で呼ばれるように配置する必要があることがわかった。この小さな依存関係の調整が、全体の構造を理解する上で一番難しいポイントだったな。

作業が終わった今、信じられないくらい軽くなった気がする。メインの app.js は1098行から637行まで減り、他のファイルもそれぞれ適切な役割を持てるサイズになったことで、「どこに何があるか」という問い自体が解消されたように感じるんだ。

ローカルバックアップを何度も取る作業は面倒だけど、こういう大きな変更をする時には必須だと痛感した。コミット履歴(b94d656, aa716ca, 4d89625)を見るたびに、「この機能が独立したんだな」と、まるで部品が増えていく過程を追体験しているみたいだ。

コードは生き物みたいなもので、どんどん大きくなっていくけれど、定期的に手を止めて「どこに住んでいるか」という整理をしてあげる必要がある。そうしないと、誰もが疲弊してしまって、気づいた時には動かないものになってしまうかもしれないからね。

ただのファイル分割作業だと思っていたけど、これはプロジェクトの体力作りだったのかもしれない。

```
この記事はgemma4:e4b(gen上でOllama稼働)が、開発作業の記録をもとに 下書きを生成したものです。公開前にまじまじさん・かもちゃんが内容を確認しています。