MongoDB介绍

当今NoSQL领域中有很多有力的竞争者通过多种方式来处理海量数据问题。其中重要的解决方案之一就是MongoDB。MongoDB是面向文档的弱结构化存储方案，使用JSON格式来展现、查询和修改数据。

MongoDB文档相当完备，扩展规模与安装一样简单。它提供冗余、切片、索引以及map/reduce等概念支持。MongoDB的开源社区非常大且非常活跃。MongoDB在很多大型产品中被实际运用，如：Disney, Craigslist, Foursquare, Github 和SourceForge。MongoDB是一个开源项目，由10gen.com建立并维护，该公司由DoubleClick的前任执行人员创立。同时，10gen也提供了极好的商业支持与参与建设。

MongoDB 与 NoSQL: 缺陷与优势

MongoDB作为一个可用NoSQL方案具有很多优势。我刚开始接触NoSQL数据库了解了一系列基于Java的方案，并且花了大量的时间来弄懂什么是列家族，Hadoop与HBase的关系，ZooKeeper到底是什么。当我终于全部清楚之后，发现Cassandra与HBase确实是对于NoSQL领域非常可靠、可信赖的解决方案。但与其他的解决方案相比，MongoDB让我在能够开始写代码之前，不用理解那么多的概念。

与其他软件相似，MongoDB也存在缺陷。经过一段时间使用MongoDB，我列举经历过并需要注意的一些事情，我成为“Gotchas”：

• 不要按照关系型数据库来思考。这很明显，MongoDB使得构建和执行复杂查询变得非常容易。当实际使用的时候，你会主要关注于效率问题（像我一样）。
• MongoDB的索引是二进制的树。如果你不是很熟悉B-tree，可能需要了解一下。这些都涉及到构建符合提供查询条件需求的建立索引的方式。
• 小心的设计索引结构。这涉及到上面提到的B-tree。刚开始我的索引包含文档中的很多字段，以防我会使用到他们。不要犯同样的错误。我有一个很小集合的索引（大约1千万记录）增长到超过17GB的空间，比集合本身还大。你应该不会想要索引一个包含成百上千个实体的列表字段。
• MongoDB采用了非常有意思的方式来实现NoSQL：采用BSON作为存储，JSON作为展示，JavaScript用于管理和Map/Reduce。因此也引起了一些小问题比如这个 （破坏了Number和Long的相等操作），在MongoDB逐渐流行之后，可能会不断的展示出来。

MongoDB, 命令行与驱动

MongoDB基本是使用JavaScript客户端命令行程序来进行复杂任务管理的，如数据整合和简单信息处理，编程都是完全使用JavaScript语言来的。本文中，我们会展示命令行的使用示例。现在有大量的MongoDB客户端产品提供，并且由MongoDB社区来支持驱动。通常每种编程语言都有驱动，并且所有流行的语言都有包括，一些不那么流行的也包含在内。这篇文章展示了使用MongoDB的Java驱动，并使用一个ORM库（MJORM）与之进行比较。

介绍 MJORM: MongoDB的ORM方案

在解决的众多有意思的问题中，最近NoSQL数据存储在开发者中主要的问题趋势就是对象关系映射。对象关系映射就是将传统中保存在关系型数据库中的持久化数据映射为在应用程序中使用的对象。这使得编程语言使用起来更加流畅和自然。

MongoDB面向文档的架构使得它非常适合对象关系映射，因为文档本身就是以对象形式存储的。可惜没有太多的MongoDB的Java对象关系映射库，但是还是有一些，如morphia-(A type-safe Java library for MongoDB)， spring-data(SpringData项目的MongoDB实现)

这些ORM库大量使用了注解，因为一些原因对我不适合，其中最重要的就是这些被注解的对象在多个项目中的兼容性问题。这让我开始了mongo-Java-orm 或者 "MJORM" (发音 me-yorm)项目，一个MongoDB的Java对象关系映射项目。MJORM是在MIT许可之下，并且在发布在了google code project。项目采用maven构建，并且maven构件仓库托管于google code版本控制服务器。MJORM的最新可用发布版本为0.15，已经由一些项目使用与生产环境中。

开始使用ORM

加入MJORM 库

Maven的使用者首先应当在pom.xml中加入MJORM的maven仓库，使得MJORM构件可用。

