软件架构设计箴言理解

今天和师弟聊天聊到他们项目开发，有些同事总是提前考虑性能优化，需求变更又是一大堆的重写，让我想起了Donald Knuth 提到的：对软件的过早地优化是万恶的根源。这里就简单的说几条重要的软件名人哲学。

1：软件中唯一不变的就是变化。

在软件开发过程中需求是不停的变化，随着客户对系统的认识，和现有开发功能和软件的认识，也许以开始他提出的需求就是背离的。记得网上有一句笑话，师说需求变化的：

在设计和架构中，凡事无绝对，作为架构师或者项目负责人你必须永远的清晰认识到没有完美的架构和设计，没有万能的软件。只存在当前环境，需求方案，团队人员素质，物理环境，安全等综合因素下的合适方案，由于总总原因你的解决方案可能不是某一个单一因素下的最优解。站在这个位置你需要做的是找到这个综合下的最优解，权衡。不要只从表面说某个人某个团队的解决方案怎么查怎么不好，或者这就是当时综合因素的最优解，站在同样的位置环境你不一定做得更好。在架构设计和人生，在我看来很相似，总是有一堆抉择，每一次的抉择都会带来得和失，权衡得失取舍。

2:KISS:(Keep It Simple,Stupid):

保持简单，但不过于太简单。在《UNIX下的编程哲学》中提到很多保持设计简单，我们能清晰看到这条原则。现在视觉设计，都崇尚简约设计，简单而不庸俗，而不是一大堆的豪华奢侈打造。VB编程开始的可视化设计，可见即可得，google的首页，商业风格。在我们的软件设计中也需要简洁的设计，用户需要的是可见可量化的功能的正确性，而是你运用了多牛b的技术模式，但绝不是一味的太过于简单。你想把意见简单的事情做复杂化是很容易的事情，但是把一件复杂的事情简单化却不那么容易。简单的人生就是幸福。但是这里需要说明的是简单是优秀的，但简单是有底线边界的，超过底线的简单也有变得稚幼。比如事务性脚本模式比其他3中常见模式都简单，但往往复杂的需求它不是最优解，因为他太过于简单了（如果你还不了解是事务性脚本可以参见这里架构设计-业务逻辑层简述）。

3：面向抽象编程。

在设计模式，架构模式，OO中都是一条完全的主线，作为oo第一原则存在。我不起那个软件牛人曾说过：请牢记没有接口的话就不要开始实现。这句话也许过于偏激，但是如果你接口理解为不变或者不易变的话，理解或契约（公司和你的合同）更贴切些吧（可能是一个不变的类，如果你能肯定的说出你的这个实现在以后，在项目开发维护中是不会变得，我觉得这也是接口，接口在于不变和不易变），你也许会同意这句话。对于目前的需求你肯定能够没有抽象没够接口完全写出完美的代码，但是第一条中我们说明的软件中唯一不变的就是变化，在未来的需求中你能够很好的一样的优秀吗？如果不能，那么我认为面对当前需求就该为以后提供扩展延伸。

我个人理解23中设计模式中大多数基本都是围绕着这个Program to an interface, not an implementation（依赖接口而不是实现）第一原则为目的。当然我们也不能不说还有第二原则：组合优先于继承。以后的什么DIP（依赖倒置，IOC的原则），LSP（里氏替换），OCP（开闭原则）等等都是他们的延伸和扩展。在追溯的话这一些列都是为了软件系统“高内聚，低耦合”（可以简叙述为：功能完备(高内聚)的对象之间是靠接口(低耦合)通讯交互的），内聚是描述的功能性完备程度，耦合是表述模块间的依赖程度。这里插一句话某同事给我说依赖接口不