最近一直在做Word文档转数据库(图个简单,用的Access)的小东西。本以为不会花太多的时间,但出乎意料的一路坎坷,好不容易算是接近完成。技术层面上貌似没有学到什么东西。但在这一路坎坷中,还是得到了不少经验和教训。
首先就是对需求的重要性有了更深的认识。有句话怎么说来着,怎么强调都不过分,用来形容需求的重要性恰如其分。动手之前做过分析,但花的功夫不是很多而且经验很少,很多设计都加进了自己的主观意识脱离了客观。比如当初手上的Word文档很少,就简单的对其中内容结构进行了判断,完成了设计。后来随着文档的增多,发现由于历史和手工输入的原因,问题变得极其复杂,特别是在Word文档中数据之间的联系与设计的有很大的不同,导致算法和数据库设计都出现重大的偏差。只能停下来好好又做了一次分析,再在付出最小代价的情况下进行了改动,浪费了大把的时间。这只是一个小的东西,如果一个大项目出了这样的问题,可能意外着前面很长一段时间的努力都要报废,真的很危险。难怪要不停的强调迭代,就是要使出现的问题再还没产生更大影响的时候解决掉。
还有就是解决问题的方式。比如说遇到格式如1999-2000的字串要求分成两个时间字串会怎么做。我的方法找到-的位置然后分开。问题很快解决了,但很快我又发现出现了1999~2000这样的格式,于是我找-或~的位置再分开。不久又出现了1999|2000和1999.1-2000.2等等大量的不同格式。我只能仔细思考,使用了一种更为通用的方法。其实这种解决办法我不应该是在最后那个时候才开始,在问题出现的时候就应该开始想想,为什么会有这样的问题,可能还有有什么情况,然后再多观察一下,在思考解决方式,俗话说磨刀不误砍柴功。这需要一个练习过程,也许下次第一次出现某个问题时我还是不会这样思考,但至少在第二次出现时,应该多一些警觉。
然后是解决问题的策略的抉择。这是个很重要的问题。比如,在做这个软件的时候。有用的信息基本存放在Word的表格中。但有些有用散落在文档的其他部分。我一开始想通过提前对全文的分析把这些信息提取出来。但在大量的文字中提取某个特定的字串,需要付出大量的时间和技术代价,而且很难保证正确性。最后我决定让用户手动输入这些信息。对用户来说这是件很容易的事,而且解决我很多的问题。当然从技术角度来说,不够优雅。但有时候实用的东西不一定就是最优雅的东西。要从实际问题仔细考虑,做出一个平衡。还是那句话,掌握一种力量容易,使用这种力量就难很多。决策要多多思考,不要沉迷于技术也不要图简单。
一点教训和体会,记录一下。