<repository>

         <id>mjorm-webdav-maven-repo</id>

         <name>mjorm maven repository</name>

         <url>http://mongo-Java-orm.googlecode.com/svn/maven/repo/</url>

         <layout>default</layout>

</repository>

然后加入依赖:

<dependency>

         <groupId>com.googlecode</groupId>

         <artifactId>mongo-Java-orm</artifactId>

         <version>0.15</version>

</dependency>

这样就可以在应用中引入MJORM代码。假如没有使用maven，则你需要手动下载MJORM的pom.xml中列举的所有依赖。

建立 POJOs

依赖已经导入，可以开始编码了。我们从POJO开始:

class Author {

         private String firstName;

         private String lastName;

         // ... setters and getters ...

}

class Book {

         private String id;

         private String isbn;

         private String title;

         private String description;

         private Author author;

         // ... setters and getters ...

}

我们在这个对象模型中的描述是，作者有ID、姓和名，书有ID、ISNB、标题、描述和作者。

你可能注意到书的id属性是一个字符串，这是为了适应MongoDB的对象ID类型。MongoDB的ID是一个12字节的二进制值显示为一个十六进制的字符串。MongoDB要求集合中的每个文档都必须有一个唯一id，但不要求一定要是ObjectId。目前MJORM只支持ObjectId，并且显示为字符串。

你也可能注意到了Author没有id字段。这是因为Book是它的父文档，因此不需要有id。记住，MongoDB只要求集合中的文档在根级别的id。

创建XML映射文件

下一个步骤就是建立XML映射文件，MJORM能够将MongoDB文档转换为对象。我们为每个文档创建一个对象作为示范，无论将所有的映射放在一个XML文件中还是分开都是可以的。

Author.mjorm.xml:

<?xml version="1.0"?>

<descriptors>

         <object class="Author">

                 <property name="firstName" />

                 <property name="lastName" />

         </object>

</descriptors>

Book.mjorm.xml:

<?xml version="1.0"?>

<descriptors>

         <object class="Book">

                 <property name="id" id="true" auto="true" />

                 <property name="isbn" />

                 <property name="title" />

                 <property name="description" />

                 <property name="author" />

         </object>

</descriptors>

这些映射文件能够很好的自解释。descriptors 元素是根元素，必须包含在每个映射文件中。在它下面是object元素定义了文档与之对应的类。Object包含的property 元素主要用于描述POJO中的属性以及这些属性如何与MongoDB中的文档想对应。property 元素至少必须包含一个name 属性，这个元素就是POJO和MongoDB的文档中的属性名称。column 属性则是可选的，用于特定一个在MongoDB文档中的可选属性名称。

property 元素当中的id属性应该是对象的唯一识别。一个对象只能有一个property 元素包含id属性。auto 的设置会使得MJORM在持久化时为该属性自动生成一个值。

可以在google code的MJORM项目主页中查看XML映射文件的更多细节描述。

整合POJO与XML

我们创建了数据模型以及映射文件，使得MJORM可以从MongoDB序列号以及反序列号POJO。我们可以进行一些有意思的事情了，首先打开MongoDB的链接：

Mongo mongo = new Mongo(

         new MongoURI("mongodb://localhost/mjormIsFun")); // 10gen driver

Mongo 对象是由10gen编写的Java驱动提供的。示例中连接了一个本地的MongoDB实例中的mjormIsFun数据库。接下来我们创建MJORM ObjectMapper 。目前ObjectMapper 在MJORM中的唯一实现就是XmlDescriptorObjectMapper，使用XML结构描述信息。可能之后会增加对注解或其他结构定义的支持。

XmlDescriptorObjectMapper objectMapper = new XmlDescriptorObjectMapper();

mapper.addXmlObjectDescriptor(new File("Book.mjorm.xml"));

mapper.addXmlObjectDescriptor(new File("Author.mjorm.xml"));

建立好了XmlDescriptorObjectMapper 并且加入了映射文件。接下来建立由MJORM提供的MongoDao 对象的实例。

DB db = mongo.getDB("mjormIsFun"); // 10gen driver

MongoDao dao = new MongoDaoImpl(db, objectMapper);

首先我们要获得10gen驱动提供的DB对象实例。然后使用DB和ObjectMapper 建立MongoDao 。我们准备开始持久化数据，建立一个Book 然后保存到MongoDB中。

