gg修改器中文正版官网_GG修改器官网版-gg修改器中文版

应用详情

大家好，今天小编为大家分享关于gg修改器中文正版官网_GG修改器官网版的内容，赶快来一起来看看吧。

考虑到现在开发者必须要处理的代码的规模，如果缺乏代码搜索，就会严重影响开发的进度。

在选择代码搜索引擎时，需要考虑以下几点：

查询语言：正则表达式只是入场券。代码搜索引擎应该确保代码搜索查询语言具有很好的表现力，且易于使用的。文字搜索应该是直观的，另外，更高级的模式匹配也是必要的；
扩展性：代码搜索引擎要能够适应代码库的规模。如果代码库超过几千兆字节，那么关键就要看代码搜索引擎是否使用了三元组索引，因为这样你才能在大型代码库中实现正则表达式匹配；
代码浏览：使用过谷歌代码搜索的人都知道的，搜索并非是其全部。用户希望单击后能跳转到定义并查找引用，就像在IDE开发环境中查看代码一样简单。但是，如果没有出色的代码浏览，用户就需要经常在编辑器和代码搜索引擎之间来回切换；
权限：如果公司强制实施代码库权限，那么就需要考虑代码搜索引擎是否符合这些权限；
总体成本：考虑代码搜索引擎的价格和保持工具在线的维护开销。

以下一些常见的代码搜索引擎：

OpenGrok：一个非常老但生命力持久的代码搜索引擎，现在由Oracle维护；
Hound：由Etsy的工程师创建和开源的代码搜索引擎；
Livegrep：由Stripe的Nelson Elhage创建的代码搜索引擎；
当然，还有我们的Sourcegraph。

获得良好的监测

另一个需要尽早改进的方面是监测。工程师总有些时候必须要处理一些在生产环境中出现的问题。生产和开发截然不同——不能只是设置断点或者添加printf就能马上看到效果。在很多方面，对于生产环境进行更新会产生巨大的开销，比如消耗计算资源，以及花费开发者大量的时间。

在过去的5-10年的时间里，部署发生了巨变。微服务、Kubernetes，云迁移等技术，极大地改变了公司部署软件方式。许多公司已经采用了这些新方式和技术，但这些公司还没有更新其监测基础结构，以便在新的生产环境中轻松地进行调试。

幸运的是，近年来，优秀的新开源工具和公司涌现，它们极大地改善了谷歌之外的世界中的监测和可观察性状态。

Prometheus：一个时间序列指标跟踪器和可视化工具，类似于Borgmon。它能够让用户通过检测应用程序来跟踪随CPU 利用率、错误率和p90延迟等指标的变化；
Grafana：一个类似于Viceroy的仪表板工具。一种常见的方式是将Grafana与Prometheus连接起来，这样用户就可以构建指示整体应用程序运行状况的关键指标的单页视图。

谷歌率先推出了分布式跟踪，这是一种日益常见的多服务架构的重要工具。Dapper的创造者之一Ben Sigelman继创建了Lightstep。分布式跟踪现在是许多监测系统的一个功能，包括像b和Sentry这样的付费产品，以及像Uber工程师构建的Jaeger这样的开源项目。

考虑到监测必须集成到生产环境中，所以引入监测比引入代码搜索要更加棘手。通常会涉及到更改部署环境，而更改部署环境可能意味着要说服部署环境的团队。监测可能还需要添加监测代码，这需要向拥有所检测代码的各个团队提交补丁。这看起来非常麻烦。但是，从某种意义上来说，引入新工具不需要任何人改变现有的习惯。让开发者自由地使用新的工具，这似乎可以减少很多反对的声音。

代码审查

引入代码搜索和监测都不需要团队改变现有的工作流，但是如果代码审查工具发生变化，那么工作流就会改变。

如果你曾在谷歌工作了一段时间，那么你可能会不适应在谷歌之外进行代码审查的方式。GitHub Pull Requests是最常见的代码审查工具，但Google前员工通常会对此有一些抱怨：

