标题: 程序员的灯下黑:重知识轻技术(转)
sinister
技术专家
Rank: 14Rank: 14Rank: 14Rank: 14


UID 36664
精华 14
积分 348
帖子 384
活跃指数 312
LU金币 2029 个
LU金条 0 个
阅读权限 200
注册 2005-11-17
 
发表于 2006-9-25 01:26  资料  个人空间  主页 短消息  加为好友  添加 sinister 为MSN好友 通过MSN和 sinister 交谈 QQ
程序员的灯下黑:重知识轻技术(转)

程序员的灯下黑:重知识轻技术


电视《雍正王朝》讲了这么一个故事:大将军年羹尧奉命到青海平叛,清军因路途遥远,军耗巨大,因此力求速战速决。但叛军避开锋芒,东躲西藏,年羹尧没有办法找到叛军决战。这时,朝廷内外压力越来越大,年羹尧陷入困境。这是一位谋士对年说:我知道叛军在那里。年大喜。这位谋士指出,敌人就在不远处的一座皇封寺庙里。年不信,谋士不慌不忙地说:这就是灯下黑,离自己越近就越不可能意识到,但却是最可能的地方。果然,大军一出,大获全胜。

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



某程序员,有一天接到一个任务:公司的有一个产品的文件太大了,要求采用压缩算法,减少尺寸,最好能压缩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行,自己都看不懂?是不是全局变量乱用?是不是没考虑前后兼容性?没考虑冗余和故障恢复?




末了再回到开头的故事:

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

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





没有道德现象,只有现象的道德解释。
顶部
orian (x40)
版主
Rank: 15Rank: 15Rank: 15Rank: 15Rank: 15



UID 18050
精华 27
积分 2431
帖子 4306
活跃指数 349
LU金币 5492 个
LU金条 251 个
阅读权限 210
注册 2004-4-14
来自 海上
 
发表于 2006-10-7 13:14  资料  个人空间  短消息  加为好友  添加 orian 为MSN好友 通过MSN和 orian 交谈
想到一个问题,对待工作是当作学习呢?还是当作艺术?或者是赚钱不得不走的过程而已?





垃圾猪 Orian

mail@msn://ensighine(at)yahoo.com
请访问垃圾猪的垃圾堆:
http://ensighine.spaces.live.com/

All other men are specialists, but his specialism is omniscience
顶部
sinister
技术专家
Rank: 14Rank: 14Rank: 14Rank: 14


UID 36664
精华 14
积分 348
帖子 384
活跃指数 312
LU金币 2029 个
LU金条 0 个
阅读权限 200
注册 2005-11-17
 
发表于 2006-10-7 22:59  资料  个人空间  主页 短消息  加为好友  添加 sinister 为MSN好友 通过MSN和 sinister 交谈 QQ
后者苦了自己,也糟蹋了技术。

可以去研究新技术,研究新方法。但如果一个新技术只是被提出,或者提出了很多年只有
一个 POC 类的东西,而非达到产品级别。那么这项技术是否能转换为产品,或者说你是否
有能力转换为产品。尤其是那些有所创新的技术,这个才是见真功夫的,把功能实现,可以
说仅仅是一个开始。





没有道德现象,只有现象的道德解释。
顶部
大漠孤星
管理员
Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20


LU爱心使者  
UID 257
精华 24
积分 3097
帖子 4279
活跃指数 570
LU金币 2934 个
LU金条 422 个
阅读权限 255
注册 2003-9-30

用支付宝求购
 
发表于 2006-11-1 20:26  资料  个人空间  短消息  加为好友  添加 大漠孤星 为MSN好友 通过MSN和 大漠孤星 交谈 QQ
恩,受益颇深。
知识就是知道多少,技术就是能用知识解决多少问题。而且问题要解决得快速,高效,这就叫水平。





顶部
 



当前时区 GMT+8, 现在时间是 2008-10-7 20:23
乐悠LoveUnix论坛-京ICP备05005823号

Thanks to Discuz!  © 2001-2007    Power by LoveUnix.net
Processed in 0.060654 second(s), 6 queries , Gzip enabled

清除 Cookies - 联系我们 - 乐悠LoveUnix - Archiver