中间件/组件的开发流程

很久没更新，写点什么？

跟大家分享下我们公司中间件/组件的开发流程吧，让大家能了解中间件/基础架构实际工作内容、开发流程，并从这个过程中分析我们需要具备哪些能力，或许你也会对这个方向感兴趣。

一个大概的流程：

• 整理需求文档
• 编写设计文档（这个过程包含技术调研）
• 技术评审（相当于需求评审）
• 分解任务（任务排期，需要每周更新进度）
• 编写代码（详细设计、编码实现）
• 单元测试（自测）
• 功能测试（自测）
• CodeReview（同事）
• 编写使用文档
• 发版（对于组件只需发布到私有maven仓库）
• 推进业务部门升级/使用（可能也需要做一次技术分享）
• 解答疑问、处理问题

从这个过程可以分析出对个人能力的要求：

一、沟通能力。这是最基本的能力，无论我们做任何岗位的工作，至少要能流畅跟别人沟通交流。跨部门沟通避免不了，如做业务开发需要与运营、产品沟通，做底层也需要与技术、运维沟通。

二、文档编写能力。我们不仅需要编写架构设计文档，也要编写使用文档，详细设计文档则不要求（但不代表其它公司不要求）。要求不高，但要逻辑清晰，能表达清楚你的设计，且不废话，设计文档要求画架构图。

三、有自己想法、见解，不要只会去抄别人的设计。我们为什么要基于开源的项目做二次开发，因为开源项目只会满足多数使用场景，而每个公司的技术栈、使用的协议、基础设施都不同，所以别人的方案也并不一定适合我们。

比如，spring-kafka也是封装kafak-clients实现与spring ioc容器整合，提供易用性，但为什么我们还需要自己开发？因为我们要做全球跨区域topic消息同步、支持多集群使用场景、结合配置中心实现动态平滑Kafka版本升级等。

四、自驱力。我们开发的产品是给业务部门使用的，需要站在使用方角度去思考问题，有些时候不能只是我觉得，更要知道业务部门觉得，并且我们也不了解业务部门都有哪些使用场景。

就以kafka的延迟消息来说，有的业务部门提出需要我们提供的组件支持延迟消息，那么我们需要主动跟他们沟通，了解他们的使用场景。如是否要求一定能够自定义任意延迟值，如果固定只能选择延迟2s、4s、8s、30s、1m等延迟值能不能满足使用场景。如果是必须支持任意延迟值，那么我们可能不会实现这个功能，因为要考虑性能问题，如果要达到这个目标我们要做很多的开发工作，或是不能保证性能问题，以及可用性、数据一致性问题，那么我们是不能给业务部门提供这样的功能的。

五、决策力。设计没有对错，调研结果往往也是不同的人有不同的想法，我们要能够从调研结果、结合自己的思考，重新调整出一个设计方案。我们开会总是计划一个小时实际三个小时，就是因为有些方案存在争议，很难得出一个结论。

六、口语表达能力。技术评审类似技术分享，要求讲解自己的设计，所以要求至少能够表达清晰自己的设计，对临场提问也要能快速构思回答，不要让别人思考你在讲什么。

七、技术深度与架构设计能力才是核心。设计能力也依赖技术深度，好的设计需要考虑方方面面，即要了解公司的整个基础架构体系，也要对自己负责的那一块有较深的了解。就比如说要你对dubbo二次开发，那么你就需要对dubbo有足够深入的了解，才能完成这项任务。

以下是笔者最近写的一个设计文档的目录结构。下一篇跟大家分享其中的延时消息的设计，这是很有趣的事情。