扩展与耦合的边界

这个题目有些大，其实还是小经验。

最近发觉做项目的时候，经常会有因为理解不对或与前辈交流不够（他们忙自己的模块，很难交流够）按自己的想法做了到头来却发觉做出来得东西需要大改的尴尬事情发生。（好长的句子，呵呵）往大了去想，这应该就是需要扩展吧。

很幸运的是，当时费劲做出来得标签类没有白费。因为当时做CMS时，我的思想是生成与设置的分离，各个标签的相对独立。同时引入队列。所以现在虽然变，但是改动不是很大。不过按照传说的做法，应该比我这种更小。今天又是一顿大改。某个标签的生成规则全部变了。发觉因为在开发初期就对区域生成与页面生成脱耦，一处的修改对于整个静态页面生成引擎的影响可以忽略不计，或者说其他的类感觉不到变化。也就是所谓的各自进化。

做到这里不由得去想扩展与耦合的边界问题。怎么设计易于扩展？怎么脱耦不会让系统太松散？这里面还有一个时间成本的问题。

今天看到一个名词解释：抽象，抽象就是忽略一个主题中与当前目标 无关的那些方面，以便更充分地注意与当前目标有关的方面。抽象并不打算了解全部问题，而只是选择其中的一部分，暂时不用考虑部分细节。抽象包括两个方面， 一是过程抽象， 二是数据抽象。

从这句话里得到启发。我猜想，在过程抽象时，分析中所谓大面上的流程，在他们衔接的地方都应该脱耦。也就是耦合的边界。只要在这里做到了脱耦，系统就会易于扩展。而在数据抽象时，记得模型不要涉及与自己不紧密相关的业务处理就行了。在通信的时候尽量传对象。对于一些公用的数据模型，一定要有管理方案。