软件架构经验总结
任何一款软件，从无到有，再到完善，一般都会经历一个漫长的过程。在这个过程当中，架构师的水平和软件体系架构本身的灵活性，就会处于一个很核心的位置。太多的软件，因为架构的问题，造成产品发布日期延迟，或者项目交付工期延迟，给测试、实施、售后等工作等造成一系列的问题。
还有的原因，是因为在同期，有很多种竞争技术，由于架构师的选型，选择了其中一种技术，而这种技术，在长期发展过程当中，败给了竞争技术，使得基于这种技术的产品不得不重新开发。比如，我服务的公司，以前基于Java Swing做了一款工作流和SOA架构的产品，在世界500强的公司当中，很多都是我们这款产品的客户，客户对它的评价也相当高，它是公司很赚钱很核心的产品。但是Java Swing在跟Eclipse的SWT竞争过程中，败下阵来，使得我们公司，不得不基于Eclipse插件机制，重新开发一套功能类似的产品，以方便以后升级。在这个转型过程当中，公司的损失，是很难计算出来的。再比如，现在火热的移动平台开发，是选择Android平台，还是选择IPhone平台，还是选择Symbian、Win dows Mobile平台？也是一个很恼人的问题，架构师选错了平台，就可能给公司造成难以估算的影响。
而程序员本身，也会给架构师带来压力和困惑。例如：SSH(Spring、Struts、Hibernate)架构流行很多年了，很多公司和程序员都拿它来开发，而把自己公司的不是基于以上开发框架的自主开发框架，称之为“山寨框架”（跟Struts、Hibernate、Spring比较起来）。他们一般信奉拿来主义，不重新发明“轮子”的理念深入人心。我自己面试过无数人，也曾被无人数面，问到难度稍微大一些的问题，比如：线程，Web 服务器负载均衡以及Java 垃圾回收机制，等等，一般都回答不出来，或者讲不明白，这就是程序员“重商主义”、“拿来主义”的弊端，只知道如何使用，对其原理一概不知道。说实话，不查资料，很多我也不明白，也是只知道个大概齐。客观原因是平时很少使用，主观原因也是在自己的懒惰。我个人是非常不赞同“不重新发明轮子”这个理念的，不重新发明轮子，你就不知道这个轮子的架构机制。对很多问题的细节，被人问起来，也只能很含糊的说：也许大概可能是，不过恐怕不见得，所以个人总以为，最终还是没把握。而这些机轮子本身，会用到缓存、多线程等等很多需要很深入研究的问题。弄明白了别人的轮子，那些很含糊的问题，一般也就解决了。
很多程序员，包括工作十几年的所谓老程序员，都自觉不自觉地遵循着某种理念，比如：他会告诉你“Action必须只能调用一个Manager，所有的与数据库打交道的地方，只能写到DAO层”，如果你不这么做，他就会告诉你，你的代码不是面向对象的，非OO的，不友好的，是不符合某某设计模式的。还有的所谓很牛的程序员，用垒鸡窝和盖大厦，来标榜他的架构是多么多么符合所谓的范式和架构，或者遵循某大师的XP理论。可是他们都忘记了，我们编写程序代码的最根本的目的是什么？我们开发软件并不是为了让它面向对象化，或遵循其它的设计模式。我们开发软件是为了解决问题。所谓为了以后的扩展或者10年之后的需求，你的架构就那么牛X不用做任何修改吗？我这么说的意思，也不是鼓励大家，不遵循任何开发的方法论，不做任何代码的约定，随意随心乱写，毕竟我们是一个团队作业，而不是自己一个人在根据自己的喜好开发个人软件。我的意思是说，我们不要迷信什么，山寨架构也好，官方架构也好，我们一定要根据自己项目的实际情况，加以改进，不要生搬硬套。
最后摘抄某哥们在dzone.com(http://java.dzone.com/news/object-orientation-not-goal)一段原话做结尾：通常，当有些很精明的程序员对我的做法说三道四，却又根本不知道我是在解决什么问题时，我很苦恼。这就像是在说“我比你更知道你需要什么，所以我们不能用这个、那个工具/风格/架构”。但事实却是，这些精明的思想家并不是更知道对于每个开发人员，什么样的工具或思路才是他们解决相应的问题所需要的。做个类比，这个极其类似那些精明的政治家宣传自己最知道人们究竟应该怎么活着…（中文翻译出处：外刊IT评论网