架构腐化之谜.docVIP

架构腐化之谜 作者: 陈金洲??来源: InfoQ??发布时间: 2011-07-21 12:08??阅读: 3182 次??原文链接?? 全屏阅读　 [收藏]?? 　　前言 　　新技术层出不穷。过去十年时间里，我们经历了许多激动人心的新技术，包括那些新的框架、语言、平台、编程模型等等。这些新技术极大地改善了开发人员的工作环境，缩短了产品和项目的面世时间。然而作为在软件行业第一线工作多年的从业者，我们却不得不面对一个现实，那就是当初采用新技术的乐趣随着项目周期的增长而迅速减少。无论当初的选择多么光鲜，半年、一年之后，只要这个项目依然活跃，业务在扩张 —— 越来越多的功能需要加入，一些公共的问题就会逐渐显露出来。构建过慢，完成新功能让你痛不欲生，团队成员无法很快融入，文档无法及时更新等等。 　　在长期运转的项目中，架构的腐化是怎么产生的？为什么常见的面向对象技术无法解决这类问题？如何延缓架构的腐化？ 　　本文将尝试解释这一切，并提出相应的解决方案。读者需要具备相当的开发经验 —— 至少在同一个项目的开发上一年以上；公司负责架构演进、产品演进的角色会从本文找到灵感。 　　架构 　　架构这个词在各种场合不断地以各种面目表现出来。从维基百科的词条看来，我们经常听到的有插件架构（Plugin），以数据库为中心的架构（Database Centric），模型-视图-控制器架构（MVC），面向服务的架构（SOA），三层模型(Three-Tier model)，模型驱动架构（MDA）等等等等。奇妙的是，这些词越大，实际的开发者就越痛苦。SOA很好 —— 但在它提出的那个年代，带给开发者的只是面向厂商虚无缥缈的“公共数据类型”；MDA甚至都没有机会沦为新一轮令人笑话的CASE工具。 　　在继续阅读之前，读者不妨问自己一个问题：在长期的项目中，这些大词是否真的切实给你带来过好处？更为功利的问题是：你，作为战斗在一线的开发者，在长期项目中可曾有过美好的体验？ 　　技术的演变与挥之不去的痛 　　企业应用的发展似乎从十年前开始腾飞。从Microsoft ASP/LAMP(Linux、Apache、MySQL、PHP)年代开始，各种企业应用纷纷向浏览器迁移。经过十年的发展，目前阵营已经百花齐放。与过去不同，现在的技术不仅仅在编程语言方面，常见的编程套路、最佳实践、方法学、社区，都是各种技术独特拥有的。目前占据主流的阵营有： Rails Java EE平台。值得一提的是Java VM已经成为一种新的宿主平台，Scala、JRuby更为活跃并引人瞩目 LAMP平台。Linux/MySQL/Apache并没有多少变化，PHP社区从Rails社区获得了不少养分，出现了许多更加优秀的开发框架 Microsoft .NET平台 Django 　　没有理由对这些新技术不感到振奋。它们解决了许多它们出现之前的问题。在它们的网站上都宣称各种生产效率如何之高的广告语，类似于15分钟创建一个博客应用；2分钟快速教程等等。比起过去21天才能学会XXX，现在它们在上手难度上早已大幅度降低。 　　需要泼冷水的是，本文开篇提出的问题，在上述任何一种技术下，都如幽灵般挥之不去。采用Ruby on Rails的某高效团队在10人团队工作半年之后，构建时间从当初的2分钟变成2小时；我们之前采用Microsoft .NET 3.5 (C# 3.0)的一个项目，在产生2万行代码的时候，构建时间已经超过半小时；我们的一些客户，工作在10年的Java代码库上 —— 他们竭尽全力，保持技术栈与时俱进：Spring、Hibernate、Struts等，面对的困境是他们需要同时打开72个项目才能在Eclipse中获得编译；由于编译打包时间过长，他们去掉了大部分的单元测试 —— 带来巨大的质量风险。 　　如果你真的在一个长期的项目工作过，你应该清楚地了解到，这种痛苦，似乎不是任何一种框架能够根本性解决的。这些新时代的框架解决了大部分显而易见的问题，然而在一个长期项目中所面对的问题，它们无能为力。 　　一步一步：架构是如何腐化的 　　无论架构师在任何时代以何种绚丽的方式描述架构，开发中的项目不会超出下图所示： 　　基本架构示意 　　一些基本的准则： 为了降低耦合，系统应当以恰当的方式进行分层。目前最经考验的分层是MVC+Service。 为了提供基础的访问，一些基本的、平台级别的API应该被引入。用Spring之类的框架来做这件事情。 用AOP进行横向切分业务层面共性的操作，例如日志、权限等。 为了保证项目正常构建，你还需要数据库、持续集成服务器，以及对应的与环境无关的构建脚本和数据库迁移脚本。 　　阶段1 　　满足这个条件的架构在初期是非常令人愉悦的。上一部分我们描述的框架都符合这