$shibayu36->blog;読者になる$shibayu36->blog;株式会社アンドパッドでエンジニアをしています。プログラミングや読書のことなどについて書いています。2016-08-05仕様や実装方針の相談をPullRequestで行う取り組みtechこれまで少し大きめな機能であれば、コードを書く前にまず仕様や実装の方針をissueのdescriptionにまとめ、それを先にレビューしてもらってから実装にとりかかるということをしていた。最近、その方針をそもそもrepositoryのファイルとして書いて、PullRequestしてレビューしてもらうようにしたら便利だったのでご紹介。コードを書く前に仕様や実装の方針をレビューするのか前提としてなぜコードを書く前に仕様や実装の方針をレビューして欲しいのかについて書いておく。これはとにかく手戻りの量を少なくしたいという要求のためである。実装に取り掛かろうとすると、実装の方針はいくつか思いつくが、どれが一番よいか迷うことはよくある。その場合に誰にも相談せず自分だけで判断し、コードを書いてからPullRequestを送った場合、もしその選択に重大なミスがあった場合全て書きなおさないといけない。これは大きな手戻りが発生する。このような手戻りを防ぐためには、まずは実装の方針をMarkdownか何かで書き、それを先にレビューしてもらうという手がある。以下のようなフォーマットで書くなどが考えられる。案1は工数が非常に少なく済むが、案2のようにしないと今後技術的負債になりうる。そこで多少大変だとしても、今回は案2の方針で行おうと思うがどうか。このフォーマットは単なる例で、その他にもデータのスキーマなどを先に相談したり、処理の流れを日本語で書いてみたりでも良い。いろんな形式で書いて先にレビューしてもらうことで、その時点で筋が悪い部分は指摘され、手戻りの量が少なくなる。これまではどうしていたかこれまではこのような実装方針レビューはGithubのissueのdescriptionに書いたり、issueのコメントに書いたりして、issueベースでレビューをしてもらっていた。この方法でも良いのだけど、次の課題があった。ある部分が筋が悪いという指摘を書くのに、いちいちその文章を引用してコメントしていて、面倒であった指摘後、実際に修正してもらった時に、その修正点が分かりづらかった新しく入った人に先に実装方針レビューやったほうが良いというアドバイスをしても、その例をissue検索で探して渡す必要があった課題を解決するために試してみたことこれらの課題を解決するために、実装方針レビュー用のディレクトリを作って、そこにMarkdownでファイルを作って、普通のPullRequestベースのレビューでコメントを書いてもらえば良いのでは?と考えた。これは以前別のチームでやっているという話も小耳に挟んでいたので、実際に試してみた。次の流れで実装方針をレビューしてもらう。docs/spec_review/みたいなディレクトリを作っておくそのディレクトリ以下にYYYYmmdd-hoge-spec.mdのようなファイルを配置し、そこに方針を書いていく完成したらいつもどおりPullRequestを送るそのファイルに対して、レビュワーにはラインコメントを書いてもらうレビューされたら、コメントに返信したり、方針のファイルを変更したりするレビューが通ったらmergeするあとはそのファイルを見ながら実装するこのようにすることで先ほど挙げた課題となっていることを解決できた。ある部分にコメントするのは普通にラインコメントで良い方針案の修正内容がcommitになるためわかりやすいdocs/spec_review/以下にどんどん実装方針レビューが溜まっていくため、後から入ってくる人に例として出しやすいまとめ今回は仕様や実装方針相談をPullRequestで行う取り組みについて書いてみた。試してみただけだけど、思ったより良い雰囲気だったので、今後も続けていこうと思う。2リンクプライバシーポリシーはてなブログをはじめよう!shiba_yu36さんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。