→ loadingN: 上版的功能切乾淨,是本來就該做的,果然過太爽04/20 07:35
推 CoNsTaR: 真的,每次看到那種一個 PR 上千行的看都不用看就知道一04/20 07:40
→ CoNsTaR: 定菜鳥發的04/20 07:40
推 vi000246: 一個pizza切兩塊跟切十塊的概念 不過做的事還是一樣多04/20 08:43
→ yamagishi: code review 可以比較簡單是真的,一次丟太多很難面面04/20 08:52
→ yamagishi: 俱到04/20 08:52
→ naestnecniv: 但切完PR,review的速度比我PR發起的速度還慢就很麻04/20 09:38
→ naestnecniv: 煩了。04/20 09:38
推 Galbygene: 請問PR是什麼的縮寫04/20 13:14
推 rabbitu04: pull request04/20 13:18
推 Galbygene: 謝謝04/20 14:59
推 s06yji3: Review通常都超拖的啊04/20 15:05
推 orangelite: 有點好奇原po是寫前端還是後端?04/20 18:52
→ orangelite: 我自己前端的經驗一個頁面就是一個 pr04/20 18:52
→ orangelite: 分很多 pr 畫面不完全感覺很怪…04/20 18:52
→ foreverk: 你的畫面如果一頁有10個新的元件,你發在一個pr內的話04/20 19:15
→ foreverk: ,review的人要嘛花很常時間看,或是分好幾天看卡住你 04/20 19:15
→ foreverk: 的pr,你切分好給人review同時你還能繼續開發或是改其04/20 19:15
→ foreverk: 他review的pr04/20 19:15
推 s06yji3: 這樣怎知道10個PR merge起來沒有問題... 04/20 19:18
推 s06yji3: 不過通常一個元件就可以是一個PR了 04/20 19:20
→ foreverk: 也不用10個pr,關聯性較高的合起來發三四個,都比一整04/20 19:25
→ foreverk: 包出去好吧04/20 19:25
推 s06yji3: 啊,應該說該break down的應該是task而不是PR 04/20 19:27
推 safe: 適用場景:案子時程不趕、團隊 junior 偏多 04/20 19:44
→ Ekmund: 理想狀態是這樣 如果不是臨時改義大利麵這週五上的話 04/20 23:49
→ holmes2136: 切得好還可以避免conflict 的機會 04/21 14:36
→ holmes2136: Review的人也輕鬆多 04/21 14:37
推 d0068267: 好聞04/21 16:06
推 bobokeke: 我自己習慣一個PR不多過4個檔案或250-300行程式,除非是 04/21 23:33
→ bobokeke: asset/config/generated files04/21 23:33
→ bobokeke: 不過我常常一天連發10張PR,哈哈哈 04/21 23:34
→ bobokeke: 切PR是一門藝術 04/21 23:34
推 assembler80: PR修改的程式碼太多,review的人會超痛苦,而且 04/25 00:13
→ assembler80: 對方可能在設計上有一些問題,但都寫那麼多程式了, 04/25 00:15
→ assembler80: 也不太好退掉他的PR,要他重寫 04/25 00:15