分治，或者说分割，分析或者简单用一个字来说，就是分。经验告诉我们，任何复杂的东西总是由简单的“零件”组成。比如汽车，飞机，建筑乃至人体，他们在鲜活的外表下，总是由许许多多精巧，简单的“零件”组成的。这些“零件”相互协作，一起完成某些事情。分很容易，但是如何分好却很难。程序本身在内存中运行的时候，总是作为一个整体的，所以本身来说，程序可能并没有分的概念，恰恰相反，它往往体现出来的是一种“合”的概念。因此，很多人开始写程序的时候，往往总是会写成一坨。这样的程序也许工作起来没有什么问题，但是日后的维护或者扩展那简直就如同噩梦一般。
所以分治的思想其实是对开发者有利的，对于程序来说，其实是无所谓的。因为无论你怎么分治，最终程序加载的时候，在内存中肯定是需要完全加载所有的程序的。有些语言天生这方面就做的好，比如java，天生强制分治的思想，不写包和类就不知道怎么写java程序了。java不是最早的讨好开发人员的语言，其实python也是，但是python没有java的这种强制性。事实证明，这件事情的却是应该强制的。因为写成一坨的程序是在是太多了。分治的思想在仅仅是规模大的程序上显得尤其重要，但其实，分治的思想应该渗透到开发的各个部分，而无论程序的规模。
分治还能引申出一个重要的思想，就是降低耦合。说白了就是要分的彻底。被分割的程序部分要彻底的独立，不能随意的暴露自己的属性或者方法给别人。其实这就是所谓的封装，面向对象的一个很重要的特性。有些语言可能并不直接支持面向对象的编程，但是这种思想总是可以变通的实现。而对于某些内聚性很高的语言，比如clojure这种lisp语言，很多的功能数据本身就是封闭的，可能没有这个方面的困扰。JS在使用一些框架之后可以很好的做到这种分治，比如在使用了require和angular之后，JS就可以完全的支持包和对象操作了，可以很容易的实现分治。
分治在大的方向上面可以也应该从业务上和模块的责任上去划分，但是通常都是从技术角度去划分的，比如什么DAO、service什么的。这样划分其实并不合适，因为程序总是应该去契合业务，我们的程序还没有通用到那种类似spring或者hibernate这样的通用框架的程度，因此我觉得对于包的划分，最好应该通过业务来划分。此外，一般来说对于一个程序来说，数据和对数据的操作其实是应该分离出来的，这对于后台服务程序来说尤为重要，有助于我们理解我们的业务操作对象是什么。后台服务程序很大程度上其实是不需要持有状态的，这是和前台UI最大的区别之一。而前台很多时候需要保持一些状态，比如页面上的某些表格中的值，文本框中的值，复选框或者单选按钮中的选中状况等，这些在程序中应该明确的定义处理。但是前台也需要把数据和对数据的操作分离开，但是前台往往需要一个转换的过程，所以前台的程序大体上也可以分为三层，一层是数据的获取和变换层，一层是和页面无关的业务处理层，一层是和页面状态相关的展现层。这和MVC的思想本质上是相同的，但是实际开发过程中，应该处理的更细致一些。MVC其实还是比较粗犷的，比如所谓的控制器往往不容易再细分，但实际上对于特别复杂的UI，在一个界面上，仅仅一个控制器往往是不够的。
分治其实是程序中最为重要的步骤了，分治的好，程序就具备了好程序的基本特征，清晰，明确。