2009.10.11 OA 项目组一周工作报告（论重构）

质量评价：60

评价依据：本周质量没有什么大的问题，除了客户报的一个bug。

先说没有大的问题。本周的主要任务是在以前的实现上添加新的功能，并且这些功能也基本上得到了实现，在代码质量上也没有发现什么不好的代码。但是在代码检查的过程中，仍然发现有很多重构的机会没有把握住。这里我又要再谈重构。

在周末讨论会上，王提到了重构是否有方法和目的。对于这个问题，我也没不能给出一个具体的答案。一直以来，我只看重重构的价值。当然重构的价值有很多，我这里指的是重构过程对于提高程序员编码水平，分析水平和设计水平的价值。在OA项目中，有不少在现有功能上添加的新功能，而那些完全独立现有功能实现而提出的新功能基本上不存在（即便是IOS的开发也牵扯到OA的服务端）。如果我们只是命令式地在既有的功能上去实现新功能，那么当我们离开OA项目组时，又能有多少提高呢？

另外客观上来说，新增功能能不能在既有功能上直接添加这取决于之前的设计。我们确实是可以分析出代码的执行路径，然后加上少许变量和代码，就可以在既有的代码上添加新的功能。设计来源于业务逻辑，是业务逻辑的抽象。如果业务逻辑发生了变动，且这种变动已经超出了设计抽象的范围，那么这个设计就要被重构了。如果我们放弃重构，而只是在代码的执行路径上去修修补补，那么设计的抽象描述将会离实际的业务逻辑本身越来越远，并会逐渐形成改一个小地方就会牵动一大片的局面。

当然，重构也有风险。方在讨论会上提出了这个顾虑。重构的风险有两个，产生bug和工作量被放大。

的确，这周客户报的bug就是由于我的一次重构造成。重构只是我们代码生活中的一种行为，产生bug是很自然的事情。目前在OA项目组中，对于重构的保障就是测试。而工作量被放大也是我要论述的问题。当我们面对重构时，我们看见他背后的就是额外的工作量，而这部分工作量可能两倍或三倍于我们最初估计的时间。在项目的时间被限制的情况下，这些额外的工作量就形成了额外的压力。而迫于这个压力，我们可能选择退缩。其实这种类似的压力谁都在面对，你们，我甚至包括公司的上层都在时刻面对压力。我想说的是，面对压力，我们可以选择妥协，但是我们咬紧牙挺过去了，那将是另外一片天空。

上面说了重构的价值以及如何面对重构，希望能够对大家有所帮助。

我再次重申：重构和测试将是今后OA项目建设的两个主线。用重构去推动项目前进，用测试来保证重构的正确性。

 

进度评价：60

评价依据：本周大家基本上按照计划完成了任务。为了更好地跟踪项目的状态，我决定使用新的文档，详情见附件，也欢迎大家提意见。

如果没有什么意见，我会在每天工作结束时，依次将项目进度管理文件发给每个人填写。

 

 

更多内容，请转到：我的项目周报