Webアプリの技術的負債を少しずつ減らす取り組み

こんにちは、CCIのくっちーです。広告案件管理システムのWebアプリの開発、運用を担当していました。（現在は別プロダクトを担当しています。）

今回は設計を見直して、技術的負債を減らす取り組みについて書いていきます。この記事はCARTA TECH BLOGアドベントカレンダー 12/18の記事です。

背景

担当システムではコードのレガシー化が進んでおり、技術的負債をどのように減らすかという課題に直面していました。ソースの変更が少なければ問題無いですが、大幅改修依頼があったため改善が必要でした。

私は改修機能を担当していたため、設計、実装を行うことになりました。

ユーザ同士がやり取りするメッセージ機能を改修しました。

以下のユーザー要望を実現することが目的です。

システム全体に影響する課題のため事業部外の知見を得たいと思い、CTO相談室にアドバイザリを依頼しました。

今回は、少しずつ再設計を進めます。

既存のアーキテクチャは既存設計と新設計が共存する構造になっています。
まずはメッセージ機能から再設計を行い、それ以外の機能は順次対応するようにしました。

まずはレガシー化している原因を調査しました。

共通処理以外のメソッドが複数箇所から呼び出されていました。
例えばAメソッドを修正した場合、呼び出している5箇所全てに動作確認が必要になることもあります。
また依存関係が多いと単体テストが書きにくいため、既存実装では単体テストの作成が難しくなっていました。

権限処理がフロントエンド、バックエンド両方に分散して書かれている状況でした。
処理分岐、ループ処理が多くなり複雑で認知負荷が高い実装になっていました。

チームでルールを決めて進めていきました。
ルールだけだと共通認識を持つことが難しかったので、 CTO室にソースレビューを依頼しました。設計方針に沿った実装になっているか見て頂きました。

クライアント、バックエンド両方でエンドポイントを分けるようにしました。

before: 全権限の処理が1つにまとまっているので処理が複雑になりやすい

after: 権限ごとにエンドポイントを分けると、分岐処理が減るのでシンプルになる

今回はバックエンドで権限制御を行うので、 httpリクエストを受け付けた時にバリデーションと権限制御を行うようにします。

before: 認可処理とvalidationが分散しており、ビジネスロジックに絡まっておりテスタブルでない

after : 認可処理とvalidationをまとめ、ビジネスロジックと分けたことで個々がテスタブルになった

各レイヤーごとの責務を明確にしました。

before: 明確に決まっていなかった

部品によって各レイヤーの責務が異なっていました。

after: チームで責務を統一

各レイヤーの責務は以下になります。

各レイヤー	責務
バリデーション	必須チェック、入力項目のチェック等を行う
認可処理	権限制御を行う
Controller層	httpトランザクションのみ行う
Converter層	Service層から受け取った値を、レスポンスの形式に成形する処理
Service層	ビジネスロジック
Model層	DBのCRUD処理を行う