如何做好业务系统(文摘)

本文为知识星球零碎的笔记, 聚合一下推送出来

本人工作中大部分时间在做业务开发, 在实现业务需求正确前提下, 更多应该思考如何去做的更好, 希望下面的摘抄内容对你能够有所启发

1. 什么是好的软件系统

在软件设计开发这个领域，好的设计和坏的设计最大的差别就体现在应对需求变更的能力上。

2. 如何给代码解耦

如何给代码“解耦”？

1. 封装与抽象 将复杂的功能进行封装, 暴露给外部简单使用, 这样底层在修改逻辑时并不会更多影响到外部
2. 中间层 当完成一个业务功能需要多个交互时, 会显著增加调用方的复杂度, 我们可以增加中间层, 由中间层完成调度, 业务方只需要调用中间层即可
3. 模块化 合理划分模块, 按功能组织类划分小模块, 按业务边界划分大模块, 大模块嵌套小模块组成系统

3. 业务的拓展性案例

在支付宝一代的业务架构中，前台的业务和后台的业务直接耦合，形成了多对多的网状结构，如果修改一个后台业务线，就会影响到很多前台业务线；如果增加一条新的前台业务线，需要同时和很多后台业务线对接，这样的架构无疑是对业务的扩展非常不利的。

而在支付宝二代业务架构中，他们在前后台业务线之间，构建了独立的支付清算平台，从而实现了前台业务和后台业务的解耦。

在这里，不管前台业务，还是后台业务，都只需要对接中间的支付清算平台，把系统的变化收敛到一个点，而业务线之间相互不影响，这样的方式，自然可以很好地支持业务扩展。

4. 中台出现的原因

前台和后台的特性是不一样的。前台对外，我们知道，消费者的需求快速多变，所以前台需要能快速响应，做到低成本试错；而后台对内，企业内部的业务流程不能经常变，所以后台需要稳定，不能随意调整，一旦改动，影响面广，成本很高。

所以，如何实现前后台的平滑对接，这是一个巨大的挑战，中台架构因此而生。

5. 应该怎样选择重构我们的系统

随着业务发展、功能堆砌, 包括人员的流动, 项目质量肯定是越来越差的.

当我们任由这种情况发展, 到最后可能要花费重大代价去重构, 但是这个问题应该是尽量避免的.

功能是持续演进的, 我们也应该保持一个持续重构的心态去做. 我们不能等到项目烂到一定程度再去集中重构, 这样也会带来很大的风险和挑战, 并且这似乎陷入了一种死循环里.

重构大致分为大规模高层次的重构和小规模低层次的重构 大规模高层次重构包括对代码分层、模块化、解耦、梳理类之间的交互关系、抽象复用组件等等

小规模低层次的重构包括规范命名、注释、修正函数参数过多、消除超大类、提取重复代码等等编程细节问题，主要是针对类、函数级别的重构

6. 如何写出可mock的代码

关于mock, 就是用一个“假”的服务替换真正的服务

一般我们用来替换 需要依赖数据库、网络通信、文件系统等.

依赖注入将很方便我们去 mock 逻辑, 而不是逻辑与数据或其他系统紧耦合.

7. 遇到难以解决的问题怎么办

当遇到一个问题是， 首先思考为什么会引出这个问题来，这个问题的本质是什么，我需要做成什么就可以解决掉这个问题， 同时会引发什么新问题，引发的新问题在一段时间内能不能被接受。

然后顺着这个思路，相信你会权衡出你的想法