作者：Mark Levison 译者：赖勤毅 发布于 2010年11月5日

现在已经到第十次迭代开发周期了，你的项目开发速度开始变慢。在之前的几个迭代周期中，团队没有像以前那样完成很多的“故事场景”（stories）。此外，最近在新的故事场景和回溯中却发现更多缺陷(bug)。项目经理知道，团队成员没有变，他们也花同样的时间工作。但是，客户会发问：“发生什么事情了？这个团队还在努力工作吗？”

很多敏捷团队的产品改进率为150-500%，可是你们的项目看起来却貌似只有20-40%左右的改进率。这到底是怎么回事呢？在此我们找不到什么大问题；相反，只是有无数的小问题。有时，这些只是一些为了方便而使用的捷径（开发人员没有时间去清理这些修改），有时开发人员仅仅是不熟悉这中语言。还有一些问题就是，代码跟灌木丛一样凌乱，需要大幅度的修整。所有这些都属于“技术债务”。

什么是“技术债务”？

它就是“那些内在的事物，现在你不去解决，遗留下来（不干完），它就会阻碍未来开发”[Ward Cunningham]。 表面上，应用程序看起来质量很高且状况良好，但是这些问题却隐藏在下面。 QA（质量保证部门）甚至可能告诉你说，这个应用程序真是不错，几乎找不到缺陷，但是其中仍然存在“技术债务”，如果我们没有很好地管理并设法降低这些“技术债务”，那么，程序编写和维护的代价最终将会超过它对客户的价值。

技术债务就像信用卡一样，会有很高的利息率，就如同给团队留下了大量的帐务开销。这种情况下，开销将会体现在时间花费和解决问题所需的努力上面。开发团队拖延债务的时间越长，所积累的利息就越多（会额外增加很多工作），付出的成本也就越高。

另外，这还增加了实际的财务支出：开发团队处理技术债务所花费的时间，可以用在对团队有价值的其它工作上。同时，这些难读的代码引起的技术债务也让我们难以找到软件的缺陷。再且，理解代码所损失的时间还可以用来做其它更有价值的事情呢。

我们为何要累积技术债务呢？

项目编码初期，不整理代码，不写单元测试，也不做测试驱动开发，整个团队粗制滥造出更多的“故事场景”。 这些问题通常都不会马上暴露出来，而循规蹈矩地编写代码往往需要更多的时间，特别是在早期阶段。

技术债务来自哪里？

• 没有经验的开发人员 —— 有些项目里面，编写Java/C#/Ruby的开发人员没有接受过培训，或者没有面向对象的观念。结果呢，他们会一直编写适用于他们曾经习惯的编程语言——像Visual Basic等——的代码。
• 项目工期的压力 —— 那些来自于经理或客户的显性压力和其它一些潜在的压力。“我们承诺在以后迭代（发布）的故事场景中做到这些”。开发团队会发现他们不会交付这些承诺的发行版本（迭代版本），而是采取便捷的手段。“我们不得不把事情做完；我们无法承担修整代码所耗费的时间。如果这不是新特性/缺陷，那么就不用去做”。 不幸的是，这些观点还会得到管理人员的支持，特别是在管理层没有意识到这些成本的时候。
• 凌乱而难读的代码。当一个方法或类中存在一些难读的代码，下一个开发人员继续这些工作的时候，就觉得他也没有必要迫使自己编写清晰的代码。所以，每次有人接手这些代码的时候，一小段脏乱的代码将会变成一大堆乱七八糟的代码。
• 专业领域的代码 —— 往往有这样的观念：这些代码看起来就是很差劲，但是这不属于我的领域，所以我不能或不会改变它们。另外，对于修改专业领域的代码，开发人员也会觉得力不从心。
• 过度复杂 —— 开发人员经常趋向于在需求之前设计解决方案。而且，很多情况下他们的代码没有找到正确的方向，还会写一些没有用处的代码。或者，这些代码没有真正地符合需求，因为代码在问题还没有完全明白的时候就已经写完了。还有另外一种情况，过度设计花费了额外的时间，产生的代码不是不能使用就是不符合项目的需求。
• 糟糕的设计 —— 有些解决方案只是设计不佳。但在设计不好的代码上面继续扩展，而不去解决这个问题，会使问题更加恶化。

