博客园_Kevin-moon

在IE中本地浏览与服务器浏览同一Html后，出现了奇异的结果

2011-08-03T16:14:00Z

今天在写html的时候，发现了一个郁闷的事情，相同一个Html页面都是通过ie浏览器来浏览，不同的只是在浏览方式上：本地浏览和服务器浏览，可是却出现了不同的效果。

1、本地浏览

将test.html文件放置在本地，然后直接双击打开后，界面如下：

点击按钮后，弹出提示框“97”（就是document.getElementById("float_area").offsetTop）

2、服务器浏览
将test.html文件放置在服务器上或通过VS2010中右键的“View In Browser”进行浏览，界面如下：

点击按钮后，弹出提示框“19”（就是document.getElementById("float_area").offsetTop）

test.html全部代码如下：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title></title>
    <script type="text/javascript">
        function getTop() {

            alert(document.getElementById("float_area").offsetTop);
        }
    </script>
</head>
<body>
    <div style="border: 1px solid #000000; height: 86px; width: 500px;">
        header
    </div>
    <div id="area_1" style="border: 1px solid #000000; height: 121px; width: 500px;">
        area_1
        <div id="float_area" style="border: 1px solid #FF0000; width: 100px; height: 100px; float: left">float_area</div>
    </div>
    <input id="Button1" type="button" value="获取area的offsetTop" onclick="getTop();" />
</body>
</html>

现在我百思不得其解，不知大家有无碰到该类试情况的，该问题到底是ie的问题，还是程序本身的问题？！不同浏览器之间对于获取offsetTop的确存在不同，不过都在ie下面，为什么还会不一致呢。。。。。

本文链接

如何避免JQuery Dialog的内存泄露

2010-06-18T09:18:00Z

对于页面来说，JQuery中的Dialog从效果上来说还可以，而且使用简单，只要短短几行绑定的代码就可以实现弹出效果。

$('#dialog').dialog({
                 autoOpen: false,
                 width: 600,
                 buttons: {
                     "Ok": function() {
                         $(this).dialog("close");
                     },
                     "Cancel": function() {
                         $(this).dialog("close");
                     }
                 }
             });

在一些JS交互性不多的一般页面来说，没有任何问题！但是对于交互性强的，需要动态加载与释放DOM的页面来说，它就是一个悲剧的东西！为什么这样说？大家看下下面的例子：

一段简单的代码，一个DIV是通过动态加载到页面上，然后对该DIV用Dialog进行绑定，以达到弹出的目的！下面的test元素就是<div id="test"></div>。

接着，我需要删除该DOM元素，一般来说，正常的做法都是$("#test").empty();这行简单的代码就完成了！这样有效吗？！当执行完这样代码后，你再用$('#dialog')来获取dialog元素，郁闷的事情发生了，既然获取到了！为什么！不是已经empty了吗！

下面我们来看下这一悲剧是如何造成的，

我们把注意点放到$('#dialog').dialog上面，然后看看JQuery的实现代码是如何写的，当我们跟踪代码到dialog类中的_create方法的时候，问题的原因找到了，看下面这段代码：

uiDialog = (self.uiDialog = $('<div></div>'))
                .appendTo(document.body)
                .hide()
                .addClass(uiDialogClasses + options.dialogClass)
                .css({
                    zIndex: options.zIndex
                })
                // setting tabIndex makes the div focusable
                // setting outline to 0 prevents a border on focus in Mozilla
                .attr('tabIndex', -1).css('outline', 0).keydown(function(event) {
                    if (options.closeOnEscape && event.keyCode &&
                        event.keyCode === $.ui.keyCode.ESCAPE) {

                        self.close(event);
                        event.preventDefault();
                    }
                })
                .attr({
                    role: 'dialog',
                    'aria-labelledby': titleId
                })
                .mousedown(function(event) {
                    self.moveToTop(false, event);
                }),

它既然也动态创建一个div，而且把该div加到了Body上面，然后把dialog中的元素从<div id=test>中移除，加入到该新的div中.....

