我只思考和回答最有价值的问题,拒绝编写流水账一样的代码。
总共分三步:
1. 分析和识别系统中易变的部分和不变的部分并结构化它们,这是最最重要和核心的部分,俗称复杂度管理,架构师的核心工作就是管理好复杂度,防止以后出现屎山代码;然后维护好易变的部分,并控制好颗粒度,防止过度设计,好处自然不必多说。至于从上往下设计或者从下往上设计,根据模块和项目大小选择,但是常常是同时进行,看似冲突的两种设计方法,其实可以很好的兼容,参考《代码大全》。如果能把这个结构通过配置文件的形式组织起来,那样更加的优雅和高级,举例,普通的CRUD程序员要想编写一个使用netty的MQ客户端,它会怎么写?编写一个Class,应该直接引入netty的依赖以后,配置一下netty,创建一个简易的协议就开始pull数据并处理之,甚至直接在一个方法里完成所有的处理逻辑。如果你看过Rocket MQ的SDK,它把这个过程拆分成了4大块,分别:1.负责接入的门面DefaultMQClient类,用来接收用户的连接和消费者参数和最主要的一个包括在回调的消费逻辑,2. RebalanceService 负责计算和分配消费者组,最重要的是负责产生PullRequest对象;3. PullMessageService 负责调用Netty代码以及消息验证等底层逻辑;4. ConsumeService 负责拉取到数据以后的消费逻辑,比如更新下标Offset;对比一下。可能有人觉得为什么要这设计得这么复杂,仔细想一下,就知道了,每个服务只负责核心的部分,分工合作,互相配合。还记得软件设计的单一职责,开闭原则等等吗?
2. 在设计阶段还要思考一个问题,让你的代码在启动的时候,已经把本来要处理的很多工作都做完(提前量),那是无论从系统效率角度还是从其他方面都是非常有裨益的。当真的有业务来的时候,比如一个web提交,或者来了一个消息推送,你只需要处理真个业务逻辑的10%部分,而90%的部分已经在启动的时候完成了,一旦你做好了这一步,你的各个有机组件就活起来,你可以让它同步运行,或者异步运行。
3. 让你的代码组件之间可插拔,容易替换,小的细胞组成蛋白,再由蛋白组成一个组织(或者器官)。