1. 否定しない 否定的なコメントは避けるようにしています。 わざと悪いコードを書こうとする人はいないと思っています。レビュイーが自分で考えた最善のコードを書いてくれていると思い、敬う気持ちを忘れないように心がけています。
コードレビューをする時に心がけている3つのこと
1. 否定しない 否定的なコメントは避けるようにしています。 わざと悪いコードを書こうとする人はいないと思っています。レビュイーが自分で考えた最善のコードを書いてくれていると思い、敬う気持ちを忘れないように心がけています。
コードレビューにおけるレビュアー側のアンチパターン
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
コードレビューするのが怖いと思っていたエンジニアが半年間コードレビューを経験して思った 10 のこと - きょくちょ日記 -THERE'S ONLY MAKE!-
これは pepabo Advent Calendar 2016 - Qiita の14日目の記事です。 昨日は id:Fendo181 さんの 日報サービス「DuPo」を作った話でした！ それは、今からちょうど半年前のこと。 海の香りと共に暑い夏がやってくる ... 甘酸っぱい青春が再び来るのではないかと予感させる ... そんな季節でした。 開発チーム内で行っていたスプリントレトロスペクティブの時間に、チームメンバーから「そろそろコードレビューをやってみよう！」と提案があり、それから本格的にコードレビューをやり始めることになりました。 早いもので、あれから半年が過ぎました。 今宵は年の瀬ということもあり、ふりかえりを目的として半年間コードレビューを積み重ねたことで僕の中で起きた考えの変化や感じたことについて 10 個書き出してみることにしました。 教育関連に興味がある方や組織の成長を考え
苦にならないコードレビュー - ASとか
はじめに 今お世話になってる現場で新規プロジェクトが始まりそうなのだが、このままだと再びコードレビュー無しの開発が始まってしまう気がしてならない。ただ、スケジュール的にキツそうな案件なので、最小の手間である程度の成果を得られる形式はなんだろうと考えてみた。 前に失敗したパターン 偉そうに言ってみたけど、実はコードレビューを上手くできたことはあまり無い。原因として レビュアーがレビュー時に初めてコードを読む 時間が掛かりすぎる。見てほしいポイントを伝えても、そもそもレビューイが見てもらうポイントを勘違いしてたら終わり 細かく指摘しすぎる 一歩踏み込むと宗教論争にまで行きそうなところまで突っ込む、そういう話は楽しいんだけど掛かる時間の割に成果が少ない 量が多い コード量が多いと、いろいろと突っ込みが入っても直すのがだるい。じゃあ次から気をつけますとかなっちゃう。 基本はdis ノウハウの共有の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソースコードの品質向上のための効果的で効率的なコードレビュー
