Web站点优化

许多web站点在初建时，由于需求不明确，需求变化太频繁，以及追求进度等诸多原因，第一版的站点多是凌乱的，难以维护和管理的。为此在站点进入稳定维护期的时候，进行优化是十分有必要的。选择在进入稳定维护期后进行优化，是因为这时需求已经基本明确，需求变化不会太严重，又有“既有站点”的经验与教训可供参考，而且“既有站点”能同时应用，时间也会较为充裕。

根据“既有站点”的实际情况。选择优化的方式：“部分调整改进”或者“完全重构”。如果“既有站点”是架构设计大部分较为合理，仅有小部分不太理想，就“部分调整改进”不合理的地方；如果“既有站点”架构严重不合理，难以维护，甚至是凌乱至极，仅是一堆代码的堆砌而已，就不得不选择“完全重构”。但无论采用哪种方式优化，以下第一步都是必须进行的。

 

1，  分析“既有站点”：罗列“既有站点”已经实现的功能，及其功能的实现方法，评估这些功能是否满足需求，以及实现这些功能采用方法的运行效率。这些罗列应该是整理成文档的，可以在已有的开发文档（如果存在的话）基础上整理补充。

 

如果在进行第一步之前很难决定是选择“部分调整改进”，还是“完全重构”，就在完成第一步之后再作决定。所需求的功能大部分都已经实现，并且运行效率也能够接受，就选择前者，否则就选择后者。但我相信大多数参与过“既有站点”开发的人员仅凭直觉就能决定是“部分调整改进”还是“完全重构”。若选择“部分调整改进”的方式进行优化，第一步整理出来的文档可以补充到已有开发文档（如果本来就不存在这样的文档，可以将整理出来的文档补充为开发文档)的“详细设计”部分。若选择“完全重构”，开发文档也基本上是需要“重构”。在“重构”文档的时候，第一步整理出来的文档，糟粕之处可以作为教训来借鉴，在重新设计的时候加以避免，精华部分可以作为经验来参考，继续沿用。

 

选择“部分调整改进”的方式进行优化，接下来需要做的工作就是：

2，  根据第一步分析的结果，改善实现不合理的功能。如果还有未实现的功能，进行补充。

3，  优化代码，增强代码的可维护性，如改善代码的结构，补充注释等。

4，  完善文档（很多时候因为 很多 原因，一个项目开发完了，并没有留下多少有价值的文档，虽然软件工程一直在号召大家避免这样，但事实上很多时候确实这样，那就现在补救），使站点更利于维护。

 

选择“完全重构”的方式进行优化，所需要做的工作就要多些了。所谓的“完全重构”其实就是重新开发，但又不同于第一次开发。“重构”时，需求绝大部分应该是明确的了，如果需求仍是变来变去，那没必要进行“重构”

 

2，参考第一步分析的结果，找出那些实现很困难的功能需求，重新考虑它的合理性，有没有相对容易实现的、好的替代。订立新的需求，与策划部门重新确认，或改或弃协商解决那些原本难以实现的功能。

 

   因为有些可能是无关紧要的功能，但实现起来成本却又很高，如果还很复杂的话，还有可能是系统的隐患。

   以下的步骤就跟开发新站点差不多了。只是比第一次开发相对容易些。

3，根据上一步确认的需求，参考“既有站点”的架构，确立“重构”的新架构。

5，  将第一步中整理出来的好东西应用在新的“重构”的文档“详细设计”部分。

当然“重构”还有许多应该考虑的地方，比如：人员安排，时间安排，过程控制，这些我还在摸索中。