老系统维护（一）[转]

对于程序员来说，最有激情的一件事也许是领导或参与开发新项目，按照《走出软件作坊》的阿朱的话来说是在白纸上作画；与之相对的，对程序员来说最无趣的一件事应该是老系统维护。

新项目能给人带来成就感，在这个过程中，大家可以尽情地展示自己的技能，尽情地享受产品一天一天成型给自己带来的快乐。

老系统维护就让人沮丧了：做好了不是自己的功劳，做不好就是自己的无能。想把自己懂的那些设计模式、框架、 OO、 ORM、 AOP、IoC都施展出来？别逗了，能把之前没有文档支离破碎打满补丁惨不忍睹的代码弄明白就不错了，再说，原有的架构往往禁锢你发挥的空间，让你有劲使不出。

 

10月中旬，我来到新部门，没几天，就接手一个项目 ——一个工具软件的开发。

具体的情况是这样的：

1. 工具是客户定制的，要满足客户的一系列要求；

2. 业务人员初步的方案是在公司 A软件的基础上修改，使用 B软件产生的数据，我们的工具输出的结果供 C软件使用。其中 B软件是正式产品； C软件是 B软件的重构版本，和 B并不完全兼容，还未开发完成，计划年底上市； A软件正在测试阶段，还不完全稳定； A、 B、 C包括我要开发的工具软件都是基于单机版；

3. 时间是一个月，要出能用的一个产品，当然，考虑到实际情况，将它定为为过渡产品，之后还要重构和增加功能，比如网络协同；

4. 数据库采用的是一种具有特殊格式和特殊使用方法的数据库；

5. 产品 A属于一个部门， B、 C属于另一个部门，都和我们不是同一个部门；

6. A部门和 C部门要赶着年底的产品发版，非常地忙；

7. 我对业务一无所知，对软件 A、 B、 C一无所知，对这个数据库的使用一知半解；

8. 没有文档可以利用；

9. 代码的编写，是我一个人在战斗；

……

典型的老系统维护。

 

为了给自己打气，我也列举了一下有利的一些方面：

1.       我对这种程序语言比较熟悉；

2.       我有着几年的工作经历，有了一些处理这类问题的经验；

3.       业务人员非常配合，能够尽其所能给我讲解业务知识；

4.       公司文化非常好，同事之间很友善，矩阵型的组织方式便于资源的协调；

5.       代码质量不差，风格比较统一；

……

 

一个多月过去了，经过磕磕绊绊，和一些日子的加班熬夜，终于出了一个版本，更重要的是，在这个过程中我同时整理着老系统维护的一些方法和经验，试着总结出一个通用的流程，希望可以给自己以后类似的工作一个指导，也希望能给面临同样问题的同行一个参考。

我整理出的整个流程包括 10个 步骤，粒度的原则是每个步骤都不需要再细分，直接可以做事。也就是说，这里面没有理论，可以作为作业书了。这些方法主要来源于我的同事的经验、书中的知识 （比如阿朱的《走出软件作坊》）以及我的实践。这其中还用到了一些工具，也穿插着介绍，在本文的最后，会给出一个完整的列表。

 

接下来我将结合我这段时间的工作，介绍一下流程的每一个步骤。

 

第一步 调整心态

这并不是开玩笑，也不是在唱高调，心态对于做一件事的过程以及这件事的结果至关重要。

之前已经提过了老系统维护面临的困难，既然无法改变，就要勇于去接受，沮丧的心态对无益于自己的行动，首先要让自己有积极的心态。退一步，即使没有积极的心态，至少不带着情绪做事，不从心里就开始排斥。

 

这并不容易，我采取的办法主要有两点：

1.       给自己制定一个让自己觉得有挑战性的 目标。

2.       使用一个 小卡片 ，早晚各一次检视自己的心态变化。早上对自己鼓励，进行精神暗示，晚上对一天总结，及时调整。

 

针对我接手的项目，我给自己定的目标是用两个月的时间开发出满足客户需要的并且具有可维护性的软件产品。

顺带说一句，我们公司要求目标的制定符合 SMART-C原则，即具体的、可度量的、可实现的、相关联的、有时限的和有成本的。

为了不让自己过分疲劳，我对目标进行了细分，基本按照一个月一个周期，汲取了 Scrum中的 Sprint的思想。