这就是为什么我们$("#test").empty()后，却对内部的dialog没有起作用了！而且这有一个最不好的一个地方，也是最容易出现内存泄露的地方：它动态的在Body中创建了一个div，这样如果窗体不关闭的话，而你又在不察觉的情况下不断的使用上面的TestAppend方法来动态加载DOM，就会创建N个这样的div！

其实这个问题郁闷的地方不是在如何解决，而且隐藏的很深，很难发现！那么发现之后解决起来就变的简单多了：

if ($('#dialog')[0]) {
$('#dialog').parent().empty();
$('#dialog').parent().remove();
}

当前加上这段后代码后，再做$("#dialog")来测试下，期望的结果终于出现了！dialog元素消失了！

本文链接

JQuery另类视角-动态执行脚本的BUG

2010-06-11T12:21:00Z

最近再用JQuery写一些东西，昨天突然出了个很奇怪的问题：

我通过Ajax请求服务器上的数据（包括html和script），然后将请求的数据动态加载到页面的一个div中，这其实是个很简单的程序，首次执行是很顺利，但是当你执行这个相同动作两次之后，html元素依然可以顺利加载，不过script脚本就失效了！

使用的是JQuery的1.4.1版本，加载的程序是用JQuery中的$(...).append()方法。类试代码如下：

$("#testdiv").append("<script type='text/javascript'> a = 1 ;alert(a);" + "<" + "/script>");

你执行后会发现，前两次能很成功的弹出提示框，但是从第三次开始就失效了！

为什么？javascript本身不可能不支持这种程序的，难道是JQuery程序的BUG吗？！是的，该BUG已经在1.4.2版本中进行了修复，你可以换成JQuery-1.4.2版本来试下。真是郁闷，这个问题害的我查了一个晚上才发现.....

下面让我们分析下这个BUG的原因：

首先看下append函数中主要的执行流程，

执行script脚本的程序是在domManip函数中，大概的逻辑如下：

导致该问题的函数是buildFragment函数，对比下该函数在这两个版本的代码，

仔细看完这两段代码后，会发现这个函数内设置scripts的程序是jQuery.clean( args, doc, fragment, scripts )，这行代码在执行之前有个判断：如果该传入的脚本数据允许支持缓存，并且数据在缓存jQuery.fragments中存在，那么这行代码是跳过的！否则，该行代码执行，设置scripts数据。

现在把关注点放到"允许支持缓存"这句话上，比较这两个版本对于该程序的不同。!rnocache.test( args[0] )，这是1.4.2版本中多加的一行代码。终于找到它，它是这个BUG解决的关键所在。让我们看下这个rnocache的正则表达式：

rnocache = /<script|<object|<embed|<option|<style/i,

看了这么多发现原因了吗！原来1.4.1版本会对script脚本进行缓存，一旦script缓存在脚本后，该脚本中的程序是不会执行的，而1.4.2多加了上面的正则，目的就是对script等这些数据不进行缓存，只要存在就会去执行！

本文链接

JQuery另类视角-动态扩展对象

2010-05-24T14:20:00Z

大家都知道javascript是动态语言，它对动态的支持是与身俱来的。

例如：有一个employee对象，

function employee(){
this.e_id = 0;
this.e_name = "";
}

现在需要为它动态的新增"age"属性和"toString()"方法，

var empObj = new employee();
empObj["age"] = 20;
empObj["toString"] = function() { return this.e_id.toString() + this.e_name; };

一行简单的代码就承担了这项工作，这是Javascript内置支持的，不过往往我们需要在这基础上支持一定程度的扩展，所以会将这一行简单的代码抽成一个方法：

function dym_setprop(obj, key, value) {
    if (obj && key) {
        obj[key] = value;
    }
}

看到这里，我们先让思路做个跳转，跳到C#中的employee对象，如下：

在面向对象的编程中，对外使用的都是属性（Get/Set），那么想想如何将这种方式签入到Javascript中，现在让我们跳回dym_setprop函数内，既在dym_setprop方法中不能使用obj[key]=value的直接赋值方式，而要支持Set。

function dym_setprop(obj, key, value, fn) {
    if (obj && key) {
        fn(obj, key, value);
    }
}

