假设你对项目管理、系统架构有兴趣。请加微信订阅号“softjg”，增加这个PM、架构师的大家庭

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

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

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

程序猿XX遭遇车祸成植物人，医生说活下来的希望仅仅有万分之中的一个，唤醒更为渺茫。可他的Lead和亲人没有放弃，他们依据XX工作如命的作风，每天都在他身边念：“XX，需求又改了，该干活了。你快来呀。”，奇迹最终发生了，XX醒来了，第一句话：“需求又改了

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

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

保持简单，但只是于太简单。

在《UNIX下的编程哲学》中提到非常多保持设计简单，我们能清晰看到这条原则。如今视觉设计，都崇尚简约设计，简单而不庸俗，而不是一大堆的豪华奢侈打造。VB编程開始的可视化设计，可见就可以得。google的首页，商业风格。

在我们的软件设计中也须要简洁的设计，用户须要的是可见可量化的功能的正确性，而是你运用了多牛b的技术模式，但绝不是一味的太过于简单。你想把意见简单的事情做复杂化是非常easy的事情。可是把一件复杂的事情简单化却不那么easy。简单的人生就是幸福。可是这里须要说明的是简单是优秀的。但简单是有底线边界的。超过底线的简单也有变得稚幼。

比方事务性脚本模式比其它3中常见模式都简单，但往往复杂的需求它不是最优解，由于他太过于简单了（假设你还不了解是事务性脚本能够參见这里架构设计-业务逻辑层简述）。

3：面向抽象编程。

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

我个人理解23中设计模式中大多数基本都是环绕着这个Program to an interface, not an implementation（依赖接口而不是实现）第一原则为目的。当然我们也不能不说还有第二原则：组合优先于继承。

以后的什么DIP（依赖倒置，IOC的原则），LSP（里氏替换），OCP（开闭原则）等等都是他们的延伸和扩展。在追溯的话这一些列都是为了软件系统“高内聚。低耦合”（能够简叙述为：功能完备(高内聚)的对象之间是靠接口(低耦合)通讯交互的）。内聚是描写叙述的功能性完备程度，耦合是表述模块间的依赖程度。这里插一句话某同事给我说依赖接口不是还有依赖嘛。我希望的是没有耦合，我的回答是：计算机二八原则说明了这一切。既然事务出如今一起了，那绝不是偶然情况，所以他们之间必然存在依赖，在软件设计中我们所能做的就是引入中间对象使其变为间接依赖，而降低他们之间的依赖，而我们希望这个中间对象是个相对稳定的。设计中一切都是一个词：间接，分层。mvc，mvp，soa。中间件等等都是体现直接依赖变为间接依赖。

说这个话题的原因是引出我们“高内聚。低耦合”行之有效的方法SOC（分离关注点）。这不仅仅是OO的任然对面向过程编程行之有效，他是在20年前 SP（结构化编程）中提出来的。

假设你想对设计原则有很多其它的了解，能够參见这里面向设计原则理解和一些软件设计的原则。

4：首先考虑可维护。延伸性，事后优化

这里也是本文的起因，正如开篇所说。Donald Knuth 提到的：对软件的过早地优化是万恶的根源。在开发的时候我们不须要进行不论什么性能的优化。即使你觉得这里可能存在性能的瓶颈，你须要考虑的很多其它的是设计的扩展和延伸性，以后的继续加入新功能和维护。对于用户需话要的需求，性能优化非常多时候仅仅是作为一个更好的体验存在。仅仅有当真正出现性能瓶颈的时候，你才须要做性能的优化。一个可延伸可扩展，层次分明。代码清晰的模块，对于你的优化也是件easy的事情，在对项目后期对于项目的整体需求明确下你也有得到很多其它的优化方案。在重构模式中相同也提倡时候优化。过早的优化导致你的项目会越陷越深，到最后才知道用户事实上根本不须要这么高的需求，或者是用户根本不经常使用的功能模块。

优化也须要有标准，多少时间是用户能忍受的。眼下是多少时间。往往用户对性能要求的仅仅有那个少量经常使用的操作，而对于功能性需求的变更却是无止境的。维护成本却是高昂的。

