技術的負債

技術的負債を大公開! 負債は嫌いになってもスペースエージェントのことは嫌いにならないでください!

Posted by SpaceAgent Tech Blog スペテク on Friday, January 18, 2019

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

@kaiba です。

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

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

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

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

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

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

システム構成

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

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

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

これらのサービスは会員情報が共通だったり、同じ情報を複数のサービスで表示する部分もあるため、 いずれも上記 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 で動作させます。

いつやるか?

今でしょ！と言いたいところですが、まだまだサービスを育てなければいけない時期ではあります。
そうはいっても絶対に解消はすべきですので、経営陣の理解も得たうえで、2018/11 から日々少しずつリソースを割いて進めています。

まとめ

まだまだリファクタリングは始まったばかりで長い戦いになります。
大規模リファクタリングに興味がある方、よりよい改善案がある方、是非お声掛けください！

FEATURED TAGS
BigQuery Firebase Firestore Fluentd Google Apps Script KPI Nuxt.js PWA React React.js Redash Redux StyleGuides Vue.js chatbot chatops google apps script hubot iOS stackshare text オブジェクト指向 会社紹介 勉強会 技術書典 技術的負債 設計