弱爆程序员的特征值

来源:陈皓

首先说明:

1、以下特征是真实遇到过的,同事犯过的,乃至我自己也犯过的;

2、为了剧情需要,某些例子进行了一些夸张修饰等演绎创作,如无雷同,请勿生气;

3、如果你出现过以下症状之一,并不代表你就是弱爆了,但是如果你一直出现,乃至一说到这个大家就能联想到你,那么你就得小心了;

4、如果你是集这几个的大成者,恭喜你,你已经找到了离开这个行业的充足理由了。

好了,搞定!

“那个Bug解决了吗?”

“好了,搞定!”

“这么快?”

正当你非常欣喜的时候,就传来了噩耗:刚才还能编译成功的,就失败了。(好吧,我们的集成编译尚未成功配置上,理论上这种事情应该会被退回。)又或者能编译成功,但是呢,原来明明能起作用的一个下拉框,突然发神经的不起作用了。最隐蔽的莫过于,一切正常,但是当你看到代码的时候,你就晕厥过去了。比如我们曾经发现了一个Bug,简单说就是每次用户点击某个东西,就会执行下面的这段C#代码:

这个Bug很明显会导致速度越来越慢,因为同一个更新操作会被更新N次,并且这个N会越来越大。其实这个Bug已经够弱了,但是后来居然被修改为:

这段代码能编译,能执行,但是就是弱爆了。因为这不仅仅没有从根本上去掉造成问题的逻辑,还会带来更多的困惑:为什么要先减后加呢? 这类特征,请大家看看有趣的《各种流行的编程风格》,我这个例子算是一种撞大运。我觉这吧,这类问题都是因为只想解决一些表面的东西为目的,完全不管底下的其它任何问题而造成的。

那估计是他的Bug

“这个问题为啥还没解决呢?”

“我觉得应该是他那里边的Bug,我调不了。”

“哦……”

这个“他”可以是某一位同事,或者前同事,或者微软,或者别的什么公司,再或者某个开源代码的作者。这些个我都遇到过,比如说是另一位现在在职的同事吧。当你告诉这位同事这个Bug似乎在他那儿,并且问问什么时候解决,他也许会很愧疚的立刻调试,可最后结果却仍然是开头对话主人翁的所写代码的问题。

再比如说是微软吧,那么对话可能就会包括:“啊,SilverLight真是烂,老是内存泄漏、崩溃等……”“是啊是啊!烂死了!早知道用Flash了。”又或者会说:“微软就是烂,Java就是好。”其实,我不想比较什么SilverLight还是Flash,.NET还是Java。因为在讨论这些问题之前,先最好想想,这真的是别人的错么?相信是其他人的错是一件很简单的事情,因为这样推脱之后你就可以啥都不做了,反正不是我的错。 如果真的发现了这是别人的Bug并证明了,那倒好说。但这种特征是一种纯粹的怀疑,并没有丝毫的证明。在仔细找了自己所有可能犯的错之后,如果你怀疑是别人的问题,那请求证一下。

无图无真相!

“楼主,无图无真相啊!”

“楼主,无代码无真相啊!”

“楼主,给翻译一下啊!”

据说Linus在别人询问Linux内存管理的一个什么问题时,回答道“Read the fxxxing source code”,很多时候我也有类似的冲动。我发现在信息发达的时代,不少人的阅读能力、动手能力都严重退化了。这些人最好就是你亲自来帮他把问题解决了,他才不想了解里面到底 发生了什么。这种问题体现在博客里面,就是寄希望于你写得图文并茂,图嘛最好花里胡哨同时言简而意概,文字嘛最好大段大段的代码。其实图不是重要的,只是为了好看,重点是代码,这样他一Copy就可以直接解决他们的问题了。

比方说,Silverlight里面没有各种图像格式的编码器,于是当你希望保存Jpg的时候怎么办呢?Google一下,发现原来有人写过一个FluxJpeg的编码器。下载下来一跑,唉还真能用哎。之后就直接签入,也不捎带看一下有没有什么问题,或者设计不合理的地方。(其实真的有,会很慢,因为有大量毫无必要的数组拷贝。)

