把三千行代码重构为 15 行

• 要在编程过程中多思考
• 编程的思想很重要，请多看点经典的书
• 从小处着眼，慢慢重构，尤其在应对一个大型的系统
• 当重复出现的时候，你应该考虑重构了
• 粘贴复制的代码越少，你的系统越稳定

少用代码生成器

• 因为使用了动软代码生成器，生成代码方便，就没多想了。
• 三层架构的概念倒是了解了，但是没有去深入思考就拿来应用
• 遇到重复的代码，没有重构的概念，这是思想的问题 —— 思想比你的能力重要

 for ( int n =  0; n < rowsCount; n++)

{

    model =  new DBAccess.Model.eventweek();

     if(dt.Rows[n][ "GroupNo"].ToString()!= "")

    {

        model.GroupNo= int.Parse(dt.Rows[n][ "GroupNo"].ToString());

    }

     if(dt.Rows[n][ "Week0"].ToString()!= "")

    {

        model.Week0= int.Parse(dt.Rows[n][ "Week0"].ToString());

    }

     if(dt.Rows[n][ "Week1"].ToString()!= "")

    {

        model.Week1= int.Parse(dt.Rows[n][ "Week1"].ToString());

    }

}

  public List< string>  GetDevices(  string dev){

    List< string> devs= new List< string>();



     int start= 0;

     for( int i= 0;i<dev.Length;i++){

         if(dev[i]== '^'){

            devs.Add(dev.SubString(start,i));

            start=i+ 1;

        }

    }



     return devs;

}

• 重复发明轮子。花费了额外的时间，函数的健壮性和很差
• 可读性差。其实是一个很简单的功能，但是用上了这么一段函数，起初我还以为有什么特别的功能。

  
  

• 了解你所学的编程语言的特性。你可以看一本基础的入门书籍，把所有的特性浏览一遍，或者上 MSDN，把相关的内容过一遍。
• 在你决定动手发明一个轮子之前，先搜索一下现成的解决方案。你还可以到 CodeProject、GitHub 之类的网站搜索一下。在知乎上有很多人都在批评这么一种现象，老是问一些重复性的问题，然后又职责知乎没落了，没有人回答他的问题，实际上相关问题已经有了很详细的解答，那提问之前，不能首先去搜一下是否有现成的答案，反而指责没有回答他的问题呢？
• 你有一定的基础之后，还应该去读一下相关的经典书籍，深入了解其中的原理。比如，你觉得你有一定的基础了，我建议你去把《CLR Via C#》多读几遍，你了解原理越多，你越是能够利用这编程语言的特性，从而来实现原本那些你认为要靠自己写代码的功能。

  
  

 public  abstract  class  MissionBase :  IMission {

     private DateTime _nextExecuteTime;

     protected  virtual DateTime[] ExecuteTimePoints {  get;  private  set; }

     protected  virtual  int IntervalSeconds {  get;  private  set; }

     protected IEngine Engine {  get;  private  set; }



     public  bool IsCanceled{ get{……}}

     public  bool IsExecuting{ get{……}}

     public  bool IsTimeToExecute{ get{……}}



     public  abstract  bool Enable {  get; }

     public  abstract  string Name {  get; }



      protected  MissionBase( IEngine engine)

    {

        ExecuteTimePoints =  null; //默认采用间隔的方式         IntervalSeconds =  60 *  60; //默认的间隔为1个小时         Engine = engine;

    }



      /// 任务的执行方法       public  void  Done()

    {

         if (Interlocked.CompareExchange( ref _isExecuting,  1,  0) ==  1)  return;



         try         {

            ……

        }

         finally         {

            Interlocked.CompareExchange( ref _isExecuting,  0,  1);

        }

    }

    

      ///实际方法的执行       protected  abstract  void  DoneReal();

}

• 需要花更大的精力来完成一些看似简单的 BUG
  你要知道，有一部分看似错误或者非常不优美的代码，其实恰恰是为了解决一些非常刁钻的问题的。

• 再也无法兼容老的系统了
  你急于把原有系统重写，却往往忽略了对原有系统的兼容，那么你新的系统的推进则会十分缓慢。 而老系统的维护，又会陷入及其尴尬的情况。

• 过度设计，导致重写计划迟迟无法完成
  有重写冲动的程序员往往是在架构设计上有一些读到的见解，他们善于利用所学的各种设计模式和架构技巧来建立系统，但是越是想尽可能的利用设计模式，越是陷入过度设计的困局，导致重写的计划迟迟都无法完成。

