暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

中间件/组件的开发流程

Java艺术 2021-09-06
716

很久没更新,写点什么?


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

一个大概的流程:
  • 整理需求文档 

  • 编写设计文档(这个过程包含技术调研)

  • 技术评审(相当于需求评审)

  • 分解任务(任务排期,需要每周更新进度)

  • 代码(详细设计、编码实现)  

  • 元测试(自测)

  • 功能测试(自测)

  • CodeReview(同事)

  • 写使用文档 

  • 发版(对于组件只需发布到私有maven仓库)

  • 推进业务部门级/使用(可能也需要做一次技术分享)

  • 解答疑问、处理问题


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

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

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

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

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

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

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

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

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

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

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




[Java艺术] 微信号:javaskill
深耕后端架构、探索底层实现原理,关注Java艺术,我们在架构师道路上一起成长!


文章转载自Java艺术,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论