我离开 Amazon 已经快一年了，来到 Twitter工作以后，我学到了很多东西，也意识到了很多事情。

1. 服务及健康

软件工程并不局限于为客户构建新的功能，还要确保现有服务的健康及功能。服务在性能方面上不应该出现倒退现象。这对于维护客户的信任非常重要。如果你现有的服务不能提供相同的 SLA（Service-level agreement，服务级别协议），那么客户为什么还要用你的服务呢？

维护服务的方法有很多种：

随叫随到
监控
自动化系统
操作规范化

随叫随到（OnCall）是维护服务健康的最大因素。如果服务发生实时停机事故，随叫随到可以尽快缓解这一情况。否则，事件拖得越久，后果就会越严重。例如，最终用户的影响可能是无法吸引新用户，从而导致收入损失。最重要的是永远不要危害产品，以免用户停止使用产品。

当内部客户的服务或工作表现不佳时，他们可以通过通信平台（如 Slack）发起呼叫请求。大多数情况下，随叫随到是由监控系统传呼的。监控系统允许工程师通过关键指标（如成功率、读写延迟、流量、内存空间等）来跟踪服务的性能。因此，随叫随到可以全面了解他们的服务中正在发生的事情，从而可以更快地调试问题。

在这些监控系统中，可以为关键指标设置一个阈值，当超过这个阈值时，随叫随到将会被传呼。然而，这些阈值的设置，却有可能是一把双刃剑。如果阈值设置不当的话（即设置过低或过高），随叫随到可能会被大量传呼所淹没。阈值需要设置为只有在服务遇到问题时才会突破的值。同样，工程师也不应过于热心，为每个指标设置一个阈值。你需要警惕的是那些可以采取行动的指标，这些指标如果不能迅速解决的话，可能会产生毁灭性的影响。

减轻随叫随到的负担并改善服务健康状况的可行解决方案是自动化。如果某个问题不断地重复出现，并且无需人工干预即可解决，那么就可以采用自动化。自动化系统可能会产生很大的影响，但如果不实施保障措施，可能会产生不良后果。例如，在重新启动有状态服务的实例时，不要同时重新启动所有实例，这一点很重要。

自动化系统甚至可以与监控系统集成。只要达到特定指标的阈值，监控系统就可以触发自动化。

为了防止人工操作造成问题和事故，必须保持高度的操作规范化。解决这个问题的一种方法是制定一个文档完整的运行手册，其中列出了每个手动操作的详细步骤。最重要的是，另一个团队成员可以验证操作员的操作过程，特别是在已知操作会导致问题的情况下。

50% 的软件工程都是维护服务的健康。这不是工作中微不足道的一部分。要知道，软件工程并不仅仅是编写代码。

2. 代码的可持续性

要确保任何推入的代码都能灵活地应对变化是很重要的，当业务需求发生变化时，这一点尤为重要。

使用 DRY 原则

DRY 代表 “Don’t Repeat Yourself”。（不要重复自己写的代码）。同一段代码不应在许多场合重复。如果你看到这种情况，那么可能需要对其进行抽象以避免出现冗余。这样，如果你需要修改它的逻辑，只需在一个地方修改它即可。

始终测试

始终为你编写的任何函数编写测试用例。引入的任何新特性都不能破坏系统的现有状态，这一点很重要。测试可能是乏味的，但它将会带来巨大的回报。

架构优先

如果在编写代码时不考虑架构，这将会产生滚雪球效应。在编写代码时，要想想其他服务将如何与它进行交互，将来更新它有多容易，以及如何测试它。编写代码的方式应该是，如果需要交换一种逻辑，那么放入一个新的逻辑是很容易的。

使用常量

永远不要硬编码。相反，要使用常量。这样，如果将来需要更新值，只需修改一次，而不是多次。

3. 采取主动

工程师永远不应该停滞不前。他们应该努力成为团队的领导者。为了在你的团队中扩大你的影响力，你必须采取主动，并愿意接受你不喜欢的新任务。优秀工程师的标志就是他或她能够在最少的帮助下解决新的挑战。我已经开始更多地参与自己并不熟悉的服务的代码评审。我敦促自己对关于边缘案例或弱点的技术设计文档进行更多的评论。我甚至和我的经理谈过，让我参与一些能够帮助我加强自身弱点的项目。

强迫自己进入一个新领域，并不是你唯一应该做的事情。你还需要提前考虑团队将面临哪些挑战，以及如何应对这些挑战。在它成为一个真正的问题之前，一定要提前考虑并及早解决。积极主动是我目前正在学习的一项技能。希望通过对这些技能和目标的努力，我能够在下一阶段取得更好的成绩。

在过去的一年来我学到了很多，我希望在未来的几年里能学到更多。

作者介绍：

Yen Huang，Twitter 软件工程师，曾在 Amazon 工作。毕业于康奈尔大学。

原文链接：

https://towardsdatascience.com/3-things-i-learned-as-an-engineer-at-twitter-fe9ac352f2eb

创作场景

我在 Twitter 当工程师学到的三件事