- その1
main, master ブランチにPushをしない
- 理由:
直接親ブランチにpushしてしまうとコンフリクトが大量に発生してしまい、作業に支障が出る
- どうしたらいいかの説明:
※今回の場合は設定で`main`, `master`にPush出来ないようにする
- その2
作業内容を分割してIssue, Pull Request を発行する
- 理由:
かなり長く作業をし、大きいPull Requestになってしまった場合
相手のレビューがかなり遅くなってしまったり、確認漏れが大量に発生する可能性がある
- どうしたらいいかの説明:
新規機能を1つ作った時点でPull Requestを発行する。
バグを1個修正したらPull Requestを発行する。
同じようなバグだった場合はそれらをまとめてPull Requestを発行する。
Pull RequestやCommitの数は多くなっても大丈夫。
Pull Requestで部分的にマージなどは出来ないためデカいPull Requestにされると反対に困る。
Pull Requestは1個単位で機能修正やバグ修正、新規機能の作成をした際に行おう。
- 理由:
変数名や関数名、クラス名や定数名、データベース上でのテーブル名で名前を決める際に
関数の場合はどういう事をしているのか、変数や引数, 定数の場合はどういうデータが入っているのかなどを一目で分かるようにする。
- どうしたらいいかの説明:
お手軽にキャメルケースを使用しよう。
名前を付けるセンスはもちろん問われるが、基本的に下記の通りに書けばいい。
| 命名規約 |
ケース |
|
| 変数名, 引数名, 関数名 |
キャメルケース( camelCase ) |
|
| クラス名 |
パスカルケース( PascalCase ) |
※大体のクラス名は1単語のため気にしなくていい |
| 定数名 |
アッパースネークケース( UPPER_SNAKE_CASE ) |
|
| データベースのテーブル名 |
ローワースネークケース( lower_snake_case ) |
|
- その4
関数を切り分けてプログラムの凝集度を上げる
- 理由:
1つの関数内に100行とかになった場合はかなり読みにくい。
- どうしたらいいかの説明:
そういう場合は関数内の処理事に関数を切り分け、親関数の行数を減らし、抑えるように
関数自体は増えても良いし、新しくファイルも増えても良い
しかし、増やしすぎて反対に分かりずらくなる事は避けないといけない。これはおいおい説明します。
- その5
関数で渡された引数を編集しそのまま返さない
- 理由:
引数の中身をいじってその引数を返すというのは良くない。
本来引数は"定数"という認識の方が良い。つまり変更は出来ない前提でコードを組むべき。
- どうしたらいいかの説明:
配列や連想配列が渡された場合はスプレッド構文で新しい配列や連想配列を作って返す
- その6
IssueやPull Request, Commitの書き方を覚える
- 理由:
これ出来るだけで1人前のプログラマーといってもガチで過言じゃない。
これが出来れば出来るほどチームの連携が上手くなっていく。
Issue の場合
タイトル名に問題点や、修正点、どういう事をするのか大まかに説明
Description(説明) でどういう内容のIssueなのか具体的に説明
Assigneesで誰が担当するのかの設定
LabelsでこのIssueはどういうカテゴリーに属すのかの設定
Pull Request の場合
書き方:
## 概要
なんとか機能をどうのこうの変更しました
oo という修正だとxxの問題があったので hoge という方針で修正しました
## 注意
外部サービスを利用してるので再ビルドが必要
スプレッドシートのクレデンシャルの設定がいる
#pr_no を先にマージする必要がある
## セルフチェック
- [x] ooが使えること
- [x] xxの時はエラーが出力されること
## SS
画像
## 関連
close #issue_no
タイトル名に問題点や、修正点、どういう事を行ったのか大まかに説明
Description(説明) でどういう内容のPull Requestなのか具体的に説明
Reviewersで誰がこのPull Requestの確認を担当するのかの設定
LabelsでこのPull Requestはどういうカテゴリーに属すのかの設定
※`close #issue_no` などをしていた場合はマージした際に自動的に指定したIssueが消えるようになっている
Pull Requestで指摘されたコメントに返信する場合
対象のコメントを修正したCommitをした後に下記のように返信する:
### update: pushの場所をpull_request_targetに変更
> 上記修正: <CommitのURL>
CommitやPull Requestの名前の決め方
| 状況 |
Commitの場合 |
Pull Requestの場合 |
| 何かを追加した時 |
[add]: 内容 |
Add/内容 |
| 機能を修正や更新した時 |
[update] 内容 |
Update/内容 |
| 何かを消した時 |
[delete] 内容 |
Delete/内容 |
| 動作に変更は無いけど途中の処理方法を変えた時 |
[refactor] 内容 |
Refactor/内容 |
- その7
分からない場合は早めに仲間に現状を報告し、助けてもらう。
- 理由:
いくら考えて実装しても、×を食らったら多少のスキルは上がるが時間の無駄になってしまう。
仲間に聞くことで自分が知らない対処法などを教えてくれたり、一緒に解決に向けて歩むことでよりスムーズに仕事を進める事が出来る。
- どうしたらいいかの説明:
全部自分が出来るというプライドはへし折り、仲間に助けてもらう