Question your own opinion twice and more

  如何让自己的想法和见解经得起别人的推敲，经得住实践的检验，我认为需要不断的从多角度的质疑自己的想法，这样才可以最大范围发现存在的问题，这种事情在项目E中出现了多次。

  说起项目E，我已经在里边待了有一个月时间了，从需求上项目实施过程中出现了许许多多的问题。前两天发现系统提供多sheet导入而不提供多sheet导出，需求规格说明书也是这样，咨询了当时参与需求调研的同事W，她说“用户只提出多sheet导入的需求没有多sheet导出需求”，但是从用户导入的需求中我们发现，用户所使用的导入文件正是从系统导出后进行修改的文件，也就是说如果我们没有提供多sheet导出，用户需要导出多份excle文件并手工进行合并后导入。同事W的说法毫无疑问需要被质疑，需求是挖掘出来的不是仅仅当一的用户说什么就是什么，需求调研的职责是更多的发现潜在需求给客户提供建议，而不是一味的与客户确认。事后同事W接受我们的建议，同样认为需要提供多sheet导出功能。

  恰巧多sheet导出的工作是我负责，工程使用的导出技术是开源jxl模板技术，开发时查看了Document发现jxl的转换器有提供mutipleSheetTransform方法，调用也挺简单，但是按照Document中的指示调用后产生的文件，要么规格不对要么就是数据没有，是我错了还是它错了（其实我们不只一次在开源组件上载过跟头，所以我有理由质疑是不是它错了），无奈之下上SourceForge下载tansformer的源代码一窥究竟，发现其中多sheet的转换逻辑有误，马上进行修复并正常应用到系统中使用。事后有些得意，而正是“得意”在本周一直困扰着我，中国有句成语叫“得意忘形”，我脑子里一直在想是不是“得意”让我忽略了某些东西，所以我的做法需要从不同方面被质疑，其实现在并没有其他更多关于该接口逻辑有问题的说法，会不会是转换器提供的多sheet接口应用场景与我们的需求不一致呢？最后我决定改正之前的错误，在没有确凿证据之前我不能认为转换器提供的接口有误，我应该扩展实现自己应用场景的接口而不是修改原有接口并使用。

  还记得同事L说过的一句话，“任何事情都可以质疑”，如果可以在真正付诸实践之前就从多方面质疑考证自己的想法和见解，那么你的想法和见解必将站的更加稳固。