morimorihogeです。あれよあれよという間にもう師走ですね。
2019/11/15（金）に開催された銀座Rails#16 @リンクアンドモチベーションでTechRachoの週刊Railsウォッチの出張版ということで参加させていただきました。スライドは以下の通りです。
ちょうど発表したその日の夜にRails 6.0.2がリリースされたりもしましたが、今回の話題は「機能開発の設計レビューについて」ということで、設計方面の話をしてみました。
いわゆるウォーターフォール型の開発をしているチームであれば、基本設計フェーズと実装フェーズは切り離されているため設計レビューを行うことが多いと思いますが、Issueベースでアジャイルっぽく開発しているようなチームだと、機能単位でチケットを割り振った後いきなりPRまで作成してしまうようなプロジェクトもあるのではないでしょうか。
もちろんチケットが切られた時点で設計もほぼ確定しているような内容（文言修正やバグ修正など）であればそのままPRを作っていっても良いと思うのですが、ある程度大きな機能になると、いきなり手を付けるよりはまず開発チーム内で設計方針についてレビューして進める方がいいのではないかと思っています。
以下は僕が大きめの機能開発でやっている設計検討から実装に移るまでの流れです。
ある程度以上大きな機能開発になってくると、設計や実装方法が一種類ではなく何種類も検討可能になってきます。そうした実現方法をまずは洗い出し、それぞれのメリット・デメリットを明らかにした上で一つの方法を選択する、という流れを設計レビューでは大事にしています。
特に大きな機能の場合、開発チーム内である程度コンセンサスを取ってから実装に入らないと、実装してPRまで作ってから「そのやり方だとダメだから作り直して」という手戻りになってしまう可能性もあります。
この辺り、実装方針を選択する際に、そのプロジェクトにとってどの方法が一番フィットするのかをきちんと選択し、開発チームと共有しておくと良いでしょう。
こうした設計の際に検討した流れや理由を記録して後から参照可能にしておくことで、将来「なんでここはこんな設計にしたんだ・・・」という苦言を呈されても「あのころはこういう事情でこういう選択をしたんだよ」という説明をすることができ、いらぬhateを受ける危険から避けることができます。
設計の記録を残す時、特に「その決定における潜在的リスク」については明らかにした上でチームで共有しておくのが将来的な禍根を残さないコツではないかと思います。
この辺り、発表では僕の経験と自分なりのやり方だけで語っているので、もっとこんなベストプラクティスがあるよ！みたいな話などあればぜひ聞いてみたいところですね。
次回は次回の銀座Rails#17 @リンクアンドモチベーションは1/16（木）19:00～となります。
ピックアップトピックはまた開発・運用系から何か考えようと思っていますが、もし何か取り上げてほしいネタなどありましたらTwitterにて @morimorihoge までご意見お寄せ下さい。
週刊Railsウォッチ 公開つっつき会のお知らせ
1/9（木）19:30より、弊社会議スペースにて毎月恒例の週刊Railsウォッチ 公開つっつき会を開催します。新年明けて新年会シーズンですが、もしよろしければご参加検討下さい。
おたより発掘
銀座Rails#16で「出張Railsウォッチ」発表させていただきました .https://t.co/amHsi2icpp
設計レビュー大事ですよねぇ。
— ゆうじ＠カメさんそろそろコタツ終わります (@yuji_developer) December 17, 2019