　　参数fn，在dym_setprop中不直接操作任何对象，使用函数fn来代替相应的操作代码，则在这里除了支持Set外，还有其他很大的自由空间。

让我们继续深入dym_setprop方法，现在我们把关注点放在参数value上，大家都清楚value可以是值类型，也可以是函数，对于值类型来说，不用考虑其他东西直接赋值就可以了，对于函数来说就没有这么简单，它支持两种操作：

1、直接将函数赋给新扩展的属性

2、将函数执行的返回值赋给新扩展的属性

在这段代码中参数exec充当了上面两种操作选择的角色，参数pass是一个额外的执行参数。除此之外，大家也许会对fn有些疑惑，因为上面有两个地方使用了，区别只有参数个数不同，fn到底代表什么？！再次想下C#中的属性，它是有Get/Set的，那么在这里fn(obj,key)就相当与Get，而fn(obj,key,temp,pass)就相当与Set。

例如：看下面的代码，对于fn的定义与使用，

employee.AccessProp = function(obj, key, value) {
    if (value) {
        obj[key] = value;
    }
    else {
        return obj[key];
    }
}

dym_setprop(empObj, "age", function(key, value) { return value + 10; }, employee.AccessProp, true);

看了这么多，也许大家觉得郁闷，简单的动态扩展对象程序为什么要以这种方式来编写，有种没事找事的感觉，其实不然，如果你只想做动态扩展对象，那么我建议你别采用上述dym_setprop的思路，但是如果你想从更加抽象的角度上思考，将dym_setprop内的程序作为一个流程执行的模板，那么这是一个不错的方式，因为dym_setprop内部不承担任何具体代码(obj[key]=value或obj[key])的执行，它都通过函数fn来代替，这样对于具体执行来说有完全自由的空间。

理解完上述的思路后，让我们进入本文的核心，JQuery是如何实现动态扩展对象的？access函数，

仔细看完access函数的代码，你一定发现它和dym_setprop的相试度很高，它只是多了一段代码：

if ( typeof key === "object" ) {
   for ( var k in key ) {
    access( elems, k, key[k], exec, fn, value );
   }
   return elems;

}

很容易看出它其实就是用来支持object对象的动态扩展属性。具体的执行流程通过下图来展示：

到这里已经写完了，本文试着从自己的角度上去猜测JQuery的开发者是如何设计出access函数的，让它去支持动态扩展对象，并且说明了access的执行流程。其实对于我的这种猜测不一定正确，不过不妨碍我对于JQuery的研究。

本文链接

如何重构代码-简单、灵活的实现对象复制

2010-05-14T00:51:00Z

前两篇（思路和方法、重构计划）从大的方面上谈了关于重构的话题，这次从小的代码上来看。我们来看下一个的代码如何从简单到复杂，然后重构这些代码。

单个对象复制

在初步的需求中有个很简单的业务，就是定义销售合同，并且合同中可以配置产品设备数据，如下：

其中有个业务功能就是需要对已经存在的销售合同进行复制、剪贴和粘贴的工作。

对于程序来说，它其实就需要实现IClone接口就可以了，

/// <summary>
/// 复制
/// </summary>
public object Clone()
{
    TestObj copiedObj = new TestObj();
    copiedObj.Parent = null;
    copiedObj.Name = this.Name;
    foreach (TestObj obj in this.Child)
    {
        TestObj childCopiedObj = obj.Clone() as TestObj;
        childCopiedObj.Parent = copiedObj;
        copiedObj.Child.Add(childCopiedObj);
    }
    return copiedObj;
}

OK，这很好的实现了业务需求。

批量复制不同对象

业务需求发生了变化，现在对于前期简单的销售合同进行了完善，同时让它变得异常复杂，如下图，

现在要求在所有内部对象都支持复制、剪贴和粘贴，并且也要支持每个部分的数据可以独立导出为特殊的文件，作为数据模板，对于其他合同为了简化操作可以将该模块导入，这些动作在实现前都必须要执行复制，前面的动作不用说都可以理解，对于后面的导入和导出来说，虽然主要通过序列化来支持，但是由于业务特殊性也必须先做复制操作，然后需要对复制后的数据做特殊处理，然后才去序列化。

