程序员夜话

记得以前是看别人的还是自己写的，编程如绣花，大概讲的就是写程序时的细节问题吧。不管规不规范，也算写了十来年的程序了，难免会有产生一些感悟，对这些方面也确实有一些认识，觉得要说一说。

写程序的工作，外人看来很神秘，一知半解的人会觉得不过如此，而经验多的人则会很平淡地对待，不自命不凡但也不会马马虎虎，越是弄的时间长，越是觉得有很多东西需要改进，不敢有丝毫的松懈。有时，不仅要满足用户的要，也要满足自己的要求。比如，你在实现用户要求的同时，还要想到当网络环境发生变化，数据库的数据量发生变化，这时候用户的需求还能一样得到满足吗？记得以前看过这样的文章，说印度的软件工程师效率高，因为他们不会过分追求程序执行的效率而优先考虑代码的编写效率，当时还挺认可这个观点的，但现在想想却觉得不妥。虽说每个程序都有其生命周期，但这样做是否会缩短期生命周期呢？

有些细节可能看起来微不足道，但如果不注意的话却会带来大问题。前段时间写过一篇文章，是关于提交按钮的处理的，说的就是这个情况。如果程序员预计到按钮响应时间会比较长，就要对按钮进行简单的处理，以避免用户重复点击。你不能假设用户不会重复点击，就像在公共场所虽然到处写着不让抽烟但还是会有人假装看不到一样，你得让他抽不成才行，比如找不到火。所以，最好的办法就是点击后让按钮失效或者看不到，技术上不难，关键是看想不想得到，有没有这样的意识。

这个是看得见的，更多的是看不见的，对于看不见的地方更是考验一个程序员功夫的所在。比如，我原来做过一个数据批量上传的程序，在数据库数据量不大的时候运行的还不错，没觉得有啥不对的。但是，随着数据量越来越大，程序执行起来也越来越慢，到后来干脆变成超时错误了。后来我就总结出经验，不能过分依靠数据库的计算能力。原来有段时间，我特别喜欢利用数据库的计算能力，还会写好多的存储过程，当时可能也是受一些观点的影响，说是要充分利用资源。后来我发现，这并不一定对。因为，数据库的计算能力再强也是有限的，而且，频繁地查询可能会引发大量的I/O操作和数据的网络间传递，都会降低代码执行的效率。如果改变一下处理方法，以尽可能少的SQL返回要处理的数据，然后在内存中计算，代码的效率就会大大提高。

原文链接http://blog.csdn.net/gaofeng2000/article/details/6979951