チーム開発のハードルを下げる

チーム開発やってみよ！

N予備校プログラミング入門コース受講2年目でDockerがでてきて喜んでいるsatsukizzzです。
「チーム開発やってみよ！」
これがプログラミング入門コースを受講しているN高・N予備校生に一番伝えたいメッセージです。

概要

1. N予備校ではソロ活動がほとんど
2. チーム開発を学ぶリポジトリ
3. 最低限必要そうな機能の導入
4. 最後に

具体的にリポジトリとその中身・活動を見たい方は3番目から読み進めてください。
なお、コースの受講が前提の記事になっていますので、受講されていない方には不都合かとは思いますがあらかじめご了承ください。

N予備校ではソロ活動がほとんど

私のプログラミング経験をざっと書きますが
- 2019年まで、散発的にHTMLやJavaScript、R、C++、VBAなどを触る
- 2020年にN予備校のプログラミング入門コースに参加する
- 入門コース途中でアルバイトとしてIT企業に採用される
- アルバイトでチーム開発に初めて携わる
- 2021年も再度入門コースを受講、続きの実装
という感じになります。最近は当時忙しくなりできなかった4章に向けて、Slackとリアルタイム授業(執筆段階で3章27節)で少しずつ復習している日々です。

このうち、チーム開発を行ったのはアルバイトでのみになります。初めての経験でとても新鮮で、アルバイトの自分が書いたコードでも社員の方にレビューしてもらって最終的にマージされるのは単純に嬉しかったですし、他人のコードをレビューするときには一体感やレベルを引き上げられる感覚を覚えました。
一方で、チームに依る部分がありつつも入門コースでは学ぶことのなかった根本的で当然の部分があるように感じました。

特に入門コースで
- gitとGitHubの使い方を教えている
- プルリクエストのあげ方を教えている
けれども、そのプルリクエストはマージされることはありませんでした。

チーム開発を学ぶリポジトリ

受講生同士なにか手伝えることがないか？と考えたときに浮かんだのは、実際にチーム開発のリポジトリを作ることでした。

Slackにチャンネル #一緒にhttpアプリ作ろう を作ってリポジトリを主催しています。

10月5日にSlackチャンネルを作り、GitHubリポジトリ整備を行って呼びかけていました。
リポジトリの目標は、N予備校の教材の内容を分担して積み上げていくことです。
この2か月で10件のプルリクエストが提出され、うち3件のプルリクエストがマージ済み、2件はリジェクト済みとなっています。
リジェクトはプルリクエストを拒否することですが、受講生で初めてのチーム開発だという方が一から上げてみた練習の名残です。

必要な機能の導入・解説

GitHubでチーム開発する場合にはいろんな機能が使えます。そのうち必要そうなものと、

README.md

既に何度か教材の中でも登場していますが、リポジトリがどんな目的でどんな風に使われるのかを書いたものです。
今回はチーム開発の練習のためですので若干アバウトですが、そのような説明を入れました。

GitHub Discussions

Discussionsはリポジトリの利用者と開発者がGitHub上で気軽に会話できるようにした掲示板のようなものです。
リポジトリの設定から機能ONにできます。
オプションで機能ONにできるDiscussionsのほかにも、Issues、Gitter(オプション)というものがGitHubにはあります。
Issuesは問題点を具体的に提示してそのままコード修正や機能追加につなげるもののようです。
Gitterはリポジトリ参加者が作るTwitterのタイムラインのようなものです。
今回はDiscussionsを使うことで随時有用な情報を提供できるようにしています。

後になって解説が必要になって追加した情報が例えば以下です。
レビューの仕方
プルリクエストの上げ方

GitHub Template

Templateはプルリクエストの作成のときにテンプレートを提供してくれます。
チーム開発が初めてでもプルリクエストに書く内容を誘導してくれるような仕組みです。
シンプルなことに中身はただのMarkdownで、リポジトリ直下に .github/PULL_REQUEST_TEMPLATE.md という名前で設置するだけです。
Template自体はほかにもIssuesで書くときなどにも使えます。同様にmd形式で設置します。

Collaboratorの設定

GitHubでは開発の仕方が二通りあり、
1. リポジトリをフォークしてもらい、フォーク先からフォーク元へプルリクエストを上げる
1. リポジトリの開発者となり、リポジトリ内部で自由にブランチを作りプルリクエストを上げる
方法です。
入門コースでやっているプルリクエストは前者ですが、共通のメンバーで一定の時間をかけて開発していくには若干厄介です。というのも、プルリクエストを上げるのは簡単ですが、それをレビューするのにはGit上の操作が多く必要だからです。
今回は後者で行うため、リポジトリの開発者になってもらうのですが、それにはCollaborator(貢献者)の設定が必要です。あらかじめDiscussionsで自己紹介してもらった方にその権限を付与し、開発してもらうようにしました。

これにより、普段行っているgit操作に加え git checkout [プルリクエストのブランチ名] として簡単にレビューできるようになりました。

ブランチ保護ルールの設定

公開されるブランチ(ここではmain)が動作しない、エラーまみれ、バグまみれというのは避けたいところです。一方で開発メンバーのCollaborator設定したので、誰でも自由にリポジトリ内での開発ができるようになっています。
mainブランチの一定のコード品質を保つにはブランチ保護ルールというのを設定します。
設定の仕方は「こんなブランチ名ならこういう制約を課すよ」って感じでシンプルです。
今回はmainブランチにコミットを積めないようにし、プルリクエストがあった場合は2人以上のApprove(賛成)が得られた場合にのみマージできる、という制約にしました。
レビューの際に動作確認までお願いしているので、バグまみれということはほぼありえなくなります。

Slackチャンネル

メンバー同士が仲良くなったり気軽な会話をするのにはDiscussionsでも堅苦しいです。今回は入門コースで案内されたSlackスペースの一部をお借りし、公開でチャンネルを作って自由に出入りしてもらうようにしています。

最後に

目標創作物

なにかチーム開発をしようというとき、題材や最終目標も重要です。
ただ、私はあまりそちらを準備するのが得意でなく、バックアップのような仕事の方が好きでしたので、題材は教材のまま、どうやってレビューやマージをするかについて個別に相談に乗りつつ記事を作ったりしてきました。
意欲のある方は題材や最終目標で人気を勝ち取って存分にチーム開発を進めていってもらいたいです。

拙いコード、見られる恐怖

レビューされるの怖いよ、リジェクトされるの怖いよ、って絶対思います。けどコードを書いた人が一番褒められるべきです。実行した人は実行しないひとより格段に先を行くんです。怖いかもしれないですが、まだやったことない受講生の方も余裕があればお試しください。

リポジトリ内の情報の利用

また、こちらのリポジトリにあるレビューの仕方などの情報は自由に使ってもらって構いません。そして、チーム開発してみたいと思ったひとはリポジトリ整備などで私を呼んでいただいて構いません。開発の下支えとしてできることをさせていただきます。DMやメンションで連絡ください。

追伸

最近は自身が多忙で全然手を入れられておらず申し訳ないのですが、時折プルリクエストが上がったりレビューされたりと、一定の反応が得られています。考えたことを実行に移してよかったなと思います。

諸事情によりAdvent Calendarに登録していた内容から変更し、突貫工事で文字ベースに作成した記事になります。訂正を随時行いますので遠慮なく質問や指摘下さい