老系统维护（三）[转]

  老系统维护（一）

    老系统维护（二）

    第四步，解决问题的流程

    理论上来说，经过二、三两步之后，大部分的问题都解决了，但是在我们的开发过程中，随着编码的深入、需求的变化、对原系统的了解、对业务的了解，我们常常会遇到各种各样的问题。

    解决问题一个常用的工具是鱼骨图，当然，我写这篇博文的初衷是介绍一下我做老系统维护工作的一些心得，不希望里面充满了工具的堆积，所以对于鱼骨图就不介绍了。

    《走出软件作坊》的作者说过，他常用的工具是 Word+Excel+PPT+脑图，我觉得很有道理。工具的目的是为了解决问题，贵在实用而不是多。

    问题一般是技术上的问题，业务上的问题和协调上的问题。对于问题，我的做法是问 ->做 ->记。

首先是问 。很多问题是难者不会，会者不难，这时候问就很重要。

1）搜索引擎。常言道內事不决问百度，外事不决问 Google，要尽量利用搜索引擎的功能尽快解决问题；

2） 问相关同事。很多情况下我们遇到的问题可能其他的同事也遇到过，这样，通过问同事解决问题能够事半功倍。另一方面，很多问题是和业务紧密相关的，即使通过 Google也未必能有结果，这样问同事就很必要。咨询同事也要讲求策略：要以虚心的态度、要找对人、要找对时间、要认真听讲、要及时确认、要表示感谢；

3） 问专业论坛。每种语言每种技术都有自己的社区，在社区中通常能获得意想不到的收获。

 

再次是做 。

一般如果有可能我会请同事或者在同事的帮助下将问题立刻做个 Demo，以便能及时确认。对于业务上的问题要做个人机界面供业务同事确认。

“做”的过程没有太多可以说的。

 

最后是记。

“记”我认为是在解决问题的过程中最重要的一步。对于问题，第一次的时候不会我们可以原谅自己，但是如果第二次还不会就该检讨自己了。通过记录解决问题的方法和流程，能避免我们第二次再去问。

记录的目的是为了让我们第二次遇到相同问题的时候有解决问题的方法，因此要尽量写得相信，最少要让自己能够看懂。同时要为这些问题建立好目录结构，这能保证在以后更好地查找。

举例来说，我们公司有自己的报表控件和报表引擎，报表使用有固定的流程，下面是我的一个记录，用 Word写的一段配置报表的步骤：

 

 

第五步，制定计划

第六步，开发

第七步，测试

第八步，需求变更

这四部都是和开发有关，也是在时间上离得很近或者并行的过程，同时还可能是一个迭代的过程。其中制定计划可能要和客户、 Boss、业务人员、测试人员一起商定；开发则几乎是我们自己的事情；测试是测试人员的事情（如果大家够幸运有专职的测试人员协助的话）；需求变更则可能来自客户或者业务人员或者市场变化或者公司的战略调整（归根结底是客户）。

这几个步骤是我们最熟悉的步骤，也是在以前可能占据我们 80%以上工作的事情，大家既然都熟悉，也就不详细说了，只是针对每个步骤说一下我的一些反思的结果。

制定计划 建议采用迭代的方式，持续给客户提供版本，这样，客户、我们心里都有底，除了问题也能够及时更正。迭代的频次有很多种软件方法论给出了不同的建议，我们部门去年采用 Scrum，以 4-6周作为一个迭代，取得不错的效果。我们的计划可以以正在进行和将要进行的两个迭代为主，制定详细计划，如果有可能，最好细化出每一天的具体计划。

开发 需要注意的是度的把握，我的建议是先完成主要路径，再考虑其他。主要路径指的是能够完成用户要求的最低标准，我们开始的任务一定是要完成这个要求，完成之后我们再考虑客户的使用体验、界面的美观甚至一些超出客户期望的功能（我们称之为添花）。

测试 是这次我做项目中的一个痛，由于我们任务的自身原因，我们并没有配备专职的测试，而是由我们的业务架构师大姐兼任，结果是严重占据了她的精力，测试也没有做得十分到位。对于测试我建议要配备专职的测试人员，同时要以一致的方式做测试的反馈和回归（ TD或者一份共享的 Excel都是一个好工具），如果有条件，能够做自动化测试则更好。

需求变更 即影响开发也影响测试，结合我们兄弟部门的成熟经验，我的建议是使用一个共享的需求表格记录需求， SVN+Excel是值得推荐的好办法。

 

第九步，重构

    产品上线了，经过严格的测试和补丁之后，产品终于可以稳定的在客户那里运行了，我们由于前一段时间的工作，对软件本身有了总体的把握，对软件的体系结构和代码都比较熟悉，虽然还会整天在骂真是一堆烂代码，但是现在即使出了问题也能够做到心里有底了。

    终于可以不用加班，不用在客户和业务人员的埋怨中度日，不用晚上愁地睡不着觉，不用整天阴沉着脸好像自己受了天大的委屈 ——生活是如此的美好。

    结束了吗？我们可以坦然接受来自客户、同事和公司的赞扬，甚至可以离开这个业务载誉而归，但是，事情真的结束了吗？

事实上，现在的工作只成功了一半，或者是失败了一大半。

我们在已经千疮百孔的产品上，为了完成客户的需求，改得代码更是支离破碎，甚至，加入了自己的烙印，让代码风格更加多样，一句话，我们将原本就很难维护的代码变得更加难以维护。

