弊社内でエンジニア3人が集まって楽しくリファクタリングをした話です。
背景
社内のプロダクトで「手が空いてるならリファクタリングやってくれると嬉しい。手が足らない」というようなSOSを受け取り、
そのプロダクトをある程度知っている人 1人 + 知らない人 2人 の3人でリファクタリング部隊を作ってリファクタリングしていこうという話になりました。
今回は、モブプロ「みたいなこと」です。厳密なモブプロではないです。
なので、
- ドライバーも考える (みんなで考える)
- ドライバーは変わらない
という感じでゆるく進行しました。
プロダクトについて
Railsで動いています。Rails3から始まり、今Rails5です。
- 7年ぐらい前から動いているプロダクト
- 新しく書いたところは新しく、古いものは古いという歴史が積み重なっている
- Rails3からのコードが残っている
- Rails何それ？Ruby何それ？から始まったコードが存在している
- ただファイルが分割されただけのコードがConcernsとして存在している
- でもテストはちゃんと書かれている
という感じで、とても歴史のあるプロダクトです。
今回やった人について
A: このプロダクトわかる。設計強い。DDD好き。Ruby, Railsともに得意。
B: このプロダクトわからない。インフラ強い。Rubyそんなに得意じゃない。 (本人談)
C: このプロダクトわからない。設計好き。DDD好き。Ruby得意。型を欲しがる。
という感じで思想やスキルの差が若干ありつつ、
- 仲が良いので思想のぶつけ合いになっても険悪にはなりづらい
- 誰か一人が発言しづらいということはない
- お互いの技術に信頼/リスペクトしている
というメンバーです。今回はBさんがドライバーをしました。
今回の流れ
実際にどんな感じでやったのか？ですが、基本は
- つっつき会
- メシ
- 修正会
という3つのフェーズで行いました。
会議室で大画面を使用してみんなで唸ります。
つっつき会
今回のメインはモブプロをやることではないので、まずはリファクタリング対象(ディレクトリ/ファイル単位)を決め、
コードを読んでみてよくなさそうなところをつっついて、方針決めをします。大体4時間ぐらい。
このつっつきはTODO: つっつき serviceとして切り出す というようなTODOコメントとして残し、コミットします。
今回は、以下のような観点でつっついていきました。
- そのファイルの構造、ネームスペースが正しいか(分割されただけのファイルがconcernsとして存在しているため)
- そのクラスの責務を逸脱したメソッドがあるか(↑と大体一緒)
- 冗長(わかりづらい)な書き方をしていないか
- これらを大幅な変更せず綺麗にできるか
この時点でも、3人分の目と知識があるので、誰かが「この書き方はなんだ？」「これどうなってるんだ」となっても、知ってる/わかってる人が説明するということもあり、一人でやるときよりもスムーズです。
また、
これらを大幅な変更せず綺麗にできるか
という判断も1人だと消極的な理由でやらないことを選択してしまいそうな部分も、誰かの「実は簡単に修正できるのでは」という知識の後押しにより、積極的な判断をすることもできます。もちろん、やらないという判断もあります。
特に、やるか/やらないか という部分以外にも判断材料を出せる人が増えるというのは多人数の有利な部分です。
メシ
修正会
実際につっつき会でつっついた部分をリファクタリングしていきます。大体2時間ぐらい
基本的につっつき会で方針が出ているのでその方針に沿ってリファクタリングするだけです。
とはいえ、この段階でも「あ、もっといい方法あるじゃん」というのはあるので、随時取り入れていきます。
KPT
Keep
- 誰かの「これどうなるんだろう？」に対して「じゃあ、試してみるか」というラフな形でやってみることができる
- コードではわからないお互いの思考フローが知れる
- ドメインエキスパートが居ないことによる「名前から直感的に判断できるか」という部分に焦点をあてれる
Problem
- 仲が良いからこそ、脱線すると脱線し続けそうになる
- ドメインエキスパートが居ないので仕様がわからないのでパスというのがあった
- 複数人いるのでガッツリ集中して書くというのは難しい
Try
- ドメインエキスパートも呼んでみる
- 仕様についてをサクッと聞けるので時間短縮になりそう
- keepの部分とコンフリクトしそう
- 人数を増やしてみる
- 人が増えれば集合知というのは単純な加算になるのか
終わりに
ペアプロ、モブプロは人と人の知識をリアルタイムでつなぎ合わせる というのがコアだと思うので、
「ドライバーは10分」「ナビゲーターの指示に従う」といった感じで厳密にやる必要は別になく、人が集まってみんなでコードに向かうというのは大事だと感じました。
特にkeepでも書いた、
コードではわからないお互いの思考フローが知れる
というのはお互いに勉強になります。
また、エンジニア間のコミュニケーションも取れるのでお互いに刺激になり、メインの業務にもハリが出ると思います。
更に、人間誰しも見落としや勘違いもあるので、単純に人数が増えることにより、見落としや勘違いなどをし続けることがなくなりやすいです。 (ダブルチェックと一緒で単純に増えればいいわけではないですが)
と、いう感じで、定期/不定期に限らずこういうことをやるのはいい感じだと思います。
おわり。