※KDDIコマースフォワード㈱ 、略称「KCF」は2019年4月1日、同グループ会社の㈱ルクサと合併し「auコマース＆ライフ株式会社」として再設立いたしました。 本記事は2019年3月31日以前に書かれた記事のアーカイブとなります。予めご了承ください。
こんにちは。エンジニアの倉井です。普段わりとアフロです。
土田が私物化しそうな勢いの当ブログですが、他にもエンジニアいるんだよということで僕も記事を書いておきます。
概要
弊社KCFが運営するサービスの「Wowma!」は2017年に生まれたばかりですが、システム自体は古くから存在したものがベースとなっています。
なんと20年近く前のコードがまだ動いているという噂も。
私の所属するチームは商品を表示する部分の改善をミッションとし結成されましたが、このエントリーではリファクタリング or システムリプレイスの2択からシステムリプレイスを選択した経緯なり理由なりを書いてみます。
リファクタリングについて
実はほぼほぼ議論の余地なくリプレイスの選択に至ったのですが、リファクタリングにも一定のメリットがありますので挙げてみます。
リファクタリングのメリット
- インフラやフレームワークなど既存のリソースを使える
- 仕様をすべて把握しなくてもすぐに小さく着手できる
リファクタリング可能であればそれで進めればよいのですが、以下のようなことが明らかになってくるはずです。
リファクタリング辛いあるある
- アーキテクチャが古すぎる
- ソースコードが複雑すぎる
- 開発環境構築やビルドの自動化、CI/CDなど開発フローに手を入れにくい
- テストコードが十分でなくプログラム変更時のリスクが大きい
- そもそも開発を外注しており権限的に手をつけられない
弊社がどれに該当したか、あるいは全部だったのかは想像にお任せします。
システムリプレイスについて
一般的に言ってシステムリプレイスの主なメリットはこちらになるでしょう。
システムリプレイスのメリット
- 新しいアーキテクチャを採用できる
- 初めから自動化、CI/CDを意識してモダンな（表現古い？）開発フローを構築できる
ちなみに一括リプレイスはさすがに恐ろしいので、私のチームではページ単位、API単位のリプレイスを方針としています。
新しい機能については当然新システム側に載せていくことになります。
メリットの一方、当然デメリットもありますね。
システムリプレイスのデメリット
- 現行の仕様のすべてを把握しなくてはならない
- リプレイスが終わるまで現行と新システム、二重運用になる
いずれもクリアできない課題ではないですが、マインド的にもコスト的にも覚悟が必要です。
システムリプレイスにおける注意事項
実際に手を動かしていくなかで気がついた点があるので挙げてみます。
仕様は綺麗にならない
現行のソース調査していくと、起こりうるのか定かではない特定条件の対応、IDベタ書きによる条件分岐等、引き継ぎたくない仕様が目に入ります。
そこは見て見ぬふりです。じゃなくて、きちんと然るべき人に確認が必要になりますが、少なくない確率で引き継ぐことになります。
結局リファクタリングも必要
リプレイスしてデプロイした瞬間から、そこで動くコードも古いコードの仲間入りです。
特に1から作り上げた場合などはソースコードがまだ十分な汎用性を備えておらず、次の改修でまた根っこの方に手を入れるというのはザラにあることです。
テストをしっかり書いて自動化しましょう。
システムリプレイスを採用したキモ
弊社KCFは2016年12月に設立したばかりで、これからエンジニアリングによって事業をドリブンさせていこうとしている会社です。
であれば当然エンジニアのテンションが上がる技術を採用しなくてはなりません。なんだかんだでこれが最終的な決め手だったと個人的には考えています。
私のチームで採用しているアーキテクチャは以下のエントリーで紹介しています。 kcf-developers.hatenablog.jp
またMSA（マイクロサービスアーキテクチャ）的なところを全体の方針にしてますので、チームによってはRoR、golangなどを採用しています。
もし興味を持たれたエンジニアの方がいればぜひ話を聞きにきてください〜。
https://hrmos.co/pages/kddi-cf/jobs/15100001hrmos.co
次回
システムリプレイスのプロジェクトを進めるときに開発手法としてスクラムを採用したのですが、その相性とか、困ったことよかったことなど書いてみようかなと思います。
