今天看到dw上有这样一段话“由于成功的机会渺茫，大多数人就采用阻力最小的捷径。这种方法在短期内可能会保护所从事的工作，但它仅仅推迟了问题的出现，并使之更复杂。如果等待时间太长，小的问题也会变得难以克服。最终将没有方法激励人们变得勇敢，去冒更多风险。”其实，删除的那句话，可以换成很多其他的话，不信可以试试。由于时间紧，由于不熟悉新技术，由于新人太多，由于式样变更太多⋯⋯
    突然想起来两年前的一个项目中DB接口设计中的问题，当时第一次接触LDAP数据库，为了方便其他开发人员的使用并进行DB处理中异常的统一处理，我在LDAP的接口这上加了一层自己的接口。实现了简单的查询，更新，删除，追加机能。整个接口当是觉得挺好，基本上实现了我想做的事情。
    但是在项目进行到一半的时候，项目经理突然提出，查询接口中的查询结果不应该使用数组，而应该使用值对的形式，可以通过一个字段名取得每个纪录对应的值。当时也觉得挺有道理，但是大概有一半的业务已经coding，结束，正在测试中，所以我提出，先再提供一种新接口给后续的业务使用，已经做完的业务就先使用老的数组的接口。
    没想到项目经理，断然拒绝，激烈争论后，最终新的接口也没有追加。现在回想起来当时的提案，觉得真是失败，绝对不能使用。因为这样的理由，抵制了新接口的修改，真是不应该。还好老大当时不给我计较。万幸后期项目中也没有出什么问题，否则真是罪过大了。
     再来说说自己提案不成熟的地方：
        1，维护两个接口，增加额外的工作量
        2，如果测试完成，修改了底层的DB访问，还需要重新测试。
        3，两个接口会影响其他组员的判断，万一他们在不知情的情况下使用了老接口，后面还要再次修改，工作量增加不说，还会影响他们的心情。
    当时自己表面上的理由是，已经有做完的业务了，不应该删除接口。其实真正是自己懒的改了，改了接口，还要改业务。正如上面说的：“短期内可能会保护所从事的工作，但它仅仅推迟了问题的出现，并使之更复杂”，使问题更加复杂化，这才是最恐怖的。

发表于 @ 2008年10月20日　22:39:00 | 评论( loading... ) | 编辑| 举报| 收藏

旧一篇:有用的测试工具Hamcrest | 新一篇:ntfs文件系统的权限设定