フィードバックは私たちにとってソフトウェア本体同様に,
覚えておくこと:セルフレビューで詳細は重要です
GitLabにおいて,
- すべてのフィードバックサイクルの前に:
- すべての行を読み返す
- コードをローカルでテストする
- すべての変更
(またはできる限り) のためのテストを書く - マージリクエストに明確な説明を記述し,
各フィードバックサイクル後に更新する - 変更ごとに少なくとも1つ以上のスクリーンショットを含める
(多いほどいい) - ラベルを確認し,
再確認する。その後に再び確認する - Monitor:Healthチームが実施しているように,
事前にIssueに対して ~"workflow::refinement"
ラベルを使うことを検討する。チームはラベル機能を使って,Issue, マージリクエスト, エピックに互いに排他的なラベルで注釈を付けることができる。これにより, 特定のラベルが一緒に使用されないようにすることで, より複雑なワークフローを実現できる。Scoped labelについてはこちらのドキュメントを参照 - レビュアーであるかのようにコードをレビューする。積極的に,
出そうな質問に答えておく, フォローアップのIssueを事前に開く - アクションにある最後の最重要な部分を確認するなら,
フロントエンド保守のNatalia Tepluhinaの方法を参照する。マージリクエストでレビューアに質問されるであろうことを事前に回答している
誠意を持ちコミュニケーションする
コードレビューを正しく行う上で最も難しいことの1つは,
従来型のコメントシステムがコードレビューにどのように貢献するか
より効果的なフィードバックを与えるために,
従来型コメントシステムはコメントの意図とトーンが分かるように,
実験してみましょう。レビューのためにコードをサブミットした時,
- 例1:代わりに,
Xについてどう思いますか? - 例2:[suggestion (non-blocking)] 代わりに,
Xについてどう思いますか?
恐らく例2を選んだのではないでしょうか。命令や必須の変更としてのコメントではなく,
このコメントで魔法となるのが冒頭の
- レビュアーからの提案であること
- 「non-blocking」,
コードの安定性に必要で難しい変更というよりは, 親近感をこめた提案であること
こうしたスタイルのコメントのもう1つの利点は,
例えばマージリクエストをコミットすると,
- ブロッカー:ライン上でマージを取得するために必要なもの
- 非ブロッカー:別途のマージリクエストとなりうるもの,
または議論のきっかけとなるもの
今度コードをレビューするときには,