初めまして、ROBOT PAYMENTでエンジニアをやっております、河津です。
こちらの記事では、2014年からサービスを提供している弊社のシステム「請求管理ロボ」で実践を目指しているクリーンアーキテクチャのお話しをします。
とはいえ、一回の執筆で網羅できるボリュームではないので、すでにシリーズ化を予定しています。
是非ファイナルシーズンまでお付き合いいただけたら幸いです。
今シーズンのテーマは「脱却予告」です。
請求管理ロボの現状
まずは、請求管理ロボがどういう状態なのかご説明します。
書き出すとキリがないですが、ざっくり下記のような状況です。
・ PHPのCodeigniterというフレームワークを用いて、皆さんお馴染みのMVCをベースに設計
・ 請求業務ドメインの複雑性に対応しDRY原則を守ろうとするあまり、コードの循環的複雑度が高く、親クラスに共通処理があり、一般的なクラス設計とは異なる箇所がある
・ 機能数も600を超えるので、シンプルにファイル数とコード量が多い
・ PHP特有の連想配列が多用され、型定義されていない箇所が多々ある
・ クラスの結合度が10以上のクラスが200個程度あり、影響範囲が必要以上に広くなっている
・ 要素数の多い連想配列が引数として定義されているが、PHPDocにもkey,valueの記載がないので、引数の見通しが悪い箇所が散見される
・ etc...
所謂、レガシーシステムかなと思いますが、請求管理ロボはこれからも成長し続けるシステムです。
しかし、このまま放っておくと、コード改修やテストに工数を割かれ、リリースすればバグを生み、請求管理ロボの成長の妨げになる未来しか見えません。
ということで、このレガシーシステムからの脱却を目指すというのが現在地になります。
目標設定
簡単に脱却できるわけもなく、また、一人の力ではこの規模のシステムはびくともしません。
となるとここで登場するのが、弊社開発チームが大切にしている価値観の一つ「やるなら、みんなで。」です。
開発メンバー全員が共通認識を持ち、常日頃からクリーンなコードを意識して、開発時に少しずつでもリファクタリングしていく必要があると思っています。
そこで、今回全員で合わせる共通認識の対象はこちら！
Clean Architecture 達人に学ぶソフトウェアの構造と設計
この本でRobert C.Martinという方が提唱している、「クリーンアーキテクチャ」という思想になります！
おそらく、皆さんもどこかで聞いたことがあるのではないでしょうか。
この思想をもとに、「請求管理ロボの長期的な繁栄を支えるクリーンでセーフティなアーキテクチャ」を目標にしています。
「セーフティ」は、期待通りに機能が動作し、ユーザーからの信頼性が高く、障害発生時の対処が早い状態を指しています。
この重要性は、エンジニアの方はもちろん、非エンジニアの方でもご理解いただけると思います。
「クリーン」は、先ほどのクリーンアーキテクチャという思想を取り入れた状態を指します。
では、なぜクリーンアーキテクチャなのか？
クリーンに保つことの重要性
簡単に「クリーンアーキテクチャ」についての説明ですが、こちらの画像一度は見たことがあるのではないでしょうか？
正直、この画像がクリーンアーキテクチャの全てです。笑
先ほど紹介した本や、こちらの素晴らしい記事に詳しい内容は記載されていますので、深掘りしたい方は是非ご覧ください。
クリーンアーキテクチャのメリットは多岐に渡りますが、大まかに以下の3つの要素が確保できることだと考えています。
1. 可読性
2. 変更容易性
3. テスト容易性
この3つの要素を維持することで、開発における生産性やシステムの品質を向上させることができ、スピーディーで長期的に成長させていきたいシステムにとっては必要不可欠です。
まさに現状の請求管理ロボにとって、喉から手が出るほど欲しい要素ですね！
ただし、メリットや重要性があるからとはいえ、それらの要素を簡単に獲得できるのであれば苦労はしません。
物事には二面性があり、光があれば闇もあります。
クリーンアーキテクチャの問題点
エンジニアとして働いていると、「クリーンアーキテクチャ」という言葉に出会う機会はあるが、実際の「クリーンアーキテクチャ」に出会う機会はあまりありません。
理由は完全に自論にはなりますが、「導入することによるメリットを上回るデメリットが存在している」からです。
自分が考えるデメリットは以下の4つがあり、その結果、導入まで至らないのかなと思います。
1. 過度な抽象化による可読性の低下
2. 過度な分割による複雑性の増加
3. 初学者の学習コストが高い
4. アーキテクトの維持コストが高い
正直、新規プロダクトでの導入はそこまで問題ないと思うのですが、既存システムへの適応の難易度はかなり高いと思われます。
でもここで諦めずに、デメリットをなくす or 減らす仕組みやルールを設定することで解決すれば、目標設定した未来に近づくはずです。
この問題の解決方法は、それだけで一つの記事にする予定ですので、乞うご期待。
脱却予告
今回は、請求管理ロボの現在と未来の目標、その目標を達成するための方法と問題点をざっくりご紹介しました。
次回は、問題点の解決方法を記事にしようと思いましたが、先に実践した具体例がないと、何が問題なのか分かりづらいと思いましたので、クリーンアーキテクチャの実践についてを記事にしようと思っています。
では、ここまで読んでいただきありがとうございました！
P.S
請求管理ロボではアーキテクトチームを発足しています！
一緒に請求管理ロボのアーキテクトの進化に携わりたい方は是非ご応募ください！
お待ちしております！
We are hiring！！
ROBOT PAYMENTでは一緒に働く仲間を募集しています!!!
speakerdeck.com
www.robotpayment.co.jp