解决问题

这个问题的并不是一下子可以解决的，解决方案需要通过几个迭代周期。并且，你需要耐心，并要从多个角度寻找解决途径。

解决方案中的要点

1. 让开发人员接受语言方面的基本培训并教授他们面向对象的原理，从而把他们的理解力提升至入门阶段。要想既成功又有效的话，这需要花几个礼拜的时间培训，还需要有精通这方面的人员来跟进和支持这一系列培训。
2. 告诉开发人员和管理人员，当前的这些问题都是需要花费企业资金的。这点尤其重要，因为它会使解决这些问题的意义更加明确。你要清楚地告诉他们，管理人员会重视这些问题，并且已经开始着手偿还这些技术债务了。不断支持这些工作使之成为常规的原则之一，这样整个团队就会信任这个准则。
3. 提供一些培训，包括代码的坏味道，重构，单元测试和测试驱动开发等。还可以结合课堂会议，基于网络的材料和书籍来进行培训。
4. 在工作的时候，给他们一些空余时间去研究和练习他们的技能（一个礼拜两个小时应该是达成这个目标的最小的时间量）。练习的代码应该被丢弃，这样，他们就能无拘无束地尝试和试验一些事情，不管怎么样，他们不用在基础代码库上面进行练习。花点时间练习和研究应该是最有用的建议了。假如没有为他们提供空闲的时间，就压根不会发现真正合理的敏捷开发方式。这种组织方式也被称为“道场”-Dojo（更加详细的资料可以参考 TDD Randori Session 和 TDD Randori Workshop）。
5. 使用工具（静态分析，单元测试，持续集成，自动化可接受性测试）来帮助团队发现、减少和衡量他们的技术债务量。应该在团队层面利用这些度量数据，而不能分享给管理人员。团队成员需要知道，他们并不会因为对这些技术债务的度量而接受奖励或者遭受惩罚。如果我们把这些度量数据报告给管理层，并由管理层来追踪的话，开发人员很快会找到一些窍门来规避它们，这样就失去了本来应有的价值了。
6. 当人们完成了他们的培训或者在技术上取得了少许提升时，应该得到奖励。奖励可以是给予一次认可的表彰或者是一些小小的礼物，但不要直接给予现金奖励。
7. 每两个礼拜进行一次午餐聚会和一些关于技术方面的学习型会议。利用这些会议来促进开发成员之间的讨论。提供午餐可以提高参会人数。另外比较重要的是需要管理人员每次都来出席，这样就很清楚的表明他们也一直支持大家提高技术。
8. 维护关于技术债务的备忘录 – 任何时候，如果开发人员发现一些无法立即应付的技术债务时，就需要填写一份技术债务登记卡。开发人员应该优先考虑这些技术债务，并花费10-15%的精力来偿还这些技术债务。大多数项目中，任何的一些小事都会使问题变得更加严重。

基于这样的立场，你会发现问题，也会拥有机会。你的问题是：项目的基础代码一直在积累技术债务，但是这些债务已经开始下降了。然而，现在跟客户申请用于处理这些问题的资金会跟处理这些问题一样困难。你的机遇是：提高了开发人员的技能；清楚地表达了管理层对这项工作的支持，还有，软件的代码质量会不断改善，软件缺陷的数目也会不断减少。同时这也会很好的提高团队的整体开发能力。

一、从数据的角度来看，数据包括：收集、存储、分析（挖掘）、展示、提取。兼顾目前的系统，收集、存储、挖掘、提取，这几个环节的系统需要加强。特别是收集和提取这块。