对于这次的需求来说，很多人的实现方式是对每个类都模仿Clone的方式来写自己的复制方法，这种方式一定是正确的，并且性能是最好的，不过它也是代码量最多的，同时随着业务的进一步完善，它的代码会越来越多。

按照上述的方式来实现，可能需要两周左右的时间，可以想想有没有办法减少开发时间呢？而且也让以后的开发时间减少？

想了很久，终于有了一种思路：

具体的实现代码看下这三个类的代码，

1、最核心的类CopyContainer

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Reflection;

namespace Kevin.CommonFunction.Clone
{
    /// <summary>
    /// 复制元素的容器
    /// </summary>
    /// <remarks>
    /// 执行批量的复制，默认只复制对象的值类型，引用关系保留
    /// </remarks>
    public class CopyContainer
    {
        #region 属性

        /// <summary>
        /// 上下文环境参数
        /// </summary>
        private Dictionary<string, object> mContextParams;

        /// <summary>
        /// 等待被复制的对象
        /// </summary>
        private List<object> mWaitToCopiedItems = new List<object>();

        /// <summary>
        /// 被复制对象-新对象的索引关系
        /// </summary>
        private Dictionary<object, object> mItemIndexs = new Dictionary<object, object>();

        /// <summary>
        /// 构造函数的缓存
        /// </summary>
        private Dictionary<Type, ConstructorInfo> mConstcCache = new Dictionary<Type, ConstructorInfo>();

        /// <summary>
        /// 字段的缓存
        /// </summary>
        private Dictionary<Type, List<FieldInfo>> mFieldInfoCache = new Dictionary<Type, List<FieldInfo>>();

        /// <summary>
        /// 复制后的新对象
        /// </summary>
        private List<object> mNewItems = new List<object>();

        #endregion

        #region 构造函数

        /// <summary>
        ///
        /// </summary>
        public CopyContainer()
        {

        }

        #endregion

        #region 方法

        /// <summary>
        /// 添加等待被复制的对象
        /// </summary>
        /// <param name="waitCopiedItem">需要复制的对象</param>
        public void AddToWaitCopiedItems(object waitCopiedItem)
        {
            if (waitCopiedItem != null && !mWaitToCopiedItems.Contains(waitCopiedItem))
            {
                this.mWaitToCopiedItems.Add(waitCopiedItem);
            }
        }

        /// <summary>
        /// 添加环境参数
        /// </summary>
        /// <param name="key">环境中的唯一主键</param>
        /// <param name="contextParam">环境参数</param>
        public void AddToContextParams(string key, object contextParam)
        {
            if (mContextParams == null)
            {
                mContextParams = new Dictionary<string, object>();
            }

            this.mContextParams.Add(key, contextParam);
        }

        /// <summary>
        /// 复制对象
        /// </summary>
        /// <returns>所有复制后的对象列表</returns>
        public List<object> Clone()
        {
            if (this.mWaitToCopiedItems == null)
            {
                return null;
            }

            foreach (object obj in this.mWaitToCopiedItems)
            {
                object newObj = CopyToNewObj(obj);

                mItemIndexs.Add(obj, newObj);

                mNewItems.Add(newObj);
            }

            foreach (object newObj in mNewItems)
            {
                ICopyReference copiedObj = newObj as ICopyReference;
                if (copiedObj != null)
                {
                    copiedObj.SetReference(this.mContextParams, this.mItemIndexs);
                }
            }

            return this.mNewItems;
        }

        /// <summary>
        /// 复制对象
        /// </summary>
        /// <param name="copeidItem">被复制的对象</param>
        /// <returns>复制后的对象</returns>
        private object CopyToNewObj(object copeidItem)
        {
            Type copiedType = copeidItem.GetType();

            ConstructorInfo constc = this.GetConstructor(copiedType);

            List<FieldInfo> fields = this.GetFieldInfos(copiedType);

