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