由于历史的原因，加之没有系统规划过，之前的数据收集来源比较零散，这样导致分析数据时需要从各个地方来同步数据。当业务多了之后，这些乱七八糟的来源就够让人头疼了。这次规划的一个重点就是，建立一套游戏数据收集系统。游戏分析涉及的数据（日志类）都从这个系统中获取，不再单独分析各自的业务数据。业务系统采用数据上报的方式，按照固定的格式来上报数据。例如：登录、注册、充值、消耗等等。

采用这套游戏数据收集系统，还有一个重要的原因。现在我们的游戏都是独立运营游戏（我们是甲方），那么我们就可以采用类似腾讯的办法，事先定义好数据规范，要求游戏方按照我们的格式上报相关数据给我们。这样我们的数据分析系统就可以做到非常通用。不管接多少游戏，分析和展示系统都统一。

数据提取，这里主要是指临时数据。这是我们这边的一个顽疾。临时数据其实包括两个部分：数据来源和数据分析。一个常见的需求就是：分析一堆帐号（数据来源）的后续行为（数据分析）。因为临时数据的业务规则复杂，并且数据来源千奇百怪，之前采用过全手工、全自动的方式来实现，但是都失败了。现在想到的一个解决方案就是，基于游戏数据收集系统之上，再开发一个临时数据分析系统。

游戏数据收集系统统一了数据的来源和格式，方便存储和提取原始数据。这基本解决了数据来源的问题。临时数据分析系统，可以事先实现常见的分析逻辑（例如：登录、留存、保有、付费人数、付费金额、消耗等等），然后采用过滤器模式或包装器模式来实现。这其实是一个半自动化的方案。系统的用户是开发人员和产品人员。开发完这套系统应该可以省掉60%以上的临时数据任务。

另外，只要数据都是来自这套游戏数据收集系统，存储、分析，包括挖掘都会简单很多。存储都会在HDFS上，分析基本都使用Hive，挖掘用Mahout。

游戏数据挖掘是需要单独发展的一块业务，特别是现在专注独立运营之后。目前这块我们还需要更多的时间来积累经验。

二、从服务的角度来看，服务包括：服务框架、服务管理、服务监控。

服务也是一个大范畴。服务化框架、页面登录服务器、GM接口，这些都属于服务相关的内容。兼顾目前的系统，这些内容都已经基本实现，这次只是做比较大的版本改进。

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

1、线上应用故障排查之一：高CPU占用

2、线上应用故障排查之二：高内存占用

3、线上应用故障排查之三：高I/O占用，包括磁盘I/O、网络I/O、数据库I/O等。

4、线上应用故障排查之四：程序僵死

敬请期待！

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

搞Java开发的，经常会碰到下面两种异常：

1、java.lang.OutOfMemoryError: PermGen space

2、java.lang.OutOfMemoryError: Java heap space

要详细解释这两种异常，需要简单重提下Java内存模型。

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

Java内存模型是描述Java程序中各变量（实例域、静态域和数组元素）之间的关系，以及在实际计算机系统中将变量存储到内存和从内存取出变量这样的低层细节。

在Java虚拟机中，内存分为三个代：新生代（New）、老生代（Old）、永久代（Perm）。

（1）新生代New：新建的对象都存放这里

（2）老生代Old：存放从新生代New中迁移过来的生命周期较久的对象。新生代New和老生代Old共同组成了堆内存。

（3）永久代Perm：是非堆内存的组成部分。主要存放加载的Class类级对象如class本身，method，field等等。

如果出现java.lang.OutOfMemoryError: Java heap space异常，说明Java虚拟机的堆内存不够。原因有二：

（1）Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。

（2）代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）。

如果出现java.lang.OutOfMemoryError: PermGen space，说明是Java虚拟机对永久代Perm内存设置不够。

一般出现这种情况，都是程序启动需要加载大量的第三方jar包。例如：在一个Tomcat下部署了太多的应用。

从代码的角度，软件开发人员主要关注java.lang.OutOfMemoryError: Java heap space异常，减少不必要的对象创建，同时避免内存泄漏。

现在以一个实际的例子分析内存占用的故障排查。

