2009.3.7 OA项目组一周工作报告

进度评价:60

质量评价:65

这周在大家的共同努力下，完成了2.54.7的提交。2.54.7涉及到了系统中charge,commission代码的重构和修改，还有可用性搜索的改动。更加庆幸的是我们在发布版本前的测试中，发现了其中存在的问题，这些问题包括，方发现的在计算可用性中存在的问题，在计算service charge中存在的问题和在IOS上页面上显示价格合计的问题，另外在和王强讨论commission计算中的问题时，我也发现了我再代码重构中一个数据的错误初始化。

在这周的项目会议讨论中，我发现大家对驱动代码的作用还不了解，我觉得有必要再在这里重申一下。驱动代码的意义是低成本运行指定代码。而低成本运行指定代码给我们带来的价值在我看来是显而易见的，但是我也发现大家似乎并没有注意到。

低成本运行代码的意义：

1. 可以很容易启动需要运行的代码，不断地审视其执行路径以及对执行过程中对数据的修改。而这个方法在我们查找bug尤为有效。例如，我们可以在认为有问题的地方设置断点，以监视其状态是否存在问题。这是一个反复的过程，而驱动代码恰恰可以反复为你低成本启动需要debug的代码，当然你也可以说我同样可以通过启动整个系统来反复运行需要debug的代码，那这是请您比较一下这两种方法的成本。

2. 可以帮组我们完成代码的重构。请注意这不是推理，而是实际经验的描述。我们要重构代码的前提就是要清楚地了解代码的执行过程。而在一个复杂的系统中，要想清楚地了解代码的执行过程需要付出很多的时间，要了解代码的执行过程的其中一个方法就是在需要重构的代码都附近打上断点，当断点被集中后，通过断点位置的callstack来了解被重构代码的输入什么？这个输入是如何被组装的？重构的代码在控制流中是如何影响流程的流转的？在清楚上面的问题之后，才能够开始重构代码或是对代码的部分执行功能进行修改。如果我们用传统的方法来执行是什么样的呢？运行到断点出，然后分析，记录下分析的内容，然后关掉系统，然后根据分析的内容对代码进行修改或重构。或者是在debug模式下，直接对代码进行修改。而用代码驱动有什么优势呢？用代码驱动运行至断点处，对代码的执行路径进行分析，注意这个行为发生在代码驱动的环境下；然后，也是和传统方法不同的地方，切换到开发环境下，对代码进行修改，并且你可以在两个环境下不断的切换来进行修改。当你完成一段代码的修改或是一行代码的修改后，只要能够编译通过，你就可以直接运行驱动代码来检查这个修改是否合理或是否正确。由于启动数据是预先设计好了的，所以你不用担心，由于输入的原因而使每次运行的过程中遇到的数据不相同。这种方法使你修改代码的依据可以直接从代码中获取，而避免了在中间环节主观地加入其它因素，至于这种方法是否可以让修改的代码质量变得很高，那就是修改者本人的问题了。同样将这种方法和传统的方法进行比较，其运行成本要低很多。

和其它框架，设计模式相比，代码驱动的应用层级更低，它针对的是工作方法，而不是代码本身。在这里，我觉得有必要再次说明一下代码驱动中的数据。王提出，代码驱动由于数据的局限性而不可能覆盖到所有的范围。的确是这样的，要设计出不同的数据使其覆盖到所有的范围，那是设计测试数据讨论的范畴。代码驱动是一种工作方法，它的数据来源于真实的运行环境。它的实施离不开单元测试框架和ObjectWriter，至于开发人员希望要什么样的数据，那是开发人员需要考虑的问题。并且现在也没有什么神秘之物可以为你准备能够覆盖所有程序执行路径的数据。

在这里说了这么多，有点王婆卖瓜，自卖自夸的意思。我也很希望大家能够在项目中推行自己的想法，这是我们这个项目所期待的。

 

 

更多内容请参考:我的Blog导读