Tech News/Blogs Notebook [22.2.5]

The Biggest Mistake I See Engineers Make

"doing too much work on their own before looping in others"

当你想开始一个feature或project时，尽早将想法（以设计原型的方式，而不是PR的方式）发给团队的成员一起看看。好处：

• 可以更清晰地界定问题，并拉齐团队成员关于该问题的认知
• 可以避免在投入大量沉没成本后，使得原先不适宜地设计无法修改

为什么会出现工程师闷头design一段时间后，才发一个巨大的inital PR出来呢？

• 对于应届生来说，在学校时是各自独立完成大作业，养成了自己端到端解决一个问题，然后拿学分的习惯
• 对于资深地程序员来说，可能习惯了独立工作，或再设计时过于自信（而忽略了寻找其他可能得解法）

所以，对于engineer manager而言，要教会新同学在工作中要「team work」，并提醒senior的同学不要overconfident。另外，团队中还需要建立一种constructive feedback的气氛，并注意清除toxic、negative 的feedback。形成互相给予建设性反馈的正向、积极氛围。

 

How to make a change to a shared codebase

几个观点：

• feature最初的commit非常重要，它基本决定了代码的设计，因此头几个commit应尽早review，以免写了一大堆代码后，reviewer才告知代码的设计有问题，而难以修改（或只好接受质量欠佳的代码）
• 不要将多组功能放在同一个review中，这样会导致reviewer看代码很困难，同时若要回滚代码也会变得困难
• 当你提交 feature_branch 进行review后，应该git checkout -b feature_branch_2来继续手上的工作，同时将feature_branch的修改通过merge的方式合入feature_branch_2中
• 使用linter来规范代码样式
• 对于质量控制而言，好的代码review是重中之重
• 团队中的新成员，可以以“secondary” reviewers的角色先跟着review若干次PR
• 如果你想维护一个巨大的代码仓，那么需要引入“readability” reviewer这样的角色，保障代码的可读性

commiter 应做到如下几点：

• 提交PR之前，先合一下master
• 先自己看过一遍PR，再提交给别人review
• 别等着reviewer来帮你发现bugs（找bug并不属于reviewer的职责范畴）
• review的速度和diff代码的大小成反比，所以当你提交的PR长时间无响应的时候，cue一下reviewer或者manager
• 从senior engineer处得到到review comment是你进步的源泉，千万不要有抵触心里

reviewer应做到如下几点：

• review应该拥有最高优先级，如果你无法第一时间响应一个review请求，则应该告诉该commiter你什么时候可以处理（一个review不应该等待好几个小时）
• 代码的设计问题是review的重点
• review时comment应该是建设性地反馈，而不是toxic的评论