ID:77080さん

# 開発・実装内容A：巨大設定ファイルの分割と、デザイン情報の階層化 【概要】 アプリケーションの表示・デザイン情報が単一の巨大な設定ファイルに集約され、保守が困難になっていた状態を改善。 デザイン情報を静的アセットとして切り出し、子要素単位で個別に定義・編集できる構造に再設計した。 【課題・問題点】 - 表示内容・デザイン情報などあらゆる設定が1つの巨大な設定ファイルにハードコードされており、変更箇所の特定や影響範囲の把握が困難だった - デザイン情報は親要素単位でしか定義できず、子要素ごとに個別のデザインを設定することができなかった - 上記により、改修は構造を把握している特定メンバーに依存する属人化した状態だった 【背景・考えたこと】 - 問題の本質は「性質の異なる情報が1か所に混在していること」と「デザインの定義単位が粗すぎること」の2点にあると考えた - 巨大設定ファイルを一度に分割するのはリスクが高いため、変更頻度が高く独立性も高いデザイン情報から先行して切り出し、残りの表示情報も同様の方針で段階的に分割していく計画とした - 既存の設定資産を壊さずに移行できることを重視し、子要素は「必要な箇所だけ定義を追加すればよい」構造を目指した 【打ち手・使用した技術】 - デザイン情報を巨大設定ファイルから分離し、静的アセットとして管理する構成に変更 - 静的アセット上でデザイン情報を親子のネスト構造で保持できるようにし、子要素ごとに独自のデザインを定義可能に - 子要素に定義がない場合は親要素の設定を引き継ぐフォールバック処理を実装し、既存設定を書き換えることなく移行できるようにした - アプリケーション側は静的アセットの内容を正として表示を決定する共通機能を JavaScript で実装し、各画面から共通で利用する形に統一 【品質確認】 - 移行前後の表示差分は画面の目視で確認。VRT（ビジュアルリグレッションテスト）の導入も検討したが、今回の変更規模に対して導入・運用コストが見合わないと判断し、目視確認とした。VRT は今後の改善課題として整理 - 従来存在しなかった子要素の概念を導入し、読み込む静的資材が増えることから、メモリリークの観点でも検証を実施。Chrome DevTools の Performance パネルで操作中のメモリ使用量の推移を記録し、増加し続ける挙動がないことを確認した 【成果】 - 従来は不可能だった子要素単位のデザイン編集が可能になった - デザイン変更時に巨大設定ファイルを触る必要がなくなり、どこを編集すれば何が変わるかが構造から自明になった - 特定メンバーにしか対応できなかったデザイン改修を、チーム内の誰でも対応できる状態にし、属人化を解消した