こんにちは！ShouldBee開発者の野澤です。
\n今日は、ShouldBeeの開発チームでコードレビューを導入したら、どんな課題が見つかったか？それをどうやって解決しようと考えているかについて書きたいと思います。
\nコードレビューを始めたきっかけは、コードや仕様の属人化を避けたいと思ったところにはじまります。ShouldBeeの開発では、たったふたりでコードを書いていても、作業を分担してやっていると、コードや仕様が作者にしか分からなくなるだけでなく、「いつの間にか追加されていた機能」もあって問題になっていました。
\nこの課題を解決するために、GitHub上でPull Requestを行い、必ず相手がコードレビューをしてからマージする運用を導入しました。コードレビューを取り入れてから2週間ほど経ったと思います。
\nそこで新たに見つかった課題が、「コードレビューをすると出戻りが発生する」ことです。コードレビューがテストケースの追加やtypoの修正くらいの軽微なものならいいのですが、APIそのもの変更など、大改修が何度か必要になることもありました。コードレビューでコードの属人化が減り、コードやテストケースの品質は高まったと感じるものの、開発スピードが以前より犠牲になっているとも感じました。
\nインターフェイスは外部に公開することが多く、コードが実装されてからインターフェイスが変わってしまうと、出戻りが大きくなってしまいます。そのインターフェイスに依存するコードは全て変更しないといけませんし、UIの場合ユーザマニュアルがあるとスクリーンショットはすべて差し替えになります。
\nこの課題を解消するには、実装する前にインターフェイスを固めることと考えました。具体的には、今2つのアイディアがあります。
\n1つ目の設計レビューをフローに加えるとは、コードを完全に仕上げる前にレビューをすることです。と言っても設計図を評価するような堅苦しいものではなく、他のモジュールとの接合部になるAPIの名前や引数・ユーザインターフェイスのラフ図についてレビューします。コードレビューと似たフローで行えるので、僕らのチームとしては導入が容易だと考えました。
\n2つ目のペア設計にする方法は、設計を2人がかりで行う方法です。非同期で行える設計レビューと比べると、ペア設計は2人が時間を合わせて作業しないとなりません。場合によっては、お互いの別の作業を止めてしまうデメリットがあります。逆にメリットとして、同じテーブルにつき、議論したり疑問を解決しながら行えるので意思疎通が早いという点があります。ペア設計の特徴を考えると、画面・モデル・インフラなど大枠の設計をするときに向いていると思います。
\n今後、この2つのアイディアを試してみて、「コードレビューをすると出戻りが発生する」が軽減されるか試してみたいと思います。何か学びがあったらまた共有したいと思います。
\n"}},"pageContext":{"id":"DatoCmsPost-5142956-ja","description":"こんにちは！ShouldBee開発者の野澤です。 今日は、ShouldBeeの開発チームでコードレビューを導入したら、どんな課題が見つかったか？それをどうやって解決しようと考えているかについて書きたいと思います。 コードレビューを始めたきっかけは、コードや仕様の属人化を避けたいと思ったところにはじまります。ShouldBeeの開発では、たったふたりでコードを書いていても、作業を分担してやっていると、コードや仕様が作者にしか分からなくなるだけでなく、「いつの間にか追加されていた機能」もあって問題になっていました。 この課題を解決するために、GitHub上でPull Requestを行い、必ず相手","toc":[],"ogpImageUrl":"https://www.datocms-assets.com/29850/1593190022-pastedimage20200627146.png?fm=png&mark64=aHR0cHM6Ly93d3cuZGF0b2Ntcy1hc3NldHMuY29tLzI5ODUwLzE1OTMxNTQ2MzYtdHJhbnNwYXJlbnQtcGl4ZWwucG5nP3c9NDAwJmg9NjQmZml0PWNyb3AmYmxlbmQ2ND1hSFIwY0hNNkx5OTNkM2N1WkdGMGIyTnRjeTFoYzNObGRITXVZMjl0THpJNU9EVXdMekUxT1RFNE16TXlPVEF0WVhaaGRHRnlOVEV5TG1wd1p6OXRZWE5yUFdWc2JHbHdjMlVtWm0wOWNHNW5KbmM5TWpVMkptZzlNalUyJmJsZW5kLWg9NjQmYmxlbmQteD0wJmJsZW5kLXk9MCZibGVuZC1tb2RlPW5vcm1hbCZtYXJrNjQ9YUhSMGNITTZMeTloYzNObGRITXVhVzFuYVhndWJtVjBMMzUwWlhoMFAzUjRkQzFoYkdsbmJqMXRhV1JrYkdVbE1rTnNaV1owSm5SNGRDMW1iMjUwUFhOaGJuTXRjMlZ5YVdZbE1rTmliMnhrSm5SNGRDMWpiMnh2Y2oweU1qRTRNVFltZEhoME5qUTlZek5XY0dKbkpuUjRkQzF6YVhwbFBUTXdKbWc5TmpRJm1hcmsteD02NCZtYXJrLWFsaWduPW1pZGRsZSUyQ2xlZnQ&mark-align=bottom%2Cleft&mark-x=100&mark-y=496&blend64=aHR0cHM6Ly93d3cuZGF0b2Ntcy1hc3NldHMuY29tLzI5ODUwLzE1OTMxNTQ2MzYtdHJhbnNwYXJlbnQtcGl4ZWwucG5nP3c9MTIwMCZoPTYzMCZmaXQ9Y3JvcCZtYXJrNjQ9YUhSMGNITTZMeTkzZDNjdVpHRjBiMk50Y3kxaGMzTmxkSE11WTI5dEx6STVPRFV3THpFMU9UTXhOVEE1TkRBdFkzSmhablJ6YldGdUxUQXhMbkJ1WncmbWFyay1hbGlnbj10b3AlMkNjZW50ZXImbWFyay13PTI1MCZtYXJrLXk9ODAmYmxlbmQ2ND1hSFIwY0hNNkx5OWhjM05sZEhNdWFXMW5hWGd1Ym1WMEwzNTBaWGgwUDNSNGRDMWhiR2xuYmoxdGFXUmtiR1VsTWtOalpXNTBaWEltZEhoMExXWnZiblE5YzJGdWN5MXpaWEpwWmlVeVEySnZiR1FtZEhoMExYQmhaRDB4TURBbWRIaDBMV052Ykc5eVBUSXlNVGd4TmlaMGVIUTJORDAwTkV0Nk5EUlBPRFEwVDBvME5FOXpORFJQVkRRMFQydzBORTg0TkRSTFV6UTBSMW8wTkV0TU5EUkhielZaWlRZMWIyazNORFJMU3pRMFIwMDFOVzAyTlRWVFpqUTBSMW8wTkV0TUpuUjRkQzF6YVhwbFBUVTFKbmM5TVRJd01DWm9QVFl6TUEmYmxlbmQtbW9kZT1ub3JtYWw&blend-mode=normal","otherPost":{"type":"author","title":"コラボすると開発チームがストレス？issueの最適な粒度を模索してます","slug":"/posts/25"}}}}