Re: [討論] 就算提早做完是不是不要回報比較好

看板Soft_Job作者 (慕尼黑林志穎)時間1年前 (2023/04/20 05:39), 1年前編輯推噓14(14推 0噓 22→)
留言36則, 16人參與, 1年前最新討論串2/2 (看更多)
看到這篇不禁讓人想起從前的菜鳥時光 以前的確會聰明地壓著一些東西 作為緊急時就可以馬上拿出手的 buffer 不過 現在除非是處理緊急的 defects 否則我會盡可能地分割工作 一個 5-8 credits 的 user story 會切成大約 10 個 PR 來做 一天完成 1-2 個 PR 每個 PR 改動少、review 輕鬆、修正容易 剩下的時間就可以排 training、讀 technical blog 或製作團隊內小型技術分享的 work shop 看到這裡有些大大可能會開始覺得 這一定是在外商過太爽 你根本工作太閒 但有興趣的朋友們可以試試看 剛開始不僅節奏會比你想像的要趕 切割 user story 更是沒有想像中簡單 (剛開始一天一個 PR 真的是要我命 還會不知不覺加班） 原本很直觀一個 PR 解決的任務 要拆成兩三個合理易懂的小 PR 這相當考驗功力 如果對版控不熟悉 更容易弄巧成拙 花更多時間處理這些小分支 但好處也是直觀的 以前習慣一個 PR 解決的東西 可能都會有十幾二十幾個檔案的增改 現在降低到五六個 修改的程式行數大幅下降 琢磨細節更容易 程式可以寫得更乾淨更有成就感 無論是可讀性還是可維護性都是大大增加 除了技術上的好處外 軟實力上我認為這幫助更大 第一就是切割工作的藝術 第二則是確實地量化並實踐 Agile 中的 credits 不然每次在 backlog refinement 中 評估 US 的 credits 都憑直覺亂猜一通 經過了切割工作的「痛苦」磨練 現在我才真正有了透視 US 的感覺 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 138.246.3.10 (德國) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1681940364.A.16C.html
→
04/20 07:35, 1年前 , 1F
上版的功能切乾淨，是本來就該做的，果然過太爽
04/20 07:35, 1F
功能是乾淨的，但這個功能要切成好幾個 mini PR 才是重點
推
04/20 07:40, 1年前 , 2F
真的，每次看到那種一個 PR 上千行的看都不用看就知道一
04/20 07:40, 2F
→
04/20 07:40, 1年前 , 3F
定菜鳥發的
04/20 07:40, 3F
推
04/20 08:43, 1年前 , 4F
一個pizza切兩塊跟切十塊的概念 不過做的事還是一樣多
04/20 08:43, 4F
是的 不過切成十個慢慢吃更好吃
→
04/20 08:52, 1年前 , 5F
code review 可以比較簡單是真的，一次丟太多很難面面
04/20 08:52, 5F
→
04/20 08:52, 1年前 , 6F
俱到
04/20 08:52, 6F
→
04/20 09:38, 1年前 , 7F
但切完PR，review的速度比我PR發起的速度還慢就很麻
04/20 09:38, 7F
→
04/20 09:38, 1年前 , 8F
煩了。
04/20 09:38, 8F
因為我待的團隊每個人都有給 approval 的權限，所以 PR 愈小，愈容易獲得 the god d amn precious approval
推
04/20 13:14, 1年前 , 9F
請問PR是什麼的縮寫
04/20 13:14, 9F
推
04/20 13:18, 1年前 , 10F
pull request
04/20 13:18, 10F
推
04/20 14:59, 1年前 , 11F
謝謝
04/20 14:59, 11F
推
04/20 15:05, 1年前 , 12F
Review通常都超拖的啊
04/20 15:05, 12F
※ 編輯: leviliang (138.246.3.10 德國), 04/20/2023 15:28:30
推
04/20 18:52, 1年前 , 13F
有點好奇原po是寫前端還是後端？
04/20 18:52, 13F
後端與 Infra，偏開發的 DevOps
→
04/20 18:52, 1年前 , 14F
我自己前端的經驗一個頁面就是一個 pr
04/20 18:52, 14F
→
04/20 18:52, 1年前 , 15F
分很多 pr 畫面不完全感覺很怪…
04/20 18:52, 15F
→
04/20 19:15, 1年前 , 16F
你的畫面如果一頁有10個新的元件，你發在一個pr內的話
04/20 19:15, 16F
→
04/20 19:15, 1年前 , 17F
，review的人要嘛花很常時間看，或是分好幾天看卡住你
04/20 19:15, 17F
→
04/20 19:15, 1年前 , 18F
的pr，你切分好給人review同時你還能繼續開發或是改其
04/20 19:15, 18F
→
04/20 19:15, 1年前 , 19F
他review的pr
04/20 19:15, 19F
推
04/20 19:18, 1年前 , 20F
這樣怎知道10個PR merge起來沒有問題...
04/20 19:18, 20F
推
04/20 19:20, 1年前 , 21F
不過通常一個元件就可以是一個PR了
04/20 19:20, 21F
→
04/20 19:25, 1年前 , 22F
也不用10個pr，關聯性較高的合起來發三四個，都比一整
04/20 19:25, 22F
→
04/20 19:25, 1年前 , 23F
包出去好吧
04/20 19:25, 23F
推
04/20 19:27, 1年前 , 24F
啊，應該說該break down的應該是task而不是PR
04/20 19:27, 24F
同意
推
04/20 19:44, 1年前 , 25F
適用場景：案子時程不趕、團隊 junior 偏多
04/20 19:44, 25F
確實，改緊急的 defects 時就不管這麼多了 不過我們團隊裡沒有 junior ※ 編輯: leviliang (138.246.3.10 德國), 04/20/2023 21:44:54
→
04/20 23:49, 1年前 , 26F
理想狀態是這樣 如果不是臨時改義大利麵這週五上的話
04/20 23:49, 26F
→
04/21 14:36, 1年前 , 27F
切得好還可以避免conflict 的機會
04/21 14:36, 27F
→
04/21 14:37, 1年前 , 28F
Review的人也輕鬆多
04/21 14:37, 28F
推
04/21 16:06, 1年前 , 29F
好聞
04/21 16:06, 29F
推
04/21 23:33, 1年前 , 30F
我自己習慣一個PR不多過4個檔案或250-300行程式，除非是
04/21 23:33, 30F
→
04/21 23:33, 1年前 , 31F
asset/config/generated files
04/21 23:33, 31F
→
04/21 23:34, 1年前 , 32F
不過我常常一天連發10張PR，哈哈哈
04/21 23:34, 32F
太神啦 大大的步調與境界是我的目標啊 我一天能有穩定的 3-5 個小 PR 就覺得今天狀態絕佳了哈哈哈
→
04/21 23:34, 1年前 , 33F
切PR是一門藝術
04/21 23:34, 33F
※ 編輯: leviliang (138.246.3.10 德國), 04/23/2023 04:35:17
推
04/25 00:13, 1年前 , 34F
PR修改的程式碼太多，review的人會超痛苦，而且
04/25 00:13, 34F
→
04/25 00:15, 1年前 , 35F
對方可能在設計上有一些問題，但都寫那麼多程式了，
04/25 00:15, 35F
→
04/25 00:15, 1年前 , 36F
也不太好退掉他的PR，要他重寫
04/25 00:15, 36F
‣ 更多 leviliang 的文章
文章代碼(AID): #1aG5-C5i (Soft_Job)
‣ 更多 leviliang 的文章
文章代碼(AID): #1aG5-C5i (Soft_Job)