通过top命令，发现PID为9004的Java进程一直占用比较高的内存不释放（24.7%），出现高内存占用的故障。

想起上一篇线上应用故障排查之一：高CPU占用介绍的PS命令，能否找到具体是哪个的线程呢？

ps -mp 9004 -o THREAD,tid,time,rss,size,%mem

遗憾的是，发现PS命令可以查到具体进程的CPU占用情况，但是不能查到一个进程下具体线程的内存占用情况。

只好寻求其他方法了，幸好Java提供了一个很好的内存监控工具：jmap命令

jmap命令有下面几种常用的用法：

•jmap [pid]

•jmap -histo:live [pid] >a.log

•jmap -dump:live,format=b,file=xxx.xxx [pid]

用得最多是后面两个。其中，jmap -histo:live [pid] 可以查看当前Java进程创建的活跃对象数目和占用内存大小。

jmap -dump:live,format=b,file=xxx.xxx [pid] 则可以将当前Java进程的内存占用情况导出来，方便用专门的内存分析工具（例如：MAT）来分析。

这个命令对于分析是否有内存泄漏很有帮助。具体怎么使用可以查看本博的另一篇文章：利用Eclipse Memory Analyzer Tool（MAT）分析内存泄漏

这里详细介绍下jmap -histo:live [pid] 命令：

从上图可以看出，int数组、constMethodKlass、methodKlass、constantPoolKlass都占用了大量的内存。

特别是占用了大量内存的int数组，需要仔细检查相关代码。

最后，总结下排查内存故障的方法和技巧有哪些：

1、top命令：Linux命令。可以查看实时的内存使用情况。  

2、jmap -histo:live [pid]，然后分析具体的对象数目和占用内存大小，从而定位代码。

3、jmap -dump:live,format=b,file=xxx.xxx [pid]，然后利用MAT工具分析是否存在内存泄漏等等。

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

以我们最近出现的一个实际故障为例，介绍怎么定位和解决这类问题。

根据top命令，发现PID为28555的Java进程占用CPU高达200%，出现故障。

通过ps aux | grep PID命令，可以进一步确定是tomcat进程出现了问题。但是，怎么定位到具体线程或者代码呢？

首先显示线程列表:

ps -mp pid -o THREAD,tid,time

找到了耗时最高的线程28802，占用CPU时间快两个小时了！

其次将需要的线程ID转换为16进制格式：

printf "%x\n" tid

最后打印线程的堆栈信息：

jstack pid |grep tid -A 30

找到出现问题的代码了！

现在来分析下具体的代码：ShortSocketIO.readBytes(ShortSocketIO.java:106)

ShortSocketIO是应用封装的一个用短连接Socket通信的工具类。readBytes函数的代码如下：

