话说架构这玩意是很不靠谱的一件事情，为什么这么说呢？因为架构这玩意是一个出力不讨好的一个工作，唉，一开始就如此宣称，一定是有什么原因吧？下面我就这一问题展开阐述，希望引起大家的重视，更加重要的是要提醒大家如何去设计出更加完美的架构来。
一个软件项目开始了，架构师（们）拿到了系统设计要求。原始需求文档或者合同书，开始对具体的业务抽象、建模、架构。分析之后到架构在到交付项目组去执行。对于一个经验成熟的架构师而言，这是一个愉快的过程。很快一个优美的开发架构诞生了。
然后呢交付给项目开发组进行项目实施，如果说架构是骨架的话，那么项目成员就是血肉，只有这两者混合在一起才能构成一个完美的整体。开发、开发、开发…… 开发人员在架构师的指导下，还是比较顺利的按照架构的思想完成了产品的研发，进入的投产实施。到此为止好像已经可以花上一个完美的句号了。看吧，这是一件多么神奇的事情。客户也拿到了自己花钱购买的产品，一片赞不绝口。大家沉浸在一片和谐之中。但是事实是这样子的吗？不是的，我好想是在讲述乌托邦的软件开发吧。哈哈～～～～如果软件都这样交付的话。估计国足都能进世界杯了。
从产品交付的那一刻开始，各种悲剧就开始上演了。为什么呢？软件的甲方比较的不成熟，对待自己提出的产品在没有看到实物之前都是幻想如何如何的美好。程序员这边的需求或者销售也是鼓吹我们的软件如何如何的优秀。这是国情，所以当用户开始用到公司交付的软件产品，客户就不再淡定了，因为他们看到的与期望的有点点的不同，于是乎针对这点提出一个小小的要求，这些看似小小的要求可能会成为架构时的致命缺陷。开始的时候，架构师还能针对提出的小小要求进行论证修改，在此补丁给客户。但是这些修改由于成本、时间等因素，无法做到与原架构的思想完全一致。这是原先优美的架构开始存在一丝丝的不完美，例如美女脸上长出的一些痘痘。这是大家都经历过的吧。好了事情可以完美结束了吧。小小的需求也满足了。短期之内大家都相安无事。一付天下太平的样子。歌舞升平啊，“哥俩好啊，三桃园啊，四季财啊….. ”嘿，还喝上了 ……. 打住，别喝了。客户提出新的业务规则了，要升级系统了。
酒醒了吧，开始设计的软件本来是貌美如花，一尘不染。现在呢满脸痘痘，还好，总体上还是可以让人接受的。随着维护的时间的推移，客户的要求也在逐步的从小小的要求到大型的手术改动。不改不行啊。客户是上帝，而且客户是付钱给你修改。甲方没有什么不满意吧。可是苦了这帮维护的小弟了。这是的软件从满脸的痘痘已经被改成臃肿不堪了，在这个过程由于人员流动、时间紧迫、代码审核松散等情况，这是系统由臃肿到了开始 腐烂的地步了，这与原先的架构师的思想是背道而驰的，已经失去了原先架构的优美的身影了。以至于到最后都没有人愿意维护它了。但是没办法啊，拿钱就要维护，这个时候小弟们开始抱怨、咒骂了？是谁架构出如此蹩脚、丑陋的程序呢？让我们现在如此的被动、无奈、看不到工作的快乐、人生如此的悲哀 。。。。。，抱怨吧！也只能通过抱怨来发泄心中的不满。这是痛苦的不仅仅是作为维护的这些成员，痛苦的还有甲方，钱也出了，系统却越来越垃圾了，软件公司也不痛快啊，给的钱都是那样，但是维护成本却越来越高了，找个维护的人也越来越难了。就这样互相抱怨痛苦N年之后，甲方（客户）终于下决心了，要投入一笔新的资金，重新设计一套系统出来用于取代现有的“腐烂”的系统，大家的苦难在一瞬间都消失了。开始新的忙碌，梳理旧有系统的功能，重新架构全新的系统（旧功能+新功能）。忙啊～～加班啊～～～新的系统有上线了，读到这里请大家想一下，这个新的系统面临如何的命运呢？
架构师开始辩解了，一套一套的说词，各种借口，“客户需求变化无常、系统架构无法与无尽的变化匹配，维护人员完全不理解我架构的思想，原本就不因该那样去修改维护代码 ……. 更有甚者 架构师都不知道给那个东家做长工去了 ”
按照目前的这种局面，好像是一个无解的过程，架构本来就当如此，一个项目的架构是有生命周期的。在好的架构也无法预测出系统未来几年发生的变化，这样一来一个新的业务出现，势必要破坏现有架构的一些规则去迎合新的功能，这种破坏有时是违背架构师原始意图的。说得更加直白一些 维护工程师可能压根就不知道架构的存在，在天马行空的编写自己的代码，用胶水粘到现有的系统上。都是很多人的权宜之计的代码拼凑罢了。
拼凑的代码从量变到质变的时候。系统估计也到了生命的尽头。因为这是会出现无尽bug，无尽的维护的一个可怕的死循环中。本人比较有体会。
下面分析一下为何出现这样的局面，发现问题是好事，更加中的要是分析问题，发现问题而不分析问题是什么行为，是对自己不负责的行为，好了经过本人分析，主要是以下几方面的因素，针对架构层面：
1、 架构过于封闭：封闭带来的坏处是很明显的，就是无法加入新的特性，因为假如一个新的特性不仅仅意味着要构建一个独立的模块，而且还会牵扯到其他在行模块的修改，这种级联改动是很危险的。
2、架构的脆弱性：说白了就是 修改一个地方会引起N的地方修改，这就是所谓的脆弱性。架构层面就是 解耦很失败，代码没有达到一个较好的解耦程度
3、代码复用率低：复用这玩意其实是一个不错的主义，小到一个接口、大道一个模块都可以复用，可是你的架构是面向复用的吗？如果架构的代码总是出现 复制+粘贴的代码用于解耦，那么这是一个失败的架构
4、代码约束不足：新的特性开发随意嵌入，这是不行的，好的架构就算是修改也会让程序员按照制定的规则去修改，而不是肆意的改动。架构的内核代码要具有这个特性
……………
分析问题之后，就要解决问题了，这是人之常情吧，这里的我提到一些是我架构时所考虑的一些细节，希望对读者有所帮助，我的水平有限，如有补充欢迎回帖，其实这些都是大家平时都说的一些名词，例如可扩展性、灵活性、可插入性、较好的复用性。对我而言还有一个特性就是 积木式编程 ……… 架构要学习Linux内核架构，学习这些完美的内核架构，不愁写不出自己的美丽架构。
架构是一尊美女雕塑。是一个艺术结晶的过程。 很晚了～～ 好友阿珍在等我的文章发表，到此为止吧。
谢谢！欢迎继续关注我的日志。
（PS：本篇的核心：一个好的架构是要 考虑 它的可维护性） 血泪的教训啊