Book book = new Book();

book.setIsbn("1594743061");

book.setTitle("MongoDB is fun");

book.setDescription("...");

book = dao.createObject("books", book);

System.out.println(book.getId()); // 4f96309f762dd76ece5a9595

首先建立Book 对象并且填值，然后调用MongoDao 的 createObject 方法，将Book 对象传入"books" 的集合中。MJORM会按照之前的xml映射文件将Book 转换为DBObject (这是10gen的Java驱动使用的基本类型)，并保存一个新的文档进"books" 集合。MJORM返回Book对象时，id属性会被填充。请注意，MongoDB默认是不需要在使用前建立数据库或集合的，系统会在需要时自动创建，这可能会造成某些困扰。在MongoDB的命令行中查看Book对象大概如下：

> db.books.find({_id:ObjectId("4f96309f762dd76ece5a9595")}).pretty()

{

         "_id":          ObjectId("4f96309f762dd76ece5a9595"),

         "isbn":         "1594743061",

         "title":        "MongoDB is fun",

         "description": "..."

}

我们来看看假如不用MJORM而直接使用10gen的Java驱动，如何使用createObject 方法：

Book book = new Book();

book.setIsbn("1594743061");

book.setTitle("MongoDB is fun");

book.setDescription("...");

DBObject bookObj = BasicDBObjectBuilder.start()

         .add("isbn",              book.getIsbn())

         .add("title",             book.getTitle())

         .add("description",       book.getDescription())

         .get();

// 'db' is our DB object from earlier

DBCollection col = db.getCollection("books");

col.insert(bookObj);

ObjectId id = ObjectId.class.cast(bookObj.get("_id"));

System.out.println(id.toStringMongod()); // 4f96309f762dd76ece5a9595

下面进行对象的查询:

Book book = dao.readObject("books", "4f96309f762dd76ece5a9595", Book.class);

System.out.println(book.getTitle()); // "MongoDB is fun"

readObject 方法根据给定文档的id从指定的集合中读取文档，转换为对象（再次使用映射文件）并返回。

敏锐的读者会注意到Book还没有指定Author，仍然保存了。这归咎于MongoDB的结构不敏感的特性。我们不能要求集合中的文档包含所有属性（id属性是必须的），所有在MongoDB中没有Author的Book是可以的。我们现在为Book添加一个Author并且更新一下：

Author author = new Author();

author.setFirstName("Brian");

author.setLastName("Dilley");

book.setAuthor(author);

dao.updateObject("books", "4f96309f762dd76ece5a9595", book);

现在Book就包含了Author，并且在MongoDB中持久化了。现在在命令行查看了Book：

> db.books.find({_id:ObjectId("4f96309f762dd76ece5a9595")}).pretty()

{

         "_id":          ObjectId("4f96309f762dd76ece5a9595"),

         "isbn":         "1594743061",

         "title":        "MongoDB is fun",

         "description": "..."

         "author": {

             "firstName": "Brian",

             "lastName": "Dilley"

         }

}

可以看到持久化的Book中已经包含了author。不使用MJORM来操作一遍：

Author author = new Author();

author.setFirstName("Brian");

author.setLastName("Dilley");

book.setAuthor(author);

DBObject bookObj = BasicDBObjectBuilder.start()

         .add("isbn",              book.getIsbn())

         .add("title",             book.getTitle())

         .add("description",       book.getDescription())

         .push("author")

                 .add("firstName",         author.getFirstName())

                 .add("lastName",  author.getLastName())

                 .pop()

         .get();

DBCollection col = db.getCollection("books");

col.update(new BasicDBObject("_id", bookObj.get("_id")), bookObj);

对于MongoDao 方法的深入讨论已经超出了本文的范围。对于将MJORM有兴趣用于实际项目中的用户强烈建议了解一下MJORM项目提供的相关文档，或者MongoDao 接口提供的相关用法。

总结

希望这篇文章对MongoDB和MJORM的亮点有所展示。MongDB是一个优秀的呃NoSQL数据存储，有着大量优秀的特性，会是NoSQL市场中长期竞争者。若你会在一个Java项目中使用MongoDB，希望你也能够考虑使用MJORM作为你的ORM框架。十分欢迎大家提交特性需求、错误异常报告、文档和源码修正。

