PushRequest on-boarding for reviewee
2024年12月22日 18:46
この資料はpushrequestでのレビューを受ける上でのルールを書いています。
こんにちは!寒河江(さがえ) です。
PushRequestでは現場の開発スタイルをみなさんにお伝えしながら素早くコードレビューすることをモットーにしています。
sagaekeiga
アカウントをあなたのレポジトリへ招待してください。
基本的にはみなさんにお任せしますが現場で使っている言語やテンプレートエンジンを使うことをおすすめします。
Ruby on Rails を利用します。
Ruby on Rails(2018 年 3 月時点では 5.1.5)をそのまま利用します。
コーディング規約については最近のレポジトリであれば Rubocop を利用してチェックを行っています。
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 を見た人間が開発に取り組めるように、情報が多すぎる位でも問題ありません。
.github/ISSUE_TEMPLATE.md は以下の通りです。
テンプレートの設定はこちらを参考にしてください。
参考
レビューして欲しい人間のアカウントを指定してください。
基本的に git-flow の流れに則った形で作業を進めていきます。
参考 : Understanding the GitHub Flow
プロジェクトメンバーが増えてリリース phase を踏む形にシフトする際はタイミングをみて Git-Flow へ移行していきます。
初期開発完了(受託開発であれば納品まで。サービスであれば初期ローンチまで)は master ブランチを merge 先のブランチとします。
issue の対応を行う際には GitHub-Flow に則り「features/your-task」のような形で新しく master からブランチを作成して作業を開始してください。
1 つのブランチで複数の issue を対応しても問題ありませんが、多く詰め過ぎると merge が面倒になるので最大 3 つの issue を目処にしてください。
作業用ブランチに master を merge するタイミングなど、ローカルで merge 作業を行う際には必ず「--no-ff」を指定してください。
作業用ブランチでの作業が完了したら、master ブランチに対してプルリクエストを作成してください。その上で Slack 上のプロジェクト用チャネルで
のような形で Slack 上で声をかけてください。
(複数のプロジェクトが同時に進行しているため、GitHub 上の作業が流れてしまうのを防ぐためです)
プルリクエストもテンプレートを用意しています。
参考 : Pull request templates make code review easier
実装する前にWIP pullrequestを作成してください。
レビュイー・レビュワーが作業を視覚的に確認することができます。
git で commit 時のメッセージとして「fixed #000」と入れておいてください。
こうしておくことで、master に merge された時点で issue が自動的に close されます。
自動的に issue を close したくない場合には、「#000」とだけ書いておけば issue に関連づけられます。
Rails のプロジェクトであれば rspec を利用します。ほとんどのプロジェクトでは原則モデルの unit テストだけで十分です。
継続して案件が進む場合には必要に応じて追加します。また、以下のものについてはリリース前までに書いておいたほうが幸せになれることが多いです。
クラス単位でのコメントは最小限に(そもそもクラス名を見てその役割が分からないのはおかしいので)とどめる形で構いません。
関数単位でのコメントは
を記述するようにしてください(以下の例を参照)。
設定や備考録等、対象プロジェクトに関するドキュメントは GitHub の Wiki にまとめてください。
無理やり 1 ページに納める必要はないので、Home ページからリンクを貼る形で機能/項目単位でページを作成して問題ありません。
ステージング環境にherokuを導入しましょう。
こうすることによって本番環境への移行がスムーズになります。
オートデプロイ機能を利用するとmasterにmergeした段階で自動的にherokuに反映されるので設定することをおすすめします。
CircleCIの導入をおすすめします。
導入することでテストを自動化することができます。
設定ファイルのテンプレートを用意しているのでカスタマイズしてご利用ください。
注: rubocop
, rails_best_practices
, brakeman
(Gem)のインストールを事前に行ってください。
テンプレート
現場で使われるGemを用意しました。
中身を確認してぜひご活用ください。
WIPのpullrequestを作成してわからない内容を書いてください。
※ テンプレートを使ってください。
▼▼▼▼▼ テンプレート ▼▼▼▼▼
ここに質問の内容を詳しく書いてください。
(例)PHP(CakePHP)で●●なシステムを作っています。
■■な機能を実装中に以下のエラーメッセージが発生しました。
ここに問題に対して試したことを記載してください。
ここにより詳細な情報を記載してください。
診断を受けるとあなたの現在の業務委託単価を算出します。今後副業やフリーランスで単価を交渉する際の参考になります。また次の単価レンジに到達するためのヒントも確認できます。