谷歌pr(谷歌Project Tango)-第1张

认同工艺技术是 Instawork 工程建设项目组的几项辅导准则。它引导她们以自学的立场去审视应用软件的工艺技术。为的是那个目地,我在今年创建了工程建设书刊俱乐部队,以协助她们从金融行业中的名企和科技人才吸取实战经验。她们的写作的第一篇书刊是Software Engineering at Google(未明英文版:《Google的计算机科学建设》)。她们很想介绍Google是怎样以非常大的体量展开应用软件设计的:数千万行的标识符,数以千计的开发者。她们的任何人作法与否适宜像她们这种的较大型项目组?

历经数年对这两本书的钻研和探讨,她们得出结论了许多较好的看法:

  1. 如旁人想像的,Google的许多作法,在她们的体量上并没象征意义。
  2. 但是,书中的许多设想对孵化器子公司而言也是可取的。
  3. 事实上,Instawork 已经已经开始接纳Google的许多最差课堂教学!

在那个月末,书刊俱乐部队明确提出了这份提议目录。她们如果已经开始做甚么,却是继续做甚么?和在她们现阶段的体量下,她们如果等候做甚么?

文档

Google像对待标识符一样对待文档。文档是受版本控制的,要历经同行的评审,并定期更新/弃用。作者持有其文档,在其离职或者其身份变更时,应将其所有权转移。Google的内部文档管理系统还会根据文档最近的更新情况来展示文档的新鲜度。为的是保证信息的准确性,系统会提醒作者有关旧文档的情况。

Google也着重指出,在编写文档时,要充分考虑到目标用户。比如,技术文档是为初级工程建设师编写的,它如果与为高级工程建设师编写的文档有很大的不同。初级工程建设师也许会觉得详尽的描述性说明非常有用,而高级工程建设师会感到冗长且多余。

她们的收获:

  • 项目负责人将继续编写彻底的、经同行评审的设计文档,以供高级工程建设师审核。
  • 她们将继续为新入职的员工编写简明的、适宜初学者的指南。
  • 她们应当从监控文档的新鲜度入手,摒弃陈旧的文档,并在编写时将目标受众纳入考量。

公平的工程建设

工程建设师编写的标识符和它对用户的影响之间往往存在着脱节。设计和构建应用软件的项目组不可能完全代表所有的产品用户。Google也遇到了这种的问题,因为她们的图像识别算法并没针对足够多样化的人群展开训练,这导致用户的照片不能较好地根据肤色展开分类。她们提议工程建设师们至少要介绍她们用户的人口统计数据。这可以协助工程建设师更加认真地考虑她们所做的改动,并且考虑到这些改动与否会给某些人产生积极影响,也会给别人产生消极影响。

与项目组成员探讨这一部分内容时,大家特别有见地。在 Instawork,她们致力于为当地企业和专业人士创造商机。促进公平的工程建设是她们工作的核心,但也总存在着改善的空间。

  • 因为她们许多用户不是以英语为母语的人,所以她们必须把国际化和优秀的翻译放在第一位。
  • 她们的用户往往拥有较旧的、资源受限的移动设备,因此,她们需要跟踪应用程序的体量及数据消耗来维持其易用性。
  • 为的是避免自己的偏见,她们会持续采访用户并查看数据。例如,她们假定她们的通知数量过多,但是数据和研究显示,她们的用户并不在意,事实上,她们是依靠这些通知来选择最差班次。
  • 她们将已经开始检查无意识的偏见,作为设计阶段的一部分,以确保她们的变更不会无意间伤害到任何人用户。

知识共享与项目组合作

计算机科学建设中的协作即使不比个人工作更重要,也同样重要。标识符是由个人开发者编写的,但产品是由项目组构建的。项目组在沟通和协作方面做得越好,她们的表现就越好。Google提议,要营造一种有心理安全感的文化,在这种文化氛围中,工程建设师能够坦然面对失败、不明白的事物,并明确提出问题。没了心理安全感,工程建设师就不太可能因为害怕公开失败而去冒险。在论坛和 Slack 频道里,为的是避免因不知道而显得愚蠢,因此都不去提问题。这种模式会阻碍自学,并且对工程建设师而言是有害的。在Google,项目组之间的社交互动都是基于谦逊(我并非无懈可击,愿意改进)、认同(我真心关注我的同事)、和信任(我认为我的同事都很有能力,而且会作出正确的决定)。这就为工程建设师提供了一个框架,让她们能够正确地给予和接受批评,并且避免了一种指责文化,那就是项目组成员会把过错归咎于谁。

她们很高兴地发现,Google许多以项目组为导向的课堂教学已经深深扎根在 Instawork 的文化中。

  • 在展开标识符审查时,她们默认会明确提出澄清性问题,而非陈述观点或假设错误。她们会以一种谦逊的立场来展开技术探讨。
  • 她们会继续坚持无责的事后总结文化:在遇到重大问题时,她们会寻找解决方案,而非责备。
  • 她们将会为 Slack 频道中的专家展开宣传,如 mobile、backend、frontend、infrastructure。这可以减少提问的摩擦,并在精神上增加这份安全感。
  • 她们会不断构建全面的文档,以拓展 Instawork 的知识,方法是找出当前文档的差距,并找到所有者来弥补这些差距。

