ロードス島戦記に学ぶ技術的負債の返し方

1年前にいたプロジェクトに戻ってきて3週間ほど経過しました。
ミーティングが多くてガッツリコードを書くことがなくなりました。
同じフロアにいたため時々飲みに誘ってもらってたので久しぶり感はなかったのですが、コードを見るとだいぶ変わってました。
1クール目はJava8を入れ逃げしたので、ちゃんと使ってくれてるのは嬉しかったです。

サービスを2年ぐらいやっているのでよくも悪くも色々なものが溜まってました。
いわゆる技術的負債です。
技術的負債は今から見ると負債になっているのですが、その頃は時間的、技術的制約でそれがベターだと判断されたものに加えて、運用中に状況が変わって作った時の想定と異なる使われた方をしたとか、大量のデータが蓄積することで発生する問題とか色々あります。 例えば

• 当初は10連ガチャ想定だったのでinsert文を10回発行で運用できていたが、100連ガチャになったので最大100回のinsertが走るようになった カードアイテムはまとめて付与というのは仕様的に難しい bulk insertを使いたかったが、テーブル分割をしていたためORMマッパーが対応してなかった
• 運用で溜まったマスタデータが8万件になって、それをすべてアプリ起動時にメモリに入れてる。そのためアプリ起動に時間がかかる ** ローカル環境やCircleCIでのテスト実行時にも本番と同じマスタを使っているのでそれぞれにも時間がかかってる

スタート時はまずユーザにサービスを提供してナンボというところはあるのでしょうがないですね。 全部を綺麗に作りすぎてたら出すタイミングを逃してサービスが終わったなんて本末転倒。 ただ、もうやらないといけない時期かなという判断をしたので改善していきたいなと。何より自分の精神衛生上良くない 最大の懸念は改善をどうやってしていくかですね。パターンはいくつかあると思います。

1. チーム内外から改善する専用の人を設ける
2. 週1日の改善dayを設けてみんなで改善する
3. 気づいた人が随時改善する

どうしようかなーと思ってた矢先に10年以上ぶりにロードス戦記を読んでて傭兵王カシューが治めるフレイム国の軍隊の運用がうまいなーと感心。 そこは正規の騎士団と傭兵団をうまく使い分けてて、きっちり固めに正攻法に真正面から行く時は騎士団で、変則的な相手や柔軟にいきたいときは自由に動ける傭兵団で運用してました。 毎週のようにリリースがあり施策ごとにスケジュールがバラバラでメンバーによって得手不得手があるので、みんなで改善するよりも、ミーティングが多くてフルで開発に入れない自分が最初に流れを作りつつ気づいた人がやっていくというのが一番無難な流れかなと最近思ってます。

新装版　ロードス島戦記　３　火竜山の魔竜（上）<ロードス島戦記> (角川スニーカー文庫)

新装版　ロードス島戦記　４　火竜山の魔竜（下）<ロードス島戦記> (角川スニーカー文庫)