skillup

技術ブログ

ドキュメント作成 プロジェクト管理

レビューについて

投稿日:

以前、コードレビューそのもののポイントについてはコードレビュー時のポイントでまとめましたが、レビュー自体の体制の注意点やそこでの気づきなど。

目的

基本ルールに則っているかどうかを見るといった初歩的な意味もありますが、人間の思考の漏れを検証するといった意味あいが強いため、多人数で行わないとそもそもの意味がない・・・と思います。

定型的なものはチェックリストを

これについてのなるべく頭を使わずに自動ではじける仕組みが大切。

  • ドキュメントの体裁→チェックリストやなるべく標準のテンプレート、標準の修正機能で防げるようにしたい
  • 規約的なものは例えば規約ツールで自動ではじくなど

このレベルで毎回指摘する、指摘事項が変わる。。。などがないようにしたい。

レビュアーの負担軽減

  • 当事者意識を持たせるために、レビュアーにノルマを付与するといいかも(一回のレビューの際に必ず何らかの指摘事項をもうけるなど・・)
  • そのために参加する際の前提知識やそもそもの仕様の共有が最も大切
  • そもそもの人間関係を壊さないような文化づくり(根本的にある信頼関係の構築)が最も大切
  • 神学論争的なものは最終決定権のある人間に決めてもらう(当人同士で争わないように)

レビューポイントについて

  • 見るポイントを各人で担当制にする(仕様的な部分、コードの設計的な部分)
  • できればファイルなどを細かく分割して、小分けにする
  • 必ずなおす、直してほしい、できたら、のようにウェートをつける
    (理想論でいえば全て直してほしいが、そのタスクがブロックになってしまい、後続タスクへの影響などをなくすため。できたら・・などは別タスクとして別途レビューをする)
  • 指摘事項で多いもののリストアップ→なるべく他のメンバーでもレビューをできるようにする、見れるようにするため
  • 余裕があればレビューの指摘事項で上がっているものの類型化など

-ドキュメント作成, プロジェクト管理

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

使える設計書作成に関して

私自身、この仕事を7〜8年やっておりますが、設計書作成については常に悩まされておりました。 設計書のメリット・デメリットとしては以下のようなものですかね。 メリット メンバー間での仕様の認識を統一でき …

no image

CI/CDに関する取り組み

CI/CDに関して知識としては5年以上昔から持ってましたが、実際にプロジェクトの中に取り組むことができるようになったのはつい最近なので、取り込みが現実的なものに関してどのように取り組んでいくかといった …

no image

ファジープロジェクト対策 その1

5月ぐらいから着手していたプロジェクト(顧客管理ソフト)が終焉を迎え、検証段階に入ったので、記して置きたいことなど。 数ヶ月程度ですが、自分が携わったプロジェクトの中では過去最大クラスのものでした。 …

no image

テスト項目の作り方(縦項目について)

テスト項目の作り方について。 単体テスト書のレビューをしていて、なるべく効率的に網羅的にできるテスト仕様書の作成について。 納品物としてではなく、開発の高速化と品質をあげるためのテスト仕様書を。 Co …

no image

コードレビュー時のポイント

コードレビュー(仕様的な点ではなくて規約的なところのチェック)などで気をつけることなど。 ポイントとしては検知ツールで確認するコストを減らすことが一番大事(カスタマイズの方法について調べておく)、ある …

アーカイブ