认识达内从这里开始

认真做教育专心促就业

Google 的软件工程经验总结(上)

发布：互联网
来源：互联网
时间：2017-03-23 19:44

    代码库

    大部分的 Google 代码都存在统一的源代码库中,可供 Google 内部所有工程师访问.但是 Chrome 和 Android 则分别有单独的代码库.

    Google 的代码库,在 2015 年 1 月的统计中,共计 86T 数据,上10亿个文件,9百万个源代码文件,其中包含了 20 亿行代码.迄今为止共计 3500 万次提交,每个工作日平均发生 4 万次更新.

    任何 Google 员工,都可以随意的访问所有代码,并下载、编译,可以在自己的环境下自行改写,但任何更改的提交,都需要通过代码负责人的审批才可以.

    所有的开发都在库的头部进行.对代码进行任何更改后,自动化系统将进行测试,并在几分钟内通知开发者和代码审查者,对更改的测试是否失败.

    代码库中每个分支都有单独的文件注明"代码所有人",只有代码所有人才有权利审核提交的更改.通常情况下,项目组的所有成员都是"代码所有人".

    编译系统

    Google 使用分布式编译系统,叫做 Blaze.Blaze 提供了标准的命令,用于编译和测试库中的所有代码.Blaze 这种统一的编译工具,让 Google 公司的所有工程师都能随时编译和测试任何软件,也都能跨项目工作.

    程序员需要撰写"BUILD"文件,用来引导 Blaze 如何编译软件.在Go语言的代码中,build 文件可以自动生成.

    每个编译步骤必须是"隔离"的,只依赖于声明的输入.为了实现编译的分布式运行,必须强制要求正确输入所有的依赖:只有声明了的输入才被发送到进行编译的机器上去.

    每个编译步骤的结果是确定的.这样保证了编译系统可以缓存编译结果.软件工程师可以回退到老的版本号,并重新编译,且得到完全一样的二进制结果.

    编译结果缓存在云端.包括中间结果,这样当有别的编译请求过来,系统直接应用缓存的结果.

    增量的重新编译非常快.编译系统运行在内存中,当重新执行编译任务时,它能够分析文件上次编译后发生的增量变化.

    提交前检查.Google 有专门的自动化工具,用来在发起代码审查和准备提交更改到代码库时,进行一整套的标准检查.

    代码审查

    Google 开发了基于 Web 的代码审查管理工具.程序员可以申请对代码进行审查,审查者可以在浏览器上比较差异,并写上评语.当写代码的人发起一次审查申请,则系统自动发邮件给审查者,并附上代码查看页的链接.

    对源代码的任何更改,必须经过最少一次审查.如果更改不是由"代码所有人"做出,则还必须由所有人中的一位进行审查.

    系统可以自动推荐合适的审查者.当然,写程序的人,可以自己选择审查者.

    Google 鼓励工程师们,将每一次代码更改控制在较小的规模上. 30-99 行的代码更改,通常视为"中等";300 行以上则标记为"大"; 1000-1999 行,则是"巨大";

    测试

    单元测试是必须的,在 Google 的开发中广为采用.集成测试和回归测试,也较为普及.Google 有一个自动化的工具,用来衡量测试覆盖的范围,这个结果也在代码浏览器中可以查看.

    部署前一定要做压力测试.项目组要用表格或者图标显示关键参数,尤其是压力之下的延迟和错误率.

    Bug 跟踪

    Google 使用的 Bug 跟踪工具叫 Buganizer.有的团队,安排专人分配 Bug,有的团队则在例行的会议中分配.

    开发语言

    Google 内部有四大语言,一般都建议工程师在这四种里挑选.四大语言是: C++,Java, Python, Go.不用多说,减少语言数量,可以增加代码复用,并提高内部协作.

    每种语言都有代码规范,保证风格统一.公司范围内,还有针对"代码可读性"的培训,由经验丰富的老司机,对新人进行培训.代码审查,也需要对"可读性"做专门的评审.

    在不同语言之间的交互操作,要通过Protocol Buffers 来处理.Protocol Buffers 是 Google公司开发的一种数据描述语言,类似于XML能够将结构化数据序列化,可用于数据存储、通信协议等方面

    调试工具和性能分析工具

    Google 的服务器连接了很多库,提供用于调试服务器的工具.服务器崩溃时,可以自动导出堆栈轨迹到日志文件. 还有 Web 界面用于调试,可以用来查看呼入和呼出的 RPC 调用、更改的命令行标志值、资源消耗、性能分析等.

    发版

    Google 的大部分项目组,都有固定的软件工程师负责发版.

    大部分的软件,发版比较频繁.通常是周发版,或者每两周发版,有些项目组甚至每天发.所以,自动化进行发版就是必须的了.频繁发版有助于工程师们保持斗志,提高整体速度,实现更多的迭代,从而也可以获得更多的反馈,并做出更多有益的更正.

    上线

    要上线任何更改,并对用户可用,则需要项目组外很多人的审批.审批来自多个方面,包括法律合规、隐私保护、安全要求、可靠性、业务需求等等.

    Google 有一个内部的上线审批工具,用来执行审查和上线审批.通过定制,这个工具,对不同的产品有不同的审查和审批流程.

    过错总结

    发生了重大的服务事故后,相关人员要起草过错总结报告.文档描述事故细节,包括标题、概要、影响、时间段、原因、故障组件、行动. 总结的聚焦在于问题,以及未来如何解决,而不是聚焦在于人,也不是为了惩罚责任人.

    频繁的重写代码

    Google 鼓励频繁的重写代码,任何软件每隔几年就重写一遍.一来可以优化产品,采用最先进技术,去掉无用的功能,另外还可以转移知识到新员工,并保持员工的斗志.

    项目管理

    20%的自由时间

    尽人皆知,google的工程师拥有 20%的自由时间,可以随意做感兴趣的东西,而无需审批.这当然是为了激发工程师的各种创意,同时也让工程师们保持高效率,而不是窒息在必须完成的任务中. 另外,也考虑到,很多员工都会私下里自己做一些东西,那么还不如鼓励大家将这些研究方向公开.

    目标和关键结果

    不论个人还是团队,都要明确的写下自己的目标,并评估达成目标的进度.每个季度的末尾,要根据关键结果,对目标达成情况进行打分,分数从 0 分到 1 分.这 OKR 分数是全公司内部公开的.但这并不直接用作个人绩效评估的输入.

    平均得分是 0.65,但鼓励大家将目标定的高一些,所以在可完成任务之上,再加 50% 的工作量是正常的.

    项目立项

    对于项目立项审批,以及项目取消,Google并没有清楚定义的流程.即便是在 Google 做过 10 年的老经理,也不知道决策是如何做出的.很可能因为在公司范围内,流程并不一致,经理们可以自行判断并决策.有时候,决策是由下而上进行的,因为项目组的人都走光了.有时候,决策是自上而下的,老板们决定哪些项目得到更多的预算,那些则必须关闭.

    机构重组

    当关闭一个大项目时,工程师们可以自行寻找新机会,加入新团队.有的时候,还会搞"去碎片化"行动,把琐碎的分散的团队合并,这个时间工程师也可以自行选择团队和工作地点.

经常进行重组,有利于突破大公司的低效陷阱.

更多潍坊达内培训相关资讯,请扫描下方二维码

潍坊达内培训