            object newObj = constc.Invoke(null);
            foreach (FieldInfo field in fields)
            {
                object copiedValue = field.GetValue(copeidItem);
                field.SetValue(newObj, copiedValue);
            }

            return newObj;
        }

        /// <summary>
        /// 获取构造函数
        /// </summary>
        /// <param name="copiedType">被复制对象的类型</param>
        /// <returns>构造函数</returns>
        private ConstructorInfo GetConstructor(Type copiedType)
        {
            ConstructorInfo copiedConstc = null;

            if (this.mConstcCache.ContainsKey(copiedType))
            {
                copiedConstc = this.mConstcCache[copiedType];
            }
                //该构造函数未加入缓存
            else
            {
                ConstructorInfo[] constructors = copiedType.GetConstructors(BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.Public);

                //循环所有构造函数
                foreach (ConstructorInfo constc in constructors)
                {
                    ParameterInfo[] paramsInConst = constc.GetParameters();

                    if (paramsInConst.Length == 0)
                    {
                        copiedConstc = constc;
                        break;
                    }
                }

                if (copiedConstc == null)
                {
                    throw new Exception(string.Format("类 '{0}' 缺少无参的构造函数", copiedType.FullName));
                }

                this.mConstcCache.Add(copiedType, copiedConstc);
            }

            return copiedConstc;
        }

        /// <summary>
        /// 获取字段
        /// </summary>
        /// <param name="copiedType">被复制对象的字段</param>
        /// <returns>字段</returns>
        private List<FieldInfo> GetFieldInfos(Type copiedType)
        {
            List<FieldInfo> fields = null;

            if (this.mFieldInfoCache.ContainsKey(copiedType))
            {
                fields = this.mFieldInfoCache[copiedType];
            }
                //该字段未加入缓存
            else
            {
                fields = new List<FieldInfo>();

                FieldInfo[] fieldsInCT = copiedType.GetFields(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance);
                foreach (FieldInfo fieldItem in fieldsInCT)
                {
                    //过滤带有KeepFixedValueAttribute自定义属性的字段
                    if (fieldItem.GetCustomAttributes(typeof(KeepFixedValueAttribute), true).Length == 0)
                    {
                        fields.Add(fieldItem);
                    }
                }

                this.mFieldInfoCache.Add(copiedType, fields);
            }

            return fields;
        }

        #endregion
    }
}

2、复制对象引用的操作接口ICopyReference

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Kevin.CommonFunction
{
    /// <summary>
    /// 复制对象引用的操作接口
    /// </summary>
    /// <remarks>
    /// 当在CopyContainer中执行复制的时候，对于复制对象引用的支持
    /// /// </remarks>
    public interface ICopyReference
    {
        /// <summary>
        /// 设置复制对象的引用关系
        /// </summary>
        /// <param name="contextParams">上下文环境参数</param>
        /// <param name="mItemIndexs">被复制对象-新对象的索引关系</param>
        void SetReference(Dictionary<string, object> contextParams, Dictionary<object, object> mItemIndexs);
    }
}

3、用于该复制操作的自定义属性KeepFixedValueAttribute

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Kevin.CommonFunction.Clone
{
    /// <summary>
    /// 当在CopyContainer中执行复制的时候，保留对象特定字段的初始值
    /// </summary>
    public class KeepFixedValueAttribute : Attribute
    {
    }
}

上述是所有的实现代码，下面看下是如何使用的：

using System;
using System.Text;
using System.Collections.Generic;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;

using Kevin.CommonFunction.Clone;
using Kevin.CommonFunction;

namespace Kevin.NUnitTest.Clone
{
    [TestClass]
    public class T_CopyContainer
    {
        [TestMethod]
        public void Clone()
        {
            CopyContainer cc = new CopyContainer();

            TestObj oldObj = new TestObj();
            cc.AddToWaitCopiedItems(oldObj);
            List<object> newItems = cc.Clone();

            Assert.AreEqual(newItems.Count, 2);
        }
    }

    public class TestObj : ICopyReference
    {
        /// <summary>
        /// 自动生成的主键
        /// </summary>
        public int mKey = System.Guid.NewGuid().GetHashCode();