作者 Bio

Brian Dilley 是一个经验丰富的高级工程师以及项目领导，在Java/Java EE /Spring Framework/Linux内部结构理解和管理有着超过13年的经验。Brian对于创业公司有很多经验，推向市场，构建/维护产品等。他是Iaas、cloud、PHP和Linux的专家，熟悉产品的采购、安装及配置定义，以及公司的软硬件架构包括负载均衡、数据库、微博等。可以follow Brian的 Twitter 。

转变了数据管理方式的技术正是虚拟化。低成本存储、云计算、NoSQL数据库以及Hadoop。当我们提起虚拟化时，已经远远超出为一台物理机器提供一套软件实例这一概念。时至今日，我们可以虚拟化服务器、存储以及网络。所有这些虚拟化意味着我们不再被这些物理条件所限制，能够迅速构建物理环境以支持我们特定时刻的特定需求。当面对Gb、Tb、Pb等级数据量的处理需求时，我们基本能摆脱结构化的数据仓库。我们不在需要仅仅为了发掘业务的某一方面而建立一个特殊的环境了。

低成本存储在业务的数据存储方面节省了开支。高昂的存储成本会使得企业寻找在限定规模的数据之上进行关键业务分析的方案，这样使得如何选择最重要的数据变得十分关键，而且还限制了系统能够处理的数据的质量。

负面影响便是业务最终可能面临很少的选择，因为没有足够的历史数据提供从而识别一个有效关键模式。或者因为高昂的投入使得业务被停止，而使用常规惯例来识别模式。

云计算为那些需要通过海量数据源在合理时间范围内产生结果的需求提供了一个可用的方式。海量数据处理需要两点：弹性存储，CPU。高速网络很有帮助，但是待会我们会看到在发掘软件在处理海量数据时，它并非是系统的瓶颈。弹性存储意味着企业不会在期望操作的数据规模或类型上受到限制，降低了使用数据仓库无法获取最佳结果的风险。更多的CPU使得结果能够在期望的时间范围内更快的被交付。

NoSQL提供了海量数据的支持，但与传统的关系型数据库没有关联。而且大部分NoSQL数据库是开源的，无须支付购买证书等费用。NoSQL对于表结构有着惊人的灵活性，无须随着系统的改进而不断修改完善定义。NoSQL可以支持不同数据源的合并查看，从而成为EII之后另一个备选方案，这或许是NoSQL最重要的方面了。

NoSQL内置了数据冗余与分布式数据存储机制。海量数据的最大问题之一就是磁盘读写，NoSQL通过将数据分布至一系列节点来缓解这个问题。当一个查询请求发出时，这些节点能够并行查询自身节点，而不是仅仅依靠一块磁盘，一个磁盘阵列或一条网络连接等，数据查询能够在节省了读写开支之后变得更加迅速。

最终，我们来讨论Hadoop，集合了上述所有技术力量与一身的用于检测和分析数据的框架。有些人可能认为Hadoop是一项NoSQL技术，实际上Hadoop是一个分布组件的java框架，用于分解“吃大象”（此处也双关Hadoop是以创立者的儿子给自己的一个大象玩具起的名字）的工作——每次一口。

Hadoop自身实际上与待处理数据是各自独立的。它将大型查询任务分解为小的并行查询任务，然后收集结果，并整合出答案返回给用户。Hadoop相对于NoSQL来说是一个并行查询框架，通过云计算驱动节点，运行在低成本存储及虚拟化技术之上。

Kicking的知识回顾

当EII第一次作为最佳实践出现于2003-2004年，关键要素就是无需再移动数据了。当时大部分的数据中心仍然运行于低速网络中，有限的空间用于复制数据。之后，EII成为了当时可用技术和问题域中最优秀的解决方案。EII的某些方面的优秀即使在海量数据中也是很显著的。

EII的优点之一就是将处理过程转移到数据所在地。海量数据方案的关键架构要素之一就是将处理过程转移到数据所在地，而不是转移数据。EII中的一个重要原则就是使用数据归属地的查询功能。这项实践就是构建靠近数据源网络的Web Service，能够建立起通用查询接口，但只针对本地数据库进行查询。我们通过开放的基于Web的接口解决了数据的专有格式的问题，从而使得多个数据子集能够迅速的整合并以统一模式展示。

