コードレビューを受けるのがつらくなったときは - めるノート
そういうときがよくあります。 コードレビューがある会社は今が初めてだけど、きっとこれから先もコードレビューがある限りは、なくならない気持ちなんだと思います。 だから、そんなときに振り返れるようなものを残しておきます。 「コードレビュー つらい」でググってみると、はてな匿名ダイアリーのこんな記事が見つかりました。 anond.hatelabo.jp さすがに、ここまでヒドいケースを経験したことはないし異常だと思ったけれど、以下のくだりは自分の胸にすごく刺さりました。 私はプログラマに向いていないんじゃないかと思う。よいプロダクトを作る上で強い言葉を交えた議論が必要不可欠ならば、それに強いストレスを感じてしまう私はプログラマとして適正がないのでは？ 刺さったのですが、それでも自分はここでやっていかなくちゃならないと思っているので、つらくなったときにいつでも読み返せるよう、見つけた記事・資料をま
人間らしくコードレビューするには(パート1) | Yakst
自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithubの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
