作者leviliang (慕尼黑林志颖)
看板Soft_Job
标题Re: [讨论] 就算提早做完是不是不要回报比较好
时间Thu Apr 20 05:39:22 2023
看到这篇不禁让人想起从前的菜鸟时光
以前的确会聪明地压着一些东西
作为紧急时就可以马上拿出手的 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://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1681940364.A.16C.html
1F：→ loadingN: 上版的功能切乾净，是本来就该做的，果然过太爽04/20 07:35
功能是乾净的，但这个功能要切成好几个 mini PR 才是重点
2F：推 CoNsTaR: 真的，每次看到那种一个 PR 上千行的看都不用看就知道一04/20 07:40
3F：→ CoNsTaR: 定菜鸟发的04/20 07:40
4F：推 vi000246: 一个pizza切两块跟切十块的概念 不过做的事还是一样多04/20 08:43
是的 不过切成十个慢慢吃更好吃
5F：→ yamagishi: code review 可以比较简单是真的，一次丢太多很难面面04/20 08:52
6F：→ yamagishi: 俱到04/20 08:52
7F：→ naestnecniv: 但切完PR，review的速度比我PR发起的速度还慢就很麻04/20 09:38
8F：→ naestnecniv: 烦了。04/20 09:38
因为我待的团队每个人都有给 approval 的权限，所以 PR 愈小，愈容易获得 the god d
amn precious approval
9F：推 Galbygene: 请问PR是什麽的缩写04/20 13:14
10F：推 rabbitu04: pull request04/20 13:18
11F：推 Galbygene: 谢谢04/20 14:59
12F：推 s06yji3: Review通常都超拖的啊04/20 15:05
※ 编辑: leviliang (138.246.3.10 德国), 04/20/2023 15:28:30
13F：推 orangelite: 有点好奇原po是写前端还是後端？04/20 18:52
後端与 Infra，偏开发的 DevOps
14F：→ orangelite: 我自己前端的经验一个页面就是一个 pr04/20 18:52
15F：→ orangelite: 分很多 pr 画面不完全感觉很怪…04/20 18:52
16F：→ foreverk: 你的画面如果一页有10个新的元件，你发在一个pr内的话04/20 19:15
17F：→ foreverk: ，review的人要嘛花很常时间看，或是分好几天看卡住你 04/20 19:15
18F：→ foreverk: 的pr，你切分好给人review同时你还能继续开发或是改其04/20 19:15
19F：→ foreverk: 他review的pr04/20 19:15
20F：推 s06yji3: 这样怎知道10个PR merge起来没有问题... 04/20 19:18
21F：推 s06yji3: 不过通常一个元件就可以是一个PR了 04/20 19:20
22F：→ foreverk: 也不用10个pr，关联性较高的合起来发三四个，都比一整04/20 19:25
23F：→ foreverk: 包出去好吧04/20 19:25
24F：推 s06yji3: 啊，应该说该break down的应该是task而不是PR 04/20 19:27
同意
25F：推 safe: 适用场景：案子时程不赶、团队 junior 偏多 04/20 19:44
确实，改紧急的 defects 时就不管这麽多了
不过我们团队里没有 junior
※ 编辑: leviliang (138.246.3.10 德国), 04/20/2023 21:44:54
26F：→ Ekmund: 理想状态是这样 如果不是临时改义大利面这周五上的话 04/20 23:49
27F：→ holmes2136: 切得好还可以避免conflict 的机会 04/21 14:36
28F：→ holmes2136: Review的人也轻松多 04/21 14:37
29F：推 d0068267: 好闻04/21 16:06
30F：推 bobokeke: 我自己习惯一个PR不多过4个档案或250-300行程式，除非是 04/21 23:33
31F：→ bobokeke: asset/config/generated files04/21 23:33
32F：→ bobokeke: 不过我常常一天连发10张PR，哈哈哈 04/21 23:34
太神啦 大大的步调与境界是我的目标啊
我一天能有稳定的 3-5 个小 PR 就觉得今天状态绝佳了哈哈哈
33F：→ bobokeke: 切PR是一门艺术 04/21 23:34
※ 编辑: leviliang (138.246.3.10 德国), 04/23/2023 04:35:17
34F：推 assembler80: PR修改的程式码太多，review的人会超痛苦，而且 04/25 00:13
35F：→ assembler80: 对方可能在设计上有一些问题，但都写那麽多程式了， 04/25 00:15
36F：→ assembler80: 也不太好退掉他的PR，要他重写 04/25 00:15