打造工程师文化可以做十件事.pdf

打造工程师文化可以做的十件事 我作为面试官最喜欢问工程师的问题是要告诉我在他 以前的公司 ，他 喜欢和不喜欢的关于工程 师文化的事。我采访了很多人 – 其中许多来自顶尖高科技公司 ，如 Faceboo k ，谷歌 ，亚 马逊 ，Pint erest - 随着时间的推移 ，这种面试问题也告诉我优秀工程师喜欢和尽量避免地方。根据 采访答复和我个人经验 ，我总结了为建立一个良好的工程文化一个团队可以做的十件 事情。 1. 优化迭代速度。快速迭代的速度提高了工作积极性和兴奋度。一些工程师在面试时对他 为什么 要离开公司列举了最常见的令人沮丧的原因是基础设施和繁冗流程阻碍他 部署代码或者上线功能 。在组织上 ，快速迭代意味着给工程师和设计师的灵活性和不设限自主做日常决策。我在谷歌 ，任 何用户可见的搜索结果改变 ，即使是低流量的实验 ，需要玛丽莎梅耶在 每周 UI 审查批准。虽然这 允许谷歌保护它的搜索的品牌 ，但它明显阻碍创新。优化迭代速度也意味着 ，有明确定义的流程推 出产品 ，而不会说花了大量时间投入后意外发 生。 优化迭代速度意味着建立持续部署以快速验证 ，提高测试覆盖率 ，减少构建和网站当机次数 ，快速 单元测试 ，并鼓励大家来运行 ，快速增量编译 和重新加载 ，以缩短开发时间。持续部署 ，提交马上 到线上特别重要。 迭代速度至少在小工程队利大于弊 （线上出错的风险 ）。人 更兴奋看到功能和 修复 Bug 是因为很快看到实时流量变化。这要比超过一周或成批的代码提交 ，要更容易推断和精确 定位错误源的位置。 团队智慧 ，快速迭代的速度意 味着有强有力的领导者 ，帮助协调和推动团队的工作。在决定关键点 上负责人需要有效地作出决定 ，并承诺他 的选择。借用比尔 · 沃尔什 ，一个领导 4 9 人队 3 次进超 级碗的一句话 ，强有力的领导者需要 “承诺 ，引爆 ，恢复” ，这意味着承诺攻击计划 ，执行它 ，然后 看反应结果。优柔寡断团队只会导致个人努力白费。 2. 尽量自动化。 在技术讲座 “规模化 Inst agram” ，Inst agram 的联合创始人迈克 · 克里格引 “优化最少的操作负担” 作 为一个重要的教训 ，领导他的 13 人团队用户增长到几千万。 产品的增长意味每工程师的操作负担 加重 ，如用户跟工程师或者特定功能跟工程师的比率。 像 Faceboo k 号称每个工程师支持超过 1 万的用户比例指标。 自动化解决方案和脚本去重复执行任务很重要 ，因为它 解放工程团队 ，让他 为实际产品工作。 确保如有失败服务自动重启和方便快捷在流量高峰期替代是在管理大而复杂产品的明智方案。在短 期内可以对应用做快速修复 ，而长期还是要依赖自动化测试 ，这需要权衡。 Et sy 的的座右铭 “衡量所有 ，衡量一切”。支持像开源监控和制图工具 graphit e 和 st at sd 突出自 动化 – 即自动化必须由数据和监控驱动。如果没有监控和日志你怎么知道什么事情错了 ，为什么错 。自动化是困难的。一个后续的座右铭是 “衡量所有 ，衡量一切 ，并尽可能自动化。” 3. 建立合理的软件抽象。 我的麻省理工学院教授和本科生研究顾问丹尼尔 · 杰克逊说的软件抽象的重要性 ： “选择正确的方式 ，程序化自然而然地设计; 模块化就是有小而简单的界面; 新功能在不影响全局的情 况下产生。要是搞错的话 ，程序将是一系列的讨厌的坑 ：接口很笨拙因为他 无法适应一些意料之 外的交互 ，即使是最简单的改动将是很难维护 “。 是什么在谷歌让数千名工程师建立可扩展的系统 ，是因为他 有非常聪明的工程师像杰夫 · 迪恩和 桑杰 · 格玛沃特创建了简单 ，但丰富的抽象 ，如 MapReduce 的 ，SSTable ，Prot oco l Buf f er 等。 是什么让 Faceboo k 工程这么支持大规模 ，是因为专注于核心 ，同样喜欢抽象和简单 ，T hrif t , Scribe, Hive。是什么让设计人员能够有效构建产品 ，Webnode ，Livenode 也是基于同样的理解。 保持核心抽象的简单和减少自定义解 决方案 ，并增加团队熟悉度和对专业知识的抽象。日益普及系 统像 Memcached ，Redis ，Mo ngo DB 等系统都是降低建立定制存储和缓存系统的必要。团队重点 转移到少数核心抽象 ，而不是分裂在很多临时解决方案 ，让公共库更稳健 ，监控更智能 ，性能更易 理解 ， 测试更全面。所有这一切都有助于搭建一个简单的系统 ，降低操作负担。 4 . 注重代码审查 ，编写高代码质量。 维持高品质的代码库增加了整个工程团队的工作效率。清洁