谷歌软件工程之道-2

《Software Engineering at Google》：

• 如何融入团队
• 知识共享

EN: https://abseil.io/resources/swe-book/html/toc.html

CN: https://qiangmzsx.github.io/Software-Engineering-at-Google/#/

一个好的事后总结应该包括以下内容：

• 事件的简要概述
• 事件的时间线，从发现、调查到解决的过程
• 事件的主要原因
• 影响和损害评估
• 一套立即解决该问题的行动项目（包括执行人）。
• 一套防止事件再次发生的行动项目
• 经验教训

这个也可以是一次很好的技术分享的路径，把 “事件” 换成 “问题” 即可。

工程本质上是关于权衡的。 除非你有一个不变的环境和完美的知识，否则你不可能一直对所有事情都是正确的，所以当有新的证据时，你当然应该改变你的最初想法。 谨慎选择你的战斗：要想让别人正确地听取你的意见，你首先需要倾听别人的意见。最好在下定决心或坚定地宣布决定之前进行倾听——如果你不断地改变主意，人们会认为你不坚定。

几乎任何规模的软件工作的基础都是一个运作良好的团队。尽管软件开发者单打独斗的 “天才神话 “仍然存在，但事实是，没有人能够真正地单干。一个软件组织要想经受住时间的考验，就必须有一种健康的文化，植根于谦逊、信任和尊重，围绕着团队而不是个人。 此外，软件开发的创造性要求人们承担风险并偶尔失败；为了让人们接受这种失败，必须有一个健康的团队环境。

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

在接收端，在回答问题时的耐心和善意培养了一种环境，使人们感到安全地寻求帮助。 让人们更容易克服最初对提问的犹豫不决，尽早定下基调：主动征求问题，让即使是“琐碎”的问题也能轻松得到答案。 虽然工程师们可能会自己摸索出内部知识，但他们不是在真空中工作的。有针对性的帮助可以让工程师更快地提高工作效率，从而使整个团队的工作效率更高。

在移除或改变某些东西之前，首先要了解它为什么存在。

在你了解了代码的背景和目的之后，考虑你的改变是否仍然有意义。如果有意义，就继续做；如果没有意义，就为未来的继任者记录下你的理由。

这个很难得，对从业者的素质是有很高的要求的，凡事总得有人起头，我依然坚信，从自己做起，是可以改变世界的。