对于开发者而言，成就感来自于每一次敲下代码后可实现的创造力，而不是把时间和精力消耗在写千篇一律又无法复用的“胶水”代码，或是在越来越复杂的软件栈面前，疲惫地写业务流程并尽量减少Bug。更加不堪的是，有时仅仅是因为同一项目的两个成员使用的库版本不同，就不得不消耗大量的精力去解决冲突。 

不过，在太平洋时间12月1日的2022亚马逊云科技re:Invent全球大会上，Amazon.com副总裁兼首席技术官Werner Vogels博士向开发者们展示了另一种可能——把精力放在更有价值的工作，而不必重复低效劳动。

自动化创建状态机和工作流

和“胶水”代码挥手作别

在re:Invent 2022大会的主题演讲中，Werner Vogels博士多次以“异步”、“事件驱动”等关键词来描述Amazon Step Functions Distributed Map的设计理念。但对于开发者来说，可能更有吸引力的是，如果你会写ETL，就可以少做一些重复工作，留出更多时间去思考能给业务价值、技术架构带来增量的研发工作。

除了恼人的业务流程外，另一类降低研发效率的工作是写“胶水”代码。所谓“胶水”代码，就是互不兼容的模块间（接口不同、语言不同等），需要写一些代码做连接才能正常工作。这类代码对业务没有任何价值，纯粹是软件研发过程中的副产物。

这个点对点流程的创建，聚焦在事件源、事件目标两个主要问题上：

● 事件源发布时，Amazon EventBridge Pipes支持以下服务作为事件源：Amazon DynamoDB、Amazon Kinesis、Amazon MSK、Apache Kafka、Amazon SQS(标准和 FIFO)和Amazon MQ(包含ActiveMQ和RabbitMQ)等。

● 事件目标则包括：Amazon Lambda、Amazon API Gateway、Amazon SNS、Amazon SQS和Amazon Step Functions等。

Amazon Step Functions Distributed Map和Amazon EventBridge Pipes的发布实际传达了一种趋势：类似的服务在未来几年可能会越来越多、越来越成熟，告别低价值代码是大势所趋——云原生时代开发者的技术栈需要做出调整。

如果在未来，可以在常见的业务流程或ETL流程上少花些时间，也不用再写“胶水”代码，我们就会有大量时间来思考业务、架构和流程本身的合理性。

 

避免更糟糕的时间浪费

当然，比起写一段ETL代码或是写一段模块集成代码，更糟糕的可能是将时间消耗在协作问题而非技术问题上。

随着业务压力的不断增加，需求能三天上线就不会拖到一周。开发者的大部分工作时间中可能都不会有工程设计的概念，中间遇到的各种协作问题只能是“在起飞的过程中换轮胎”。

所以当Werner Vogels博士在这次re:Invent2022上发布Amazon CodeCatalyst时，台下开发者的掌声十分热烈。

Amazon CodeCatalyst的功能包括：

● 项目资源蓝图——不仅是新项目的脚手架，还包括支持软件交付和部署所需的资源

● 统一开发环境，保持项目组环境一致

● 管理issue、pr、部署跟踪等

● CI/CD

● 显示项目仪表板

● 通过一封电子邮件即可邀请他人就项目进行协作

● 统一搜索，跨用户、问题、代码和其他项目资源检索内容

这里的资源蓝图包括启动代码、示例代码和云服务相关配置的最佳实践，其他几项也都是软件研发项目管理的必需品。另外一大特色在于CodeCatalyst本身集成的第三方工具是高度灵活的，是不是要用GitHub和Jira，完全和团队的习惯有关。