【42Tokyo本科生向け】はじめてのチーム開発

はじめに

本記事は42Tokyoのfirst circle初のチーム課題に臨む本科生に向けたものです。今後追記すると思います。

この記事でわかること

• チーム開発経験がない方がどのように円滑に協業すればよいのか
• チーム開発での最低限のgit(githubを仮定します)の使い方

この記事でわからないこと

• チーム開発のあるべき方法論
• minishellの内部実装のTIPs
• 各単語の詳細説明

推奨しない/する協業プロセス

推奨しない

1. 開発したい機能をmainブランチでプッシュする
2. 相方の作業前にgit pullしてもらう

→こちらの問題点は、コンフリクトが発生した際に解消が非常に厄介であることに加え、mainブランチが動作する保証がなく、ロールバックしたいときにどこまで戻れば少なくとも実行できる状態なのか判断が難しいことです。

推奨する

1. githubのissueタブで開発したい機能のissue作成
2. 'git checkout -b {issue番号を含んだbranchの名前}'で作業ブランチ作成
   ※このとき、　作業中のコミットメッセージにissue番号を含めるとissueタブに反映されます。
3. 実装が完了したら、pushしてgithubのPull Requestタブからプルリクを作成
4. チームメンバーにレビューしてもらい、問題なければマージする
   参考：https://qiita.com/tkmd35/items/9612c03dc60b1c516969

→この場合、gitflowモデルをどこまで踏襲するかには寄りますが、mainブランチは少なくとも稼働することは保証されるように出来るはずです。

円滑な協業のための3つのルール

1. 目的の統一
   →マンダトリー一つとっても解釈が分かれるので、スタンスを明確にした上でチームで意思統一がされている状態がやりやすいはずです。例えば、例外処理一つとってもエラーを出すだけか、プログラム自体を終了させるか等。
2. ドキュメントの統一
   →githubのissueにすべて残しましょう。自分たちは突発的に見つかった修正事項等はすぐにissueを立てて相手に修正意見を提示したり議論したりしていました。
3. コーディングルールの統一
   →簡単なもので良いので見やすい関数名のルールを定めるとだいぶやりやすいと思います。自分たちは関数の先頭はなるべく動詞になるようにしました。リーダブルなコードのためには1関数に命名しやすいわかりやすい一つの仕事がある状態が良いです。normは最後に修正しました。

おわりに

　本科生用のScrapboxで書いていたものを再掲しました。かなり簡潔に書いているので今度LT会なんかでも話そうかな…