牛!Google 开源的这份工程实践,GitHub标星14.4k,果然大厂出品,必是精品!

点击上方“Github爱好者社区”,选择星标

回复“资料”,获取小编整理的一份资料

牛!Google 开源的这份工程实践,GitHub标星14.4k,果然大厂出品,必是精品!_第1张图片

作者:GG哥,来源:GitHub爱好者社区

这是GitHub爱好者社区 27 篇原创文章

Hello,大家好,我是GG哥!

今天给大家分享的Google公司开源的工程实践,英文名:Google's Engineering Practices documentation。没错是全英文的。那么有没有中文版呢?可以直接拉到文末。

牛!Google 开源的这份工程实践,GitHub标星14.4k,果然大厂出品,必是精品!_第2张图片

英文版

牛!Google 开源的这份工程实践,GitHub标星14.4k,果然大厂出品,必是精品!_第3张图片

中文翻译版

很多公司都要求项目做CodeReview,但很多人第一次CodeReview往往不知道该如何做,也不知道为什么去做。笔者参加过几个项目的CodeReview,发现一些共性问题:

  • 有时候参与Review的人太多了,意见太分散,Review时间拉的很长,发现问题效率低;

  • 有时候会发现一个CodeReview时间很长,参与者会觉得煎熬和浪费时间;

  • 有时候不太了解对方评审的东西,没法跟上大家的思路,影响效率;

  • 有时候走查的代码量太大了,无法做到详细走查;
    有时候会看到有些人无所事事、精神不集中、不发言,影响效果。

Google在这篇文档中,详细概述了代码Reviewer和代码Developer需要考虑的点。

这篇文档主要包含以下文档:

  • 代码Reviewer指南

  • 代码Developer指南

比如我们需要在代码的可读性上注意,如果代码的可读性强,那么维护起来也就方便很多;一个好的代码规范和编码风格会节省大家对代码的理解时间,减少维护成本;虽然我们有编程规范检查工具,但有些内容检查不出来,是需要靠大家去规范的。

  • 关注代码注释:我们在编写函数和进行逻辑判断的时候最好要标注一下这个函数或者这段判断是用来做什么的;做了这种注释的好处,一来当别人阅读这段代码的时候看到你的注释以后就会根据你的思路快速理解代码,甚至不阅读直接跳过;二来防止自己由于长时间不阅读代码而忘记这段代码的用途。

  • 关注命名规范:虽然我们有自己的编码规范,但是这种规范只是限制了使用驼峰命名法还是其他命名法;而好的命名风格应该是看到变量或者函数名字就能“望文生义”,毕竟我们不能把自己写的所有代码都做注释。

  • 关注重复代码:如果出现大量的重复性代码,要考虑将这些代码抽象出公用函数,以减少代码量并增强代码可读性。

  • 关注繁琐的逻辑:如果一个简单的功能却对应大篇幅的代码,要考虑一下是不是有比较简单的实现方式,因为过于复杂的代码会给后来者的维护带来麻烦;如果没有简略的办法,一定要把注释写好

由于内容较多,不一一介绍,大家可以下载后阅读。

目前 Google 的这份文档已正式开源到了 GitHub 上,并且还基于 GitHub Pages 构建了文档的静态站点。此外,英文不太好的同学也不用过于担心,国内有开发者已将这份指南翻译成了中文,下面是该项目的完整链接,感兴趣的同学可以看一下。

中文版:https://jimmysong.io/eng-practices/

英文版:https://google.github.io/eng-practices/

GitHub 地址:https://github.com/google/eng-practices

好了...

现在是真的结束了...

我已经夸不动了...





千言万语化成一句,这么优秀的仓库,大家多多给仓库创建者 star 支持,你们的 star 是万千开源者源源不断创作的动力!


当然还有多多对我的在看转发支持啦,你们的“在看转发”也是我源源不断创作的动力呀...



好啦,今天的分享就到这儿啦,我们下次见啦~



推荐阅读:
张一鸣:为什么BAT挖不走我们的人才?
GitHub标星5.6K,这张二维码火了,有了它,电脑手机文件互传秒完成
网传互联网公司加班表,哈哈哈这也太真实了吧!
关注「Github爱好者社区」加星标,每天带你逛Github好玩的项目

你可能感兴趣的:(牛!Google 开源的这份工程实践,GitHub标星14.4k,果然大厂出品,必是精品!)