经过一个简单的转换，恼人的 老系统维护变成一个具体明晰的目标，同时我的目标中满足客户需要是公司对我的要求，而软件具有可维护性是我自己给自己的要求，这样，这件事更有挑战性了， 也有趣一些了。同时，可维护性意味着自己要对代码进行重构，慢慢的一件维护工作转变成一件开创性的工作，心态也开始积极起来。

 

有了这个目标还不够，还需要采用一些手段来维持自己的心态。我的方法是用一个不大的卡片，最上面简要写着自己的目标，下面是积极心态的一些要求，每天早晚检视，在做到的条目上打勾，通过卡片强化自己的心态调控。

至于哪些是积极心态，我列举了一下（看过李践老师的《行动日志》的应该可以会心一笑了）：

乐观自信

保证完成任务

绝不找借口

勇于承担责任，绝不推卸责任

当日事当日毕

坚守承诺

 

第二步 弄清要做的事情

 

这似乎有些简单，事实上却不简单。

程序员对业务的理解本身会带着一些先入为主的偏见，这里的先入指的我们常常带着技术的观点去倾听业务问题，并根据自己的直觉作出判断。

特别是自己对业务不熟、对之前的代码不熟、对将要做的事情不熟，我们很容易陷入彷徨的境地，甚至会有挫败的感觉，进而影响自己的心态。

 

下面是很常见的场景：

1.       业务人员：“明白了吗”

技术人员：“明白了”

……

技术人员：“这个流程是怎么回事？”

业务人员：“不是说过了吗？”

技术人员：“这么多东西我哪记得住？”

2.       技术人员：“做完了，你看看”

业务人员：“你这是啥啊，我明明说的要 @#￥”

技术人员：“你就是这样说的，不信你看”（从一堆的草纸中翻当时画的圈圈线线）

3.       技术人员：“怎么连个文档也没有？”

业务人员：“这么简单的问题还要文档？你怎么理解能力这么差啊？”

技术人员：“你自己写代码得了”

 

造成这些问题可能有下面这些原因：

1. 技术人员对业务背景不了解，无法跟上业务人员的思路和节奏；

2. 专业的不同造成理解偏差，有些问题业务人员觉得简单但是实现起来不容易，有些问题业务人员很熟悉而没有考虑到技术人员的业务储备；

3. 心态问题，技术人员怕被人认为自己能力差，没有及时反馈问题，不懂的地方寄希望于会谈后的总结，结果在事后往往记忆的还不如当时深刻，从而形成恶性循环；

4. 使用草图的形式，交流之后草图往往一团乱麻，无法查看和复用。即使草图清晰，也只能看到结果而看不到之前的推导过程；

5. 还可能有一些客观原因：文档不全，其他部门配合问题等等。

 

对于如何弄清要做的事情，或者说如何把握好需求，我采用了下面的方法，其中包括一个工具 ——思维导图。

1. 在了解需求之前先 做好准备 ，比如将之前类似的程序运行一遍，了解主要功能；尽可能寻找相关文档，了解业务背景；列出自己不明白的地方和待确认的地方；列出计划和提纲，不要一次接受太多的业务知识；

2. 在和业务人员交流的过程中，学会 确认 。对于一个业务点或者问题，在业务人员讲解之后通过自己重复和确认一次，保证自己已经理解到位了；

3. 放 平和心态 ，不要因为怕被别人以为理解能力差就不懂装懂，如果当时表示理解了之后出错或者反复询问更会被人理解为能力差，并且会被认为执行力差；

4. 使用工具记录谈话要点，不要只是在纸上涂画，这样容易遗忘，可以使用 思维导图 来记录（可以使用 MindManager软件，软件的使用说明我也总结了一下，请参考MindManager使用说明 ）；

5. 和业务人员一起尝试使用 建模 工具，使得业务人员和技术人员有共同的方法论和工具，避免因为专业的不同造成的理解偏差；

 

其中思维导图工具 MindManager能够很好地帮助我们理清思路，记录过程，甚至可以作为计划工具来用，推荐大家试试。甚至，有一些错误它也能和Word一样帮我们发现，比如下面的Scrum。

  

 

老系统维护（二）

老系统维护（三）

老系统维护（四）