不够直观。有时无法查看自上一轮审核以来所做的更改。简单路径仅允许查看显著的差异；
不支持堆叠的CR；
变更集中所有文件的全部差异显示为一个巨大的页面，并且很难跟踪所查看的内容；
GitHub PR的审核机制非常不友好。如果不添加额外的第三方集成，审核流程可能看起来很松散，即使使用了第三方集成，它仍然可能缺乏执行更精确的审核和签出策略的能力；
对于某些语言，模糊跳转到定义或者查找引用存在限制，但是它远比不上谷歌内部使用的Critique的水平。

在谷歌之外，和Critique最接近的是Gerrit。Gerrit最初是Rietveld的一个分支，而Rietveld本身就是谷歌原始代码审查工具Mondrian的开源分支。因此，谷歌前员工应该对它有种亲切感，因为它来自一系列工具，而这些工具是为了支持谷歌进行代码审查的方式而创建的。

另一种谷歌前员工似乎更喜欢代码审查工具是Phabricator。Phabricator最初是Facebook的内部代码审查工具，随后被开源并向外界发布。这款工具由Phacility公司提供托管实例和支持，以防用户因不想为维护自己的实例而陷入麻烦。

还有一个值得研究的工具是Reviewable，它由前谷歌员工Piotr Kaminski创建。不同于Gerrit或Phabricator，Reviewable仅限云的，但能够提供最类似谷歌内部的代码审查体验。

向团队的其他成员推销Gerrit，Phabricator或Reviewable的前提是，现有的代码审查工具让团队感觉很痛苦。

以下是一些通过从类似GitHub-Pull-Request的工具切换到类似Gerrit的工具来解决一些常见问题的方法：

通过明确的签发，Gerrit能够提供更具有结构化的审核流程，这对于希望审核策略更加严苛的组织来说是个助力；
Gerrit可以让审阅大量的差异变得更加轻松，因为用户可以逐个文件查看、查看自上一轮评审以来的更改以及堆叠CR，以便于更快、更彻底地进行审查。

最后一步

在软件开发生命周期中，最棘手的部分通常是CI和构建系统。因为要理解构建，通常需要理解整个代码库的每一个部分。而不断有人在尝试各种方法来加速构建，于是有越来越多的黑客参与构建代码，进行的优化也逐渐增多，直到人们发现不产生负面影响的更改屈指可数。

总之，构建系统就像是一团乱麻，所以在利用底层开发人员的成果之前，需要更加的谨慎。想要早发现早解决的话，Blaze是很好的选择，谷歌甚至帮助开源了Blaze的衍生产品Bazel。但Bazel不是Blaze——首先，它缺乏一个免费的大规模分布式构建集群，毕竟谷歌以外的世界和谷歌不尽相同。

然而，Bazel也不是万能的。Bazel首次发布时，Go社区中的许多开源项目纷纷转向使用Bazel。后来，由于其使用的复杂性、难上手以及Bazel的构建速度实际上较慢等缺点，在一年之内，许多开源项目又将工具切换了回来。不过，自那以后，Bazel对Go的支持有了重大改进。如果你选择再次使用它，还是需要对这些改进进行严格地评估。

进行这些严格的评估需要大量出色的开发工具，特别是需要出色的代码搜索工具，这样你才能深入研究代码库各个部分中的构建脚本，并且了解它们的来龙去脉。代码审查工具也是非常重要的，因为更改构建系统将是一个复杂的过程，需要获得许多不同工程团队的批准。

在万事俱备之前，你还需要知道，除了Bazel之外，还有许多构建工具，这些工具旨在实现大型代码库中的可扩展构建。包括以下几种：

Buck：来自Facebook；
Gradle：Java界的宠儿；
Pants：由前谷歌前员工最初为Twitter和Foursquare创建；
Please：一个由谷歌前员工创建的新手构建工具；
还有YourBase，它不是一个构建工具，而是由谷歌前员工Yves Junqueira发起的CI服务，旨在为Google以外的世界带来超快速和可扩展的构建，而与使用的底层构建工具无关。