2017/06/02 08:05:47
tbpg
"修正箇所を指摘して，直してもらったあとに，再度修正箇所を指摘するとしたら，実装者のミスというよりかは，実装者とレビュワーのチームプレイのミスで，コミュニケーションに失敗しているのではないか"
2017/06/02 08:55:41
minemuracoffee
“個人的には，大きめの物を作るときにも，1日1個ずつくらいの粒度でpull requestを送って，その日のうちに収束させてマージして少しずつ出していくようにしている．”
2017/06/02 09:02:55
sezemi
“昼にレビュータイムがある” リズムよさそう
2017/06/02 09:14:57
kyohei_hamada
良さそう “1日のうち決まった時間にレビュータイムを設けたり”
2017/06/02 09:18:47
t-wada
"修正箇所を指摘して，直してもらったあとに，再度修正箇所を指摘するとしたら，実装者のミスというよりかは，実装者とレビュワーのチームプレイのミスで，コミュニケーションに失敗しているのではないか"
2017/06/02 09:22:53
windish
大プルリクはいけませんよな…反省
2017/06/02 09:28:03
Shisama
良記事。粒度を小さくしろは会社でもよく言ってる気がします。自分がレビュアーのとき、一回で見るところ多ければ、誤りを見落とす可能性も増える傾向にある
2017/06/02 09:38:16
mooonymann
“少なく正確な回数のやりとりでマージできるよう努める”
2017/06/02 09:45:42
oakbow
往復の回数を減らせれば早くなるのは確かだけど、意識しても難しいんだよね。そのうち修正の方針がずれてて再修正というのは改善しやすいので、レビュー時点でサンプルコード書いたりして齟齬をなくしておきたいね
2017/06/02 09:58:22
Konboi
自分のチームでは、大きめの改修するときはIssueとかで改修方針をレビューしてもらってから作業するようにしてる
2017/06/02 10:09:12
y_koh
PR細かくするの苦手なんだよなぁ。見てもらう努力と、早めに見る努力をしないと溜まる一方。。
2017/06/02 10:12:42
luccafort
"小さいpull requestを少しずつ送ると，一度で収束するサイクルを導入しやすくなる"これぼくも同意なんだけど抵抗のある人はこの時間を取るのを嫌がっていてそういう人に対してどうするか？で悩む。
2017/06/02 10:14:58
takezoh_1127
コードレビュー、プロジェクト毎に試していますがなんかいつもうまくいかないで途中でグダグダになってしまう...
2017/06/02 10:17:01
Tomato-360
“「直してみました，こんな感じですか?」「そんな感じよりは，むしろ…」みたいに低コストなコミュニケーションが始まってしまい，” こういうやり取りはしんどいけどよくやりがちな気がする。
2017/06/02 10:32:39
wkubota
レビューについてよその意見はいつも参考になる
2017/06/02 10:51:46
ryota-murakami
これを契機にGitHubのPRを用いたワークフローが原因で生じる事となった一連のコスト・摩擦について議論が活発になればいいと思う。昔はローカルで修正してFTPでアップすればそれで作業完了だったわけで
2017/06/02 11:10:06
enmtknt
“早く収束させる→何度もコードの改修を含むやりとりをしていては時間がかかるので，少なく正確な回数のやりとりでマージできるよう努める”
2017/06/02 11:17:54
s_osa
完全にその通りで「はい」という気持ち。
2017/06/02 11:29:59
toshiwo
この手の修正の往復もそうなんだけど、質問もあるならちゃんと質問の意図とか聞きたいことを明確にコメントしてくれとか思う時ある。エスパーじゃねーのよ？的な
2017/06/02 12:05:41
kuniku
三項演算子見にくい/１行のフォーマット長い方がいい/ return x >0 等 好みの問題あるからなー。本質はそこか？仕様か？コードか？将来性か？他と合わせるか？youと合わせるか？泥に泥を重ねても泥のまま
2017/06/02 12:30:39
yuzutas0
TodoコメントとI/Oだけのプルリクで内部設計→各クラス+テストコードのプルリクで中身を詰めるやり方が個人的には良かったです。
2017/06/02 12:46:48
koogawa
個人的にレビュータイム設けなくてもレビューが回るのが理想なんだけど、昼にみんなでやることでリズムができて割と良さそうな気がしてきた
2017/06/02 12:53:50
kwms
“低コストなコミュニケーション”
2017/06/02 12:57:49
nilab
コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
2017/06/02 13:06:08
fgshun
「直してみました」ができるのが github を使うメリットの1つでは？ コードを見せるより話し合ったほうが早いケースでコード書き始めるのを止めたいというケースならば同意
2017/06/02 13:34:54
gongoZ
修正のやりとり回数が1、2回で収まらない場合は、記事内にあるとおりコミュニケーションでミスっているか、やはり PR の粒度が大きい時に起きやすいんだろうな。「これを!やる!」「うぃっす」で済むぐらいに
2017/06/02 13:52:39
side_tana
おー
2017/06/02 14:11:25
progrhyme
往復回数よりはPR時からクローズ時までの時間を重視、かなぁ
2017/06/02 14:22:14
ktakeda47
"実装者とレビュワーのチームプレイ"
2017/06/02 15:33:28
akulog
"「直してみました，こんな感じですか?」「そんな感じよりは，むしろ…」みたいに低コストなコミュニケーションが始まってしまい"
2017/06/02 16:08:42
fukurou112
クオリティかスピードかの二極ではないと思う 品質高いコードは改修とかするときとっちらかったコードより明らかにやりやすいし作業速くなる
2017/06/02 17:04:08
inumax21
(ﾟДﾟ)
2017/06/02 17:09:42
saiid
これチーム内の雰囲気とか日頃の人間関係も大きな影響あるんだよなぁ
2017/06/02 17:31:55
psfactory
コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
2017/06/02 19:26:05
rjge
“早く収束させる→何度もコードの改修を含むやりとりをしていては時間がかかるので，少なく正確な回数のやりとりでマージできるよう努める” 事前にセルフレビューして修正したり実装意図記入したりしてる
2017/06/02 19:51:25
wannabeahacker
方法論 コードレビュー
2017/06/02 19:57:27
NOV1975
コードレビューは査読以外にも、いろいろな見方があるから早さはケースバイケースかなあ。僕は条件とかはテストでみろや派なのでなんでそうなってんの？あたりを中心にざっと見てる
2017/06/02 21:15:21
t2y-1979
大きいものは口頭のコミュニケーションで設計の合意をとって細かいところをコメントで良いと思う
2017/06/02 21:34:51
ginga0118
欲しい物は要求通りに動くコード。たとえ、それがくそみたいなコードでも。 レビューに時間をかけるよりテストをしたがよいといつも思う。
2017/06/02 22:39:21
kibarashi9
人間が集まればケンカする。それは避けられない。
2017/06/02 22:46:57
garage-kid
307
2017/06/03 08:16:32
yamak
"早く収束させる"ために毎日ベテランの人に口頭レビューの時間をとってもらい、今日やったことをコード見せながら説明してその場で指摘してもらってる。質問もまとめてその時間にできてよい
2017/06/03 08:37:11
mate_gai
“完成版の完璧なイメージができて，そのイメージにお互い合意をとれてから修正を始めるべき”→すごく同意。一方で「無駄を経験しないと気づきが得られない」派をどうやって納得させよう？？？
2017/06/03 16:18:16
braitom
“GitHubのコメント欄でのやりとりだと，送信コストが低いので”確かにだらだらとやりとりしてしまいがち。口頭でやりとりして認識あわせれば確かにすぐ片付くことなんだよなあ。気をつけよう。
2017/06/04 14:11:46
papilio17
これ、原稿確認とかでも同じことが言える気がする
2017/06/05 06:27:22
sylvan_l
コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて