重复业务流程的重复代码从代码本身其实并没有什么弊端,毕竟业务稳定不出问题的交付才是目标。但是从技术人力资源的角度 来说,本质上基于重复代码带来的高额的维护人员的成本支出,后续的项目成本支出。在组织结构轻量化的组织中还不太明显,随着组织层级的叠累,臃肿的部 门上下级带来的则是项目中无尽的扯皮和边界的划分沟通,方案的拉齐。常见的则是拉扯一星期,开发两小时。对于一线的具体实施开发同学来说,不得不说 是一种折磨。
目前在厂里在做购物车前台的这块的业务线,开发过程中对于我来说最大的痛点就是各大的业务线所有的购物车需求都统一在 购物车前台一个部门这边来处理。诸如:汽车、健康、物流、前置仓等等。这样的一个模式带来的问题则是购物车前台的人力资源被集中挤兑,成为瓶颈。有的 同学就说了,加人不就好了。恭喜你,你有当老板的潜质。但现实过程中往往是残酷的,人月神话的故事并不能落地,开发并不是1+1等于2的故事,特别是代码 已经在这种模式下历经十年以上迭代(堆屎)。没有壮士断腕的决心,不得不在这种老(屎山)代码下继续战战兢兢,上线之前各种保命的开关,万能的 try catch 都统统加上。 举一个简单的例子:健康的商品在
用以处理业务逻辑中大量的逻辑分支场景,通过扩展点的形式来实现稳定的业务逻辑,并沉淀业务的既有扩展点知识库。周知各业务 方做到扩展点认知拉齐,各业务方就可以在扩展点能力与自有的业务场景结合做到自定义的整个扩展点串联,形成业务方需要的个性化业务流程。
资料: tmf2.0 关键设计 https://www.ryu.xin/2021/08/13/tmf2-design-summary/ swak 内含扩展点实现:https://mcolley.gitee.io/swak