技術的負債（英: Technical debt）とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である。https://ja.wikipedia.org/wiki/%E6%8A%80%E8%A1%93%E7%9A%84%E8%B2%A0%E5%82%B5

以前、スペースエージェントでのスクラム導入の記事を書かせて頂いたエンジニアリングマネージャーの海馬沢です。

今回は第二弾として、スペースエージェントが抱える技術的負債とその改善の話を書きます！
本来、外部に公開することはおろか内部でも蓋をしたくなるような技術的負債をあえて公開することで、改善に向かっているプロセスなど、同じように技術的負債に悩まされたことのある同士たちに勇気を持ってもらえるきっかけになれば幸いです！

スペースエージェントが抱える技術的負債

どんなサービスにも多かれ少なかれ技術的負債は付き物ですが、 スペースエージェントの最も大きな技術的負債は「分断されたモノリス」だと感じています。

分断されたモノリスとは?

この用語は Ruby on Rails(以後 Rails) 界隈で時々耳する用語です(単純に僕が Rails の勉強会に行くことが多いだけ？)
1 枚岩(モノリス)と表現される Rails のサービスが、適切に分割されていない状況を指すようです。
スペースエージェントのバックエンドは CakePHP なのですが、Rails の影響を強く受けたフレームワークですので、 同じ問題が起こります。

スペースエージェントの分断されたモノリス

スペースエージェントは以下のサービスを運営しています。

• 民泊物件.com
• 収益物件.com
• SPACE CLOUD
• 民泊の窓口
• 管理画面

データベースは以下があります。

• 投資家向けのデータベース
• 不動産会社向けのデータベース

これらのサービスは会員情報が共通だったり、同じ情報を複数のサービスで表示する部分もあるため、 いずれも上記 2 つのデータベースを参照しています。
また、CakePHP のプロジェクトはサービスの数だけあります。

何が辛いのか

ビジネスロジックをコピーして作成

CakePHP も Rails と同じく、テーブルに紐付いたモデル層を使用し、そこにビジネスロジックを書きます。
SPACE CLOUD で作成したビジネスロジックを民泊物件.com で使用したいケースが当然あり、 モデル層のソースコードをコピーして使っており、その後編集され差分が出ています。

「ソースコードをコピーして使う」という精神的苦痛が大きく、 すでに本来同一であるべきビジネスロジックに差分がでてしまっています。。

ドキュメントや自動テストがほとんどない

上記のソースコードの差分を無くしたいのですが、スタートアップらしくどんどん新機能やデザインの Try and Error を繰り返しているため、僕が join したときにはドキュメントや自動テストはほとんどありませんでした。

どう解決していくのか

ヘイトを吐かない

「なんでこんな構造にしてしまったんだ…」と頭を抱えたくなりますが、限られたメンバー、リソースで当時できることをやったのです。
ヘイトを吐いても良いことはありません。
「少しづつ良くしていこう」というポジティブな気持ちを持つように心がけます。

改善案

いくつか方法が思いつきます。

• 綺麗なマイクロサービスに分割する。管理すべきデータベースだけを参照するようにし、マイクロサービス間は API にする
• モデル部分を共通のライブラリに切り出す
• CakePHP のプロジェクトを統合する

サービスの機能や今後のビジネス展開を含めてあるべき姿を考えたとき、「CakePHP のプロジェクトを統合する」が自然で今後の開発工数も少なく済むと判断し、これを採用しました。

具体的な改善方法

データベースの変更は影響が大きく、どこに問題が生じるかすぐにはわかりません。
王道なやり方ですが、以下の方法で進めています。

1. E2E(End to End。実際にブラウザを機械で操作するようなテスト)の自動テストを拡充する。まずはバグると致命的な箇所の正常系のみに絞って記載します
2. データベース、ソースコードを変更し、複数の CakePHP を 1 つに統合します
3. 自動テストが落ちるので修正します
4. リリース

E2E テストは以下の技術を使用し、CI で動作させます。

• puppeteer
• jest-puppeteer
• TypeScript
• Docker

いつやるか?

今でしょ！と言いたいところですが、直近のエンハンスや機能追加を行うプライオリティが高く、時期を見計らっているところになります。。
とはいえ、必ず解消しなければならに問題ですので、2018年の11月頃 から日々少しずつリソースを割いて進めています。この負債が解消されれば開発速度、品質が大きく向上することになるのでガツっとやってしまいたいところでもあります。

まとめ

まだまだこの負債に対してのリファクタリングは始まったばかりで長い戦いになります。

そんな負債を含め未来あるサービスを一緒に改善から育てていきたい方を募集中です笑
大規模リファクタリングに興味がある方、よりよい改善案がある方、是非お声掛けください！