新人プログラマをレビューで傷つけないために - Qiita

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この半年くらいで初めて本格的にチーム開発を行い、今では日常的に GitHub の Pull Request を使っています。 チームの方々には、基本的なことから応用的な部分まで様々な観点からレビューをしてもらって、大いに勉強になりました。 ただ、時には「新人にとっては厳しいレビュー」をいただき、1 人で傷つきモチベーションを落とすこともありました。 もちろんそれは悪意のあるものではなくて、新人とレビュワーのスキルのギャップによって意図せず生み出されてしまうものです。 そのような不幸なレビューによって苦しむ新人が減ることを願って

[ene0kcal]

はっきり言って凄く良い。タイトルとは裏腹に。改善例の、共に目標に向かって歩む感が本当に尊い。／タイトル変更されたようでなにより。

[aroechan]

そろそろプログラマ達も、コミュ障陰キャを言い訳にコミュニケ―ションを拒否するのはやめるべきなのではないか。技術があればいいというわけではないということを理解するべき

[living]

「公式ドキュメントで殴る」にもレベルがあり、英語ドキュメントのほうが強い。また、応用として「本で殴る」「仕様書で殴る」などもある

[Kil]

このレベルの新人であれば、プルリクエストにレビューコメント付けて返す、という形式自体やめて、対面でレビューしてその場で一緒に画面見ながら指摘をしていってあげるべきじゃ。

[Fushihara]

クイズは絶対に出さないように心がけてます。なんでそうしてるか分かる？

[shun_libra]

レビュアーとレビュイーで、ヒラと役職持ちみたいな立場の違いがある現場とかだと、レビューを通して権威勾配がキツくなりがちなので、正しさで殴ると副作用がヤバい。努めて対等な共闘関係を築く姿勢が大事。

[ifttt]

余裕が無いときにこれやるのめちゃくちゃムズい

[evil07]

内容はとても良いと思う。でも、これタイトル「殺さない方法」にするほうが良いと思う……

[donchan922]

文書の書き方ひとつで伝わり方や受け取り方が全然違ってくるので、こういう記事すごくいいです☺️

[not_funassyi]

良いと思うけど、「ちゃんと確認した？」を無条件に避けるレビュアーも困るので注意。一度も動かしてない、動かせば即座に問題が発覚するコードに対して優しくし過ぎてモンスター産んだ例見たことある。

[ryamate]

悪いレビュー → 良いレビューをまとめてあって、とても参考になりました。「公式ドキュメントで殴る」「わからない単語を並べる」が、個人的には一番イヤでした…

[hevohevo]

“公式ドキュメントに「コントローラ」について詳しく載っているので、あとで一緒に読みながら修正していきましょう。”　僕が新人だったらこう言ってもらえると嬉しいよなぁ。

[jerryb]

いろんなところに応用できそう。正論で殴らない、自分で間違いに気付けと強要しない、「確認した？」って責めない。誰の時間も気力も有限な今の世の中で新人教育に必要なのは、精神論じゃなく次の方向を示すこと。

[naglfar]

とてもいい。「無意識に煽る」は、自信のなさから確認のつもりでやらかしがちなので申し訳ない。

[koemu]

プルリクエストでコミュニケーションできるためにはある程度練度が必要だと思うので、まずはペアプロなどから始めるとよいのかなと思いました。

[demAge]

プログラミングに限らず技術は積み重ねの継承によって到達点が伸びると思ってる。「見て盗め」は新人に現場で車輪の再発明を不必要なぐらいに繰り返せって言ってるように見える

[tmatsuu]

公式ドキュメントで殴る、俺よくやっちゃうやつだ。気をつけよう

[diveintounlimit]

いや素晴らしい。オッサンでもわりと殺される。

[yu_fuk]

単にレビューにおける言葉遣いに留まらず、コミュニケーション全般にわたって通じる話だと思う。また、新人に限らずキャリア5年目程度の技術者にも同じ事は言えるのではないだろうか(若手に限らないかも！？)。

[nishemon]

いい記事。このレベルならまず対面レビューか師匠を付けさせるかなあ。プロジェクトのレビュアーはアーキテクチャやポリシーを視点とすべきで、それがセンセイを兼ねるのは健全ではないようにも思う

[tick2tack]

具体例があって分かり易い。細かいとこまで気を付けてるんだなー

[nunulk]

2018年も終わろうとしてるのにまだこういうレビューしてるひとはおおいに反省してほしい

[tmtms]

新人相手のレビューは単なるレビューじゃなくて、どっちかというと育成だし、そういう観点がない人がレビューしちゃダメ。

[nisisinjuku]

φ(..)メモメモ　よい先輩がいるところにはよい新人が育つってことだね。

[totttte]

えっ…もっときついこと言いまくってしまってるんだけども、丁寧に書いてると冗長で時間かかるから…

[sasagin]

僕は殺されてプロジェクト抜けました。

[windish]

雑なコミニュケーションで得られる時間短縮よりもリスクの方が昨今は大きくなっていると感じる。だからこういうの大切。

[kkobayashi]

「定数に切る」って言い方初めて聞いたけど一般的に使われてるの？／「マニュアルちゃんと読んだ？」くらいは自分も言ってしまいそうだなぁ

[NOV1975]

相手が新人か否かで変わってもいいと思うんだよなこういうのは。少なくとも新人に対してここの悪い例でやっちゃうのはOJTではなく投げっぱなし感あるもんな。

[RabbitBit]

心理的安全性の確保の為に、コードレビューで心がけた方が良い事が書かれた良記事。コードレビューの前に読み返したい。

[Hokanoko]

無意識にマウントしちゃってるかもしれないので気をつける。

[sdkd6611]

マジで言われたことを飲み込まずただやるだけっていう新人さんも居て、どこが本来自分で考えないといけない部分かは、都度立ち止まって考えてみて貰ってあげなければならないケースもある。。

[moneycubed]

すごく役に立つ記事！うちはほとんど対面レビューだけど、だからこそ、記録に残らない部分での発言(言い方)に気をつけないとなあ。

[eichisanden]

その書き方を自分が知らないだけかと思って「無意識に煽る」はやってしまってるな。純粋に確認したいだけなんだけど。新人と仕事した経験が極端に少ないんだけど、今後機会があれば対面でレビューしようと思った。

[momonga_dash]

回答を予想せずに自分の言いたいことだけ言う奴はアカン

[aTn]

新人がいない所は、どんなレビューをやり合っているのかな。誰か書いて！

[fumiya-neko]

こえーー。汗 相手も悪意が無い場合もあるし難しいな。 これで、パワハラだブラックだと叫ぶ人もいそうだな

[sunvisor]

“新人プログラマをレビューで殺さない方法” に改題された。