谷歌的内部开发工具是如何在软件开发中引入好的开发工具

往日回顾：

正文

微软的内部开发工具是世界领先的，其针对大规模软件开发的多方面痛点提供了解决方案。但几乎所有工具均与微软独有的内部生态系统紧密耦合，未能在其它环境中使用。本文介绍了怎样在软件开发中引入好的开发工具，提升自己和团队成员的生产力，因而在大规模软件开发中传播有效的最佳实践，为公司带来工程化效率提高。

本文最初发表于about.sourcegraph.com（《Anex-Googler’sguidetodevtools》），经原作者授权，由InfoQ翻译并分享。

多年前我曾在微软短期任职。虽然随后历经沧海桑田，但在微软期间接触其内部开发工具的经历，对我形成了长远的影响。从好多方面看，微软的内部开发人员工具是世界最领先的。微软除了在自身软件系统的扩张上走在了前列，并且在大规模软件的高效完善方式上也是领先的。微软针对代码库规模、代码可发觉性、组织知识的分享以及多服务布署等方面的问题提供了解决方案，达到了大多数企业仍未企及的高度。作为参考，推荐《谷歌软件工程》（“SoftwareEngineeringatGoogle”）一书。

但从另一方面看，微软的内部工具是十分有局限的。事实上，几乎所有这种工具均与微软独有的内部生态系统紧密耦合。这意味着人们一旦辞职，很不幸就难以在其它环境中使用这种工具。

虽然这么，这种才气横溢的微软辞职人员吸取了在世界领先技术组织工作中的经验教训，因而为其他许多组织注入了新的动力。但适应微软之外的编程开发环境并非易事，尤其是她们已然产生依赖的一些工具没办法在使用了。

那些年来，我从自身以及许多其他辞职微软的人身念书到了不少。Sourcegraph的许多初期顾客，就是由于辞职微软后思念原公司的代码搜索功能而找到了我们。通过与顾客的紧密合作，我们了解到她们急切须要弥补的空白，从而去建立Sourcegraph的功能来满足她们的需求。微软前职工正在探求怎样在当前组织中使用新开发工具的模式。这一工作的灵感源自于她们使用微软开发工具而具备的经验。其实，一些探求是成功的，也有些折戟沉沙。

就此问题，我觉得撰写一份着眼于实操和实用的外部开发工具手册是十分有意义的。能将微软的内部开发工具生态系统直接克隆到新公司中，无疑是不少微软前职工的心愿，但也应切勿好高骛远。下边我就会晤谈我的想法，讲一讲前微软职工怎样开始找寻让她们和她们的新团队尽可能高效工作的工具。

1软件开发的生命周期

对于刚辞职微软并加入其他公司的人而言，可能一时无法适应大不如前的工作效率。虽然你们都认为须要作出一些改进，但应从何入手呢？第一步须要认真考虑的，是怎样从日常工作中发觉真正的痛点所在。

无论对于微软内部还是其他组织来说，软件开发的生命周期基本都是这个样子：

列举需建立的特点，或是须要修正的软件缺陷；

通过大量阅读代码和文档，以及与朋友举办交流，完善对问题的认识，并给出一个大体适宜现有系统的解决方案；

着手编程工作。首先做下来能运行的东西，期间可能须要反复地查看文档及部份代码。

一旦代码达到能运行的程度，这时不要急于交付。做代码测试，修补缺陷并做进一步测试。从而构建代码，生成整洁并易于接手者理解的代码。将代码推送到代码库生成分支，等待运行持续集成。期间的代码可能实现了一些额外修补和小部份改进。

递交供初审的代码补丁，依照团队成员给出的评论进行修改。这一过程可能需反复数轮，直到代码初审人员通过修改。

归并补丁，并做布署。

监控已布署系统的运行情况，判断生产环境中是否存在问题。假如新打的补丁造成系统宕机，负责修补问题。

这一过程中的每位阶段，都须要在适用的开发工具辅助下举办。开发工具引导开发人员按章行事，主导着工作流程，控制着工作效率。