如果不希望这个产品在我们之后不久就因为难以维护被彻底的抛弃，不希望后面的程序员和我们一样骂娘，那么，趁热打铁，继续将这个产品做下去。

当然这个阶段最大的危险来源于公司，也许他们会觉得产品已经稳定了就调我们去做别的事情，这也是公司和公司之间的境界的差距。

假设，公司也支持我们进一步整理代码的工作，那么我们会面临着两种策略的选择：

    1.重新架构，重新开发；

    2.重构。

    第一种选择，基于自己这段时间对业务的理解，对原有架构的不满，以及技术人员与生具有的创造精神：毕竟开发新系统比给别人擦屁股更有成就感，还能施展平生所学，将什么框架啊、设计模式啊、 OO啊全融进去。

    第二种选择则更谨慎一些，对公司和自己造成的影响相对较小。

    两种方法没有优劣之分，各有利弊，需要根据时间、资源、公司战略、自身能力等多个方面进行权衡，在这个项目中，我的选择是重构。

    既然要重构代码，就首先制定一些原则，在进行重构的过程中要严格遵循这些原则：

1.       代码风格统一，如果自己难以做到，就找一些第三方的代码格式化工具；

2.       严格测试，正确性要保证在第一位；（这也取决于公司的支持，去年我们的一个部门对产品进行重构，投入了几十个开发人员和开发人员数目一般的测试人员，并且引入了敏捷开发和自动化测试，最终在年终取得了巨大的成功。一亿多人民币的收入的直接贡献者哦呵呵）

3.       做减法不要做加法。在重构的过程中，不给软件增加任何功能，对于不用的功能，能够确定的情况下，能砍就砍，事实证明，越简单出错的几率越低；

4.       使用 SVN做版本管理，每日构建，保证每天上传的版本都是可运行的版本，如果当天的版本无法调试通过，就干脆抛弃，第二天重新进行；

5.       不出现重复的代码；

6.       每个方法的长度不超过一屏。

 

其实还有很多原则，但是原则太多反而记不住。接下来开始重构工作。对于重构我们可以参考与设计模式齐名的《重构》这本书。

我觉得自己的能力难以同时处理多件事情，我的做法是从程序的起始点开始，一个功能一个功能，或者一个类一个类顺序进行，最小的重构单元是对“方法”的重构，基本上按照下面的步骤：

1.       修改代码使得风格统一，命名临时变量，查看全局变量，能变成参数就让全局变量成为参数；

2.       如果方法太长就看是否能够变成几个小方法；

3.       将类中重复的代码抽离出单独的一个方法；

4.       将类中的 Public方法进行整理，看是否需要 Public出去，保证 Public的部分尽量少；

5.       将类中没有用到的私有方法删除；

6.       如果一个类有太多责任就看能否分成几个具有单一职责的类；

7.       对类书写一些注释；

8.       将公用的方法和公用的类进行而并整理，放到公共单元中；

9.       重构和一个类关联的一些类；

10.   重构一个业务或者一个功能中的所有类；

11.   重构整个系统。

 

需要注意的是，这是一个漫长和辛苦的过程，也是一个不被人理解和不被重视的过程，更是一个容易让我们沮丧和容易放弃的过程。重构，非常非常不容易！

 

    第十步，整理开发文档

我们在做老系统维护的时候，遇到最大的问题就是文档问题。可能大家都有这样的感叹：“如果能有一份文档该多好！”，“如果能有一份和当前版本一致的文档该多好！”。

作为程序员来说，大家应该都不喜欢写文档，特别是绷紧了神经开发之后，更不喜欢再耗费时间来整理文档。如果有一个称职的文档人员，当然是最大的幸运，如果没有，文档又是如此的重要，我们只能打起精神，来个善始善终。

    对 于我来说，我比较欣赏敏捷的一种思路，写恰当的文档。那么什么是恰当的文档呢？我认为应该是我们在维护程序的时候不明白的地方都能从文档中找到，同时文档 里面没有太多的废话。至于文档的格式，如果公司有统一的要求还是按照公司的要求为好，如果没有就不要太拘泥于格式，而是将重点放在内容上。还有一个建议是 多用图或者表来表达思路，有的时候一幅简单的图也许能够代表一段复杂拗口的文字。

开发文档我觉得应该至少包括这些内容：

系统设计文档 。最好能使用图来表达系统的设计思想和架构；

数据库设计文档 。如果有可能，一个良好的 PowerDesigner文档能很好帮我们理清思路；

软件使用说明书 。良好的软件使用说明书能够帮助我们理清业务，明白软件中的流程，甚至能理解源代码中一些看起来不可理喻的写法；

系统需求列表 。一个自始至终的需求列表即能理清系统的功能，也是回归测试的依据；

公共函数库说明 。一些公共服务的类要介绍清楚，这样即能帮助我们理解之前的代码，也能让我们在以后的编程中能尽量复用之前的代码，避免重复劳动。一般来说，公共代码都是讲过检验并且成熟稳定的；

常见问题解决方法 。就像在步骤四中提到的那样，常见的问题也许之后维护这个系统的人也会遇到，一份清晰明了的列表能够让后面的同事少走弯路；

良好的注释 。注释的写法也是见仁见智，恰当准确的注释的作用，确实不言而喻的。

香气四溢的源代码 。最重要的当然是香气四溢的源代码了，经过我们重构过的代码，我们自己也会为它骄傲。

如果大家觉得还有重要的文档，欢迎和我讨论。

 

老系统维护（四）-我是否最合适的人