・人格と文章
・人格と思想
なんでも良いんだけど、結局は分離できないんじゃないの?と思う。
「人を憎まず」以前に、すべてを同じ色で染めるのをあきらめないといけないと思う。現実路線は、住み分けが肝心だと思う。
まあ、同じ色で染めるのをあきらめても、被害が自身に及ぶ場合は、やっぱり憎むだろうし、衝突すると思うけどなぁ。それは、利害関係の問題。
人格、価値観
悪いコードを憎んで人を憎まず! プルリク送付前に心がけたいコードレビューのコミュニケーション術 - エンジニアHub|若手Webエンジニアのキャリアを考える!たぶん、分離できないと思うんだけどなぁ。大抵の場合は、レビューアは、コードとコードを書いた人を同一と認識し、レビューイも、コードと自分自身を同一と認識しているので、定期的にコードレビュー冷戦が起こります。
2018/02/03 13:04
見慣れてくると、この部分は、たぶんこの人が書いたコードでないのかなぁ?とわかってしまう場合もあるし、逆にレビューの指摘でも、名前が書かれてなくても、この指摘はこの人かなぁ?となんとなくわかったりするので・・。
悪いコードを憎んで人を憎まず! プルリク送付前に心がけたいコードレビューのコミュニケーション術 - エンジニアHub|若手Webエンジニアのキャリアを考える!そもそも、良い成果物の定義が違うとダメだよね。
- [codereview]
“レビューの目的はお互いに協力して良い成果物を作ることです。”
2018/01/26 01:10
この時点で、たぶん、価値観違うと、違うよ
いろいろ
悪いコードを憎んで人を憎まず! プルリク送付前に心がけたいコードレビューのコミュニケーション術 - エンジニアHub|若手Webエンジニアのキャリアを考える!まわりのスキルが低いのが原因で、理解しにくいコードになっている場合は、ダメなのは、「周り」なのか?それとも「コードを書いた人」なのか?といえば、微妙だと思うんだけどね。“悪いのは理解しにくいコードであり、人ではない”というのは本当に重要。
2018/02/27 11:25
悪いコードを憎んで人を憎まず! プルリク送付前に心がけたいコードレビューのコミュニケーション術 - エンジニアHub|若手Webエンジニアのキャリアを考える!紳士的に表現すればOKっていう話でもないと思うんだよね。『状態変数が多くなるとメンテナンスしづらくなるため、良い方法を一緒に考えたいです』ってコメントもらったらキレる自信ある。
2018/02/12 10:27
悪いコードを憎んで人を憎まず! プルリク送付前に心がけたいコードレビューのコミュニケーション術 - エンジニアHub|若手Webエンジニアのキャリアを考える!職業プログラマーなら、どこかで妥協は必要だと思う。というか、妥協しないと仕事として成立できないのでは?勉強になりましたー。 別の記事であったけど、コードレビュー文化自体の良し悪しやレベルみたいなのも考えたほうがいいよなとも思いました(それによって効率やスピードが下がることも十分あるので)
2018/02/05 14:35
悪いコードを憎んで人を憎まず! プルリク送付前に心がけたいコードレビューのコミュニケーション術 - エンジニアHub|若手Webエンジニアのキャリアを考える!結局は、日ごろの人間関係などの影響受けるよね。人は雑に扱われたと思えば心が離れていくものなので、細かい気遣いはいきすぎるぐらいでもいいと思ってる。それが後々自分のためにもなる。
2018/02/05 13:37
レビューの指摘・意見と、その発言者の人格って、結局、切り離せない場合が多いわけで、あの人が同じことをいってもOKでも、別の人は同じことをいうとNGっていうのはあると思う。
あと、相手の性格にもよるかなぁと思う。
ズバリと簡潔に指摘したほうがいい人もいれば、言葉を選んで遠回しに言うほうが良い場合があるでしょう。
レビューだけじゃないし?!
業務でチーム開発をする際はPull Requestの粒度を小さくし、頻度を増やすことをおすすめします。 1つのPull Requestが大きい場合、レビューするレビュワーの負担が大きくなります。差分が数100行以上ある場合は、かなりの集中力がないとバグを見逃してしまうリスクもあります。そのため小さくPull Requestを出してレビューの負担を減らし、少しずつ着実に進めていくのが得策です。数10行以内の差分であればレビュワーの負担も少なく、素早くマージまで進むことができると思います。
悪いコードを憎んで人を憎まず! プルリク送付前に心がけたいコードレビューのコミュニケーション術 - エンジニアHub|若手Webエンジニアのキャリアを考える!
悪いコードを憎んで人を憎まず! プルリク送付前に心がけたいコードレビューのコミュニケーション術 - エンジニアHub|若手Webエンジニアのキャリアを考える!状況次第なんじゃ?時々この逆(粒度最大、頻度少なく)を強要してくる人を見かけるけど、やっててつらくないのかな? >チーム開発をする際はPull Requestの粒度を小さくし、頻度を増やすことをおすすめします。
2018/01/24 14:40
数十行?程度なら、逆にレビュー要らないんじゃないの?とかいう話もないのかなぁ?
あと、品質を保証するのは、レビューだけではないよね。
テストもするわけだし・・。
スポンサーリンク
コメントを残す