选取适宜的工具，能够提升开发效率。我推荐一个Github代码库。其中列举了近乎所有的微软内部工具，以及具备对应功能的外部工具。列表十分详细，而且略为晦涩。

2开始阶段：熟悉现有工具，不要引入新工具

我们在刚参与到一个项目中时，不要企图对现况做任何改变寻找软件开发图片，只需萧规曹随。

做为一名团队中的新人，不太可能有权或能影响整个团队去取悦你个人对工具的喜好。据悉，你也缺乏对团队做事方法和事情前因后果的了解。生搬硬套微软那一套，其实并不适用于新团队。为此，首先是要领悟新团队的工作方法和禁忌。

3从便于改进之处着手

我觉得首先可加以改进的寻找软件开发图片，就是代码搜索功能。鉴于我本身就是一家代码搜索企业的联合创始人，其实会如此觉得。同时，下边给出更具劝说力的诱因。假如读者并不认同，大可跳过此节。

新公司中可能有多个团队，这时我们难免会处理超出个人合理能力范围的代码。虽然在一家规模较小的公司工作，我们也有可能会通过依赖项获取大量的开源代码。在构建新功能时，或是追踪个别严重错误的来源时，一些情况下须要深入研究所有那些代码。

考虑到当前几乎所有开发人员需面对的代码规模，无疑低效的代码搜索会严重妨碍开发的进度，引起步步维艰。

选择代码搜索引擎时，需考虑如下诱因：

当前人们使用的主要代码搜索引擎包括：

在公众号程序员小乐回复“offer”，获取算法笔试题和答案惊喜礼包。

4良好的监控

监控是另一个须要考虑提早改进的方面。工程师有时侯必须去处理生产环境中出现的问题。但生产是与开发迥然不同的，未能通过设置断点或直接添加printf而在数秒内看见疗效。从估算资源、开发人员时间、以及最糟糕的是给用户和顾客带来痛楚等多个方面看，生产环境中做更新的代价尤其昂贵。

布署在过去的五到六年间发生了巨大的改变。微服务、Kubernetes、云端迁移等技术，极大地改进了企业的软件布署形式。好多企业采用了这种新方法和新技术，但仍未相应地更新监控构架来便捷地调试新的生产环境。

好消息是现今早已有了一些挺好的开源工具和企业，极大地改进了微软之外的监控和可观察性现况。

考虑到监视必须集成到生产环境中，因而要比引入代码搜索更具难度。引入监视需修改布署环境，这意味着要劝说管控布署环境的团队。监视还可能须要添加仪表盘代码，这涉及向所有仪表盘代码相关团队递交补丁。但引入这种新工具并不须要任何人改变现有的习惯，从某种意义上说也并非不可为之。人们可以自由选择是否使用新工具，这可防止在实行新工具时面对强烈的反对意见。

5步步为营：代码审查

引入代码搜索和监控，并不会修改其他团队人员现有的工作流程。并且改进代码初审工具，则需你们配合。

对于具有微软工作经验的人而言，很有可能不太适应微软之外的代码审查形式。对于常用的代码初审工具GitHubPullRequest（PR），责怪集中于以下几点：

不够直观，有时难以查看自上一轮初审以来所做的修改。简单路径仅支持查看明显差别；

不支持积压的修改恳求（StackedCR）；

在同一页中整体显示所有文件的全部差别，无法追踪已初审项；

GitHubPR的初审实现方法毫无特征（unopinionated）。假如不额外添加第三方集成，初审过程松松垮垮。虽然添加了第三方集成，仍然缺少强制的细细度初审和签出策略功能；