        /// <summary>
        /// 上级对象
        /// </summary>
        public TestObj Parent;

        /// <summary>
        /// 下级对象列表
        /// </summary>
        public List<TestObj> Child = new List<TestObj>();

        /// <summary>
        /// 名称
        /// </summary>
        public string Name;

        /// <summary>
        /// 设置复制对象的引用关系
        /// </summary>
        /// <param name="contextParams">上下文环境参数</param>
        /// <param name="mItemIndexs">被复制对象-新对象的索引关系</param>
        public void SetReference(Dictionary<string, object> contextParams, Dictionary<object, object> mItemIndexs)
        {
            List<object> arrCopiedItems = new List<object>();

            foreach (TestObj obj in this.Child)
            {
                if (mItemIndexs.ContainsKey(obj))
                {
                    arrCopiedItems.Add(mItemIndexs[obj]);
                }
                else
                {
                    arrCopiedItems.Add(obj);
                }
            }
        }
    }
}

虽然，每个支持复制操作的对象都需要实现ICopyReference接口，这是为了处理对象内的引用属性。但是整体而言，代码简单和清晰了很多。

其实，该操作还有其他更好的优化方式可以实现，这里只是借这个例子来说明两点：

1、写代码的时候不要因为前人怎么写，你也去模仿怎么写，这样会让你变得思维方式固化，一定要有新意，养成这种思维的习惯，并且合理地去实现它。

　　2、善于从不同的事物中去发现共同点，并将这个共同点抽象出来，从而达到代码复用的目的

本文链接

如何重构代码-重构计划

2010-05-10T15:09:00Z

　　上一篇已经阐述了重构的思路和方法，这里主要阐述下里面提到的重构计划。

首先，了解一个待重构的老项目

项目名称A，某公司重点项目，已经正式上线运行几年了，公司业务遍布全球，很多国家都有办事处或研发部门，也就需要使用该系统。并且随着公司的不断发展，业务流程也在不断地完善和变化。

技术上，项目是CS架构的，支持在线和离线两种操作方式，对于在线方式，数据访问是直连服务器上的Oracle数据库，离线的数据访问是连接本地的Access数据库；对于本地数据库，系统提供WebService来实现本地数据的同步。

目前项目代码的规模已经达到100多万行，负责项目开发和维护是由同一个团对来承担，其中的开发和设计人员有10人，这些是项目的基本情况。

项目存在的问题：

1、维护工作量很大，这占用了差不多40%左右的时间，这主要是因为易用性差造成的，不过由于在以前的代码中把太多的逻辑放在UI层上，在业务复杂和界面都复杂的情况下根本不敢去修改，这就导致无法改善易用性。

2、开发BUG很难减少，特别是做一些变更任务的时候，往往简单的修改会牵涉出很多BUG，这是由于项目代码混乱，复制的代码随处可见，导致变更分析很难做到全面。

3、代码复用度低，导致每个版本的开发时间都比较长，而且，每次的版本开发都导致代码规模的暴增。

4、从业务上说项目已经成熟，公司希望将项目产品化起来，并且在内部真正实现组件化（根据业务模块来划分模块，并像搭具木一块快速的组合与拆分）的架构方式。

现有架构：

项目在架构上根据业务划分成了几个子模块，下面是提取出来的三个模块，同时也表示出了模块之间的关系。

在每个子模块中根据传统的三层模式来划分，不过层之间业务数据的体现都是以DataTable为核心。

了解完上述这些后，不知道大家都有什么想法？反正对于我来说，这个过程现在想想都郁闷，从进入项目开始算起，花了三个月的时间才提出了最终的重构计划！

1、在存在的问题、现有的架构、重构时间（1个半月的开发时间）和项目风险几方面的综合考虑制定了新的架构

（看到上面这幅图后，有些人可能会坐不住了，觉得很平常化，没有任何高深或有新意的东西，就连基本的设计原则还都不符合，为什么不加入设计模式，例如：层次之间的利用接口隔离，数据操作类上可以使用工厂模式等等，其实这些并不是没有想过，去掉的理由很简单：初步重构老项目不要去理想化，它的首要目的是解决现有存在的问题，对于理想化的东西我们放到以后的持续重构中去实现。）

