Reproさんのイベントで登壇させていただいた件の後編です。
ビシバシ振り返っていきます。
スライド
Problem
マルチドメイン・シングルリポジトリでカオス
リジョブでは、「求職者向け画面」「企業向け画面」「リジョブ用管理画面」の3ドメイン体制で運用しています。
3ドメインですがデータベースは一つなので、Railsプロジェクトも一つで運用しています。
よくある構成なのですが、長期運用していると肥大化に次ぐ肥大化で雪だるま式にコードが増えていきます。
肥大化したコードは可読性が下がり、開発着手時に仕様を把握することに時間を取られ開発速度の低下を招きます。
また、3ドメインが絡むので必然的に複雑度も上がり、不具合の温床となりやすいです。
結果、コードに手を入れることに消極的になったり、工数見積がバッファ盛り盛りでスピード感が極端に下がったりします。
スピード感が出ないので人員を増強するも、複雑度が高いので思ったように進まずオーバーヘッドのみ増えていく。という負のスパイラルが発生します。
歴史が長く、属人化しているので仕様変更がきつい
LongLifeという名の通り、8年ほど運用していますので過去の仕様に引きずられることが多々あります。
また、ドキュメントも細かいものは無く、動作しているコードから読み解いていくという地道な手順が各工数にのしかかってきます。
当時のコードや経緯を知る人がほぼ居ないのでコードも正しいのか判断できない場合もあります。
そういう時は現状に合わせて一部作り直したりと、地味に工数が膨れていきます。
テストのカバレッジが極端に低い
ソースコードの量が多いというのもありますが、10%程度だと思います。
主要なところは押さえているのでなんとかなっていますが、テストが無いところに手を入れる恐怖感は拭えません。
見積もりの精度を上げられない
いくつかのProblemをまとめると、見積もりやスケジュールの話になります。
- ドキュメントが散らかりまくり
- 当初の要件が不明なので設計が理解不能
- 暗黒期のコードが理解不能
自然に難読化されたコードが点在するため、思わぬ落とし穴があります。
読みづらい、理解しづらいコードはリファクタリングをしましょう！
決めたルールを守り、守られているかチェックする機構がない
コーディング規約を守っているか？決めた仕様通りの実装になっているか？
現在は上記のようなチェックをコードレビュー時に行っています。
しかしレビュアーも実装者であるため、まとまった時間を確保できない場合の方が多いです。
そうすると、必ずと言っていいほど漏れが発生します。
この漏れに気づかずにいると、漏れた箇所を参考に新しい機能が作成されたり、仕様の不具合が発生する場合があります。
仕様の不具合はかなり深刻で、障害として通知が来る訳でも無く、
「なんかおかしい...」「変なデータが飛んでるんだけど？」といった声でようやく気付くので、
機会損失額が大きくなる傾向にあります。
保守に対してコストを割きづらい
自社サービスではよくある話ですが、施策に対して投資という側面があるのでリファクタリングやテストといった保守施策に手が回りにくいです。
障害が出た時に初めて問題を認識し、対策を練ろうとしますがその時にはコストが膨大に...というのはそう先の未来ではないと思います。
ビジネスロジックに対する学習コストが高すぎる
200近いテーブルを駆使したビジネスロジックを把握しておくのは人間の脳では限界があります。
新しくエンジニアを採用しても学習するのに2ヶ月〜3ヶ月は学習のためパフォーマンスが50%以上下がる傾向にあります。
部分的に疎結合なアプリケーションがあったりして忘れる
これもあるあるですが、Wordpressをリバースプロキシで表示している場合など、メインリポジトリに入っていないので忘れます。リリースしてから気付くのでバタバタしてしまうので注意が必要。
Gemを大量に使っていて身動きが取れない
Railsあるあるです。Gemfileが300行ぐらいあります。
絶対使っていないgemが紛れています。
Try
イベントでは時間があまり無かったので懇親会で知見を溜めるというtryにしましたが、まじめに振り返ります。
ドキュメントに向き合う
ドキュメントが無いと何が正しいのかわからない。何が正しいのかわからないのでテストが書けない。
テストが書けないから不安になる。見積もりも曖昧になるし、動作確認コストが跳ね上がる。
ドキュメントは偉大だったという話です。
という訳で、ドキュメントとの向き合い方は、二通りあると考えられる。
- 常に向き合う
- 何か大きな変更を加える時だけ向き合う
常に向き合う
サービス要件定義書、仕様書、設計書、画面遷移図、ガイドライン、画面操作手順書、etc...
をまとめる人や、チームを据えて品質管理部門として置く。
何か大きな変更を加える時だけ向き合う
例えば、メイン機能のリニューアルや、全体的なリプレースの際に、現状をまとめたドキュメントをまとめて作る。
そこから変更点を加えていき、要件定義書としたり仕様書として活用していく。
どっちが良い？
スポットでの対応が安く済む。
常に向き合う方はかなりのコストと担当者の熱量が必要。
個人的には、常に参照できるドキュメントがあるだけで開発スピードの向上や、
ブラックボックスに手を入れなくて済むという安心感を得られるので常に向き合いたい。
まとめ
サービスが大きくなってから慌ててドキュメント整備やテスト作成を行うのは本当に大変です。
ドキュメントを書く文化やテストを書く文化を取り入れるなら早い段階の方がハードルが低いです。
初期段階なら記述量も大したことないはずです。ほんの少し手間をかけるだけで引き継いだ人の苦労が変わります。
自分がもし初期段階からジョインできるサービスが今後あるなら、
土台をしっかりと作っていきたいと心から思うようになりました。