CHAPTER 3 Knowledge Sharing

知识共享

你的组织对你的问题领域的理解比互联网上一些随机的人要好；你的组织应该能够回答自己的大部分问题。要做到这一点，你需要知道这些问题答案的专家，以及传播他们知识的机制，这就是我们在本章要探讨的内容。这些机制的范围很广，从完全简单的（提问；写下你所知道的）到更有条理的，如教程和课程。然而，最重要的是，你的组织需要一种学习文化，这需要创造一种心理上的安全感，允许人们承认自己缺乏知识。

学习的挑战

在整个组织中分享专业知识并不是一件容易的事。如果没有强大的学习文化，挑战就会出现。谷歌已经经历了一些这样的挑战，尤其是在公司规模扩大的时候。

缺少心理安全
在这样的环境中，人们不敢冒险或在他人面前犯错，因为他们害怕因此受到惩罚。这往往表现为一种恐惧文化或避免透明的倾向。
信息孤岛
在一个组织的不同部分发生的知识碎片化，这些部分没有相互沟通或使用共享资源。在这样的环境中，每个小组都会形成自己的做事方式。这往往会导致以下情况的发生。
- 信息碎片化
  每个岛屿对更大的整体都有一个不完整的描述。
- 信息重复
  每个岛国都重新发明了自己的做事方式。
- 信息偏斜
  每个岛屿都有自己做同一件事的方法，这些方法可能会或可能不会发生冲突。
单点故障 (SPOF)
当关键信息只能从一个人那里获得时，就会出现瓶颈。这与总线因素有关，在第2章有更详细的讨论。单点故障可能是出于良好的愿望：我们很容易陷入 "让我来帮你处理"的习惯中。但是，这种方法优化了短期效率（"我做起来更快"），但代价是长期的可扩展性差（团队从未学会如何做需要做的事情）。这种心态也倾向于导致全有或全无的专业知识。
全能或无能的专业知识
一群人被分成 "什么都懂 "的人和新手，几乎没有中间环节。如果专家们总是自己做所有的事情，而不花时间通过指导或记录来培养新的专家，那么这个问题往往就会被强化。在这种情况下，知识和责任继续在那些已经拥有专业知识的人身上积累，而新的团队成员或新手则只能自生自灭，提升得更慢。
鹦鹉学舌
模仿而不理解。其典型特征是在不了解其目的的情况下无意识地复制模式或代码，通常假设上述代码是出于未知原因而需要的。
闹鬼的墓地
通常在代码中，人们避免接触或改变的地方，因为他们担心会出问题。与前面提到的鹦鹉学舌不同，闹鬼的墓地的特点是人们因为恐惧和迷信而避免行动。

在本章的其余部分，我们将深入探讨谷歌的工程组织发现的成功解决这些挑战的策略。

哲学

软件工程可以被定义为多版本程序的多人开发。人是软件工程的核心：代码是一个重要的成果，但只是构建产品的一个小部分。最重要的是，代码不会凭空出现，专业知识也不会凭空出现。每个专家都曾经是新手：一个组织的成功取决于对其员工的成长和投资。

专家的个性化、一对一的建议总是非常宝贵的。不同的团队成员有不同的专业领域，因此，对于任何特定的问题，要问的最佳队友会有所不同。但是，如果专家休假或调换团队，团队就会被抛在脑后。虽然一个人可能能够为一对多的人提供个性化的帮助，但这并不具规模，而且仅限于少量的 "多"。

另一方面，文档化的知识，不仅可以更好地扩展到团队，而且可以扩展到整个组织。诸如团队 wiki 这样的机制使许多作者能够与更大的群体分享他们的专业知识。但是，即使书面文件比一对一的对话更具可扩展性，这种可扩展性也是有代价的：它可能更笼统，不太适用于个别学习者的情况，而且它还需要增加维护成本，以保持信息的相关性和长期的更新。

部落知识存在于各个团队成员所知道的和所记录的内容之间的差距中。人类专家知道这些没有写下来的东西。如果我们把这些知识记录下来并加以维护，那么现在不仅可以让今天的专家一对一地直接接触到这些知识，而且还可以让任何能够找到并查看这些文件的人使用。

因此，在一个神奇的世界里，所有的东西都会被完美地立即记录下来，我们就不需要再去咨询一个人，对吗？并非如此。书面知识有扩展的优势，但有针对性的人类帮助也是如此。人类专家可以综合他们广泛的知识。他们可以评估哪些信息适用于个人的使用案例，确定文档是否仍然相关，并知道在哪里可以找到它。或者，如果他们不知道在哪里可以找到答案，他们可能知道谁可以。

部落知识和书面知识相互补充。即使是一个拥有完美文档的专家团队也需要相互沟通，与其他团队协调，并随着时间的推移调整他们的策略。没有任何一种知识共享方法是所有类型学习的正确解决方案，良好组合的具体内容很可能会根据你的组织而有所不同。机构知识随着时间的推移而演变，对你的组织最有效的知识共享方法可能会随着组织的发展而改变。培训，专注于学习和成长，并建立自己稳定的专家队伍：没有太多的工程专业知识。

设置舞台: 心理安全

心理安全是促进学习环境的关键。

