mironal/開発ガイドライン.md

## 開発ガイドライン.md

      
    Raw
  

              開発ガイドライン.md
            
          
    esa に移しました。

--
コベリンの開発ガイドライン

概要

これは合同会社コベリン (covelline, LLC.) でソフトウェア開発を行う際のガイドラインです。
複数人で円滑に開発を行う為の最低限のルールを記述します。
あくまでもガイドラインなので完璧に守る必要は無いです。個々のプロジェクトの独自ルールなども
確認してください。
ここでは issue を作って coding をして pull request を出して review
してもらって merge するまでの基本的な流れについて記述します。

Issue

人にアサインしよう

新機能、アイディア、バグなど作業に繋がるものは issue にしましょう
作りっぱなしにならないように必ず人にアサインしましょう
他人にアサインするときにはひと声かけましょう

非開発者が issue を立てるとき

ユーザーサポートのバグ報告などで非開発者が issue を作る場合
誰にアサインしたらいいか分からず困る場合があります。
その場合はとりあえず自分にアサインした後にどこかで開発者側と時間を取って
アサインを行いましょう。
Issue を作るごとに開発者側と話し合うと時間を無駄に消費してしまうので
複数個作ることが想定される場合はまとめて話し合いを行えるようにしましょう。
Coding

作業の前に話し合おう
ある程度の規模の作業なる場合は予め誰かと設計やデザイン機能について相談して
pull request を出した後に作業が手戻りになるのを防ぎましょう。

例) 新しい UI を実装したけど、他の人が想像してたのとぜんぜん違った


例) coding する人は頑張って実装したけど、本人が知らないだけで実は簡単にやるライブラリがあった


例) もっと優先度が高いタスクがあった

あとは自由に開発しましょう。
Commit


コミットメッセージなどは各プロジェクトのガイドラインを参照しましょう
コミットメッセージのテンプレートファイルがある場合は活用しましょう
参考: http://postd.cc/how-to-write-a-git-commit-message/

Pull Request

review する人が分かるようにコメント・メッセージを書こう

Review する人の為に 概要 と チェックして欲しい所 は必ず書きましょう

チェックして欲しい所はチェックボックス - [ ] 項目 で書くとわかりやすいです


Review してもらいたい人にアサインしましょう
アサインだけだと分からないので slack などでメンションを飛ばしましょう

ex) @mention れびゅよろ〜 <pr の url>


Template

### 概要

- なぜこの変更をするのか
- 現在どんな問題があるのか
- バグだったらバグの内容・再現方法・バグの理由
- issue やコミットメッセージに詳細が書いてある場合はその案内を書く

### チェックして欲しいところ

- [ ] 不安なところとか実機チェックが必要なものとか

Review

レビューが終わったらアサインを変えよう

チェックして欲しい所 は必ずチェックしましょう

チェックしたらチェックボックスを埋めてあげましょう


Review が終わったら pull request を出した人に アサインを戻しましょう

その際には pull request を出した人が次に何をすればよいのかが分かるようにしましょう

レビュー完了なら LGTM をコメントに書いて merge して良いことを示すとか
修正が必要なら 修正待ち と書くなど


いずれの場合も github からの通知だけだと気が付かないので slack などで一言メンションを飛ばしましょう


Merge


Pull request を出した人が merge しましょう
コミットが base branch の先頭にない場合は git rebase しましょう


必要に応じて編集していきましょう。

https://github.com/covelline/covelline/issues/154