search

fuzhe1989 / blogissues

0 stars 0 forks source link

2022/03/05/one-creed-intention-semantic/ #9

Open utterances-bot opened 2 years ago

utterances-bot commented 2 years ago

纲领、意图、语义：从接口设计到公司治理 | Fu Zhe's Blog

TL;DR 为什么接口设计要表达清晰明确的语义？ 为什么一次代码修改（cl/pr/commit）要有唯一明确的意图？ 工作中为什么要树立自己的人设？ 如何让 OKR 发挥作用？ 如何三句话让客户为你的产品花钱？

http://fuzhe1989.github.io/2022/03/05/one-creed-intention-semantic/

wuzhouhui commented 2 years ago

对接口设计和代码审查方面的观点, 我非常赞同, 但是从 GitHub 来看, PingCap 采用的 Pull Rquest 流程, 对于 Patch Series 好像不太友好, 而且 Change Log 也不完善.

fuzhe1989 commented 2 years ago

@wuzhouhui 确实是个问题，而且这种向“一个 pr 承载完整功能“的倾向越来越重了。对于一个很 open 的社区而言，功能只进一半确实可能会令人心里一紧：谁知道后一半未来还做不做了。

wuzhouhui commented 2 years ago

可是在开发一个新功能时, 难免要对 code base 先进行一些清理和重构, 最后才是真正的功能代码. 或者是由多个小重构组成的大重构. 如果把这些修改都放在一个 Pull Request 里, 那么在代码审查时会非常累, 而且最后会被压缩成一个 commit 进入到代码库里, 后面追溯修改历史时也不方便. 这些问题不知道你们遇到过没有. 我个人比较喜欢 Gerrit 的审查风格.

fuzhe1989 commented 2 years ago

@wuzhouhui 确实，我个人是喜欢你说的这种带有历史的 pr chain 的，我之前在某大厂也是习惯这样工作的。其实即使是基于 github，如果参与群体比较固定，仍然是可以形成这样的工作流的。但现在在 P 社我理解一方面是社区这种模式会倾向于一个完整的 pull request，另一方面确实 github 没有好的功能来支持 pr chain。有点无奈，但也只能接受。