フロントエンドの負債解消で取り組んだこと

Last updated at 2024-12-24Posted at 2024-12-23

はじめに

この4ヶ月間で、フロントエンドのリポジトリにおける負債解消を行いました。取り組みに際しては、課題と目標を明確にし、計画的に進めることを意識しました。

開発環境

負債解消のために取り組んだ際に直面した、主な設計や構造に関する課題を以下に示します。

ページごとに共通のレイアウトが存在していたにもかかわらず、共通化がされていない箇所が多く、各ページで個別にコードが記述されていました。その結果、デザインに一貫性が欠け、ページ間で違いが生じてしまう問題が発生していました。

ビューとロジックが同一ファイル内に集約されているため、コード量が増大し、可読性が低下していました。また、どこにどの機能が実装されているか分かりにくく、問題の特定や修正が難しくなる可能性がありました。

1つのコンポーネントフォルダ内に複数のレイアウトファイルが混在しており、汎用性が低い設計になっていました。これにより、コードの可読性が悪化し、管理が煩雑になっていました。

コンポーネント名が長く、同じ名前のバリエーション（例: "HogeBlockInnerFeature"、"HogeBlockInnerItem"）が多く並んでいるため、親コンポーネントと子コンポーネントの関係が分かりにくくなっていました。このような命名は、構造の理解を難しくする原因となります。

コンポーネントが参照される場所がバラバラで、ファイルの場所を毎回確認しなければならない状態でした。これにより、開発者がコードの構造を把握するために多くの時間を費やすことになりました。

コンポーネント作成のルールが不明確であり、開発者ごとに異なるアプローチが取られていました。その結果、コードベースにばらつきが生じ、メンテナンスが困難になる要因となっていました。

実際に使用されていない可能性がある機能が残っており、不要なコードが多くなっていました。これがリポジトリの肥大化を招き、全体的な可読性を低下させていました。

これらの課題が放置されると、以下のような問題が発生する可能性があります。

課題に対して、理想的な状態を実現するために以下の目標を設定しました。

以下の取り組みを実施しました。

リファクタリングは直接的なビジネス成果には結びつきにくい場合がありますが、以下のような長期的なメリットが期待できます。

このように、リファクタリングと保守作業は、ビジネス成果と切り離して考えるべきではなく、並行して取り組むことが重要です。また、コードだけでなく、ドキュメント作成や開発ルールの整備も並行して進めることで、属人化を防ぎ、チーム全体の生産性向上に寄与します。