• 无法有效利用现有系统已经完成并测试的代码
  如果你确实有必要进行重写，我还是建议你把代码尽可能的重构。 因为重构之后的系统，能够让你更轻易的重写，又最大限度了保留以前可用的 业务代码。

  class  MainEngine:IEngine{

      public  MainEngine (ConfigSettings config){

        

    }



      public  void  Start ();

      public  void  Stop ();

}

 class  ConfigSettings{

     public  bool NewFuncEnable{ get; private  set;}

      public  ConfigSettings(){

        NewFuncEnable=xx; //从配置文件读取     }

}

  class  MainEngine:IEngine{

     private NewFuncClass newCls= new NewFuncClass();

      public  MainEngine (ConfigSettings config){

    }



      public  void  Start (){

         if(config.NewFuncEnable)

            newCls.Start();

    }

      public  void  Stop (){

         if(config.NewFuncEnable)

            newCls.Stop();

    }

}

• 主程序代码和扩展功能耦合性太强，每增加一个功能都要修改主程序代码，这里非常非常容易出错。尤其是新的人进度开发组，很容易就忘主程序中增加了一些致命性的代码。比如上述的扩展功能，可能是在特定的项目中才会有这个扩展功能，但是，写代码的人忘记增加是否启用的配置选项了，导致所有的项目都应用了这个功能，而这个功能需要特定的表，这样就悲剧了。即使是你增加了配置，也是非常的不美观，因为在通用的版本中使用了这个配置，往往会让定制项目以外的人员感到困惑。
• 增加扩展功能的人还需对整个 MainEngine 代码有一定的熟悉，否则，他根本就不知道在 Start 方法和 Stop 方法进行 newClas 的对应方法的调用
• 如果你打算对这段代码进行重写，那么，你会感到非常的困难，因为你分不清楚 newCls 这个新实例的作用，要么你花大精力去把所有代码理清楚，要么直接就把这段新增的业务代码去掉了。

 private  void  RegisterTaskHandlerBundles()

     {

         var bundles = xxx.BLL.Caches.ServiceBundleCache.Instance.GetBundles( "TaskHandlerBundle");

         if (bundles !=  null && bundles.Count >  0)

        {

             var asmCache =  new Dictionary< string, Assembly>();

             foreach ( var bundle  in bundles)

            {

                 try                 {

                     if (!asmCache.ContainsKey(bundle.Category)) asmCache.Add(bundle.Category, Assembly.Load(bundle.AssemblyName));

                     var handler = (ITaskHandler)asmCache[bundle.Category].CreateInstance(bundle.ClassName,  false, BindingFlags.Default,  null,

                         new  object[] {  this, bundle },  null,  null);

                    _taskHandlerBundles.Add(bundle, handler);

                }

                 catch (Exception e)

                {

                    NLogHelper.Instance.Error( "加载bundle[Name:{0},Assembly:{1}:Class:{2}]异常：{3}", bundle.Name, bundle.AssemblyName, bundle.ClassName, e.Message);

                }

            }

        }

    }

  class  MainEngine:IEngine{

     private NewFuncClass newCls= new NewFuncClass();

      public  MainEngine (ConfigSettings config){

        RegisterTaskHandlerBundles();

    }



      public  void  Start (){

        _taskHandlerBundles.Start();

    }

      public  void  Stop (){

        _taskHandlerBundles.Stop();

    }

}

• 新增的类只需按规范写即可，完全对 MainEngine 代码没有任何影响。你甚至可以把这个 MainEngine 代码写在一个新建的 Dll 中。
• 新增功能的这个业务类跟原来的代码解耦，非常方便进行新功能的业务测试，而无需考虑原有框架的影响
• 新增功能的业务类与架构完全分离，我们在重写代码中只要保证接口的稳定性，无论我们怎么把系统架构重写，我们可以马上就重用上原有的业务功能代码。

所谓重构

• 把基础打牢固
• 多看点优秀的代码
• 避免复制粘贴，如果看见重复代码时应该有意识要消灭它
• 减少对代码生成器的依赖
• 在处理现有代码时尽量用重构代替重写，在重写之前一定要先重构
• 尽量让所有的方法都是可测试的

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31556440/viewspace-2674448/，如需转载，请注明出处，否则将追究法律责任。