本文为知识星球零碎的笔记, 聚合一下推送出来
本人工作中大部分时间在做业务开发, 在实现业务需求正确前提下, 更多应该思考如何去做的更好, 希望下面的摘抄内容对你能够有所启发
1. 什么是好的软件系统
在软件设计开发这个领域，好的设计和坏的设计最大的差别就体现在应对需求变更的能力上。
2. 如何给代码解耦
如何给代码“解耦”？
- 封装与抽象 将复杂的功能进行封装, 暴露给外部简单使用, 这样底层在修改逻辑时并不会更多影响到外部
- 中间层 当完成一个业务功能需要多个交互时, 会显著增加调用方的复杂度, 我们可以增加中间层, 由中间层完成调度, 业务方只需要调用中间层即可
- 模块化 合理划分模块, 按功能组织类划分小模块, 按业务边界划分大模块, 大模块嵌套小模块组成系统
3. 业务的拓展性案例
在支付宝一代的业务架构中，前台的业务和后台的业务直接耦合，形成了多对多的网状结构，如果修改一个后台业务线，就会影响到很多前台业务线；如果增加一条新的前台业务线，需要同时和很多后台业务线对接，这样的架构无疑是对业务的扩展非常不利的。
而在支付宝二代业务架构中，他们在前后台业务线之间，构建了独立的支付清算平台，从而实现了前台业务和后台业务的解耦。
在这里，不管前台业务，还是后台业务，都只需要对接中间的支付清算平台，把系统的变化收敛到一个点，而业务线之间相互不影响，这样的方式，自然可以很好地支持业务扩展。
4. 中台出现的原因
前台和后台的特性是不一样的。前台对外，我们知道，消费者的需求快速多变，所以前台需要能快速响应，做到低成本试错；而后台对内，企业内部的业务流程不能经常变，所以后台需要稳定，不能随意调整，一旦改动，影响面广，成本很高。
所以，如何实现前后台的平滑对接，这是一个巨大的挑战，中台架构因此而生。
5. 应该怎样选择重构我们的系统
随着业务发展、功能堆砌, 包括人员的流动, 项目质量肯定是越来越差的.
当我们任由这种情况发展, 到最后可能要花费重大代价去重构, 但是这个问题应该是尽量避免的.
功能是持续演进的, 我们也应该保持一个持续重构的心态去做. 我们不能等到项目烂到一定程度再去集中重构, 这样也会带来很大的风险和挑战, 并且这似乎陷入了一种死循环里.
重构大致分为大规模高层次的重构和小规模低层次的重构 大规模高层次重构包括对代码分层、模块化、解耦、梳理类之间的交互关系、抽象复用组件等等
小规模低层次的重构包括规范命名、注释、修正函数参数过多、消除超大类、提取重复代码等等编程细节问题，主要是针对类、函数级别的重构
6. 如何写出可mock的代码
关于mock, 就是用一个“假”的服务替换真正的服务
一般我们用来替换 需要依赖数据库、网络通信、文件系统等.
依赖注入将很方便我们去 mock 逻辑, 而不是逻辑与数据或其他系统紧耦合.
7. 遇到难以解决的问题怎么办
当遇到一个问题是， 首先思考为什么会引出这个问题来，这个问题的本质是什么，我需要做成什么就可以解决掉这个问题， 同时会引发什么新问题，引发的新问题在一段时间内能不能被接受。
然后顺着这个思路，相信你会权衡出你的想法
