Caution，标题不是《可复用架构设计》，而是《可替换架构设计》。
近期查看其它团队的框架代码，发现与想象中的有些差距。基于这些框架完成项目需求并没有问题，而且从很多编程细节的处理也可以看出相关作者也都是经验丰富的老手，问题在于这些框架的接口和边界不够简洁明确，框架代码与逻辑代码之间相互交织、纠缠不清。
代码设计的原则有很多，工作多年的程序员多少都会知道一些。但知道与用好很可能是两回事，因此很多“设计原则”的没有给出明确的判别标准。比如”简洁性“，地球人都知道简洁是好的，但如何判断一段代码是简洁的还是复杂的，很难给出一条另人信服的客观标准，也因此沦落为以主观臆断为主。因为缺乏客观判别标准，即使框架一开始的设计是简洁的，在迭代演变过程中想保持下去也不是一件容易的事情。大家知道，时间短&任务重是多数项目的客观情况，在繁重的任务开发过程中，原则性往往会向方便性妥协，代码中引入坏味道这件事情不是一蹴而就的，是通过一段时间慢慢渗透的结果。
作为程序员，我相信大家都是有一定追求的人，都希望设计出好的甚至是最优的架构，从而一劳永逸、永垂不朽、仙福永享, 寿与天齐。然而实际情况是要时刻牢记我们自己设计的框架不可能是最优的，在未来的某一天必然需要优化甚至是替换，只有基于这样的觉悟才能强迫你自己坚持设计出简洁明确的接口。
写代码时考虑架构优先于考虑性能，如果你的代码不够快，好的架构是允许在此基础上进行优化的。
比较核心如正交性和紧凑性。
而且，这种方便性多数都是眼前的苟且，从长远看会严重破坏框架的易用性。
从本质原因上来反驳某些设计的问题谢谢是软绵无力的，
当我问到一些功能设计的原因的时候，对方也能够慷慨陈词，列出大量事实来证明这些设计的优点。
References
- 《Effective Java, 2E, Item 55: Optimize judiciously》P234