软件从业者误区（一）

最近看到一系列争论，包括ICPC/ACM，包括对注释的争吵，于是打算写这么个系列来说下现在传统的软件行业究竟是什么样子的。究竟多少算误区。
首先如果你所从事的行业涉及到极其高深的人工智能，语义网络和对算法要求极高的科研项目，我这里所涉及的内容多数是建立在业界比较广泛的企业级软件和网络应用服务上面。
误区一：算法是软件编码的最高境界
很多人都觉得那些掌握了一流算法的人特牛，那些参加诸类大赛的人都是高手， 但就我看到的企业和软件来说，里面高级算法占有的比例可能不及千分之一，这还不是代码行数，而是从功能上说。在企业级的软件里，不是说算法一点价值都没有，算法能做出很多很有意思的改进，但必须明确的是需求会比任何算法更复杂更难以控制，你可以在一个团队里找出无数个熟悉各种算法的程序员却很难找出能对每个需求都了若指掌的人，因为需求往往错综复杂，相对于算法说的话，他更为庞大，更为怪异，有时不会顺着你的思路走，如果你什么算法都会写，你可能就是一个高级程序员，但如果你什么需求都清楚，你一定前途无量。
误区二：代码是最好的注释
如果你还在试图阅读一个2000行的类，并且说其实这个类并不是那么复杂，我们可以通过阅读代码来了解所有的信息时，那如果你面对上百万行代码的企业级软件呢？很多人过度崇尚代码即注释的Geek精神，我承认如果你能把代码都读明白，注释一点用的没有，问题是，你面对的代码不是出自你一个人的手笔，也不是一个bug都没有，当你发现一个bug的ifelse写饭的时候，如果需求注释写在那边，你只需要一秒钟就知道这个地方写错了，但如果没有注释你可能要画出一整个diagram来看这个地方确实是写反了。注释能加速你阅读的进程，提醒你容易忽略的重点，告诉你那些非英语国家的怪异命名规则究竟是什么意思，请问当你看到一个变量名字叫做fis的时候你会意识到这其实是一个文件输入流吗？你说你可以看类型，没错，但要花时间对不对？别忘记写注释，我见过的优秀的代码他们总是把注释写在最需要的地方，如果你也能这样，那种水平和你不靠注释就能读代码相比，才是真的水平。
误区三：QA可有可无，测试的事情开发都能做
我想首先需要明确的是QA和Test完全是两码子事，如果非要把QA和Test混为一谈，那就是大错特错了，QA可以做Test的事情，开发也能做，QA和Test有交集，例如需要做测试驱动，那么从根本上说QA如果连整个需求和编码条件都不明白，那谈何测试驱动，我并不建议QA来充当测试驱动中测试模块的撰写者，因为代码很多时候都是一气呵成的东西，怎么驱动，怎么划分模块，多数时候真的要开发QA两边都能一致是很难的，当然，如果有条件，结对编程是个不错的选择，当然这是另外一说，至少可以看出，开发确实能做Test，但开发就是QA吗？显然不是，编码人员再有经验，再牛，都难免出错，这些错误不是指编码写错了个函数啊之类的，而是所谓的需求盲区，需求从PM的角度给出，但往往并不能涵盖所有的情况和边界条件，这时就需要需求补完，但很多补完是在开发阶段完成的（别和我说什么CMM5，那是外包忽悠人的），这时，开发人员很容易陷入自己的需求圈，出现需求盲区，这时你还要求这个开发人员同时兼职白盒测试，那就搞笑了，在一个封闭需求环境下做测试是不会有任何结果的，QA这时就会充当一个第三方补完的角色，他们能跳出开发人员的圈子来思考需求，两份需求出现差集时，就是需求bug。QA也能找出很多开发可能想都没想过的边界条件。这就是为什么我们一直强调QA需要有自己的独立思维习惯。一个好的QA不光要有缜密的心思，还要能独立思考。
暂时先写到这里，有时间我再慢慢添加。