如何搭建一个系统？
首先要学会搭建一个系统，你需要先成为一个优秀的工程师。一个优秀的工程师应该【具备扎实的基础能力】、【书写高质量代码】、【拥有良好的风险控制能力】以及【具备一定的测试基础】。
(1)，系统架构
1)，评价一个优秀的系统的指标
- 代码具备一定的可读性、扩展性。 => 也使得代码的干净，不混乱。 => 这里混乱的定义是相对的，也就是说，如果你自己按照一定的逻辑封装的，那么对于自己而言是清晰的；但是如果这个代码给到其他的人看，在不清楚你的思路的情况下会存在一些问题(
变量名任意起、方法一坨等)，所以面对可读性的挑战，我们就可以通过良好的结构去管理这些复杂性，我们把这个结构称之为【系统架构】。 - 代码的具备的一定的健壮性。
- 在排查问题的时候也容易定位。
2)，用发展的眼观去看待一个功能的设计
ps:不仅仅用发展的眼光去看待一个功能的设计，其实编码更像一种“救世主”模式，你通过代码实现的一个个功能，就是你的一个个的作品，而于这些作品而言，它的好坏完全取决于你，基于换位思考的原则。
A01：示例伪代码
假设我们有一个http接口，需要返回用户的信息。用户信息包括：用户昵称、用户vip等级、用户标签、用户余额、余额历史以来用户最贵一次消费。
public Result<?> getUserInfo(String userId){
log.info("打印方法入口日志");
log.info("校验入参");
try{
log.info("ServiceA -> 获取用户基础信息");
log.info("ServiceB -> 获取用户特殊信息");
// log.info("ServiceC -> 获取当前用户充值的总金额");
log.info("ServiceC -> 获取当前用户余额");
log.info("ServiceD -> 获取用户的消费记录");
log.info("利用strem流的方式获取最近一次最贵的消费");
}catch(Exception ex){
log.error("捕获异常日志 -> ", ex);
}
log.info("打印访问成功出口日志");
return ResultGenerator.genSuccessResult("返回接口处理结果");
}
分析上述代码中存在的问题：
-
业务变动 => 如果新增一个接口的话？
- 通用日志模块是存在优化空间的，比如打印方法入参、出参。 => 通俗的讲就是如果新增接口，每个接口都要添加入参、出参的打印。
- 通用异常处理模块。 => 这里如果是针对业务本身的而设计的异常处理，那么无可厚非，但是如果从
try ... catch ...看的话，如果是为了替代全局异常而将所有的方法都添加在函数体内的话就会存在问题了。
-
功能变动 => 如果替换需求中的“计算”部分，转为获取用户的充值总额，用户的基础等不变。
- 对应的入参(
增加用户姓名查询)是可能变动的，那么意味着入参的打印、校验都需要修改。 - 其他的用户信息的获取也是需要是复制一份的。
- 对于返回信息而言也是如此，此时需要修改新的新的信息的话，那就需要往这个代码里添加新的业务逻辑。而这个类一旦有变化，就涉及对这个类的回归验证。
- 对应的入参(
-
问题抽象：
- 存在部分冗余代码，在逻辑变动的时候会发现，代码的冗余会带来修改的效率低下、存在漏改的风险、存在逻辑不一致的风险。
A02：通过模版方法解决部分冗余的问题
- 算法简介：统一算法框架，将算法要素暴露给子类去实现。
-
算法核心：
- 控制业务执行步骤，例如先打印日志、再校验，执行业务逻辑，统一处理异常。
- 和业务相关的核心要素实现，在每个业务中是不一样的，所以这些需要子类自己去实现。
- 伪代码示例：
public abstract class ServiceTemplate<T, R> {
private final Logger logger = LoggerFactory.getLogger(getClass());
/**业务执行步骤*/
public R process(T request) {
//1,打印入口日志
Logger.info("start invoke, request=" + request);
try {
//2,校验参数(抽象方法)
validParam(request);
//3,子类实现逻辑(业务的具体实现)
R response = doProcess(request):
//4,打印出口日志
logger.info("end invoke, response=" + response + ", costTime=" + timeCost);return response;
} catch (Exception e) {
}
}
/**父类抽象方法：参数校验，具体的逻辑由子类自己实现*/
protected abstract void validParam(T request);
/**父类抽象方法：执行业务逻辑，具体的逻辑由子类自己实现*/
protected abstract R doProcess(T request);
}
- 子类实现修改：
public Result<?> getUserInfo(String userId){
return (new ServiceTemplate<String, Result<?>>){
@Override
public void validParam(string request) {
log.info("校验入参");
}
@Override
public Result<?> doProcess(String request) {
log.info("ServiceA -> 获取用户基础信息");
log.info("ServiceB -> 获取用户特殊信息");
// log.info("ServiceC -> 获取当前用户充值的总金额");
log.info("ServiceC -> 获取当前用户余额");
log.info("ServiceD -> 获取用户的消费记录");
log.info("利用strem流的方式获取最近一次最贵的消费");
return ResultGenerator.genSuccessResult("返回接口处理结果");
}
}).process(userId); // 调用业务执行步骤的相关方法
}
-
优化后分析好处与仍然存在的问题：
- 相关公共的逻辑被抽象了，例如日志打印、异常处理等。
- 不用担心接口有遗漏步骤及搞错步骤顺序，例如入参校验在执行业务流程之前。
- 子类只需要关注自己业务逻辑的实现即可。
- 如果对于接口要增加一些公用的能力的话，可以直接在方法内部抽象接口中添加，
A03：通过流程引擎来优化步骤的执行顺序
- 算法简介：将要执行的逻辑看成是一个个步骤的串接，由统一的角色来管理步骤的执行顺序，这个角色就是流程引擎。
-
算法核心：算法的核心体现就是“管理者”角色的出现，当然需要将可以独立的功能抽象成一个一个的 执行器，这些执行器可以是不同的业务领域类，而管理者的职责就是将这些通用的流程放在一个池子中，根据不同的耦合业务场景从池子中获取不同的执行器，去编排到不同的业务流程中。
- 【核心优势 -> 避免冗余】：利用抽象和池化思想，将不同的执行器统一管理，从而避免了代码的冗余。
- 【核心优势 -> 最小修改】：如果业务逻辑在组织过程中，需要增加一个环节，可以方便的通过直接添加一个执行器即可。
- 【核心优势 -> 方便追踪】：在原始的模板方法中可以增加耗时统计处理，此时也可以印证模板方法的优势，根据耗时统计可以知道每个执行器的耗时情况，方便追踪日志，去找到最耗时的执行器去进行精细化的定位。
- 【核心优势 -> 利于分工】：每个处理器在约定职责的情况下可以独立开发，当然就可以独立测试，减少整体出错导致排查问题混乱的情况出现。 => 同时代码的可读性也会翻倍增加。 => 当然模块化的设计，也就更加利于各个处理器以循环和分支的方式进行组合。
![[Pasted image 20231030214347.jpg|给出参考连接作者的一副图方便理解对应的优势]]
Pasted image 20231030214347.jpg
- 示例代码：这里不再对文章中的方法进行整理，感兴趣的话可以直接查看原文。我更倾向于这是一种代码的组织方式，你可以通过示例中去通过接口和对应的实现类去创建不同的执行器，然后通过模板方法再去组织业务，也就是通过模板方法中抽象接口去组织业务流程，充当一个管理者的角色。 => 从这个角度看，去实现自己的流程引擎就需要根据自己的代码架构去实现了，而实现方式则不拘泥于这一种。
