【最終章】 リファクタリングを通してチームを強化していく
※ この記事は「Railsのリファクタリングに立ち向かうための教科書」シリーズの最終章になります（5/5）
【序章】 問題はどうして起こるのか ~ 方針とアーキテクチャについて
【第1章】 ModelとServiceを紐解く
【第2章】 ApplicationServiceの導入
【第3章】 マイクロサービスを見越した実装
★【最終章】 リファクタリングを通してチームを強化していく
ここまで読み進めていただき、誠にありがとうございます。最終章となる今回は、まとめとして、簡単にですがリファクタリングを通してどうチームが変わっていくかというところを書きたいと思います。
開発速度があがる、レビューの質があがる
ここまで説明してきた責務を考えながら実装すると、単純に設計で迷う回数が減るので、開発速度があがります。また、レビューの質が向上することもぜひ体感していただきたいです。設計がしっかりしていないと、どこをレビューしてよいのかという軸が定まらないのでレビューが非常にしづらいです。ここまで説明してきたことをチームに落とし込めると、設計方針に沿っているか、責務は正しいかというところにフォーカスできるので、レビュワーもレビュイーも質の高い議論がしやすくなります。
オンボーディングも容易に
設計方針が決まっていると、新しく入ってくる方のキャッチアップコストも低くなります。私に業務委託としてリファクタリングを任していただく際は、ここまで説明してきたことに加えて、wikiでrootになる設計方針の説明書きを用意することをよくします。また、勉強会等で全体に対してプレゼンをすることもよくあります。この辺りの開発の心地よさを是非このシリーズで説明してきたことを実行して味わっていただければと思います。
終わりに
いかがでしたでしょうか。実際に実装を進めていくと、細かいところで迷うこともあるかと思います。その際はご自身やチームでDDDの復習などを進めて理解を深めて言っていただければと思います。また、ご縁があれば仕事の依頼をいただいて私も一緒に進めていけると良いかも知れません。
最後まで読んでいただき、ありがとうございました。それでは！
