重知识轻技术

      讲一些关于程序员对自身认识的故事，这些故事都和灯下黑有关。只要正确认识自己，道理非常简单，但是，到处都可以看到灯下黑的故事。

　　某程序员，有一天接到一个任务：公司的有一个产品的文件太大了，要求采用压缩算法，减少尺寸，最好能压缩20%。

　　程序员兴高采烈地接受了任务：以前没玩过压缩算法，这下可以学习新东西了！研究了几个月后，他觉得差不多了，就交给了项目经理。项目经理正等着呢，高兴坏了，拿着演示文件就去找产品经理。产品经理开始挺高兴，看完脸就拉下来了。打开文件，把所有的文件尺寸一算，很淡淡的说：“才压缩了10%，有什么用啊！”

　　程序员愣住了，“不会吧！我看过的，压缩了 20%！”

　　产品经理指着文件列表说：“你看，某文件是压缩了20%，可你的压缩算法增加了一个动态库文件，尺寸还不小，总共加起来，不就只减少了10%吗？”

　　各位看官，这是不是软件公司里经常发生的情形？

　　这种失败的成因当然是复杂的，有沟通管理方面的问题，也有程序员能力的问题。我今天想要说的是程序员认识方面的问题。

　　继续故事：

　　项目经理很没面子，回去就和程序员找原因。项目经理是老程序员了，直话直说；终于弄清楚的事情的本质：

　　第一，这位程序员一个月的时间读了很多关于压缩算法的书，会了不少算法。可是从来没比较过算法的优劣。这老兄觉得研究算法很有趣，乐此不彼，写了好几个实现。

　　第二，这位老兄在最后几天才想起来20%的目标，也没太放在心上，看看差不多就拿出来了。

　　这是典型的程序员的认识问题，重知识而轻技术。

　　先从是么是知识，什么是技术说起。

　　知识就是知道，你知道了某件事是怎么回事，就是有了知识。

　　技术就是你能做出来，做得好叫技术好，做的不好叫技术差。

　　怎么写操作系统？看完操作系统原理，再苦读完源代码，这叫有知识了。如果有本事把任务调度、内存管理、IO什么的都写出来，还能写得稳定，快速，可扩展，那是有技术。有知识和有技术可差远了。早年我在工厂实习，要挫一个圆孔，拿着内锉刀干了一天，只挫了一个椭圆；师父来了，三分钟，比冲床冲出来还圆！我是个好学徒，使用锉刀的知识全记住的，可以写一篇内圆挫使用大全。知识是有了，可没这个技术。 程序员也一样。什么C++，Java，.net，什么STL，Struts，Spring，就是门门都满分，这也就是有知识。算不算技术好呢？差远了。软件工程师界就专门出这种不会写程序的“高手”。我遇到一位老兄，精通Java知识，从虚拟机到各类框架，概念，无所不同，谈起Java来，没人说的过他。可是他的代码永远Bug最多，而且都是最简单的Bug，什么逻辑不对啊，功能没实现啊，UI不对啊。他的领导只有又好气又好笑。问下去，发现这老兄写了几个程序文件以后，就不感兴趣了，因为所用的技术没什么不知道的了。所以马马虎虎交差。

　　说到底，写程序是个手艺活，就和古代的匠人一样，是要讲工艺的。比如一个玉匠，能打造栩栩如生的玉孔雀，那得打的好！要是一个玉匠说，这些手艺我都知道了，重复做东西没劲，将就着给客人做出来吧！那他还不吃西北风！

　　可是，十几年来，程序员界有的是这样的人，还引发大规模争论。象什么C++和Java之争啦，J2EE和.Net之争啦。你看里边的帖子，不停有人赌这个阵营那个阵营，有发誓一辈子做C++的，有发誓打倒.Net。我还奇怪了，专门没人效忠机器码的，那不是最难最有“学问”吗？这都是在争论什么知识最重要。可是啊，很少有人谈谈怎么做好产品的。

　　现在程序员最大的问题就是太看重知识，拼命追逐新玩意，而忽略了身边的够得着东西。好，什么C++，Window API都知道了，东西也弄出来了，可是三天两头崩溃，还找不到原因？为什么？有没有看看代码，看看是不是某函数写了2000行，自己都看不懂？是不是全局变量乱用？是不是没考虑前后兼容性？没考虑冗余和故障恢复？

　　末了再回到开头的故事：

　　项目经理回去和程序员再重新设计，又多花了一个月，终于达到了目标。但因为这个部分是一个大项目的一部分，整个项目不得不延迟了一个月。

　　年底考评的时候，项目经理给程序员打了一个及格；程序员不服，告到总经理那里。总经理说：“你知足吧，给你打及格已经看在你干的很辛苦的份上了，因为你没有按时完成，整个项目延迟了一个月，这帐都没找你算呢。”程序员颓然。

转载于:https://www.cnblogs.com/sukiwqy/archive/2009/12/05/1617789.html