雷锋网按：本文作者Edmond Lau，公号“董老师在硅谷”翻译首发。
我作为面试官最喜欢问工程师的问题是：在他们以前的公司，他们喜欢和不喜欢的关于工程师文化的事是什么？我采访了500多人——其中许多来自顶尖高科技公司，如Facebook，谷歌，亚马逊，Palantir，和Dropbox，随着时间的推移，这种面试问题也告诉我：优秀工程师喜欢的和尽量避免的地方。根据采访答复和我个人经验，从过去七年跨越谷歌，Ooyala和Quora的工作，我总结出为建立一个良好的工程文化，一个团队可以做的十件事情。
快速迭代有助于提高工作积极性和兴奋度。一些工程师在面试时说到他们离开公司的原因，其中最常见的也最令人沮丧的是基础设施和繁冗流程阻碍他们部署代码或者上线功能。
在组织上，快速迭代让工程师和设计师更灵活自主地作日常决策。我在谷歌，任何用户可见的搜索结果改变，即使是低流量的实验，也需要玛丽莎·梅耶在每周UI审查批准。虽然这允许谷歌保护它的搜索品牌，但它明显阻碍了创新。优化迭代速度也意味着，按照明确定义的流程推出产品，避免投入大量时间后意外发生。
优化迭代速度意味着建立持续部署以快速验证，提高测试覆盖率，减少构建和网站宕机次数，快速单元测试，并鼓励大家来运行，快速增量编译和重新加载，以缩短开发时间。持续部署，提交到线上特别重要。比如在Quora它提供的迭代速度至少在小工程队利大于弊（线上出错的风险）。人们更兴奋地看到功能和修复Bug是因为很快看到了实时流量的变化。这要比超过一周或成批的代码提交，要更容易推断和精确定位错误源的位置。
团队智慧，快速迭代的速度意味着有强有力的领导者，帮助协调和推动团队的工作。在决定关键点上负责人需要有效地作出决定，并承诺他们的选择。借用比尔·沃尔什（领导49人队3次进超级碗）的一句话：强有力的领导者需要“承诺，引爆，恢复”，这意味着承诺攻击计划，执行它，然后看反应结果。优柔寡断的团队只会导致个人努力白费。
在技术讲座“规模化Instagram”上，Instagram的联合创始人迈克·克里格引“优化最少的操作负担”作为一个重要的教训，领导他的13人团队将用户增长到几千万。 产品的增长意味每个工程师的操作负担加重，如用户跟工程师或者特定功能跟工程师的比率。 像Facebook号称每个工程师支持超过100万的用户比例指标。
自动化解决方案和让脚本去重复执行任务很重要，因为它们解放工程团队，让他们为实际产品工作。确保在流量高峰期，如果有服务失败并自动重启的情况下，能找到替代者是管理大而复杂产品的明智方案。在短期内可以对应用做快速修复，而长期还是要依赖自动化测试，这需要权衡。
Etsy的座右铭是“衡量所有，衡量一切”。支持像开源监控和制图工具graphite和statsd突出自动化 -——即自动化必须由数据和监控驱动。如果没有监控和日志你怎么知道什么事情错了，为什么错。自动化是困难的。一个后续的座右铭是“衡量所有，衡量一切，并尽可能自动化。”
我的麻省理工学院教授和本科生研究顾问丹尼尔·杰克逊说的软件抽象的重要性：
"选择正确的方式，程序化自然而然地设计;模块化就是有小而简单的界面; 新功能在不影响全局的情况下产生。要是搞错的话，程序将是一系列的讨厌的坑：接口很笨拙因为他们无法适应一些意料之外的交互，即使是最简单的改动也将很难维护。"
在谷歌，什么让数千名工程师建立可扩展的系统——因为他们有非常聪明的工程师像杰夫·迪恩和桑杰·格玛沃特，创建了简单但丰富的抽象，如MapReduce，SSTable，Protocol Buffer等。什么让Facebook工程这么支持大规模——是因为专注于核心，同样喜欢抽象和简单，Thrift, Scribe, Hive。是什么让设计人员能够在Quora有效构建产品，Webnode，Livenode也是基于同样的理解。
保持核心抽象的简单和减少自定义解决方案并增加团队熟悉度和对专业知识的抽象。日益普及的系统像Memcached，Redis，MongoDB等都是降低建立定制存储和缓存系统的必要性。团队重点转移到少数核心抽象，而不是分裂在很多临时解决方案，让公共库更稳健，监控更智能，性能更易理解，测试更全面。所有这一切都有助于搭建一个简单的系统，降低操作负担。
维持高品质的代码库增加了整个工程团队的工作效率。整齐的代码更容易便捷发展和维护，更适应变化，不容易引入错误。健康的代码审查过程使之成为可能。
建立及时代码审查流程，不管是预提交或提交后，代码审查有很多必要性。首先，知道有人会检查你的代码，提交写得不好的代码可能会辜负你的队友。那些难以维护，或未经测试的代码是一种压力。第二，代码审查也提供了评审和相互学习编写更好代码的机会。
代码审查更容易接触到其他工程团队成员，评论也有很多促进作用：
a）增进一段时间内审查代码的责任感；
b）允许团队成员——特别新手——观摩别人的好代码；
c）加快最佳编码实践的传播。
有种说法，灵活的团队没多少时间花费在代码审查而忽视了技术债务，可以很容易地从写得不好的代码积累。 Ooyala公司，在创业早期就为了完成尽可能多的功能而忽略代码审查;其结果是，虽然最初的产品更迅速地拥有了市场，但代码修改变得很痛苦，我们花了一年多时间仅仅是改写脆弱的代码，以偿还技术债务。
谷歌预先对所有的代码进行审查，但规模较小的团队并不需要那么全面和严格，因为不是所有的代码都需要使用相同的标准审查。 Ooyala公司后来采取了措施——通过电子邮件通知核心处危险的变化。在Quora，我们用Phabricator对所有的代码进行审查，大多后提交，并采用了不同的标准模型，比如控制器代码和视图代码; 对于敏感的代码或新工程师的代码，我们要么做预提交的评论或试图在几个小时内去被提交的代码中查看它们。
同事之间的尊重构成开放交流的基础。靠谱的想法往往通过大家的辩论获得，这种挑战也是令人感觉很舒服的方式。人们不爽的是重要反馈没有及时回应。
1948年，亚历克斯·奥斯本概述了过去几十年中在工作环境中流行的方法：参与者走到一起，抛开批评和负面的反馈，共同凝聚在一起不用担心被评判，头脑风暴会议。最近的心理学研究已经开始推翻奥斯本的做法，表明在头脑风暴会议中，鼓励辩论实际上避免了群体思维并产生了更有效的思路。鉴于这一研究，一个相互尊重的环境变得更加重要，攻击仅仅是观点上的而不是针对个人。
工程往往跨越广泛的领域（系统，机器学习，产品等），而不是每个人在每个领域都有相同的专业知识。其实一个强大的团队应该具备：在某些领域都有能干的牛人，即使他们最终会被替代。这有时很麻烦，让一个系统工程师来评估产品工程师的能力，但在一个健康的工程师文化中，尊重这些差异很重要，而不是完全根据自己的优势来判断。
虽然有些人很自然地就精通代码库或基础设施的各个部分，但没有一个人可以觉得他们拥有其中任何一件或者是某一件的唯一维护者。虽然有人能在一些领域成为专家，在短期内有成效，但这种做法最终伤害长期利益。
在组织上，共享代码所有权提供了三个好处。
首先，保持因子8大于1可以减轻压力和降低团队维护者离开的风险。这也使人很难在休息时间无忧。我清楚记得，当我在夏威夷火山上徒步旅行度假时，得到报警，因为我是公司的日志处理器的唯一维护者。
其次，共享所有权让工程师不限制在特定区域，以促进新的见解。它让工程师们从某些项目上解放出来，并鼓励他在多样的项目上工作，这有助于保持工作的趣味性，并提升员工学习的积极性。从长远来看，它降低了组织风险——一些工程师一旦感到停滞将会决定离开。
第三，共享所有权还设置了多个团队成员聚焦在高优先级的问题上（敏捷开发的一种），为更迅速地完成战略目标奠定了基础。而孤立的所有权，责任通常落在一两个人肩上。
很多工程组织犯的错误是为时过早地将整个团队分成子团队。子团队会形成责任的阻碍，并很难去打破所有权的墙，因为个人可能会被其子团队的目标进行评估。 Ooyala有很多小团队，我很珍惜与一些其他团队的工作机会;他们使用敏捷开发，重心放在共享代码所有权，使得工作幸福感和生产力更佳。 在Quora的初期，我喜欢的一个方面是这里更强调项目而不是团队，让我有机会合作很多不同项目：从用户增长，机器学习，工具，推荐，分析，网站的速度，和垃圾检测都有。
单元测试和集成测试覆盖率是管理一个大的代码库与一大群人或产品的唯一可扩展的方式。自动化测试提供了对提高代码质量的大规模重构的信心和有意义的保护。缺乏严格的自动化测试，需要手动测试无论是对工程团队还是外包测试团队，都是令人害怕的，很容易形成恐惧改善代码的文化，因为它有可能破坏原有代码秩序。
在实践中，自动化测试是对持续部署工作团队成长的要求。代码库规模随着时间的推移增长，但熟悉的代码库的数量会随团队成员新人加入而减少。测试和验证最容易被原代码作者完成，因为在他们脑子里还是清晰的，而不是稍后几个月或几年才尝试修改代码的人。鼓励单元测试是让作者为自己的工作负责。
Gmail是保罗·布赫海特的20％的项目，第一个版本在一天搞定。 谷歌新闻，谷歌公交，和谷歌建议也是推出的20％的项目。我用20％的时间，在谷歌写一个Python框架，使得它更容易建立搜索页面演示。而谷歌的20％的时间在创业初期可能降低生产力，但是让工程师们花20％的时间在做某件事情而不是他们的固有的产品规划，仍然是小型工程组织的创新摇篮。
Ooyala公司没有正式的20％的时间，但我花了一些，写了一个命令行构建工具Flex和ActionScript，加快了团队构建时间。正当Adobe的Flex Builder工具降级之时我完成了它，在工程团队超过两倍大小时该工具仍然在使用。 Atlassian公司在尝试一年后通过20％的时间。Facebook和Ooyala公司后来又增加了一个20%时间：是周期性的黑客比赛——规则是，你可以做任何东西，除了你的正常项目的工作。
自上而下对产品进行规划，对公司的总体方向是重要的，不能指望从工程师中冒出很多的想法。只有工程师对他们20％的时间和专注的项目有负责任的态度，这些项目有很大的向前发展的可能。没有官方的20％的时间，它仍然是可能的，但是对工程师和设计师来说有可能去尝试疯狂的想法——也基本上都找周末或假期做。
持续学习和得到充分的挑战是必须的，因为心理学教授米哈里·米哈伊称所谓的“心流”表明，一个人完全集中在他们做的事情上，甚至会忘记了时间。 但直接即时的反馈能够适应更快的迭代。
每周技术会议为工程师分享他们的设计或正做的项目创造了一个机会，工程师们为他们的工作感到自豪，并学到了更多工作以外的内容。内部文档记录电子邮件服务的工作原理或如何让排名改变搜索服务，让工程师学习和探索新的东西，也很好地补充了20％的时间。在Quora，我们通过内部运行Quora去问产品和发展有关的问题。
建设学习文化的一个办法是注重指导和培训，以确保每个人都掌握基本的算法，系统和产品成功所必需的技能。工程组织的成长，花在招聘（尤其是高校招聘）越多，需要投入到指导和培训的努力也要更多。一个导师每天花1个小时来指导新员工前4周工作似乎是很大负担，但投资是总时间不到一年的1％，这也是决定新员工是否成功的关键。
雇佣最好的人是以上列出的所有方法的基础。如果你认为自己是一个B级工程师很难有人尊重。如果你不信任他们开发产品的能力，很难给别人自主权去开发产品。如果没有足够的工程经验，很难识别正确的抽象去构建系统。这很容易陷入构建复杂结构的陷阱，又没有其他聪明人来挑战你的想法和推动你走向简单正确的道路。
在硅谷的史蒂夫·乔布斯曾说，"A等人聘请A等队员。 B等人聘请C等人。"关注招聘和雇佣合适的人很难，但这对工程组织有效增长很关键。黄易山，是前Facebook一个工程经理和总监，认为招聘必须是工程组织的首要任务，不只是管理者，工程师也如此。 他也正确地指出“雇佣最好的”和“雇用你面试过的最佳人选”的区别。
在Ooyala的初期，我们在客户工作上不堪重负，我们很想降低我们的招聘门槛，这样我们可以聘请足够的人来做大量工作。我很高兴我们没有，因为低质量的代码和较弱的工程师团队积累技术债对团队和产品的伤害是很大的。
建立一个良好的工程文化无疑是一个大量的工作，但由此产生的工作环境是值得的。
正在生成分享图...
张进