软件架构经验总结

软件架构经验总结

任何一款软件，从无到有，从初级到完善，一般都会经历一个漫长的过程。在这个过程当中，架构师的水平和软件体系架构本身的灵活性，就会处于一个很关键的位置。太多的软件，因为架构的问题，造成产品发布日期延迟，或者项目交付工期延迟，给测试、实施、售后等工作等造成一系列的问题。

还有些情况是因为在同期有很多种竞争技术，由于架构师选择了其中一种技术，而这种技术，在长期发展过程当中，败给了其他的竞争技术，使得基于这种技术的产品不得不重新开发。比如，我以前基于Java Swing做了一款工作流和SOA架构的产品，在世界500强的公司当中，很多都是我们这款产品的客户，客户对它的评价也相当高，它曾是公司很赚钱很核心的产品。但是Java Swing在跟Eclipse的SWT竞争过程中败下阵来，使得我们不得不基于Eclipse插件机制，重新开发了一套功能类似的产品，以方便以后升级。在这个转型过程当中的损失，是很难计算出来的。再比如，现在火热的移动平台开发，是选择Android平台，还是选择iPhone平台？是选择Symbian平台，还是选择Windows Mobile平台？也是一个很恼人的问题，架构师选错了平台，就可能给公司造成难以估算的影响。

而程序员本身，也会给架构师带来压力和困惑。例如：SSH（Spring、Struts、Hibernate）架构流行很多年了，很多公司和程序员都拿它来开发，而把自己公司的不是基于以上开发框架的自主开发框架，称之为“山寨框架”（跟Struts、Hibernate、Spring比较起来）。他们一般信奉拿来主义，不重新发明“轮子”的理念深入人心。我自己面试过无数人，也曾被无数人面试，问到难度稍微大一些的问题，比如线程、Web服务器负载均衡以及Java垃圾回收机制等，一般都回答不出来，或者讲不明白，这就是程序员“重商主义”、“拿来主义”的弊端，只知道如何使用，对其原理一概不知。说实话，不查资料，很多我也不明白，也是只知道个大概。客观原因是平时很少使用，主观原因是自己的懒惰。我个人是非常不赞同“不重新发明轮子”这个理念的，不重新发明轮子，你就不知道这个轮子的架构机制。对很多问题的细节，被人问起来，也只能很含糊地说：也许大概可能是，不过恐怕不见得，其实这还是没有掌握。而这些机轮子本身，会用到缓存、多线程等很多需要深入研究的问题。弄明白了别人的轮子，那些很含糊的问题，一般也就解决了。

很多程序员，包括工作十几年的所谓老程序员，都自觉不自觉地遵循着某种理念，比如他会告诉你“Action只能调用一个Manager，所有与数据库打交道的地方，只能写到DAO层”，如果你不这么做，他就会告诉你，你的代码不是面向对象的，不友好的，是不符合某某设计模式的。还有的所谓很牛的程序员，用垒鸡窝和盖大厦，来标榜他的架构是多么多么符合所谓的范式和架构，或者遵循某大师的XP理论。可是他们都忘记了，我们编写程序代码的最根本的目的是什么？我们开发软件并不是为了让它面向对象化，或遵循某些设计模式，我们开发软件是为了解决问题。所谓为了以后的扩展或者10年之后的需求，你的架构到时候真的就不用做任何修改吗？我这么说的意思，不是鼓励大家不遵循任何开发的方法论，不做任何代码的约定，随意随心乱写，毕竟我们是一个团队作业，而不是自己一个人在根据自己的喜好开发个人软件。我的意思是说，我们不要迷信什么，山寨架构也好，官方架构也好，我们一定要根据自己项目的实际情况，加以改进，不要生搬硬套。 

最后摘抄某大侠在dzone.com（http://java.dzone.com/news/object-orientation-not-goal）一段原话做结尾：通常，当有些很精明的程序员对我的做法说三道四，却又根本不知道我是在解决什么问题时，我很苦恼。这就像是在说“我比你更知道你需要什么，所以我们不能用这个、那个工具/风格/架构”。但事实却是，什么样的工具或思路才是他们解决相应问题所需要的，这些精明的思想家并不比每个开发人员更清楚。做个类比，这极其类似那些精明的政治家宣传自己最知道人们究竟应该怎么活着……