最后说一句，常常有人说反射性能低下，对我们必须承认反射比其它方案性能是不好，可是我们有解决方式：缓存。在则说性能低下。是以什么什么标准？用户的接受程度？反射我们能够有其替代方案Emit，Expression tree。

从反射，Expression tree，Emit的选择，其使用难度在提升，开发效率在添加，性能在改善。本人一般却倾向于Expression tree，两种剧中吧。

5：继承是为了多态而不是重用

OOP中能够编写一个类。然后我能够不断的继承重用去扩展新需求。

这是类的重用，是所有的重用？重用这个词看上去也许更加的微妙。多态是面向对象的核心特征之中的一个，也不记不清那里听到的：重用仅仅是继承的附带功能。在我们的继承体系中不宜庞大假设一个拥有4,5层的继承体系，对你的理解也添加难度。并且集成体系必须是个干净的继承体系，满足LSP（里氏替换原则）：在所实用到父类的地方都能够替换为子类。还能正常准确工作。这就要求你继承很多其它的是改动扩展父类的行为，尽量避免状态。继承仅仅是不要为了重用的为目的。在恰当的时机更好的办法是实现一个全然的类来替换不能满足现有需求的类。

这也是oo原则第二原则吧。组合优先于继承。组合比方设计模式中的策略模式，你得到的是一个算法组合功能个数是一个笛卡尔积。但也是绝对的组合。仅仅是优先，不是代替，软件和现实世界都是充满了矛盾的。就如开篇第一条“软件中唯一不变的就是变化”就是最大的矛盾，来自辩证唯物主义，你要做的是权衡。组合表述的是总体的替换，如策略模式模式的算法总体替换。继承是部分的少量的扩展改动行为。比方设计模式中的模版方案，在父类的流程控制下，部分步骤的改动，数据，事务的流转控制权在父类。这条在最后说一句：设计模式不是万能的。仅仅是前人的优秀经验。是依赖于场景存在的，了解设计模式我认为更重要的是其使用场景，在遇见同类场景的时候知道能够有这样的模式作为解决方式也许更好，仅作为供你选择的解决这个问题方案。

6：用户的一切输入都是万恶的

用户的输入是属于我们系统之外的，是无法控制的，是不可罗列的。

对于用户来说软件仅仅是一个黑盒子，不须要，也不是必需了解详细内在实现。对于汽车销售人员不须要了解发动机螺栓是怎么上的一样。他了解宣传的是能有什么优势，能给用户带来那些方面的满足，价格？性能？速度？豪华？….对于门户站点来说你相应的用户不仅是可信任的用户，可能还有竞争对手黑客攻击行为。

假设你的系统信任于用户的输入，早晚一天总会“纸包不住火的”。用户有意无意的一次输入就可能导致你系统的功能性的全盘崩溃，你不应该限制用户的操作。你是不能命令用户该输入什么不能输入什么，比方某天某人使用用户可能降工资了或者挨批了。心情不好，你或许会潜意思的对你的系统进行挑战。

讲到这里随便说一句，曾经项目组有人层提过因为自己主动化測试server执行时间太长了。把部分验证等逻辑移到单元測试中保证。

对于我的理解来说自己主动化測试近似于集成測试吧，功能性測试，应该是黑盒子。在单元測试中我们总是如果输入是正确的。某个依赖也是正确的。验证输出的正确。

而集成測试重点在于这一些都是层次的组合，贯通。不存在如果的正确性，仅仅有来自測试人员的測试用例得到预期的输出。

今天就写到这里吧。还有非常多可是一下想不起来。兴许有机会的话对于重要的也会继续补上。

现实是矛盾的，没有完美的设计，也没有绝对的简单。生活也是如此就如：简单就是幸福，快乐就是幸福。那么简单的标准是什么？如何才是快乐？这在于你自己的抉择，权衡。想起了某次面试和小公司面试官谈话。面试官说ORM存在性能问题，并且一直在纠结的说反对DDD。反对模式。本人先说了假设存在了性能问题有什么解决方式。首先怎么做假设不能满足再怎么做。从索引缓存到分表服务集群，再总结性的一句话：架构如人生。总是要面临得到取舍。

假设你对项目管理、系统架构有兴趣。请加微信订阅号“softjg”。增加这个PM、架构师的大家庭