老系统维护（二）
前面的章节请参考老系统维护（一）
第三步 理清做事的思路
弄清楚要做的事情很重要，在对自己要做的事情有了明晰的认识之后，接下来就要理清做事的思路。
老系统维护可以看成一个小型的项目，既然是项目，那么就有项目的一些特征，比如有时间要求，有可以交付的成果，有投入产出比的测算等等。对于项目类，我们公司使用五环策划表的方式来协助分析和实施，基本的过程如下：
1. 针对目的提出可以达成目的的目标，只要完成了这些目标我们就认为达到了目的。目标前面已经说过，是量化的目的，要符合SMART原则。举例来说，提高公司员工身体素质是一个目的，要达成这个目的显得让人无处下手：怎么样才算提高公司员工身体素质？标准是什么？在多长时间内完成等等。我们可以提出一些目标来量化这个目的，认为达成这些目标就认为完成了这个目的。我们相应的目标可能是利用3个月时间举行全公司羽毛球比赛，参加者达到员工的85%，员工满意度达到90%以上。这样的目标是具体、可量化、可实现和有时间限制的；
2. 针对目标提出策略。策略就是达成之前提出的目标需要哪些行动来支撑。针对参加者达到员工总数的85%这个目标，我们的策略可能是通过多种途径宣传、提供奖品、取得公司领导和部门经理的支持等等；
3. 对每条策略提出方案。方案就是具体的做事方法，要求执行者拿到方案之后可以直接去执行。接着上面的例子，针对取得部门经理支持，我们可以提供这些方案：9月1日编写经理联席会大纲；9月3日发送邮件，通知部门经理开会讨论；9月10日举行经理联席会……等等。
4. 划定里程碑。对整个实施过程提供一些检视的时间点。
这些就是五环策划表的要点，其中最重要的一条原则是一致性，也就是说后面的行为要支撑前面的行为。
下面是一个典型的五环策划表：
对于老系统维护来说，我们往往没有那么多的时间做这么全面和漂亮的五环策划表，大家都要忙着埋头看代码，找资料，和需求PK，昏天暗地写代码，哪有这些精力来做Excel表格啊？
五环策划表最重要的是思路，之前说了这么多也是为了说明这点。即是我们没有使用工具来记录，也要经过这个过程，当然，思维导图能做到两全其美：即帮助了分析，也不影响效率。下面是这个羽毛球比赛策划的思维导图分析过程。
刚才提到的都是方法，下面介绍一下我是如何将方法落地：）
老系统维护，一般都是在原有基础上增加或者修改一些功能，几乎不会涉及到架构的改变，因此我们在理清做事的思路的时候，可以着重从功能、流程、要素三方面来考虑。
在弄清要做的事情中和需求人员确认的是功能，在这个过程中我们要分析出这个功能是由什么流程构成，在这个流程中需要哪些要素，要做什么加工，最终数据要保存成什么格式。比如我接手的项目，我花费了大量的精力和业务人员进行沟通和确认，得出我要做的事情，其中的一个功能是将系统A产生的数据保存到老系统中，使用老系统的功能进行数据加工，最终产生数据供A使用。
分析老系统之后，我发现老系统的流程是使用Excel标准模板产生数据，将Excel数据导入到原系统中，保存到多个MDB文件中，原系统对这些MDB文件进行数据加工后生成一种自定义的文件格式，并将此文件供系统A使用。
对过对功能的对比，我得到两种方案：
1） 将系统A产生的数据按照Excel模板的方式导入到原系统中；
2） 将系统A产生的数据按照原系统使用的MDB文件格式导入成MDB格式，供原系统调用。
通过对比这两种方案，我发现MDB文件是稳定的，Excel模板是可能发生变化的。同时我们除了需要给原系统提供数据来源，还需要对原系统进行数据扩展，使用Excel作为我们的目标会比较被动。业务人员给我的建议是避开Excel模板的方式，避免陷入因为接口不稳定而造成我们的被动中。
同时我分析了技术难度，两种转换来说，转Excel更加容易一点，只要分析Excel模板的构成规则，甚至不需要原系统的代码支持，我们只需要做一个小工具即可；转MDB要陷入代码的细节，但是难度不是指数级别的。考虑到之后的功能扩展，以及参考了业务人员和A、B、C部门的技术人员的建议，我决定按照方案2）来修改。
知道了功能和流程，最终需要确定要素。要素指的是数据流或者字段。确定要素就要弄清楚数据都有哪些？这些数据来源于哪里？如果找不到来源该如何处理？这些数据要保存到哪去？
还是拿之前的例子，我的手头缺少MDB的表定义文档，通过初步的观察，我发现这些表里面有很多表之间存在关系，比如主外键，一对多，多对多，是否聚合等等。我没有头绪，只能找业务人员给我讲解业务，同时找技术人员给我讲解这些表的定义和相互之间的关系，讲过之后使用思维导图（实际上我开始使用的是PowerDesigner，后来觉得有些费时费力，就该用MindManager）来建立联系，由于表众多，而且讲解通常只有有限的时间，对于表的细节，技术和业务上往往存在脱节，这些问题只能自己解决。这时候要发挥一下开发人员常常不具备的两项能力：
1) 脸皮要厚。不懂就问，哪怕一个问题问过多次，也不能因为估计面子而不去问；
2) 借助资源。开发人员常常陷入问题的求解中，认为代码是诚实的，可以从代码中找到答案。这是正确的，代码的确是诚实的，但是时间也是有限的，因此对于难题的求解，要善于找到合适的人，得到准确的答案，而不是全部自己设法去解决。
当功能、流程、要素清楚之后，就几乎可以动手写代码了，这时候，常常对自己对项目做到了心里有底，随之烦躁的情绪也减去了大半。