有了低成本存储和10G网络之后，我们就不必那么担心数据冗余与数据迁移，但还是有其他问题存在的，数据仓库无法确保数据的原始性便是其中之一。在EII中，我们将从原始数据源获取数据视为“黄金准则”，这样就能够保证信息未被修改过，且是准确的。

Big Data要求数据必须转移到新的物理位置，这样可信任度又成为了问题。EII的那些获取基线数据的最佳实践仍然是相关而且重要的。实际上，那些为EII设计开发的Web Services接口最终在Big Data的启用中扮演主要角色。

当然，讨论数据管理不能不涉及到安全问题。EII在安全领域中还是超过了Big Data。技术上来说，Big Data在数据集成方面更加高效与敏捷，但是大部分缺少了固有的安全性，因为在设计上会加大处理的难度。所以，可能要由源系统来担任起数据访问安全方面的责任。因为EII直接在源系统中查询数据，所以必须要求有适当的授权，否则查询就将失败。

上述关于安全讨论描述的是内在的安全控制情况。将访问权限控制列表集成进数据库是非常合理的，这将确保安全能够作为查询的一部分进行维护。然后，一旦能够直接查询NoSQL数据源，就意味着能够自由的访问你所有的数据。

总结

引用老的Virginia Slims的广告中的台词：“我们已经历很长的路途了，宝贝儿！”文中讨论到的技术的发展已经对21世纪第二个10年中的的数据解决方案产生了巨大的影响。商业化与小型化扫除了一些思想体系上的障碍，使得架构师能够专注于问题本身，而不是寻找一些实用及可实现的问题解决方案。构建10000个节点的处理引擎，能够在数秒内处理Pb级别的数据量，却只消耗每小时几便士，这就是数据处理的美好前景。

有了这些新工具，我们就要重新考虑如何推进数据管理。为何数据无法被很好地被维护整合，并且需要花费数万美元。数据管理几乎是每个大中型企业的心病。数据管理曾经在存储、管理、访问、整合以及查询上花费巨大，但是今后不再会是这样了。

关于作者

JP Morgenthal 是在IT策略与云计算方面的世界级专家之一。他在企业复杂问题域的解决方案实施上有着25年的经验。JP Morgenthal以其在技术方面的深度和广度，有利的支持他在企业问题域中的敏感度。他在集成、软件开发和云计算是一位让人尊敬的作者，同时也是InfoQ在引领云计算方面的编辑，并且参与了“云计算：评估风险”项目。 

原文链接：http://www.infoq.com/articles/DataIntegrationFromEIItoBigData

原文引用：http://www.infoq.com/articles/tips-to-developers-starting-on-large-apps

假设你是正在开发和维护一个包含2000个类并使用了很多框架的Java开发者。你要如何理解这些代码？在一个典型的Java企业项目小组中，大部分能够帮你的高级工程师看起来都很忙。文档也很少。你需要尽快交付成果，并向项目组证明自己的能力。你会如何处理这种状况？这篇文字为开始一个新项目的Java开发者提供了一些建议。

1         不要试图一下子搞懂整个项目

好好考虑一下，为什么理解项目代码是第一位的？大部分情况是你被要求修复一个bug或者加强系统已有功能。你要做的第一件事情不是理解整个项目的架构。当对项目进行维护时，这样（理解整个项目架构）可能会对你造成巨大的压力。

即便是有着10年可靠编程经验的Java开发者可能也没有理解项目的核心工作机制，尽管他们可能已经在这个项目工作超过一年（假设他们并非原始开发人员）。比如，对于认证机制或事务管理机制。

他们是怎么做的？他们对于自己负责的部分非常了解，并且能够交付价值给小组。每天的交付价值远比了解一些以后还不确定有没有的东西重要的多。

2         关注于尽快交付价值

那我是否定了你对于项目架构理解的热情了么？完全不。我只是要求你尽早的交付价值，一旦你开始一个项目，搭建了开发环境，你就不应该花一两周时间才交付什么，无论他的规模大小。假如你是一个有经验的程序员却两周都没有任何交付，你的经理怎么会知道你是真的在工作还是在看新闻。

所以交付可以使大家都轻松起来。不要认为你能够做有价值的交付前必须理解整个项目。这是完全错误的。加一段javascript的验证代码对业务就很有价值，经理能够通过你的交付达到对你的信任。这样能够向上级领导证明你的贡献以及员工价值。

