雰囲気で使っていたFactoryBotを調べ直した

ちょっと仕事で思うことがあって、FactoryBotは雰囲気で使っているし、ちゃんと調べてベストプラクティス押さえておくかとなったのがきっかけ。

正直、FactoryBotってまともに使えてる組織ないんじゃないかと思うぐらいにはカオスになると思っており、ちゃんと設計できておらず、えぐい差分プログラミングで「よくわからんが、動いているからヨシッ！」となっているのが大半なんじゃないだろうか。

そういうわけで、調べた限りのFactoryBotの機能と挙動を踏まえFactoryBotベストプラクティスもまとめた。

まとめた結論が

「つまり、FactoryBotは実行可能なドキュメントだったんだよ！」

ΩΩΩ<な、なんだってー!!

になって正直驚いている。

ちょっと触ることがあるかもなで調べ始めたのに、今はもう徹底的にリファクタするモチベが湧いている。

コードがカオスになっていてどうにか整理したいとなった場合、いきなりDDDを持ち出すのはあまりにも目指すところが遠い。まずもってテーブル定義書もER図もユースケース一覧もない状態だろうから、リバースエンジニアリングでそれらを明らかにした後、本来あるべきモデルは何か分析し直して、それらが終わってようやくDDDに手をつけられる。

それらの作業はあまりにもヘビーで、機能を切り出して処理していくにも一つ終わらせるだけでひどい労力がかかり気が遠くなる。

しかし、FactoryBotの定義ファイルがきちんとしているなら、テーブル定義書チックな情報もER図もAggregateを作るのに必要十分な範囲で実行可能なコードで（コードだから頑張ればPlantUMLなりMermaidで吐ける）、ユースケースはデータと処理がセットで手に入るということで、これはもうヘビーな部分がほぼほぼ解決でき、あとは新規開発相当のDDDを行えば良くなる。既存コードの差し替えとかリグレッションテストとかあるけど。

FactoryBotの定義ファイルはRSpecからしか使われないから、間違っていても影響を心配することはないしお気楽に作業を進められる。仮に間違っていても本番データ修正なんてことにはならないし、RSpecで実行されるので一定の動作保証という恩恵も受けられる。

「Railsプロジェクトの負債を解消するためにまずどこから手をつけるべきか」という問いに、ずっと答えられずにいたが「FactoryBotの定義ファイルを整理するところから始めよ」が答えになるかもしれない。