标识符搜索

现代 IDE 能够搜索符号定义和引用,提交历史等。但是,IDE 会被Google 20 多亿行的单体仓库所吞噬。因此,Google开发了一个内部工具,可以在自己庞大的标识符库上展开标识符搜索。虽然现在的工程建设师还在利用 IDE 的特性来协助编写标识符,但是她们却是会利用标识符搜索来写作、理解和搜索标识符。(本着Google的精神,)搜索结果是有排名的,这种,开发者可以通过她们的搜索关键词来判断哪些标识符最流行。如果搜索结果没排名,那么开发者就必须对数以千计(甚至数百万)的结果展开分析。随着标识符库的发展,这种排名有助于促进更多的最新模式,并且可以发现那些可能准备废弃的标识符。

对于Google这种非常大的标识符库而言,开发一种单独的工具是很有必要的。她们一致认为,IDE 可以提供许多这种的特性:符号查询、引用、定义,都是期望的标准,大多数工程建设项目组不需要更多的东西。在 IDE 中可以访问这些特性中的大多数更方便,并且不需要维护另一个应用程序。但是,她们更喜欢的是排名的搜索结果。IDE 只能对一个特定的资源库展开分析,而无法对其展开推断开发者是怎样使用它的。排名的搜索结果提高了工程建设师发现相关标识符示例的概率,同时忽略了潜在的死标识符。

  • 她们会持续地利用和强化 IDE 工具,用于标识符完成、导航和搜索。
  • 一旦她们的体量需要,她们将等候引入像 Sourcegraph 这种更强大的标识符搜索。

持续集成

持续集成是一种流程,它介绍在开发的各个阶段都要展开甚么样的测试。她们越早找到 Bug,修复 Bug 的成本就能做到越低。在编译过程中出现的错误将被迅速地找出来。等候测试套件所花费的时间更长,或者更糟糕:捕获生产环境中的 Bug。Google提倡迅速的反馈循环,以便尽早发现 Bug。在一个完美的世界里,所有的测试都是在编译时展开的。但是对于Google的体量而言,这种做是行不通的:数以百万计的单元测试和集成测试无法在一台计算机上展开。甚至在云端中并发展开测试,对她们而言也不够快。所以,Google在提交前(当 PR 标识符更改时)展开一套很小的、重要的测试,而另许多则在提交后(当标识符被合并到 main 时)展开。提交前展开的测试既快速又可靠。提交后展开的测试会变得缓慢,并且会对多个子项目展开测试,而且还会有些不稳定。权衡利弊:提交前的测试会丢失测试覆盖率以加快速度,而在提交后的测试会弥补这些测试空白。

Google之所以维护独立的测试套件,是出于她们庞大的标识符库的需要。从 Instawork 的体量来看,她们并不认为采取这种的方式会带来任何人好处。她们的全部单元测试套件大约需要 15 分钟的时间,考虑到她们每次都能获得 100% 的测试覆盖率,这对于她们的需求而言,是完全合理的。

  • 她们将继续在提交前运行她们的整个测试套件。
  • 她们将继续监控测试套件的执行时间以保持快速。
  • 一旦这变得不可取,她们将等候创建一个 Staging 阶段的 CI 流程(提交前-提交后)。

结束语

Software Engineering at Google这两本书是她们工程建设书刊俱乐部队的绝佳选择,使她们的项目组获益良多。这两本书的主题与她们产生了共鸣:计算机科学建设是随着时间推移而整合的编程。作为计算机科学建设师,她们不只是负责编写标识符。她们还需要迭代项目组能够在标识符的生命周期内为标识符库作出贡献。

鉴于Google的庞大体量和悠久历史,她们采取了一系列的措施来保证标识符质量和工程建设生产力。Instawork 作为一家孵化器子公司,它还处在起步阶段:她们最古老的标识符只存在了 5 年,而她们的产品却在飞速地发展。她们每一年都会变得更加成熟。随着上百万的用户依赖于她们的产品而获取商机,她们的投资将会不断增加。当她们的项目组和标识符库越来越成熟的时候,她们自然会像Google一样采取同样的作法。令人欣慰的是,她们正处于相同的计算机科学建设旅程中。展望未来,随着她们项目组和标识符库的扩大,她们很高兴能引入更多的课堂教学。

作者简介:

John Torres,Instawork 计算机科学建设师。

原文链接:

https://engineering.instawork.com/do-googles-engineering-practices-work-for-a-startup-6b9a3b6b0ad7

介绍更多应用软件设计与相关领域知识,点击访问 InfoQ 官网:https://www.infoq.cn/,获取更多精彩内容!