噢，等等，先想想再说
转载时请注明出处：http://blog.csdn.net/absurd/
最近我和同事犯了几个错误，那位同事所犯的错误也正是我以前常犯的。说是错误或许有些严重，但至少这种做法不是那么正确吧。相信很多人都有类似的毛病，写到这里，希望大家引以为戒。
1. 完成了吗？再想想，有遗漏没？ 前几天解决了一个关于setlocale的问题，那是一个遗留很久的问题，以前不知道如何在远程调试时在共享库里设置断点。因些调试非常困难，只能靠printf，而setlocale的实现又很复杂，所以后来这事就搁下了。现在已经如何远程调试共享库了，只花了一天多时间就解决了。我测试过setlocale，确认没有问题，自以为万事大吉了。
今天发现iconv转换字符编码还是失败，只好重新去看glibc的代码。和同事花了半天才查明，原来是没有把gconv下的动态库拷贝到小机上。上次虽然解决了主要问题，仍然留了个小漏洞，为此我心里耿耿于怀。解决setlocale之后，本来我应该再测试一下iconv的，如果当时发现问题，有现存的调试环境，很快就可以查出来。
前段时间看了一下《如何求解问题》，这是一本非常好的书。由于比较忙，只是粗略的翻了一下，有时间一定仔细阅读。其中有一句话给我留下了深刻的印象，大意是说，一旦找到问题的一个解，千万不要轻易放弃。继续思考！看看是否真正找到了所有的解，或者是否有更好的解。如果你马上放弃的话，就可能永远不知道这些解了。
2. 走捷径了吗？再想想，有副作用没？同事遇到一个问题，在daemon里调用一个初始化函数，进程就停在这个函数里不出来了，而正常调用时没有任何问题。同事比较聪明，但缺少经验，他把这个函数挪了下位置，放到fork之前去调，一切正常了。今天我发现，把代码移到fork之前，移动距离不远，但设计发生了本质性的变化了：这个函数从插件里移到框架里，位置虽然不远，逻辑关系完全变了，这使得框架代码依赖于插件代码，两者紧密耦合，失去了插件式设计的意义。我建议他先找到问题真正原因，再决定如何修改。
走捷径即是通过转换面临的问题，简化求解问题的方法。这本来没有错，特别是作为临时解决方案非常有效。但在需要长期维护的项目中，权宜之计通常得不偿失。因为问题虽然表面上解决了，但问题的实质被掩盖了(我们甚至不知道问题的实质是什么)，而且捷径本身也可能有些副作用，从长远来看，走捷径引发的问题比较解决的问题更多。
如果你用一个巧妙的方法解决了一个难题，在沾沾自喜之后，冷静一下，看看这个方法是不是真的很巧妙。就花一点点时间，有益无害。
3. 要重新发明轮子？再想想，有必要没？同事说他在写一个helper launcher，我问他为什么不用SCIM自带的helper launcher。他说SCIM太复杂，使用它自带的可能要花更多时间，所以就自己写了。我以前也是这样，有些代码太复杂，我宁愿自己写，也不愿去把它们研究清楚，然后重用它们。
重新发明轮子，虽然一时畅快了，但从长远来看，通常要付出更大的代价。原因在于：
l 新写的程序要花更多的时间去测试，才能达到原来代码的稳定性。
l 新写的代码要与环境吻合，要经过很长的磨合期。在这段时间，你会很多因素你都没有考虑到。
l 新写的代码，从功能上讲是重复的，维护重复的代码是一件痛苦而且容易出错的事情。
l 或许还违反了某些规则…
在有重新发明轮子的冲动时，先冷静一下，仔细想想，是否真有必要，原先的代码是否真的无可救药，你是否准备好应付重新发明轮子带来的种种后果。
~~end~~