2、选择重构的代码，100多万的代码不可能在一个半月内都完成重构，所以如何选择是个很重要的事情，上面三个模块中，销售模块的使用度最高，其中用户的问题反馈基本占了80%，代码规模处于平均阶段，综合这些考虑选择这块进行重构。那么其他模块怎么办？！采用当后期模块内有需求变更的时候，对于变更的内容采用新的架构来做，这样一步一步地达到目标。

3、对选择模块的UI层，让BA、UI工程师和用户重新设计界面流程。

4、对模块内部代码的变动制定详细的执行步骤，例如：先从业务层开始在类中新增对象属性和相关方法，接着利用属性消除DataTable，最后抽出UI层的业务规则等，并且要清楚工作之间的依赖程度，要做出串行和并行的任务，例如：上述步骤是需要串行的，而基础组件模块的重构是可以并行的，这样做是保证你对整个重构过程有很好的控制。

5、接下来进入实质的编码阶段了。有个注意的地方，最好安排两个设计人员每天对修改的代码进行代码走查，以确保明天不要重构今天的代码。

就这样团队整整辛苦了一个半月后，终于完成了重构！虽然现在的代码依然存在很多问题，但是至少我们让一直困扰的问题消失了，也许又会出现新的问题，为了避免这种情况，引入了敏捷开发中的过程-对于每个版本的持续重构！

本文链接

如何重构代码-思路和方法

2010-05-10T00:54:00Z

　　先从接触过的几个老项目经历来谈谈，对于老项目来说，大家在初步接触的过程中，大多总是抱着抵触的情绪，甚至有些是蔑视。总喜欢对以前的代码挑出一大堆的问题，接着就开始抱怨代码、抱怨以前的开发人员，经过一段时间郁闷的抱怨阶段后，处于职业的责任心，就很想去改变这一切，希望把自己认为好的方式给带进来，于是接下来的工作就是重构代码了。

　　这也许大多数开发人员都经历过，这种经历是辛酸的（因为重构工作虽然重要，但是得不到过多的认可，目前国内关注的是可用性，对于代码质量并没有得到应有的重视），也是甜蜜的（风雨之后总会有彩虹）。对于年轻的开发人员来说，见到彩虹的过程是痛苦、漫长地。他们都是在失败中成长，这些失败除了经验外，主要是由于太急功尽力了，盲目的重构！

　　盲目主要体现在：

　　1、在还没有对系统整体架构有个清晰认识的时候，就想用自认为新的技术或架构来替换。

　　2、根本不分析现有系统架构或程序存在的弊端，只是一味地谈设计模式，以设计模式中固有的一套来重构（在重构中，它只作为一个参考，而不是一个依据。）

　　3、重构比较随性，每个版本的开发都跳出架构之外随意带入新的设计思想

　　这种盲目重构后给系统会带来更多问题：

　　你会发现当你重构完后你的系统运行效率变低了，

　　系统中同时存在多种思想，新加入人员更难接手，

　　由于你没有完全了解系统，反而在你的重构当中带来了很多重复代码，

　　最悲剧的是你重构后的代码也被其他人当成垃圾，而进行重构。

　　那么我们怎么消除盲目呢！？

　　首先，了解目前项目是否存在问题，存在什么问题，这些问题是否能通过重构来解决，如果能，才进行重构，你的重构时间是需要公司给的，老板不会因为你说依赖性强偶合性低就同意的，你必须要通过问题来让他认识，关键的是只有通过问题才能得到重构时间和资源，并且你的工作才能得到认可，这是一个很现实的情况。

　　接下来，你要确定重构的对象，是针对架构还是局部代码，并且去设定一个理想的目标（为什么是理想的？因为我们不可能一步到位，理想和现实是有差距的，但是我们要做的是尽力去往理想上靠拢）。

如果是针对架构进行重构，那么这可不是一件轻松的事情，再真正开始之前需要做到以下几点：

