→ loadingN: 上版的功能切乾淨,是本來就該做的,果然過太爽04/20 07:35
功能是乾淨的,但這個功能要切成好幾個 mini PR 才是重點
推 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
因為我待的團隊每個人都有給 approval 的權限,所以 PR 愈小,愈容易獲得 the god d
amn precious approval
推 Galbygene: 請問PR是什麼的縮寫04/20 13:14
推 rabbitu04: pull request04/20 13:18
推 Galbygene: 謝謝04/20 14:59
推 s06yji3: Review通常都超拖的啊04/20 15:05
※ 編輯: leviliang (138.246.3.10 德國), 04/20/2023 15:28:30
推 orangelite: 有點好奇原po是寫前端還是後端?04/20 18:52
後端與 Infra,偏開發的 DevOps
→ 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
確實,改緊急的 defects 時就不管這麼多了
不過我們團隊裡沒有 junior
※ 編輯: leviliang (138.246.3.10 德國), 04/20/2023 21:44:54
→ 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
太神啦 大大的步調與境界是我的目標啊
我一天能有穩定的 3-5 個小 PR 就覺得今天狀態絕佳了哈哈哈
→ bobokeke: 切PR是一門藝術 04/21 23:34
※ 編輯: leviliang (138.246.3.10 德國), 04/23/2023 04:35:17
推 assembler80: PR修改的程式碼太多,review的人會超痛苦,而且 04/25 00:13
→ assembler80: 對方可能在設計上有一些問題,但都寫那麼多程式了, 04/25 00:15
→ assembler80: 也不太好退掉他的PR,要他重寫 04/25 00:15