コードレビュープロセスの負荷や時間を減らすために取り組んでいる10のTips - Qiita
この記事は、開発生産性 Advent Calendar 2022の3日目の記事です。 2日目の記事はnaoto_pqさんの「PR数は開発生産性のセンターピンかもしれない」でした。PR数を増やすことにフォーカスすることで、Four Keysの向上やベロシティが安定したという学びが深い記事でした。 私は開発の生産性向上施策の１つとして、コードレビュープロセスの負荷や時間を減らすために取り組んでいる10のTipsを紹介します。 ぜひ、面白いなと思ったTipsがあれば、トライしてもらい、コードレビューの効果や効率を高めていただければ嬉しいです。 Tipsを紹介する前に コードレビューは、開発プロセスの早い段階で欠陥を発見できる有効な開発プラクティスとして多くの開発チームで実施されています。 しかし、プルリクのレビュー依頼をしてからレビューが返ってくるまで1日以上かかったり、その後、レビューの対応か
設計/コードレビューで"常に"心がけるポイント - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
