2004年10月10日星期日

目前网站系统问题，可以采用Robert C. Martin的“敏捷…”一书中提及的“腐化软件的气味”来分析：僵化性、脆弱性、牢固性、粘滞性、不必要的复杂、不必要的重复、晦涩性。

网站的搜索功能变化很多也将会进一步变化，Strategy模式是否可以用来组织系统的这个行为呢？“当准备在一个系统中里使用策略模式时，首先必须找到需要包装的算法，看看算法是否可以从环境中分割开来，最后再考察这些算法是否会在以后发生变化。”（阎宏“Java与模式”）。需要包装的目标就是和构件搜索相关的那些功能，但是这些功能是不是算法？是不是可以从系统中分离出来呢？构件搜索的功能在以后发生变化的可能性是很大的。

因此现在的问题就是如何分离这些搜索功能以及这些功能之间的联系和共同点呢？是否可以尝试采用活动图，详细的分析他们的每一部分，在这个过程中来比较每种方法的共同之处呢？包括分离他们和这个系统无关的那部分内容？“我们现在需要增加一种新的搜索方法，那你将怎么做？”

通过今天第一的小组重构讨论，郭提出了

1.         像Config文件的管理可以由专人负责维护，在后续开发中由他人提出修改意见。

2.         由郭准备一次讲座：关于ASP.NET中Session操作等的公共技术使用技巧。

3.         类似Common Data 这样公共的数据结构分到每个逻辑功能的在命名空间内：ComponentData.cs这样的DataTable的命名空间由scl.Common.Data 改到 scl.Business.Component下（假设的命名空间），但是物理路进还是放在scl/Common/Data内。

大家达成的共识：

1.         重构的目标：改善代码可读性，消除部分冗余代码，调整部分容易发生功能变化的代码结构，使之适应需求的变化。同时，建立网站架构文档。

2.         重构的过程：通过小组对指定范围代码的Review，然后对代码的问题进行小组讨论，列出重构的目录，对这些重构点根据重构目标和紧急程度进行优先级排序，首先重构那些优先级高会对下面的功能扩展的开发产生影响的重构点。

3.         重构的方法：

(1)      抽取代码类内部函数和公共方法，部分方法移入专门管理的类中。

(2)      分解过大的页面，分解成几个Module。

(3)      消除冗余临时变量，页面及类和代码段。

(4)      除非必要采用继承机制取代部分Switch结构。