　　1、全面的了解系统的过去，包括以前的架构/技术背景、业务需求

　　2、分析以前架构的问题，例如：可维护性低、在哪个方面已经不满足现有需求等等

　　3、查看至少80%的核心代码，最好有一定时间的真实在以前代码基础上编码的经历

做到上面几点就是为了保证你能有一个清晰的认识，做到知己知彼。接下来可以进入实质阶段了吗？不行，还少了一个很重要的东西，重构计划！

这种大范围的重构，在真实情况下，一般老板给予的时间和重构真正所需用的时间相差很大，所以重构的工作是需要往后延迟的，那么就会出现又要重构又要进行新需求的开发；还有这项工作不是一个人的事情，是一个团对，既然涉及到多人合作，除了共同的目标外，还需要有一定的评审机制，这是为了保证重构的方向一致，等等，在这些因素下要做好重构，就是需要重构计划的理由。

　　针对局部代码进行重构来说，也许会简单的许多，不过需要注意的地方是，你一定要符合现有架构的思想，在它的范围之内去思考。

　　其实这种方式的重构大多就是提取方法，或者是以真实业务流程的思路去重构现有的代码执行流程，以便易于理解，或者是降低程序之间的依赖性。要做到这些有个很重要的思维方式：

1、善于从某个事物中分析出什么是事物的本质和什么是事物的外部环境。

　　2、从很多不同事物中去发现共同点，并对这些共同点进行抽象化（举个简单的例子：对于宝马和奥迪，你应该把他们抽象化为汽车）。

　　为什么这样说，因为这些能带来重构代码所需要的：

　　1、在写代码过程中降低了依赖性，

　　2、抽象化的事物复用性更强

　　做好上述的所有就表示重构完成了吗！不可能，这只是一个好的开始而已，我们要做到持续重构，就像敏捷中提到的。

　　也许有的人认为不现实，因为项目经理不会在每个版本周期内给出这个时间，其实，我就纳闷了，为什么不给？！不给的原因一定在你，如果你期望是一周或者更久，那么谁都不会同意，一周的时间都基本都能做完一个版本的设计了，重构还需要这么久，如果真的需要就说明你前期的设计很差！我所希望的时间是两天左右，因为这只局限于很小范围内的变动。

　　如果你们很好的做这些，那么你的项目可维护性一定很好，并且加入你的项目会是一件愉快的事情，这并不是什么理想的事情，只要你持之以恒地去做，实现起来其实很简单。

　　以上这些就是个人关于重构的一些想法，也许光从文字看上去比较空洞，后面，将分享一些真实的重构案例，供大家参考和交流。

架构重构：

1、重构计划

代码重构：

2、提取获取交集的算法

3、简单、灵活地实现对象复制

本文链接

谈谈多线程的思维方式

2009-04-24T00:53:00Z

前段时间仔细看过些关于多线程方面的资料，项目中用到线程的地方也不少，可是，当看了Jeffrey的一篇关于锁的文章后，发现自己虽然一直都在使用多线程，但是缺少了做多线程编程需要的思维！所以想从Jeffrey的Optex（锁）入手，来谈谈我从其中体会的东西..... 多线程编程虽然复杂，但是我觉得很有意思和挑战性，而且随着硬件的发展，多线程编程会更加重要，既然已经上路就让我们走到尽头！

简单的数据移动算法(C#)

2009-04-14T03:06:00Z

数据移动算法，其实是一个比较简单的程序，当移动的数据是一个的时候，只是移动的数据和被移动的数据相互交换下排序值Seq就可以了，不过当移动的数据不止一个的时候，有多个数据，而且这些数据可能是连续的，也可能是不连续的，这个时候虽然也不复杂，但是还是有点烦琐的。前段时间我正好碰到了个这样的需求，就写了个比较通用的算法.....

[ASP.NET MVC]-理解Routing

2009-03-10T10:42:00Z

ASP.NET MVC的了解，让我们从Routing开始，站在应用的角度上看，这绝对是个非常简单的，因为应用程序中只需要寥寥几行代码就可以了！所以让我们从本质的角度上去了解，认清它的工作机制。