当范围很大时，重构的同构性确实很难掌握啊，记最近维护代码时一些教训

 从事的产品发布版本了，也稍微清闲点，也就想动手脚修改修改代码，把一些代码修改的，更容易被理解，这是我想达到的目标。人类对一个东西的把握能力，其实就看对其的理解程度。而人类的理解能力，就心理学各方面来说，以7为界限，超过7位的数字，一般人很难牢记，所以，一个事物被理解所抽象出来的概念数也最好不要过多。

    我们现在产品的代码，确实很乱、很难以理解，经常弄不好就会出错，即使是有时修改很少的代码。代码有时很令人费解，但是，却保证了运行上的正确，因为测试了几个版本下来，功能总是满足的，呵呵！我总觉得，既然认识到问题，光天天指责、骂娘，却没有为此付出自己的解决办法，不是我喜欢的风格，那是一种类似清谈，看着十分正确，但于事无补，事情还在剩余着，一天一天烂掉。

   

    我很欣赏，钱玄同劝鲁迅出山时所说的，“虽铁屋子万坚难破，但并不是没有破的可能”，鲁迅亦赞同之。总之，做比不做要好点，那我就奋然前行了，呵呵！

 

     在修改代码到产品发布的Bｘ之后，发现自己被自己所修改几次改动折腾的够呛，往往认为修改很少，修改也很正确，但是，却出现了几次的大故障。这也小小地让自己有点灰心 ：（。更外破坏自己原有观念的是，在编译式语言中，因为提供编译的支持，一般应该不怎么会出现错误，但是却错误；而在javasript中，由于是解释执行的，出错是可以理解的。但是，最近的几次的错误，让我幡然认识到，即使在编译式语言中，通过修改代码想达到同构，也是要极其小心，需要推敲的。
  
  
   现在流行的XP编程，一方面要先编好测试用例。我欣赏XP的一个很重要的原因，是他测试的观点，逼着你去思考：我新增加的代码和模块如何才能被很好的测试。如果一段代码、一个模块，可以被很好地测试，在测试用例充足的场景下，几乎代表了这段代码所遇到的所有情况。那么，我对这段代码和模块的信心，可以无限地膨胀，因为这段代码所遭遇到的现实情况，可能仅仅是我测试用例极小的“子集”。
  
      但是，我在修改的过程中，确实很偷懒的，总是大致推演下，感觉满足一定“等价”关系，就动手修改代码，事先没有准备起测试用例。不过，按照我们现在的产品情况，把测试用例写出来，也是一个极难问题，类似前一段算法导论中“NP”介绍中一段文字：认为多项式时间能够解决的问题是不难的问题，消耗非多项式时间解决的问题是难的，虽然是一种哲学上一种观点。而实际上，多项式100次方，其实在现实中都是非常非常难的了。对我们的系统编写测试用例，就类似于此，唉，一声叹息！不说别的了，说说犯的错误吧，一般我写文章喜欢东扯扯西扯扯，呵呵！

 

错误1
{

  fA();
  fB();
}

 

   代码fA、fB完成一件事情，所以，我想在这一层中，仅让维护人员看到一个概念，而不是fA和fB，所以，当时一个直观的想法是把fB融入fA中，且在fA函数的尾部调用，则可以认为“同构”。当时，也确实这样做了。但，现在，就在我写的时间，就发现这是一种不同构的修改方法。呵呵，可能也是经历了那次教训后明白了。所以，把一些感受写出来，可以更好的理解、掌握。记得初中时，一个读物，名字就叫《读写算》，它的用意就是，用人的读、写、算三种能力结合一起用，达到学习的最高效率。

 

     一般来说比较正常的做法，就是，将fA、fB统一成为fC，那么很多程度上，将可以保持比较好的同构。但，将fB融入fA的最后，会遭遇到一个问题，就是如果fA在前面异常返还了，就会导致后面fB不能被执行。而在原来的形式下，并没有这样的问题，即使fA内有异常返还，fB的代码依然会被执行到。所以，fB融入fA尾部的做法，即使在编译式语言中，虽然能够编译过，但是，在逻辑上也是错误的，是不等价的。

 

 

错误2
这个错误就更有意思了，由于javascript并非编译式语言，所以，有些隐藏的错误，不能在编写的时间替你发现。这个错误发现起来就更直接，只要能够走到这个地方，就会暴露出来，但就错就错在，这里修改的代码，牵扯if/else分支，正常的测试场景，一般会走到一个多数情况下的分支；而另外一个分支的构造，要靠特殊情况。好在的是，在发布版本之前，碰巧自己测试出来了这种错误，避免了因重量级故障被大罚款。

   从这两个修改出来的故障情况来看，修改代码代码要保持同构，还是要详细推演的，不可大眼一观，疏忽过去！修改的代码，最少要保证逐行走到，以驱除比较低级的错误，呵呵！

 

  祝2010年元旦愉快，新的一年，新的起点和开始，更有信心过一个丰收的一年 ：）