「Slack」Slack 技术演进模式：在正确的时间采用革命性的技术( 四 ) |技术|大商潮流装备控|硬件|

虽然我们一直在讨论“技术采用曲线” ，但实际上在第三阶段会出现一个分岔口。即使非常成功的项目也不可能彻底采用全新的技术。例如，在 Slack ，我们已经广泛地采用 gRPC 作为内部的 API 技术。但是，我们不太可能构建一个全新的基于 gRPC 的 memcached 。 memcached 的自定义协议很不错，并得到了客户端的良好支持。这种例外并不意味着采用 gRPC 是失败的。
对于其他一些情况，采用多种技术的成本（工程师的认知负担、运行旧系统的负担）太高，所以我们有必要彻底采用新技术。对于这样的项目，我们需要制定一个应对顽固派的计划，不同的情况需要采用不同的策略。长时间没有发生改动的系统可能需要使用代理，并逐步对其进行迁移。如果顽固派的存在是因为新系统缺乏必要的功能，那就需要增强新系统，或者对新系统进行封装，模拟旧系统的功能。
对于对旧系统产生了情感依恋的情况，进行面对面的沟通通常比高风险的公开辩论有效得多。请温柔些，如果你的新系统足够成功，总有一天它也会成为旧系统。
技术人的期望作为 Slack 的工程师和工程负责人，我们对彼此的期望是什么呢?

首先，我们要去做一些探索工作。外面的世界很大，我们偶尔也要抬头看看外面发生了什么。但没有人可以做到探索一切，也没有人可以做到一直在探索新事物。我们有对外部的承诺和内部的路线图，这些事情仍然具有高优先级。不过，我们还是要分出一些能量用于探索新事物。
在成为其他团队技术产品的用户时，我们要讲道理。提供底层技术支持的团队需要将他们的系统向前推进，有时候，这会给上层的用户带来成本。如果这种成本是不合理的，或者当它朝着与你的团队需求相反的方向发展时，你需要以他们能够理解的方式与他们沟通。
有时候，我们需要避免依赖无法满足我们需求的底层技术。在设定团队技术发展方向时需要注意这一点。不过，这并意味着一定是他们做错了什么，我们需要用成熟和专业的方式来应对这种依赖分离。
当我们试图推动他人做出改变时，我们会对试图理解和使用新系统的团队抱持以用户为中心的态度。他们的快乐是你成功的唯一晴雨表，包括沟通、需求收集、反馈、迭代、有目的性的培训和技能分享。

如果有疑问，请记住：你要对技术采用的成功与否负责，而从长远来看，这是由你的产品的用户来决定的。
关注我并转发此篇文章，私信我“领取资料” ，即可免费获得InfoQ价值4999元迷你书！