日复一日，在你不断修复bug及增强功能之后，就能够慢慢开始理解项目架构。不要低估对系统方方面面理解时需要花费的时间。花3-4天理解认证机制，2-3天理解事物管理。这些都是依靠之前的相似项目的经历，但关键还是要花时间才能透彻的理解。要在日常工作中挤出时间，不要向经理要求特定的时间来做这些。

找找项目是否有一些不断维护的单元测试用例。有效的单元测试用例是理解大型项目代码的很好途径。单元测试能够帮助理解代码片段，包括一个单元的外部接口（单元如何被调用以及返回内容）及其内部实现（调试单元测试比调试整个实际用例简单许多）。

你如果能够很好的理解一些内容，写一些笔记，或者画一些类图、时序图、数据模型图，以便你或日后其他的开发者维护。

3         维护大型项目所必须的技能

你能从事当前的工作，必然已经具有良好的java技术。我们来谈谈能够让你在新项目中良好表现的其他技能。大部分时间，你在项目中的任务是修复bug和增强功能。

有两项很重要的技能能够协助你维护大型项目代码。

3.1         能够迅速发现需要的类

在任何维护活动中，无论是修复bug或增强功能，第一个动作就是识别出当前修复或增强的用例中调用的类。当你定位到需要修复或增强的类/方法，就已经完工了一半。

3.2         能够分析变更的影响

当你在完成必要的修改或增强工作后，最重要的就是要确认你的修改没有破坏代码的其他部分。你要用你的java技术及对其他框架的理解找出变更可能影响的部分。下面有两个简单的例子详细描述了最后提及的情况：

a）当类A的equals()方法变更后，调用一个保护A实例的List的contains()方法时就会被影响到。若Java知识不够，很难考虑到这样的影响。

b）在一个web项目中，我们假设“user id”保存在session中。一个新入程序员可能在“user id”中加入一些信息作为bug修复的方法，但是却不知道会影响到那些关联“user id”的用例。

当你提高了如上两个技能，尽管你对项目不是非常了解，但大部分的维护任务会变得简单很多。若你修复一个bug，你会定位并修复这个bug，并且保证变更不会破坏项目的其他部分。若你增强或加入一个特性，基本上你只需要模仿现有的特性使用相似的设计。

在一个在线银行项目中，为什么“查看账户摘要”和“查看交易历史”的设计需要巨大的差别呢？如果你理解了“查看账户摘要”的设计，完全可以模仿开发出“查看交易历史”的功能。

就修复bug和增强来说，你不必完全理解所有2000个类的工作内容和代码如何运行来推动系统。你若有上面的技能，就能很快定位需要修改的代码的部分，使用良好的java和框架技能修复，保证变更不会破坏项目的其他部分并交付，尽管你可能只知道一小部分项目的设计。

4         使用工具找到需要的变更内容以及变更产生的影响

继续我们尽快交付的主题，你应当寻找那些能够通过尽量少的了解项目但能帮助你尽快实施交付的工具作为辅助。

4.1         迅速发现需要变更内容的工具

无论是修复bug还是系统增强，首先都要找到该用例调用的你需要修改的类及方法。基本有两种方式理解一个用例的工作方式，静态代码分析和运行时分析。

源码分析统计扫描所有代码并且展示类之间的关系。市场上有很多设备与工具。比如：Architexa， AgileJ， UModel， Poseidon等。

所有的静态代码分析工具缺点在于无法确切展示用例中类或方法的运行时调用情况。因此Java新加入了特性，如回调机制（callback patterns）。如静态分析工具无法推断出当页面提交按钮被点击时哪个Servlet被调用了。

运行时分析工具能够展示类和方法在用例运行时的状态。工具包括：MaintainJ， Diver，jSonde，Java Call Tracer等。这些工具可以捕获运行时的堆栈状态，并以此为一个用例生成序列图和类图。

序列图展示了该用例在运行时所有调用的方法。若你在修复一个bug，那这个bug很可能就是这些被调用的方法之一。

若你在增强已有功能，利用序列图理解调用流程然后再修改。可能是新增一个验证，修改DAO等。

若你在新增功能，找到一些相似的特性，利用序列图理解调用流程然后模仿开发新功能。

