こんにちは！
島根支社でウェブエンジニアをしているカナツです。
GW も終わり、現実と向き合う日々に引き戻されたみなさま、いかがお過ごしでしょうか。
次の大型連休は島根観光をオススメします。自然が豊かすぎる島根で非日常的な日々を過ごしたくないですか？
前置きはさておき、みなさん、チーム開発時のソースコード管理って何使ってますか？
GitHub？GitLab？bitbucket？そんなことより進捗どうですか？
弊社ではソースコードの管理に GitHub Enterprise をつかってチーム開発を行うことが多いです。
複数人で開発を行うと、大きなシステムでもスピード感をもって開発を進めることができたり、複数機能を並行して進めることができたりするなど、良いこともある反面、チーム開発だからこそのさまざまな問題が立ちはだかることってありますよね。
たとえば…
- 誰が何のタスクを対応しているかわからなくなる
- Issue や Pull request に書くフォーマットがバラバラで読むのに時間がかかる
- 新しく誰かがジョインした時にコード設計のインプットに時間がかかる
- 仕様の伝わり漏れなどでケアレスミスが増える
など、ぱっと思い浮かべてもこのくらい思いつきます。
実際、私も複数人で開発したプロジェクトではこのような事案が起こってしまうことがよくありました。
そこで、複数人のプロジェクトでも円滑に開発が進むように、幾つか工夫しながらソースコードを管理しています。
※ 以下、GitHub Enterprise を利用した開発を前提としています
もくじ
- Issue & Pull request のテンプレート機能が便利
- Wiki を書こう
- Label, Milestone はできるだけ細かく/分かりやすく
- Hook を使って外部サービスと連携する
- Issue への Assign を徹底しておくと後が楽
- Perfect な状態で PR を Merge するための体制を整える
- DOC コメント, TODO コメント の明記をしっかりと
- プロジェクトをまたいだ PR チャットルームを設置してみる
Issue & Pull request のテンプレート機能が便利
GitHub には Pull request (以下 PR ) や Issue をテンプレート化できる標準機能があります。
今までは、別途 Wiki に書いてある PR テンプレをコピって PR にペーストし、各々で内容を埋めるという運用方法をとっていましたが、そんなめんどくさいことをしなくても良くなりました。ハッピー！
開発者への負担軽減
そもそも開発者的には「コードを書くこと」以外の作業である、”PR 概要を書く”とか、”Issue を書く”だとかは、できるだけ減らしたいですよね。
Issue や PR をテンプレート化しておくことで、項目に従って記入する形になるので、小さなことですが開発者への負担の軽減になりました。
セルフレビューの強化
私がジョインしているプロジェクトでは、PR テンプレートに「チェック項目」のようなものを設けています。
例えば、以下のような内容です。
- 各種パラメータのチェック
- プロジェクトのコーディングルールに則っているか
- テストが通っているか
こういった内容をチェック項目としてテンプレートに明記することで、開発者は PR を出す前に「確認すべき内容が網羅できているか」を確認し、バグをあらかじめすくい上げるというメリットが生まれます。
Wiki を書こう
言わずもがな、Wiki 機能です。Wiki 機能、使っていますか？Wiki の発音が未だに分からないカナツです。ちなみにわたしは餅と同じイントネーションです。
意外とWiki って使わなかったりするんですよね。デフォルトの「Welcome to ~」のままになってるリポジトリもしばしば。
せっかく用意してあるので、使わないともったいないです。使いましょう。Wiki を。
プロジェクトメンバー（特に開発者）に見てもらいたい内容は Wiki になるべく明記するように心がけています。
開発 Tips の記載
Wiki には仕様関連の内容（API 仕様、開発環境など）を記載するほか、開発者が開発を進めるにあたって気付いたことがあれば積極的に Tips として明記してもらいます。
また、共通コンポーネントの使い方なども明記してもらっています。
これにより、新しくジョインされた開発者への説明の手間が大幅に解消されました。
また、コンポーネントの利用方法を明記しておくことで、コンポーネントを作成した開発者にわざわざ使い方を聞かなくても導入できるようになりました。
ただし、 定期的にメンテをしないと、 Tips の情報が古いままになってしまって引き継ぎのときに＼( ‘ω’)／ウオオオオアアーーーッッ！！！ってなります。くれぐれも放置しないように気をつけて下さい。
Label, Milestone はできるだけ細かく/分かりやすく
Label と Milestone は Issue や PR の状況説明的な使い方をしてます。
Label
Label は小〜中カテゴリの機能や画面毎に分けています。
それ以外にも、「結合テスト FB」「保留」「優先度」など、状況が容易に把握できるように細かくラベルを切っています。
Milestone
Milestone は納品フェーズに分けて管理しています。
課題洗い出しの容易さ
Issue 起票時に必ず Label と Milestone は明記しています。
これにより、ソート（課題洗い出し）が容易になり、今やるべきタスク、後回しにしても問題ないタスクを切り分けやすくなります。
[課題] Project が活用できていない
Project はリポジトリ内に機能・画面より大きなカテゴリが複数ある場合は利用しています。
Issue のソート機能としては便利ですが、Project 本来の機能（カード）としては活用出来ていないのが現状です。。
振り分けをする手間がかかり、Issue 起票の速度に振り分け作業が追いつかなくなってしまいました。。
もはやよりソートをしやすくするためのイチ機能として割り切ってしまうのもありかもしれません。
Hook を使って外部サービスと連携する
Webhook 機能を使いチャットツールや課題管理ツールと連携をしています。
Backlog 連携
結合テストの結果などは Issue ではなく別の課題管理ツールで管理することもあります。
私のプロジェクトでは結合テスト結果は Backlog で管理していましたので、Backlog に課題が起票されたら自動的に GitHub にIssue が投下されるようにしていました。
これにより、開発者のテスト結果の対応漏れを防ぐことに繋がりました。
ただ、今のところ1対1 連携しか出来ないので、こちらは改善していきたい次第です。
（例えば、1つの Backlog プロジェクトでもタグによって連携する GitHub リポジトリを切り替えるとか）
Chatwork 連携
もはや GitHub とチャットの連携は必須ですね。
Issue/PR のオープン時、クローズ時、コメント、メンション etc を連携するようにしています。
個人的に Conflict 通知があるとよりハッピーですね。白バラコーヒー2本のお礼するので誰か作って下さい。
Issue への Assign を徹底しておくと後が楽
開発者に Issue を対応して貰う前に必ず担当者を Assign に入れるようにしています。
これにより、複数人で開発を行っていても、誰がどこを担当したか、またこれから誰がなんの対応をするかが明確化します。すべては未来のため。
Perfect な状態で PR を Merge するための体制を整える
見出しがルー語みたいになってますね！
PR は軽微なものであっても複数人でレビューを通すことが多いです。
複数人による多角的な目線でのレビュー
基本的に1PR に対して、2人以上でレビューするようにしています。
また、SE がプロジェクトメンバーに居る場合は、 PG / SE を1名ずつレビューにアサインします。
主に PG はコーディング規約、処理の書き方が適切であるかなど、ロジック的な部分のレビューをしてもらいます。
SE は仕様が満たされた実装になっているかチェックすることに注力しています。
仕様確認方法ですが、個人的にはブランチをローカルに落として実際に動作確認する方法をオススメしたいです。（SourceTree に圧倒的感謝）
上記の方針により、致命的なバグをレビュー段階でキャッチが可能であったり、
PG ⇔ SE 間の仕様の齟齬を無くすなど、Merge するまでに質の高い内容に仕上げることが出来ます。
その分1つのPRマージまでにやや時間が掛かってしまいますが。。
しかし、その分コードの質も上がりますので、致し方ないかと思う部分もあります。
開発期間が短く、かつスピード感が重視されるのであれば別の方法を取ったほうが良い場合もあるかもしれません。
DOC コメント, TODO コメント の明記をしっかりと
複数人でソースコードに触るためコメントの明記は不可欠です。
TODO にルールをつける
関数の DOC コメント記載はもちろんのこと、まだ未実装の箇所については TODO コメントを明記してもらうことを徹底しています。
また、「TODO: {内容} {名前}」のように名前を明記してもらうことで、誰が明記したTODOなのかを明確化しています。
プロジェクトのある程度区切りがいい場面で、 GitHub の検索機能をつかって TODO 箇所を洗い出し、消し忘れや対応漏れが無いかをメンバーで定期的にチェックしています。
難点は、”TODO” を “DODO” とかに typo したら一生その TODO は拾えないことです。その時は諦めましょう。
プロジェクトをまたいだ PR チャットルームを設置してみる
私の所属している部署では PR 部屋というものを設定し、部署内で動いているプロジェクトの PR がすべてその部屋に通知されるような仕組みにしています。
これにより、
- プロジェクト外の有識者へのヘルプ
- 他プロジェクトへの関心が生まれ全体的な技術力向上につながる
上記のような良い流れが生まれました。
このように、私が現在関わっているプロジェクトではよりよい開発を行うためのフローのベストプラクティスとは何か、常に試行錯誤しながら取り組んでいます。
同じようにチーム開発の運用フローで困っている方の参考に少しでもなれば幸いです。
読んで頂きありがとうございました！よい開発ライフをお過ごし下さい！そして連休明けで現実から逃避したい人はぜひ島根に遊びに来て下さいね！
フェンリルのオフィシャル Twitter アカウントでは、フェンリルプロダクトの最新情報などをつぶやいています。よろしければフォローしてください！
フェンリルの開発者アカウントでは、フェンリルプロダクトの最新開発情報などをつぶやいています。よろしければフォローしてください！
フェンリル採用チームの Twitter アカウントです。応募前のお問い合わせや、ちょっとした相談ごとなどお気軽にどうぞ！
フェンリルの Facebook ページでは、最新トピックをお知らせしています。よろしければいいね！してください！
関連記事
