写了篇《 Google 软件工程》的读书笔记。这篇主要分享文化相关的内容,这也是我认为国外做软件工程和国内差异大的地方,相反过程与工具的差异可能就是规模不同导致的👇
https://www.bmpi.dev/dev/software-engineering-at-google/culture/
中篇过程篇在此帖子:https://v2ex.com/t/872134 ,包括Code Review、技术文档、自动化测试如单元/集成/E2E、弃用过程等。
1
XenoVation 2022-07-25 09:17:39 +08:00
感谢 OP 分享
|
2
AilF 2022-07-25 09:18:20 +08:00
点赞
|
3
kneep 2022-07-25 09:28:09 +08:00
很棒,这本书我最近也在看。还会写下一篇吗?
|
4
EXChen 2022-07-25 10:04:36 +08:00
有空看看。
|
5
bmpidev2019 OP @kneep 下个月写过程与工具篇,总共就两篇
|
6
kneep 2022-07-25 13:12:53 +08:00
@bmpidev2019 下篇写好了提醒下哈,给我们做谷歌组织研究提供了很有用的输入。
|
7
ericgui 2022-07-26 06:07:37 +08:00
总结的很好,这套方法论也确实是我们目前日常工作的方式
|
8
ericgui 2022-07-26 07:05:25 +08:00
哦,我不是 G 家的,声明一下。我只是说,这一套,在硅谷这边其实还是用的很多的。
|
9
bmpidev2019 OP @ericgui 国内一些外企也是这种文化,但不知道国内的企业有没有这种文化的
|
10
shawndev 2022-07-26 10:17:09 +08:00
Code Diff 这个说法第一次见到,和 Code Review 有什么差异吗?
|
11
bmpidev2019 OP @shawndev Diff 和 Review 不太一样的地方在于,Diff 是一个团队集体行动,大家一块看某个开发者写的前一天的代码,这样的好处在于每个人都能反馈,也能了解其他人做的工作,防止一些信息不同步的问题。Review 一般是一两个人去审查对方已经要合入主干分支的代码,更适合外部人员提交代码到主干这种 GitHub 分支管理模式。
|
12
shawndev 2022-07-26 10:23:57 +08:00
@bmpidev2019 听起来很棒的实践,我在团队极速扩张的时候尝试过这样的方式,一时间没有平衡好产出效率和评审尺度的关系。OP 可以分享下自己的经验吗?
|
13
bmpidev2019 OP @shawndev 我们团队每天会做 Code Diff ,这是个必须的实践。团队规模在几人以内可以让每个人都有时间讲解自己的代码,如果代码太多,那可以给每个人一个时间限制。如果团队太大那可以拆分成多个 stream 来管理,总之 Diff 的人员不能太多,但每天都应该花时间做,因为收益要高于成员,可以统一代码风格,保证可读性,提高成员水平等
|
14
456789 2022-07-26 11:25:08 +08:00
这个每日站会的时间是多少?
|
15
bmpidev2019 OP @456789 15 分钟
|
16
SeaTac 2022-07-28 14:28:31 +08:00 via iPhone
G 家不是挺多组没有 daily standup 的么
有不少人觉得 daily stabdup 过于 push |
17
bmpidev2019 OP @seaiaddca 敏捷有站会实践,Google 这书里并没有提到站会。
|
18
SeaTac 2022-07-29 02:25:41 +08:00 via iPhone
@bmpidev2019
这种细节一般具体看组看 manager |
19
456789 2022-08-04 09:39:54 +08:00
大多数的每天都站会都是在给顶层领导看,一般每天的站会都没有太大意义
|
20
li746224 2022-08-05 09:08:02 +08:00 via iPhone
严重怀疑我们公司看的这个,简直一模一样
|
21
li746224 2022-08-05 09:13:09 +08:00 1
但是不太适合国内环境,就拿响应变化高于计划这一条来说。在国内就会变成加了需求但是不给加工期
|