为了学习，你必须首先承认你有不懂的地方。我们应该欢迎这种坦诚，而不是惩罚它。(谷歌在这方面做得很好，但有时工程师不愿意承认他们不明白的东西。）

学习的一个重要部分是能够尝试一些事情，并感觉到失败的安全。在一个健康的环境中，人们对提出问题、犯错和学习新事物感到很自在。这是所有谷歌团队的基本期望；事实上，我们的研究表明，心理安全是一个有效团队的最重要部分。

导师制度

在谷歌，我们试图在 "Noogler"（新的Googler）工程师加入公司时就定好基调。建立心理安全的一个重要方法是为 Noogler 分配一个导师 -- 一个不是他们的团队成员、经理或技术领导的人，其职责明确包括回答问题和帮助 Noogler 提升能力。有一个正式指定的导师可以寻求帮助，这对新人来说更容易，也意味着他们不需要担心会占用同事太多的时间。

导师是在谷歌工作了一年以上的志愿者，他可以就使用谷歌基础设施和浏览谷歌文化等任何问题提供建议。最重要的是，如果被指导者不知道该向谁寻求建议，指导者就会成为一个安全网。导师与被指导者不在同一团队，这可以使被指导者在棘手的情况下更放心地寻求帮助。

导师制度使学习正规化，并促进了学习，但学习本身是一个持续的过程。同事们总是有机会互相学习，无论是加入组织的新员工还是学习新技术的经验丰富的工程师。在一个健康的团队中，队友们不仅愿意回答问题，也愿意提出问题：表明他们不知道的东西，并相互学习。

大群体中的心理安全

向附近的队友寻求帮助比接近一大群大部分的陌生人要容易。但正如我们所看到的，一对一的解决方案并不能很好地扩展。团体解决方案更容易扩展，但它们也更可怕。对于新手来说，形成一个问题并向一个大群体提出，知道他们的问题可能会被存档很多年，这可能是很可怕的。对心理安全的需求在大群体中被放大了。小组的每个成员都要在创造和维持一个安全的环境中发挥作用，以确保新来的人有信心提出问题，而新来的专家感到有能力帮助这些新来的人，而不用担心他们的答案会受到老专家的攻击。

实现这种安全和欢迎的环境的最重要方法是使小组的互动是合作性的，而不是对抗性的。表3-1列出了一些推荐的小组互动模式（以及相应的反模式）的例子。

表 3-1 群体互动模式

推荐的模式 (合作)	反模式 (对抗性)
基本问题或错误被引导到正确的方向上	基本问题或错误被挑剔，问问题的人被责备
解释的目的是为了帮助提问的人学习	解释的目的是为了炫耀自己的知识
回应亲切、耐心、有帮助	回应是居高临下、尖酸刻薄和毫无建设性的
互动是寻找解决方案的共同讨论	互动是有 "赢家" 和 "输家" 的争论

这些反模式可能是无意中出现的：有人可能试图提供帮助，但却意外地居高临下，不受欢迎。我们发现 Recurse 中心的社交规则在这里很有帮助。

不要假装惊讶（"什么？我不相信你不知道这堆东西是什么！"）假装惊讶是心理安全的障碍，使团体成员害怕承认自己缺乏知识
没有 "好的事实"
迂腐的纠正，往往是为了哗众取宠而非精确
不在后座上开车
打断现有的讨论，提供意见，而不投入到对话中
没有微妙的"-主义"（"这是很容易的，我的祖母可以做到！"）小小的偏见表达（种族主义、年龄歧视、恐同症）会使个人感到不受欢迎、不被尊重或不安全

增长你的知识

知识共享从自己开始。重要的是要认识到，你总是有东西要学。下面的准则可以让你增加你自己的个人知识。

提出问题

如果你从本章中只带走一件事，那就是：永远学习，永远提问。

我们告诉 Nooglers，提升速度可能需要六个月左右。这段时间的延长对于在谷歌庞大而复杂的基础设施上的提升是必要的，但它也加强了学习是一个持续的、迭代的过程的想法。初学者犯的最大错误之一是在遇到困难时不寻求帮助。你可能会想独自挣扎一下，或者害怕你的问题 "太简单"、你想 "我只是需要在向别人寻求帮助之前更努力地尝试"。不要落入这个陷阱! 你的同事往往是最好的信息来源：利用这一宝贵资源。

没有神奇的一天，你突然总是知道在任何情况下该怎么做 -- 总是有更多的东西需要学习。在谷歌工作多年的工程师们仍然有他们觉得自己不知道自己在做什么的地方，这没关系！不要害怕说 "我不知道那是什么，你能解释一下吗？" 拥抱不知道的事情，将其作为一个机会的领域，而不是害怕。

无论你是新加入的团队还是高级领导，都不要紧：你应该始终处在一个有东西可学的环境中。如果不是这样，你就会停滞不前（应该找到一个新的环境）。

对于那些担任领导角色的人来说，树立这种行为模式尤为关键：重要的是不要错误地将 "资历" 等同于 "知道一切"。事实上，你知道的越多，你知道你不知道的就越多。公开提出问题或表达知识上的差距，可以加强别人也可以这样做。

在接受问题的一方，在回答问题时的耐心和善意培养了一种环境，使人们感到安全地寻求帮助。让人们更容易克服最初对提问的犹豫，尽早定下基调：伸出手来征求问题，让 "琐碎" 的问题也能轻易得到答案。虽然工程师们可能会自己摸索出部落知识，但他们不是在真空中工作的。有针对性的帮助可以使工程师们更快地提高生产力，这反过来又使他们的整个团队更有效率。

理解背景

学习不仅仅是对新事物的理解，它还包括对现有事物的设计和实施背后的决策的理解。假设你的团队继承了一个已经存在多年的关键信息结构的遗留代码库。原作者早就不在了，而且代码也很难理解。与其花时间学习现有的代码，不如从头开始重写，这很有诱惑力。但是，与其想 "我不明白" 并在那里结束你的想法，不如更深入地思考：你应该问什么问题？

考虑一下 "Chesterson's fence "的原则：在删除或改变某些东西之前，首先要了解它为什么在那里。

在改造事物的问题上，与变形不同，有一个简单明了的原则；这个原则可能会被称为悖论。在这种情况下，存在着某种制度或法律；为了简单起见，让我们说，在一条道路上竖起了栅栏或大门。比较现代的改革者高高兴兴地走到它面前，说："我不知道这有什么用；让我们把它清除掉吧。" 对此，更聪明的改革者会很好地回答。"如果你看不到它的用处，我当然不会让你清除它。走吧，好好想想。然后，当你能回来并告诉我你确实看到了它的用途时，我可能会允许你销毁它。

这并不意味着代码不可能缺乏清晰度，也不意味着现有的设计模式不可能是错误的，但工程师们有一种倾向，即 "这很糟糕！" 比通常所需要的要快得多，特别是对于不熟悉的代码、语言或范式。谷歌也不能幸免于此。找出并理解背景，特别是对于那些看起来不寻常的决定。在你理解了代码的背景和目的之后，考虑你的改变是否仍然有意义。如果有意义，就继续做；如果没有意义，就为未来的读者记录你的理由。

许多谷歌风格指南明确地包括上下文，以帮助读者理解风格指南背后的理由，而不是仅仅记住一串任意的规则。更微妙的是，理解某条准则背后的理由，可以让作者做出明智的决定，知道该准则何时不适用，或者该准则是否需要更新。见第8章。

缩放你的问题: 向社区提问

获得一对一的帮助是高带宽的，但在规模上必然有限。而作为一个学习者，可能很难记住每个细节。帮你未来的自己一个忙：当你从一对一的讨论中学到一些东西时，把它写下来。

未来的新人有可能会有和你一样的问题。也帮他们一个忙，分享你写下的东西。

尽管分享你得到的答案可能是有用的，但不从个人而是从更大的社区寻求帮助也是有益的。在这一节中，我们将研究基于社区的学习的不同形式。这些方法中的每一种 -- 群聊、邮件列表和问答系统 -- 都有不同的权衡，并相互补充。但它们中的每一种都能使知识寻求者从更广泛的同行和专家社区中获得帮助，并确保该社区的当前和未来成员都能广泛获得答案。

小组聊天

当你有一个问题时，有时很难从正确的人那里得到帮助。也许你不确定谁知道答案，或者你想问的人很忙。在这种情况下，群聊是很好的，因为你可以同时向许多人提出你的问题，并与任何有时间的人进行快速的来回对话。作为奖励，群聊中的其他成员可以从问题和答案中学习，而且许多形式的群聊可以自动存档，以后可以搜索。

群聊往往是专门针对主题或团队的。主题驱动的群聊通常是开放的，所以任何人都可以进来问问题。它们倾向于吸引专家，并且可以发展得相当大，所以问题通常会很快得到回答。另一方面，以团队为导向的聊天，往往规模较小，并限制成员。因此，他们可能没有话题驱动型聊天的影响力，但其较小的规模会让新人感觉更安全。

虽然群聊很适合快速提问，但它们没有提供太多的结构，这可能使您很难从一个您没有积极参与的对话中提取有意义的信息。一旦你需要在组外分享信息，或使其可在以后参考，你应该写一份文件或给邮件列表发邮件。

邮件列表

Google 的大多数主题都有一个 topic-users@ 或 topic-discuss@ 的 Google Groups 邮件列表，公司的任何人都可以加入或发送电子邮件。在公共邮件列表上提出问题，就像在群组聊天中提出问题一样：这个问题有很多人可能会回答，任何关注这个列表的人都可以从答案中学习。但与群聊不同的是，公共邮件列表很容易与更多人分享：它们被打包成可搜索的档案，而且电子邮件比群聊提供更多的结构。在谷歌，邮件列表也被编入索引，可以被谷歌的内部网搜索引擎 Moma 索引。

当你发现你在邮件列表上提出的问题的答案时，你可能会很想继续你的工作。不要这样做! 你永远不知道什么时候有人会在未来需要同样的信息，所以把答案发回给列表是一个最佳做法。

邮件列表并不是没有缺点的。它们很适合处理需要大量背景资料的复杂问题，但对于小组聊天所擅长的快速来回交流来说，它们就显得很笨拙。一个关于特定问题的线程通常在它活跃的时候是最有用的。电子邮件档案是不可改变的，而且很难确定在一个旧的讨论主题中发现的答案是否仍然与今天的情况有关。此外，信噪比可能比其他媒介（如正式文件）低，因为某人在其特定工作流程中遇到的问题可能并不适用于你。

谷歌的电子邮件
谷歌的文化是臭名昭著的以电子邮件为中心的。谷歌的工程师们每天都会收到数以百计的电子邮件（如果不是更多的话），其中有不同程度的可操作性。新手们可以花好几天时间来设置电子邮件过滤器，以处理来自他们自动订阅的群组的大量通知；有些人干脆放弃了，不尝试跟上流量了。一些群组将大型邮件列表默认为每一个讨论，而不试图将信息锁定在那些可能对其特别感兴趣的人身上；因此，信噪比可能是一个真正的问题。
谷歌默认倾向于基于电子邮件的工作流程。这并不一定是因为电子邮件是一个比其他通信选项更好的媒介 -- 它往往不是 -- 而是因为这是我们的文化所习惯的。当你的组织考虑要鼓励或投资什么形式的沟通时，请记住这一点。

YAQS: 问题和解答平台

YAQS（"Yes Another Question System"）是谷歌内部的一个类似于 Stack Overflow 的网站，使 Googlers 能够很容易地链接到现有的或正在进行的代码，以及讨论机密信息。与 Stack Overflow 一样，YAQS 分享了邮件列表的许多相同的优点，并增加了完善的功能：标记为有帮助的答案在用户界面上被推广，用户可以编辑问题和答案，以便随着代码和事实的变化，它们保持准确和有用。因此，一些邮件列表已经被 YAQS 所取代，而其他的邮件列表已经演变成更一般的讨论列表，不再专注于解决问题。

扩充你的知识: 你总是有东西可教

教学并不限于专家，专业知识也不是一种二元状态，你要么是新手，要么是专家。专业知识是你所知道的多维矢量：每个人在不同领域都有不同程度的专业知识。这就是为什么多样性对组织的成功至关重要的原因之一：不同的人带来不同的观点和专业知识（见第四章）。谷歌工程师通过各种方式教导他人，如办公时间、举办技术讲座、教授课程、编写文档和审查代码。

办公时间

有时候，有一个人说话真的很重要，在这些情况下，办公时间可以是一个很好的解决方案。办公时间是一个定期安排的活动（通常是每周一次），在此期间，一个或多个人可以回答关于某个特定主题的问题。办公时间几乎从来不是知识共享的首选：如果你有一个紧急的问题，等待下一次会议的答案可能会很痛苦；如果你主持办公时间，它们会占用时间，需要定期宣传。也就是说，它们确实为人们提供了一种与专家当面交谈的方式。如果问题还很模糊，工程师还不知道该问什么问题（比如他们刚开始设计一个新的服务），或者问题是关于某个专业的东西，以至于没有相关的文档，那么这就特别有用。

技术讲座和课程

谷歌拥有强大的内部和外部技术讲座和课程的文化。我们的 engEDU（工程教育）团队专注于向许多受众提供计算机科学教育，包括谷歌工程师和世界各地的学生。在更基层的层面上，我们的g2g（Googler2Googler）计划让 Googlers 报名参加，以举办或参加 Googlers 同伴的讲座和课程。该计划非常成功，有成千上万的 Googlers 参与，教授的主题从技术性的（如 "了解现代CPU的矢量化"）到只是为了好玩（如 "初级摇摆舞"）。

技术讲座通常由一个演讲者直接向听众介绍。另一方面，课堂可以有讲座的成分，但往往以课堂练习为中心，因此需要与会者更积极地参与。因此，与技术讲座相比，教师授课的课程在创建和维护方面通常要求更高、更昂贵，而且只保留给最重要或最困难的主题。也就是说，在一个班级创建之后，它的规模可以相对容易地扩大，因为许多教员可以用同样的课程材料来教课。我们发现，当存在以下情况时，课程往往效果最好:

主题足够复杂，以至于经常出现误解。班级的创建需要大量的工作，所以只有在解决具体需求时才应该开发。
该主题相对稳定。更新课堂材料是一项大量的工作，所以如果该主题快速发展，其他形式的知识共享将有更好的回报。
该主题受益于教师回答问题和提供个性化的帮助。如果学生可以在没有指导帮助的情况下轻松学习，那么像文档或录音这样的自我服务媒介会更有效率。谷歌的一些介绍性课程也有自学版本。
有足够的需求来定期提供课程。否则，潜在的学习者会通过其他方式获得他们需要的信息，而不是等待上课。在谷歌，这对小型的、地理位置偏远的办公室来说尤其是一个问题。

文档

文档是书面知识，其主要目的是帮助读者学习一些东西。并非所有的书面知识都是文档，尽管它可以作为一个纸质线索而有用。例如，我们有可能在邮件列表中找到一个问题的答案，但这个问题的主要目的是寻求答案，其次才是为他人记录讨论。

在这一节中，我们着重于发现贡献和创建正式文件的机会，小到修复错别字，大到记录部落知识等。

关于文档的更全面的讨论，见第10章。

更新文档

第一次学习的时候，是了解现有文档和培训材料可以改进的最好时机。当你吸收并理解了一个新的流程或系统时，你可能已经忘记了 "入门" 文档中的难点或缺少的简单步骤。在这个阶段，如果你发现文件中的错误或遗漏，就把它改正过来吧让营地比你发现的时候更干净，并尝试自己更新文件，即使这些文件是由组织的不同部分拥有的。

在谷歌，工程师们觉得自己有权力更新文档，不管谁拥有它 -- 我们经常这样做 -- 即使是修正一个小的错别字。这种社区维护的水平随着 g3doc 的引入而明显提高，这使得 Googlers 更容易找到一个文档所有者来审查他们的建议。它还留下了一个可审计的修改历史痕迹，与代码的修改历史没有什么不同。

创建文档

随着你的熟练程度的提高，编写你自己的文档并更新现有的文档。例如，如果你建立了一个新的开发流程，记录下这些步骤。然后，你可以让别人更容易地沿着你的道路走下去，把他们指向你的文档。甚至更好的是，让人们自己更容易找到这个文件。任何足以让人无法发现或无法搜索的文件都可能不存在。这是 g3doc 大放异彩的另一个领域，因为文档可预测地位于源代码旁边，而不是在某个（无法找到的）文档或网页上。

最后，确保有一个反馈的机制。如果没有简单直接的方法让读者指出文档过时或不准确，他们很可能懒得告诉别人，而下一个新来者也会遇到同样的问题。如果人们觉得有人会真正注意到并考虑他们的建议，他们就会更愿意做出改变。在谷歌，你可以直接从文档本身提交一个文档错误。

此外，Googlers 可以很容易地在 g3doc 页面上留下评论。其他 Googlers 可以看到并回复这些评论，而且，由于留下评论会自动为文档的所有者归档一个错误，读者不需要弄清楚该与谁联系。

推广文档

传统上，鼓励工程师记录他们的工作是很困难的。编写文档需要花费时间和精力，而这些时间和精力本可以用在编码上，而且这些工作所带来的好处并不直接，大部分是由其他人获得的。鉴于许多人可以从少数人的时间投资中获益，像这样的不对称权衡对整个组织来说是好的，但如果没有好的激励措施，鼓励这样的行为是很有挑战性的。我们在第 57 页的 "激励和认可" 一节中讨论了其中的一些结构性激励。

然而，一个文档作者往往可以直接从写文档中受益。假设团队成员总是向你寻求帮助，以调试某些类型的生产故障。编写文档需要前期投入时间，但在这项工作完成后，你可以在未来节省时间，指点团队成员看文档，并在需要时才提供动手帮助。

编写文档也有助于你的团队和组织的发展。首先，文档中的信息会被规范化，成为一种参考：团队成员可以参考共享的文档，甚至可以自己更新它。其次，规范化的内容可能会传播到团队之外。也许文档中的某些部分对团队的配置来说并不独特，对其他想要解决类似问题的团队来说是有用的。

代码

在元层面上，代码就是知识，所以写代码的行为可以被认为是一种知识转录的形式。虽然知识共享可能不是生产代码的直接目的，但它往往是一个新兴的副作用，这可以通过代码的可读性和清晰度来促进。

代码文档是分享知识的一种方式；清晰的文档不仅有利于库的消费者，而且也有利于未来的维护者。同样地，实现注释也能跨时空传递知识：你写这些注释是明确为了未来的读者（包括未来的你！）。就权衡利弊而言，代码注释和一般的文档一样有缺点：它们需要积极维护，否则很快就会过时，任何读过与代码直接矛盾的注释的人都能证明这一点。

代码审查（见第9章）对作者和审查者来说都是一个学习机会。例如，审查者的建议可能会给作者带来新的测试模式，或者审查者可能会通过看到作者在他们的代码中使用一个新的库而了解到它。谷歌通过代码审查的可读性过程将指导工作标准化，这在本章末尾的案例研究中详细介绍。

扩展你的组织的知识

随着组织的发展，确保专业知识在整个组织内得到适当的共享变得更加困难。有些事情，比如文化，在每个成长阶段都很重要，而其他事情，比如建立规范的信息来源，可能对更成熟的组织更有利。

培养知识共享的文化

组织文化是许多公司事后才考虑的软弱的人的东西。但在谷歌，我们相信首先关注文化和环境比只关注该环境的产出（如代码）会带来更好的结果。

进行重大的组织转变是很困难的，关于这个主题的书已经不计其数。我们并不假装拥有所有的答案，但我们可以分享谷歌为创造一个促进学习的文化而采取的具体步骤。

请参阅《工作规则！》(英文名 Work Rules)一书，了解对谷歌文化的更深入研究。

尊重

仅仅几个人的不良行为就可以使整个团队或社区变得不受欢迎。在这样的环境中，新手会学会把问题带到别的地方去，而潜在的新专家会停止努力，没有成长的空间。在最糟糕的情况下，小组会减少到最毒的成员。要从这种状态中恢复过来是很困难的。

知识共享可以而且应该以仁慈和尊重的态度进行。在科技界，对 "聪明的混蛋" 的容忍--或者更糟糕的是，崇敬--既普遍又有害，但成为专家和善良并不相互排斥。谷歌软件工程职位阶梯中的领导力部分清楚地概述了这一点。

虽然在较高的级别上需要一定的技术领导力，但并非所有的领导力都是针对技术问题的。领导者可以提高周围人的素质，改善团队的心理安全，创造团队工作和协作的文化，化解团队内部的紧张关系，为谷歌的文化和价值观树立榜样，并使谷歌成为一个更有活力和令人兴奋的工作场所。笨蛋不是好领导。

这种期望是由高级领导层示范的。Urs Hölzle（技术基础设施高级副总裁）和Ben Treynor Sloss（副总裁，谷歌SRE的创始人）写了一份经常被引用的内部文件（"No Jerks"），讲述了为什么谷歌人应该关心工作中的尊重行为以及如何做。

激励和认可

良好的文化必须积极培育，而鼓励知识共享的文化需要承诺在系统层面上认可和奖励它。对于组织来说，口口声声宣扬一套价值观，却积极奖励不执行这些价值观的行为，是一个常见的错误。人们对激励措施的反应超过了陈词滥调，因此，通过建立一个补偿和奖励系统，把钱放在你的嘴里是很重要的。

谷歌使用了各种认可机制，从全公司的标准，如绩效审查和晋升标准到谷歌员工之间的同行奖励。

我们的软件工程阶梯，我们用它来校准整个公司的报酬和晋升等奖励，通过明确指出这些期望来鼓励工程师分享知识。在更高的级别上，阶梯明确指出了更广泛影响的重要性，而且这种期望随着资历的增加而增加。在最高级别上，领导力的例子包括以下内容:

通过担任初级员工的导师来培养未来的领导者，帮助他们在技术上和谷歌的角色上得到发展
通过代码和设计审查、工程教育和发展以及对该领域其他人的专家指导，维持和发展谷歌的软件社区

关于领导力的更多内容，请参见第5章和第6章。

工作阶梯的期望是一种自上而下引导文化的方式，但文化也是自下而上形成的。在谷歌，同行奖金 (Peer Bonus)计划是我们拥抱自下而上文化的一种方式。同行奖金是一种货币奖励和正式认可，任何谷歌人都可以将其授予任何其他谷歌人，以表彰其超越的工作。例如，当 Ravi 给 Julia 发了一个同行奖金，因为她是一个邮件列表的顶级贡献者--定期回答问题，使许多读者受益--他是公开承认她的知识共享工作及其对团队的影响。由于同级奖金是由员工驱动的，而不是由管理层驱动的，因此它们可以产生重要而强大的基层效应。

与同级奖金相似的是嘉奖：对贡献的公开承认（通常比那些值得同级奖金的贡献要小），提高了同级贡献的知名度。

当一个 Googler 给另一个 Googler 一个同行奖金或嘉奖时，他们可以选择在奖励邮件上抄送其他团体或个人，以提高对同行工作的认可。收件人的经理也通常会将奖励邮件转发给团队，以庆祝彼此的成就。

一个人们可以正式和容易地认可他们的同行的系统是一个强大的工具，可以鼓励同行继续做他们所做的了不起的事情。重要的不是奖金：而是同行的认可。

建立规范的信息源

典型的信息源是集中的、全公司范围内的信息库，它提供了一种标准化和传播专家知识的方法。它们对与组织内所有工程师相关的信息效果最好，否则容易出现信息孤岛。例如，建立一个基本的开发者工作流程的指南应该成为经典，而运行一个本地 Frobber 实例的指南则只与从事 Frobber 工作的工程师有关。

与维护更多的本地化信息（如团队文档）相比，建立规范的信息来源需要更多的投资，但它也有更广泛的好处。为整个组织提供集中的参考信息，使广泛需要的信息更容易找到，更容易预测，并解决信息碎片化的问题，因为当多个团队在处理类似的问题时，会产生他们自己的--通常是冲突的指南。

由于标准信息是高度可见的，并且旨在提供组织层面的共同理解，因此内容由主题专家积极维护和审核是非常重要的。一个主题越是复杂，规范内容有明确的所有者就越是关键。善意的读者可能会发现某些内容已经过时，但却缺乏专业知识来进行必要的重大结构性修改，即使工具可以很容易地建议更新。

创建和维护集中的、规范的信息来源是昂贵和耗时的，而且不是所有的内容都需要在组织层面上共享。当考虑在这个资源上投入多少精力时，要考虑你的受众。谁从这些信息中受益？你吗？你的团队？你的产品领域？所有的工程师？

开发者指南

谷歌为工程师提供了一套广泛而深入的官方指导，包括风格指南、官方软件工程最佳实践、代码审查和测试指南，以及每周提示（TotW）。

这个信息库是如此之大，以至于期望工程师从头到尾读完它是不切实际的，更不用说能够一次吸收这么多信息了。相反，已经熟悉某项准则的人类专家可以将一个链接发送给其他工程师，后者可以阅读参考资料并了解更多。专家不需要亲自解释公司范围内的做法，从而节省了时间，而学习者现在知道有一个值得信赖的信息的典型来源，他们可以在必要时访问。这样一个过程可以扩展知识，因为它使人类专家能够通过利用共同的、可扩展的资源来识别和解决特定的信息需求。

go/links

go/links（有时被称为goto/链接）是谷歌的内部 URL 缩短器。

大多数谷歌内部参考资料至少有一个内部go/link。例如，"go/spanner" 提供关于 Spanner 的信息，"go/python" 是谷歌的 Python 开发者指南。这些内容可以存在于任何资源库中（g3doc、Google Drive、Google Sites 等），但有一个指向它的 go/link 提供了一种可预测的、可记忆的访问方式。这产生了一些很好的好处。

go/link 是如此之短，以至于很容易在谈话中分享它们（"你应该检查一下go/frobber！"）。这比去找一个链接，然后给所有感兴趣的人发一个信息要容易得多。有一个低摩擦的方式来分享参考资料，使得这些知识更有可能首先被分享。
go/link 提供内容的固定链接，即使底层的 URL 改变了。当所有者将内容移到不同的资源库（例如，将内容从 Google doc 移到 g3doc），他们可以简单地更新 go/link的目标 URL。go/link 本身保持不变。

go/link 在谷歌文化中如此根深蒂固，以至于出现了一个良性循环：一个寻找 Frobber 信息的谷歌用户可能会先查看 go/frobber。如果 go/link 没有指向 Frobber 开发者指南（如预期），Googler 一般会自己配置链接。因此，Googler 通常可以在第一次尝试时猜出正确的 go/link。

代码培训

谷歌代码实验是有指导性的实践教程，通过结合解释、最佳实践示例代码和代码练习，向工程师传授新的概念或流程。在go/codelab网站上，可以看到谷歌广泛使用的技术的典型代码集。这些代码集在出版前经过了几轮正式的审查和测试。Codelabs是介于静态文档和教师授课之间的一个有趣的中间点，它们分享了两者的最好和最坏的特点。它们的实践性使它们比传统的文档更有吸引力，但工程师仍然可以按需访问它们，并自行完成；但它们的维护费用很高，而且不是针对学习者的具体需求。

静态分析

静态分析工具是分享可以通过编程检查的最佳实践的有力方式。每种编程语言都有其特定的静态分析工具，但它们有相同的一般目的：提醒代码作者和审查者注意可以改进代码以遵循风格和最佳实践的方法。有些工具更进一步，提供自动将这些改进应用到代码中。

关于静态分析工具的细节以及它们在 Google 的使用情况，见第20章。

设置静态分析工具需要前期的投资，但只要它们到位，就能有效地扩展。当最佳实践的检查被添加到一个工具中时，每个使用该工具的工程师都会意识到该最佳实践。这也使工程师们可以腾出时间来教其他东西：原本用于手动教授（现在是自动的）最佳实践的时间和精力，可以用来教授其他东西。静态分析工具增强了工程师的知识。它们使一个组织能够应用更多的最佳实践，并比其他方式更一致地应用它们。

留在圈内

有些信息对一个人的工作至关重要，例如知道如何进行典型的开发工作流程。其他的信息，比如流行的生产力工具的更新，虽然不那么关键，但仍然有用。对于这种类型的知识，信息共享媒介的正式性取决于所传递信息的重要性。例如，用户希望官方文档保持更新，但通常对通讯内容没有这样的期望，因此通讯内容对所有者的维护和保养的要求较低。

新闻简报

谷歌有许多公司范围内的新闻简报，包括 EngNews（工程新闻）、Ownd（隐私/安全新闻）和 Google's Greatest Hits（本季度最有趣的故障报告），都会发送给所有工程师。这些都是传达工程师感兴趣但并非关键任务的信息的好方法。对于这种类型的更新，我们发现，如果通讯发送的频率较低，并且包含更多有用的、有趣的内容，就会得到更好的参与。否则，通讯会被认为是垃圾邮件。

尽管大多数谷歌新闻通讯是通过电子邮件发送的，但有些新闻通讯的发送方式更有创意。厕所里的测试（测试提示）和厕所里的学习（生产力提示）是张贴在厕所里的单页新闻通讯。这种独特的发送媒介帮助《厕所里的测试》和《厕所里的学习》从其他新闻通讯中脱颖而出，而且所有期刊都在网上存档。

参见第11章，了解《厕所里的测试》的诞生历史。

社区

Googlers喜欢围绕各种主题形成跨组织的社区来分享知识。这些开放的渠道使你更容易从你的直接圈子以外的人那里学习，避免信息孤岛和重复。谷歌群组尤其受欢迎。谷歌有数以千计的内部小组，其正式程度各不相同。有些是专门用于故障排除的；其他的，如代码健康组，更多的是用于讨论和指导。内部的 Google+ 作为非正式信息的来源，在 Googlers 中也很流行，因为人们会发布有趣的技术故障或他们正在进行的项目的细节。

可读性:标准化的指导通过代码审查

在谷歌，"可读性" 指的不仅仅是代码的可读性；它是一个标准化的、在谷歌范围内传播编程语言最佳实践的指导过程。可读性涵盖了广泛的专业知识，包括但不限于语言习语、代码结构、API 设计、通用库的适当使用、文档和测试覆盖率。

可读性最初是一个人的努力。在 Google 的早期，Craig Silverstein（雇员编号3）会亲自和每个新员工坐下来，对他们的第一次主要代码提交进行逐行的 "可读性审查"。这是一个吹毛求疵的审查，涵盖了从代码可以改进的方式到白色空格惯例的一切。这给了谷歌的代码库一个统一的外观，但更重要的是，它教授了最佳实践，强调了哪些共享基础设施是可用的，并向新员工展示了在谷歌写代码是什么样子。

不可避免的是，谷歌的招聘速度越来越快，超出了一个人的能力范围。如此多的工程师发现这个过程很有价值，于是他们自愿拿出自己的时间来扩大这个项目。今天，大约有 20% 的谷歌工程师在任何时候都在参与可读性过程，他们要么是审查员，要么是代码作者。

什么是可读性流程

在谷歌，代码审查是强制性的。每个变更列表（Change List）都需要可读性批准，这表明拥有该语言的可读性认证的人已经批准了该 CL。经过认证的作者隐含地对他们自己的 CL 提供可读性批准；否则，一个或多个合格的审查员必须明确地对 CL 提供可读性批准。这项要求是在谷歌发展到无法强制要求每个工程师接受代码审查，以达到所需的严格程度的最佳实践之后增加的。

请参阅第9章，了解谷歌代码审查过程的概述以及批准在这里的含义。

在谷歌内部，拥有可读性认证通常被称为一种语言的 "可读性"。拥有可读性的工程师已经证明了他们一直在写清晰、成语和可维护的代码，这些代码体现了谷歌对特定语言的最佳实践和编码风格。他们通过可读性程序提交 CL，在此过程中，一个集中的可读性审查员小组审查 CL，并就它在多大程度上展示了各个领域的掌握程度给出反馈。随着作者对可读性准则的内化，他们收到的对其 CL 的评论越来越少，直到他们最终从这个过程中毕业并正式获得可读性。可读性带来了更多的责任：拥有可读性的工程师被信任，可以继续将他们的知识应用到自己的代码中，并担任其他工程师的代码的审查员。

大约 1-2% 的谷歌工程师是可读性审查员。所有审查员都是志愿者，欢迎任何具有可读性的人自荐成为可读性审查员。可读性审查员被要求达到最高标准，因为他们不仅要有深厚的语言专业知识，还要有通过代码审查进行教学的能力。他们被期望把可读性首先作为一个指导和合作的过程，而不是一个把关或对抗的过程。我们鼓励可读性审查员和 CL 作者在审查过程中进行讨论。审稿人为他们的评论提供相关的引文，这样作者就可以了解制定文体指南的理由（"切斯特森的篱笆"）。如果任何特定准则的理由不清楚，作者应该要求澄清（"提问"）。

可读性特意是一个由人类驱动的过程，旨在以标准化而又个性化的方式来扩展知识。作为书面知识和部落知识的互补混合体，可读性结合了书面文件的优势，可以通过可引用的参考文献来获取，也结合了人类专家评审员的优势，他们知道应该引用哪些指南。典范指南和语言建议被全面地记录下来--这很好！--但信息的语料库太大，以至于它可能被压倒，特别是对新人来说。

为什么要有这个过程

代码被阅读的次数远远多于被编写的次数，这种效果在谷歌的规模和我们的（非常大的）单体代码库被放大了。任何工程师都可以查看并学习其他团队的代码知识财富，而像Kythe这样强大的工具使得在整个代码库中寻找参考资料变得很容易（见第17章）。记录在案的最佳实践（见第8章）的一个重要特征是，它们为所有谷歌代码提供了一致的标准，使其得以遵循。可读性既是这些标准的执行机制，也是传播机制。

可读性的主要优势之一是，它让工程师接触到的不仅仅是他们自己团队的部落知识。为了获得特定语言的可读性，工程师们必须将 CL 发送给一组集中的可读性审查员，这些审查员在整个公司内审查代码。集中化的过程做了一个重要的权衡：程序被限制在线性扩展，而不是随着组织的增长而次线性扩展，但它使执行一致性更容易，避免了孤岛，并避免（通常是无意的）偏离既定的规范。

整个代码库的一致性的价值怎么强调都不为过：即使有成千上万的工程师在几十年里编写代码，它也能确保特定语言的代码在整个语料库中看起来是相似的。这使读者能够专注于代码的作用，而不是被为什么它看起来与他们习惯的代码不同而分散注意力。大规模的变更作者（见第22章）可以更容易地在整个语料库中进行变更，跨越成千上万个团队的界限。人们可以更换团队，并确信新的团队使用特定语言的方式不会与他们以前的团队有很大的不同。

这些好处伴随着一些代价：与文档和类等其他媒介相比，可读性是一个重量级的过程，因为它是强制性的，并由谷歌工具化强制执行（见第19章）。这些成本是非同小可的，包括以下几点:

对于那些没有任何团队成员具备可读性的团队来说，增加了摩擦，因为他们需要从团队之外寻找审查员来对 CL 进行可读性审批。
对于需要可读性审查的作者来说，有可能需要额外的几轮代码审查。
作为一个由人驱动的过程，其扩展的缺点。由于它依赖于人类审查员进行专门的代码审查，因此对组织增长的线性扩展有限。

那么，问题是，这些好处是否超过了成本。还有一个时间因素：效益与成本的全部影响不在同一时间尺度上。该计划特意权衡了短期代码审查延迟和前期成本的增加，以换取更高质量的代码、资源库范围内的代码一致性和工程师专业知识的增加等长期回报。效益的时间尺度较长，因为人们期望编写的代码有几年甚至几十年的潜在寿命。

与大多数--也许是所有的工程过程一样，总是有改进的余地。一些成本可以通过工具化来减轻。一些可读性评论涉及的问题可以通过静态分析工具静态检测并自动进行评论。随着我们对静态分析的不断投资，可读性审查员可以越来越多地关注更高层次的领域，比如一个特定的代码块是否可以被不熟悉代码库的外部读者所理解，而不是像某行是否有尾部空白这样的可自动检测。

但光有愿望是不够的。可读性是一个有争议的项目：一些工程师抱怨说这是一个不必要的官僚主义障碍，是对工程师时间的糟糕利用。可读性的权衡是值得的吗？为了找到答案，我们求助于我们可信赖的工程生产力研究（EPR）团队。

EPR 团队对可读性进行了深入的研究，包括但不限于人们在毕业后是否受到过程的阻碍，学到了什么，或者改变了他们的行为。这些研究表明，可读性对工程速度有一个净的积极影响。与不具备可读性的作者相比，具备可读性的作者所做的 CL 在统计学上大大减少了审核和提交的时间。拥有可读性的工程师与不拥有可读性的工程师相比，自我报告的对其代码质量的满意度（缺乏对代码质量的更客观的衡量标准）更高。绝大多数完成该计划的工程师对这一过程表示满意，并认为这是值得的。他们报告说，在编写和审查代码时，他们向审查员学习，并改变自己的行为以避免可读性问题。