pushrequest Rule

この資料はpushrequestでのレビューを受ける上でのルールを書いています。

はじめに

こんにちは！寒河江（さがえ） です。

PushRequestでは現場の開発スタイルをみなさんにお伝えしながら素早くコードレビューすることをモットーにしています。

レビューの受け方について

■ レポジトリへの招待

sagaekeiga アカウントをあなたのレポジトリへ招待してください。

招待の仕方

開発の進め方について

基本的にはみなさんにお任せしますが現場で使っている言語やテンプレートエンジンを使うことをおすすめします。

■ 開発言語

Ruby on Rails を利用します。

◆ バックエンド

Ruby on Rails（2018 年 3 月時点では 5.1.5）をそのまま利用します。

コーディング規約については最近のレポジトリであれば Rubocop を利用してチェックを行っています。

◆ JavaScript

Rails 5.1 以降で導入された webpacker を利用して、ES6 で記述します。

▲ スタイルガイド

クラス名/関数名は CamelCase を基本とします。

◆ テンプレートエンジン

Hamlを利用します。

すでにerbで開発をしている方は erb2haml を使ってhamlに一括置換することができます。

参考

▲ スタイルガイド

'='の後には必ず半角 space を 1 つ入れてください。

◆ スタイリング

SASS（SCSS）で記述します。

CSS のフレームワークとしてはBootstrap 3（Bootstrap4でもOK）を利用します。

▲ スタイルガイド

Google HTML/CSS Style Guideに準拠します。

■ ソースコードの管理について

GitHubを利用します。

実装を行わない方も issue の登録等でレポジトリを閲覧できる必要がありますので、アカウントを持っていない場合は作成してください。

また、セキュリティレベル向上のためアカウント作成後に二段階認証を有効にしてください。

◆ issue 登録時に設定する項目

件名（Title）

長すぎず、完結に。

本文（Comment）

issue を見た人間が開発に取り組めるように、情報が多すぎる位でも問題ありません。
.github/ISSUE_TEMPLATE.md は以下の通りです。

テンプレートの設定はこちらを参考にしてください。
参考

レビュー者（Reviewer）

レビューして欲しい人間のアカウントを指定してください。

■ 作業開始から終了まで

基本的に git-flow の流れに則った形で作業を進めていきます。

参考 : Understanding the GitHub Flow

• issue に作業内容を登録
• 作業用ブランチ作成
• 実装作業
• GitHub へ作業用ブランチを push
• プルリクエストの作成
• 実装者以外のレビュー
• （レビューで修正の指定がある場合は修正後、再度レビューを依頼）
• 本ブランチ（主に master）へのマージ

プロジェクトメンバーが増えてリリース phase を踏む形にシフトする際はタイミングをみて Git-Flow へ移行していきます。

◆ 利用するブランチ

初期開発完了（受託開発であれば納品まで。サービスであれば初期ローンチまで）は master ブランチを merge 先のブランチとします。

issue の対応を行う際には GitHub-Flow に則り「features/your-task」のような形で新しく master からブランチを作成して作業を開始してください。

1 つのブランチで複数の issue を対応しても問題ありませんが、多く詰め過ぎると merge が面倒になるので最大 3 つの issue を目処にしてください。

◆ ローカルでの merge について

作業用ブランチに master を merge するタイミングなど、ローカルで merge 作業を行う際には必ず「--no-ff」を指定してください。

参考

◆ プルリクエストの作成

作業用ブランチでの作業が完了したら、master ブランチに対してプルリクエストを作成してください。その上で Slack 上のプロジェクト用チャネルで

のような形で Slack 上で声をかけてください。

（複数のプロジェクトが同時に進行しているため、GitHub 上の作業が流れてしまうのを防ぐためです）

プルリクエストもテンプレートを用意しています。

参考 : Pull request templates make code review easier

◆ WIP pullrequestの作成

実装する前にWIP pullrequestを作成してください。

レビュイー・レビュワーが作業を視覚的に確認することができます。

参考

◆ issue の完了

git で commit 時のメッセージとして「fixed #000」と入れておいてください。

こうしておくことで、master に merge された時点で issue が自動的に close されます。

自動的に issue を close したくない場合には、「#000」とだけ書いておけば issue に関連づけられます。

■ テストコードについて

Rails のプロジェクトであれば rspec を利用します。ほとんどのプロジェクトでは原則モデルの unit テストだけで十分です。

継続して案件が進む場合には必要に応じて追加します。また、以下のものについてはリリース前までに書いておいたほうが幸せになれることが多いです。

• 決済機能
• API

■ コメントについて

クラス単位でのコメントは最小限に（そもそもクラス名を見てその役割が分からないのはおかしいので）とどめる形で構いません。

関数単位でのコメントは

• その関数が行っていること
• 引数の説明
• 戻り値の説明
• その他補足事項

を記述するようにしてください（以下の例を参照）。

■ ドキュメンテーションについて

設定や備考録等、対象プロジェクトに関するドキュメントは GitHub の Wiki にまとめてください。

無理やり 1 ページに納める必要はないので、Home ページからリンクを貼る形で機能/項目単位でページを作成して問題ありません。

■ Herokuの導入

ステージング環境にherokuを導入しましょう。
こうすることによって本番環境への移行がスムーズになります。

オートデプロイ機能を利用するとmasterにmergeした段階で自動的にherokuに反映されるので設定することをおすすめします。

■ CircleCIの導入

CircleCIの導入をおすすめします。
導入することでテストを自動化することができます。

参考

設定ファイルのテンプレートを用意しているのでカスタマイズしてご利用ください。
注: rubocop , rails_best_practices , brakeman （Gem）のインストールを事前に行ってください。
テンプレート

■ 参考Gem

現場で使われるGemを用意しました。
中身を確認してぜひご活用ください。

参考Gem

■ わからない（実装できない）ところがあったら？

WIPのpullrequestを作成してわからない内容を書いてください。
※ テンプレートを使ってください。

参考

▼▼▼▼▼ テンプレート ▼▼▼▼▼

前提・実現したいこと

ここに質問の内容を詳しく書いてください。
（例）PHP(CakePHP)で●●なシステムを作っています。
■■な機能を実装中に以下のエラーメッセージが発生しました。

発生している問題・エラーメッセージ

該当のソースコード

試したこと

ここに問題に対して試したことを記載してください。

補足情報（FW/ツールのバージョンなど）

ここにより詳細な情報を記載してください。