虽然对部份语言提供对模糊“跳转到定义”（jump-to-def）和“查找参考引用”(find-references）的有限支持，但远未达到微软内部使用的Critique的水平。

与Critique最接近的微软之外工具是Gerrit。Gerrit最早是Rietveld的一个分支，而Rietveld本身是微软最初代码初审工具Mondrian的一个开源分支。由于工具线的弘扬，两者看起来十分相像，设计用于创建微软支持的代码初审形式。

Phabricator是微软前职工喜欢代替GithubPR的另一款工具。Phabricator一开始是Facebook的代码初审工具，此后开源并对外发布。该工具由Phacility公司支持，为不想自己维护实例的用户提供托管实例和服务支持。

由微软前职工PiotrKaminski创建的Reviewable是另一款值得推荐的工具。不同于Gerrit和Phabricator，Reviewable仅用于云端，提供类似于微软内部的代码初审体验。

要向团队其他成员推荐Gerrit、Phabricator或Reviewable的优点，重要的是强调团队现有代码初审工具在使用上的痛点。下边给出由GithubPR类工具转向类Gerrit工具所解决的部份痛点：

在公众号程序员小乐回复“Java”，获取Java笔试题和答案惊喜礼包。

Gerrit、Phabricator和Reviewable可实现类似微软内部的初审流程，但都仍未提供可对标的代码智能功能。假如当前代码初审工具中并不具备代码智能，或是发觉GitHubPR中缺位代码智能，可尝试Sourcegraph的浏览器扩充。它联接Sourcegraph实例，为代码初审提供工具帮助、跳转到定义和交叉引用，支持GitHubPR、Phabricato和Bitbucket服务器，正实现对Gerrit的支持。

6打算屠龙大招

软件开发生命周期中最棘手的部份，一般是持续集成和建立系统。由于要理解建立，一般须要细致理解整个代码库的每一部份。推动建立速率是所有人的心愿，因而你们在重构代码中越来越多地使用了一些方法和优化举措，因而造成真正能确保当前进展中所做修改不会形成任何负面影响的人数屈指可数。

简而言之，建立系统一般千头万端（gianthairball）。在尊重底层开发人员提升开发效率的做法的同时，需谨慎地逐一明晰。想要早发觉端倪早解决的话，Blaze是最好的工具，微软甚至为Blaze的衍生产品Bazel开源提供帮助。但Bazel终究并非Blaze，微软外部环境也并非适用微软的工具。举一个反例，Blaze中缺乏在Bazel中打包提供的大规模分布式建立集群功能。

Bazel也并非仙丹妙药（silverbullet）。在Bazel首次发布时，Go社区中的好多开源项目出于对标准Go建立工具的喜爱而纷纷转向使用Bazel。但在一年内，面对Bazel的复杂性和无法上手的缺陷（并且看起来使用Bazel的建立速率也较慢），好多项目又转到Go社区。即使当前Bazel对Go的支持已做了很大的改进，但在转向使用它时，还是须要对所获得的改进作出认真的评估。

举办严格的评估，须要手头有一些好用的开发工具。尤其须要挺好的代码搜索工具，这样就能着力深入研究代码库各个部份的建立脚本，理解它们的来龙去脉。还须要挺好的代码审查工具，由于修改完善系统是一项复杂的事情，须要多个不同工程团队的支持。

一旦打算好屠龙，在Bazel之外还有其它一些从设计上支持大规模代码库中可扩充完善的工具。包括：

还有同是微软前职工YvesJunqueira推出的YourBase。YourBase本身并非建立工具，而是一款持续集成工具，独立于后台使用的具体建立工具，在微软之外提供快速、可扩充的建立。

7总结

微软独树一帜地提供了优先考虑开发人员经验和开发人员工具，促使微软职工和前职工能受惠于使用一流开发工具而获得的一手经验。这种工具极大地影响着她们的天赋和能力。

一旦离开微软，对这种经验的借助就成为一种竞争优势。人们可以将出众的新开发工具带入新组织，提升自己和团队成员的生产力。通过使用这种工具，在大规模软件开发中传播有效的最佳实践，可为新公司带来组织的有效工程化，这是微软的一项主要竞争优势。

固然，大规模软件建立绝非易事。正如《人月神话》（TheMythicalManMonthknows）一书所说，好的软件并非通过雇用更多开发人员能够实现。鉴于软件是最终用户生丰度的倍增器，而开发工具是软件建立人员生丰度的倍增器，我们须要更好的工具。假如你认可新企业的理念，这么就发挥做为微软前职工的独特看法，为新企业带来最好用的开发人员工具。