场景漫谈：软件过程的升级

最近从一个较为无序的开发环境转到了专业的软件公司工作，刚过来就接到一个较为紧急又让人抓狂的任务，经过几天的努力自我感觉还算过得去，回想完成任务的经历，虽然还有很多不足，但也有一定的收获，整理出来一个小场景，博君一笑尔。

背景：公司某部门需要把一堆EXCEL表格（数万行）数据按一定的规则输出到Xml文件，经公司领导研究，该研发部门可以提供程序员Brook帮助该部门开发一个转换小程序，开发过程中需求部门提供Pretty直接与Brook对接。

场景一：Brook和Pretty直接沟通需求，并制定出一套XML模板。Brook拿着这个模板写一个小程序验证开发难点或瓶颈在哪里。通过几个文件的测试，Brook和Pretty确认这个程序可以把EXCEL表格中的数据大致转换成想要的XML，但细节方面仍需调整。
此场景可以称为原型阶段。

场景二：Brook把场景一所写的程序优化了一下，分离出几个类，分别是负责Excel读写的ExcelReader类，把Excel转换成XML的Converter类，封装了一些静态方法的Utility类等等，此外Brook还在Converter中把逻辑完善了一下，使转换出来的XML符合Pretty提出的要求。在此场景，程序不再是一堆方法的集合，它变成了有“架构”的东西。

场景三：但需求总是在不断变化，完成场景二后，Pretty并没有让Brook安心收工，因为她发现除了之前交付给Brook的那套转换规则外，不同的Excel表还可能使用不同规则。于是Brook根据不同的转换规则在Converter类中实现了多个转换方法，并成功通过测试。虽然Brook感觉现在程序的Converter类显得臃肿不堪，但迫于Pretty的淫威，还是将实现了功能的程序交付给Pretty。而在交付之后，Brook利用空闲的时间将程序进行了改写，通过实现多个Converter子类来实现不同的业务逻辑，对重复代码进行Extra Method，实现了代码的轻量化。
这个场景用到的相关手段是迭代、重构以及策略模式。

场景五：需求还在继续变化，又过了一天，Pretty对Brook说：不好意思啊我之前忘了，如果在规则A的转换中遇到了“xxx”字段，你要做XXX特殊处理哦。由于改动太小，Brook把“xxx”字段的特殊处理硬编码到代码中，也很快通过测试交付给Pretty。然而世事并没有想象的简单，接下来的一小时，Pretty以每5分钟一次的频率向Brook提出了不同的特殊字段处理情况。至此Brook忍无可忍，只想跟Pretty发飙：那些特殊字段你自己处理去吧！没错，Brook的做法也是这样，让Pretty把特殊字段和处理方式写到某个XML里，当程序读到XML中出现的字段数据时，将自动进行特殊处理。
这个场景中，Brook把大部分常量移到配置文件中，实现程序的松耦合。

场景六：Pretty毕竟不是专业的测试人员，她测试数据是否正确的方式就是一条条地查看数据是否正确，但几张表下来，Pretty散光加深了300多度，于是她来向Brook求救，让Brook跟她一起查表。但Brook是什么人，人家可是程序员，怎么能干这种机器人干的事？于是Brook让Pretty把不同规则和情况的数据抽取出来，并且按照模板写好预期的输出情况，而他自己只把数据转换了一次，并让机器去检查输出和预期是否一致。这样一来，Pretty的测试工作就轻松多了（当然这活正常是由测试工程师做的）。
这个场景叫过自动化测试。

场景七：程序需求还在不断改，但某一天改到一半突然断电了，重新通电之后Brook一脸懵懂：到底哪些是之前稳定版本的代码哪些是后来新加的。好在断电的前一天Brook贪玩在程序目录下建了个版本管理，于是Brook放弃了断电前的修改，直接回退到稳定版本代码，虽然浪费了一定量的付出，但毕竟知道自己处于哪个位置，不至于无从下手。
这个场景重点在于版本管理。

场景八：程序的需求变更接近尾声，重构也接近尾了，但奇怪的是之前好好的功能到现在却出现了错误，Brook只好找到出错的数据，一步步地去调试程序。终于他在十几次调度后，在千百行代码中找到出错原因，原来是在重构的时候新提取出来的方法逻辑出了错。于是Brook痛定思痛，每次新提取出来的方法都要再三确认其正确性，并且用自动化的方法对它进行测试。
这个场景引入了单元测试。

至此，一个小小的转换程序引入了N多个软件工程概念，或许对于不需要做太多后期维护的项目而言这样做有点过度工程了，但在大多数情况下引入这些概念和做法，都是对成本管理和风险控制的最佳选择。