文 | Alex Vauthey

选自LinkedIn工程博客，“From Good to World-Class: What Makes Software Engineers Excel at their Craft”，作者Alex是工程部VP。

在LinkedIn我们评价工程师有三方面指标：领导力，执行力和工艺水平。

前两个都很显然：我们通过它们来评估，让大家向相同方向前进，是不是成功发布和做完事情。但“工艺”还是挺讲究的。

我和团队很多人讨论过这个概念，我们对待它不仅是评估的组成而且是文化的一部分。有些问题重复提到：在工艺上卓越意味着什么？我们能不能分解到几个关键原则和软件指标？能不能在写代码时候考虑到实际问题去帮助到每天上亿用户？我们能不能让刚加入团队的刚毕业的工程师理解什么是好的好的工艺？

为了解答这些问题，我列举了软件工艺的七大基础维度。每一点都在搭建世界级软件和团队中同等重要。它们是：

代码质量

就是从写代码开始。我们总是要假设在未来，其他人会接管代码。我们需要设身处地想，问自己代码是不是很清晰，模块是不是很容易能被理解。组织上应该提供一些代码规范来很容易支持每种语言。编写优质代码标准和实践。

我还记得当我2008年拆开苹果电脑时候的赞叹。所有的东西都是合理的布局和管理着。设计清晰，即使内部布线都是精巧对齐，我能马上看到各个模块：显卡，内存，主板。我们要把代码想成Mac电脑。我们用户虽然看不见，但还是能作为最漂亮和精致的东西，因为这会更容易的维护和后期扩展。

伸缩性

伸缩性可是看成是软件系统在负载高峰还能正常工作的能力。如果系统的高峰发生在节假日后的那一天，我们的产品和服务能够处理。搭建可扩展和伸缩的系统在这很看重，这是为什么我们持续投资在建立大型伸缩性系统的组件，比如Kafka，一个高吞吐消息系统让我们能每天处理8000亿条消息。

不仅如此，伸缩性还有更广的考虑。我在组织上的功能也考虑伸缩性。搭建可重用的组件让其他用户受惠也是一种伸缩性。

当LinkedIn成长为热门应用时，我们用户和客户在实时分析上也有需求，比如需要去理解广告或者给定职位发布的转化率，基于上百个用户资料的维度：行业，职能和地理信息。我们需要在上百个维度去展开和查看十亿量级的数据。我们没有去搭建定制化和一次性的解决途径，而是建立在线分析服务去在更广阔的范围内去服务需求。这就是Pinot，一个实时分析OLAP数据存储的出现。这种回报非常显著，现在Pinot支持所有的公司产品和服务的在线分析场景。

高可用性

系统可能会当机。但全球用户可是7＊24小时依赖我们的服务。一个单一失败会导致服务中断，我们也就失败了。一个节点的丢失不应该导致集群的失败，而数据中心级别的错误情况也不应该导致整个服务的中断。高可用是考量的重点，我们开发了Helix，一个内置高可用的集群管理框架。Helix在节点失败时候，节点恢复或扩展时候，重新配置服务器时候自动分配资源，这可以在系统部分出现错误时候避免服务的中断，在维护阶段依然发挥作用。

安全性

互联网其实很不安全，我们希望产品和服务变得尽量安全。我们需要写软件时候，不要引入安全隐患或者劫持用户数据。在软件开发早期能够纠正潜在安全风险是极大减少风险，这也是比起事后发布补丁效率要高成本更低。安全性就是需要内置。我们很想给一些例子是怎么保护站点和数据安全，工程师在写代码时候是如何注意的，但这本身很敏感不方便公开。

简单性

就像我们说代码需要维护和被以后的工程师所扩展，系统设计时候需要考虑简单。后来，其他人可以去维护和操作。爱因斯坦曾说过我也很喜欢的话“你需要去把事情尽量简化，直到不能更简化”

如果通过过度的工程让事情复杂化，会造成系统脆弱，损害团队迭代和增强软件的能力。当然这是需要平衡的，我们需要软件来解决手头复杂问题。但是如果你考虑简单，没用最优的方式会让下游的同事处理起来麻烦，最后还是伤害了用户。我们一直努力去加强最复杂系统的原因就是让系统尽量简单化，这里包括如何在当前架构下运行海量机器学习算法，让竞价广告系统每秒支持百万级别查询。

性能

页面很慢就是无用的。我们已经通过实验证明低性能会对注册，交互，收入等核心指标产生伤害。每一个页面和应用都需要性能指标记录。在新的功能，产品和服务上线，我们都要跟踪和解决性能问题，这是一个健康的习惯。每个工程师在写代码时候要考量性能指标。这也是为什么，采用RUM（实时用户监控）框架，每个工程师都需要去监考页面和实时性能跟踪。累计页面延迟会在用户友好的报表中自动显示出来，让你去看一个页面和应用在加载和渲染的快慢，然后去选择，过滤并深入到一些设备的性能指标（网页，iOS，安卓）或者地理分布。

操作性

操作性是让软件系统保持在安全和可依赖的条件下。我们有一些方式去采集，如网站可靠性工程师来衡量和操作软件和节点。到底是1人，10人还是100人去监控1000个节点？

其他的指标包括：一个实例多久能够变活？如果服务需要15分钟去重启，操作性就很差。如果服务每小时产生百万级别无意义的异常和日志，也很差。加强可操作性，就是与系统中日夜操作的同伴一起战斗。

不管你是全职开发OP，还是跟SRE合伙，系统管理员去操作软件，很好的实践方式就去跟操作性很强的同事一起，让服务更容易可操作化。里面好处包括1）增强从错误中恢复的能力 2）系统操作的同事可以花更多有价值时间去搭建新东西而不是仅仅保持系统的活动服务状态。

按：回想我自己多年的经验，这里是7条软件工艺的总结。理解这些对建立更快更好，更稳定的软件很关键。但是，最重要还是回到工艺上，这是统一所有的关系的事情。