public byte[] readBytes(int length) throws IOException {

    if ((this.socket == null) || (!this.socket.isConnected())) {

        throw new IOException("++++ attempting to read from closed socket");

    }

    byte[] result = null;

    ByteArrayOutputStream bos = new ByteArrayOutputStream();

    if (this.recIndex >= length) {

           bos.write(this.recBuf, 0, length);

           byte[] newBuf = new byte[this.recBufSize];

           if (this.recIndex > length) {

               System.arraycopy(this.recBuf, length, newBuf, 0, this.recIndex - length);

           }

           this.recBuf = newBuf;

           this.recIndex -= length;

    } else {

           int totalread = length;

           if (this.recIndex > 0) {

                totalread -= this.recIndex;

                bos.write(this.recBuf, 0, this.recIndex);

                this.recBuf = new byte[this.recBufSize];

                this.recIndex = 0;

    }

    int readCount = 0;

    while (totalread > 0) {

         if ((readCount = this.in.read(this.recBuf)) > 0) {

                if (totalread > readCount) {

                      bos.write(this.recBuf, 0, readCount);

                      this.recBuf = new byte[this.recBufSize];

                      this.recIndex = 0;

               } else {

                     bos.write(this.recBuf, 0, totalread);

                     byte[] newBuf = new byte[this.recBufSize];

                     System.arraycopy(this.recBuf, totalread, newBuf, 0, readCount - totalread);

                     this.recBuf = newBuf;

                     this.recIndex = (readCount - totalread);

             }

             totalread -= readCount;

        }

   }

}

问题就出在标红的代码部分。如果this.in.read()返回的数据小于等于0时，循环就一直进行下去了。而这种情况在网络拥塞的时候是可能发生的。

至于具体怎么修改就看业务逻辑应该怎么对待这种特殊情况了。

最后，总结下排查CPU故障的方法和技巧有哪些：

1、top命令：Linux命令。可以查看实时的CPU使用情况。也可以查看最近一段时间的CPU使用情况。

2、PS命令：Linux命令。强大的进程状态监控命令。可以查看进程以及进程中线程的当前CPU使用情况。属于当前状态的采样数据。

3、jstack：Java提供的命令。可以查看某个进程的当前线程栈运行情况。根据这个命令的输出可以定位某个进程的所有线程的当前运行状态、运行代码，以及是否死锁等等。

4、pstack：Linux命令。可以查看某个进程的当前线程栈运行情况。

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

根据经验，应该是程序有死锁情况，于是在线上运行“jstack –F <pid>”命令，想把线程堆栈dump下来。

但是，发现这个命令老是报下面的错误：

Thread 27316: (state = BLOCKED)
Error occurred during stack walking:
sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp

线上环境是：

Linux 2.6.18-194.el5 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)

经过分析发现，这是JDK6u23之前版本的一个Bug，将JDK升级到最新版本（1.6.0_31）就可以解决问题了。

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

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

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

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

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

1. 关注于尽快交付价值

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

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

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

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

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

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

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

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

2.1 能够迅速发现需要的类

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

2.2 能够分析变更的影响

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 对上述内容的两个忠告

4.1 不要降低代码质量

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

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

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

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

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

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

5. 结论

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

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

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

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

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

英文原文：Choudary Kothapalli    本文由  陈晨 编译并投稿于伯乐在线

转载自伯乐在线 http://blog.jobbole.com/16526/

  利用Hadoop分析BHO上报日志时，发现很多日志文件会出现下面的错误：

  即在map结束的时候抛出Java堆栈溢出异常！

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

  首先设置下面的参数：

发现还是解决不了问题。开始怀疑代码问题，于是进行了一系列的优化：

主要的优化是，在map和reduce程序中，重用key和value对象。但是发现还是解决不了问题。并且mapred.child.java.opts设置3G也无济于事。

没有办法，只好继续找原因。最后发现一个规律：报这个异常出错的日志不一定是最大的日志。

只好使用最后一招了，直接分析报错时的Java堆内存情况！

再次出现异常的时候，把集群里面所有的机器的Hadoop进程的堆内存导出来分析！

主要是下面的几类进程：

同时，关注每台机器的top命令输出，可以从内存的使用情况中发现主要是哪台机器出问题！然后重点导出这台机器的Java堆参数！

jmap -dump:live,format=b,file=heapt0923.bin pid

剩下来的就是把/data/bhopid_output/heapt0923.bin这个文件复制到本地，利用Eclipse Memory Analyzer Tool 进行分析！

下面是分析的结果：

发现有两个内存泄漏的情况：

1、

2、

找到根本原因：说明日志文件有这样很大的空记录导致的！在代码中把这些记录忽略掉即可！

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

　　
    优化的地方涉及：

　　1.减少重复代码，保证功能修改只会发生在一个地方。

　　2.优化界面，布局更加合理，美观。

　　3.优化SQL语句，提高性能。

　　4.JS文件的整合，公用的函数提取出来成为单独的文件，减少HTTP请求的次数（浏览器缓存），同时也减少当前页面的大小。

　　5.加了缓存模块

　　经过这些优化之后，系统性能提升不少。最重要的是，系统的可维护性大大地提高了。相信以后增加功能不会那么累了。看来连续两个晚上的加班时值得的。