要小心挑选运行时分析工具。信息过多是这类工具的主要问题。选择一些提供简单过滤无效信息并能够方便的查看各种视图的工具。

4.2         迅速发现需要变更内容的工具

若单元测试有效，可以通过运行单元测试发现变更有没有破坏其他测试用例。有效维护并且覆盖大型企业应用的单元测试还是比较少的。下面有一些针对该情况的工具。

仍然是有两种技术静态代码分析和运行时分析可以使用。市场中有很多静态代码分析工具可用。如：Lattix, Structure101, Coverity, nWire and IntelliJ's DSM。

给定一个变更后的类，上述工具均可识别对该类存在依赖的类的集合。开发者需要根据这些信息“猜测”可能产生影响的用例，因为这些工具无法展示运行时类之间的调用关系。

市场上的可以用于运行时影响分析的工具并不多，除了MaintainJ。MaintainJ先捕获在一个用例中调用的所有类和方法。当所有用例的上述信息都被捕获之后，就很容易发现类的变更对用例的影响。MaintainJ能够有效工作的前置条件就是项目的所有用例都应当先运行一遍，以便能够获得运行时的依赖关系。

总之，目前你在迅速准确分析变更影响方面，还是可以从工具中获得有限的帮助。首先根据需要实施一些影响分析，然后根据自己或小组其他高级成员评审来判断变更的影响。你可能需要上面提到的工具对你的判断进行反复确认。

5         对上述内容的两个忠告

5.1         不要降低代码质量

为了快速交付，所以没有全盘理解架构，但绝不能以降低代码质量为条件。下面是一些你可能因为只考虑快速交付而引发的代码质量问题。

因为修改代码涉及到很多的依赖，所以新增代码相对而言风险较小。例如，有5个用例都调用了某个方法。为了改进某个用例，你需要修改这个方法的实现。最简单的做法就是复制这个方法，重命名，然后在改进的用例中调用新方法。千万不要这么做。代码冗余绝对是非常有害的。尝试对方法进行包装或者重写，甚至是直接修改，然后重新测试所有用例，通常停下来想一想，然后亲手去实施，是一个比较好的方式。

另一个例子是将“private”方法改为“public”，使得别的类也可以调用。尽量不要将非必须的部分暴露出来。假如为了更好的设计需要重构，就应当着手去做。

大部分应用都有确定的结构和模式来实施。修复或增强程序时，确认你没有偏离这样的模式。若对约定不确定，请其他的高级开发者来审核你的变更。若你必须做一些违背约定的实施，尽量放置于一个规模较小的类中（一个200行代码的类中的私有函数应当不会影响应用的整体设计）

5.2         不要停止深入理解项目架构

按照文章列出的方式，假设你能够在对项目了解较少的情况下进行交付并以此持续下去，可能你会停止对项目架构的深入了解。这样从长远角度来说对你的职业生涯没有帮助。当你的经验增加时，你应当承担比较大的模块任务。如构建一个完整的新特性或者修改项目的一些基础设计等较大的改进。当你能够做这些改进时，你对项目的整体架构应该相当了解。文中列举的方法是让你在最短的时间内提升自己，而不是阻止你完整理解整个项目。

6         结论

整篇文章集中在对项目进行必要了解的前提下进行快速交付。你可以在不降低代码质量的前提下这么做。

若修复一个bug，迅速定位并修复。有必要可以使用运行时分析工具。若新增一个特写，可以寻找相似特写，理解流程（有必要使用工具）并编写。

或许这些听起来很简单，但是实用吗？当然。但前提是你有良好的java技术以及对框架足够了解才能先修改代码，然后对变更影响进行分析。对变更影响的分析比实施变更需要更多的技巧。你可能需要高级开发人员协助你分析变更影响。

大约有50%的IT可操作预算用于简单的bug修复和功能增强。根据文中的建议，对于维护活动中的经费的节省应当还是很有帮助的。

作者Choudary Kothapalli 也是MaintainJ项目的建立者。

About the Author

Choudary Kothapalli is the founder of MaintainJ Inc., the company that builds tools to reduce the costs of maintaining large Java applications. He has over 15 years of experience in developing and maintaining enterprise Java applications. He is a Sun Certified Enterprise Architect and Java Programmer. He lives with his wife and two sons in Toronto, Canada.