又或者说,遇到了某个Bug,搜索一下发现,哎,还真有人遇到过,而且还有代码哎!把代码扒下来一跑,发现好像解决了,至于为什么就不管了。甚至还遇到过根本就不管解决不解决问题,反正代码扒下来了就签入了的。

再比如,写一篇博客讲解如何缩减.NET编译出来的文体大小,其中提到许多概念需要先阅读微软官方的一个文档。结果,还是会有人回复说,你那个文章里面提到那么多的Blob,也不说说Blob里面都有什么,大概是很不满意吧。可是这个文档里面都有啊,难道就不能自己阅读一下?其实即便我连这个文档都没有给出,自己也应该有这个能力去进行思考,去动手寻找。

千万不要退化成一个啥都要别人给你嚼烂了才能够吞下去,吞下去也不会消化吸收的人。这样的人大概别人给的是大便,只要有代码无真相,也会照样吃下去的。若真如此,那你打算如何提高呢?

那是个对象!

“这个ExpressionVisitor,它是用来干什么的?”

“……”

“好吧,或者这么说,他是一个什么东西?”

“他是一个对象!”

“啊?”

“哦,是一个对象的实例。”

大概这样的回答,和那个微软工程师说“你在直升飞机上”差不多——反正你也不能说是错的,但是就是没什么意义。其实不知道没啥问题,人又不是神,怎么可能都知道呢?不去仔细了解和学习问题也不严重,因为你可以改。但是当你习惯性的随便找一个绝对没错但又不说明任何问题的答案,甚至似是而非的东西来对付的时候,你就离弱爆的边缘很近了。

当然,上面的对话也许是比较极端的。一个稍弱一点的对话版本是:

“这个内存泄漏是怎么造成的呢?”

“嗯,会不会是图片放的位置不对呢?”

哈,还是很夸张对吧?没办法,写博客有时候需要夸张的文字,否则你无法理解我的意思是:有时候,大家会倾向于从自己的记忆中寻找一些相似的物品,然后选择相似度自认为比较高的东西出来当作答案,而全然不管两者之间的逻辑是否有哪怕那么一丝的关联。也许很多时候,我们确实需要从相似的东西开始,但请别把他当作终点。程序是需要严谨的逻辑的,所以你也必须非常严谨的去推演。

关于这类的问题真的太多太多了,比如我指着下面这段代码当中的红字:

var dictionary = new Dictionary<string, string>();
dictionary[“someKey”] = “someValue”;

“这句话说明了什么?”

“说明dictionary是一个数组。”

集大成者

最后我举一个集大成者的例子,说,有个任务是要在SilverLight应用上面添加一个“收藏本站点”。好,怎么解决呢?网上一搜,发现有很多这样的代码:

 

“这是什么原因呢?”

“不知道,反正浏览器报告没有权限,可能是浏览器的安全设置原因吧,或者操作系统的Bug,也可能是浏览器的某种Bug?”

“不可能啊?这些代码存在很多年了,要有问题早就能在网上搜索到了。”

“那也许是SilverLight调用的时候有什么安全问题。哎!SilverLight好烦啊!”

“那怎么还没有解决呢?”

“好,我马上解决它!”

很快,那段Javascript就变成了:

看到这样的代码,我彻底震惊了。亲自调试了一下,发现确实报告了一个“没有权限”的异常。但是,我还发现,那个Url参数的值是“www.adomainname.comtestpage.html”。那这不废话么!浏览器认为你要收藏的是一个本地硬盘上的路径,怎么可能在一个Internet Zone上允许收藏这种路径呢?我于是指着代码问:

“这个Url是什么?”

“是一个变量”

“啊?”

“哦,不对,是一个参数。”

你是否也有类似的经历呢?

收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部