什么是分而治之？

分享：

“使用函数主要有两个目的：降低编程难度和代码重用。函数是一种功能的抽象，利用它可以将复杂的大问题分解成一系列简单的小问题，而后将小问题继续划分成更小的问题，当问题细化带足够简单时，就能分而治之，为每个小问题编写程序，并通过函数封装，当各个小问题都解决了，大问题也就解决了。这是一种自顶向下的程序设计思想，后面的章节会详细介绍该设计思想。函数可在一个程序中的多个位置使用，也可用于多个程序，当需修改代码时，只需要在函数中修改一次，所有调用位置的功能都要更新了，这种代码重用降低了代码行数和代码维护的难度。”

这段话也讲出了编程的意义，编程实际上就是制作一种“机器”，在这种“机器”的输入端，输入原材料，通过处理器，其输出端就输出的是产品。制造机器不也是有主零件，备件，螺丝等，把这些东西按照组装图的要求进行组装起来，在经过调试，就实现了该机器的功能。

从某种意义上讲，人就是一个高级的机器，身体相当于硬件设备或平台，思维和思想就是软件，接受教育就是安装软件，只有软硬件都安装好了，再进行适当低调试，达到了应有的功能。这其中软件里最重要的是如何“先做人，再做事！”，因为我们的社会是由人们组成的，只有每个人多为人类做贡献，社会才会良性运行，否则社会会倒退或恶性运行。

历经人世六十有四，深感在处理事件的时候，特别是处理复杂事件，采用“分而治之”方法具有普遍性，这样做成事的概率高很多。

分治时，拆分软件系统的形式很多，可以拆分成：

• 不同的方法

• 不同的类

• 不同Package

• 不同的moudule

• 不同的jar

• 不同的进程（微服务）

• 不同的系统

以上形态拆分形式的的隔离级别越来越大（当然，还存在其他不同的拆分形式和粒度），我们又要如何选择拆分的形态呢？

这需要看我们当前对业务的理解程度。隔离级别越大，说明打通隔离越困难，修改调整越困难，但同时也意味着设计的架构越容易被遵守。因此当你坚信架构划分正确，不同部分需要尽可能分割时，可以采用基于进程甚至更高级别的隔离。

但对于业务变化依然很大，边界不清晰，难以把握全局时，采用不同进程隔离或者不同jar的隔离可能就不合适，因为架构依然可能还需要调整，如果已经拆分了进程、jar那么架构调整的难度将大幅增加。若不调整架构并要兼容之前架构未作适配的业务的话，那只能大幅增加模块间的耦合（接口）

因此个人觉得大规模的拆分，最理想的情况下，应该是在同一个jar的粒度下，先做好基于module/pakcage的拆分及重构，然后稳定运行一定程度后，如果仍然觉得有拆分的必要的话，再将其进行jar、进程级别的隔离。

当然上述的做法可能难以奏效，因为我们干很多事情都是运动式的，上面的做法看起来只是个内部重构，“很简单”，因此也难以争取到相关的时间、人力等资源来进行，因而我们的重构也许只能通过一次性“搞个大”的，冒着更高的开发风险与顶着可能不完善的架构来进行。