各种流行的编程风格

各种流行的编程风格

在过去的N年中,我遇到了很多使用囧然不同风格的开发者,下面是我所知道的一些,你还知道其它的吗?

散弹枪编程

这种编程风格是一种开发者使用非常随意的方式对待代码。“嗯,这个方法调用出错了……那么我会试着把传出的参数从 false 变成 true!”,当然依然出错,于是我们的程序员会这样:“好吧,那我就注释掉整个方法吧”,或是其它更为随意的处理方式,直到最后让这个调用成功。或是被旁边的某个程序员指出一个正确的方法。

如果我们把一个正规的程序员和一个撞大运的程序员放在一起做结地,那么,那个正规的程序可以马上变得发疯起来,并且,可以把正规的程序员的智商降到最低。两个撞大运的程序员不应该在一起做结对编程,这是因为他们破坏性的才能会造成的伤害会比只有一个还差。

撞大运编程

这是一种比散弹枪编程要温和一些的编程方式,我相信这种方式可能会是大多数程序员都会使用的方式。这种编程方式经常出现于程序员并不确切知道他们在干什么,也不知道所写的程序的本质和实际,但是可以让程序工作起来。他们以一种撞大运的方式在写程序,某些时候,他们根本就不知道某个错误的原因,就开始稀里糊涂地修改代码。一旦出现问题,他们会用两条路:1)停下来,理解一下程序,找到出错的原因。2)使用散弹枪编程方式开始解决问题。

测试驱动开发(Test Driven Development)是一种可以用来拯救上百万的撞大运编程的程序员。于是,他们有了一个更为NB的借口:只要我的程序通过测试了,你还有什么话好说?别骂我,测试驱动开发是一个不错的事物,其主要是用来控制撞大运开发所带来的问题。


Cargo-Cult 编程

关于Cargo Cults 这个词儿来自二战期间的某些太平洋上小岛里的土著人。在战争期间,美国利用这些小岛作为太平洋战场上的补给站。他们在这些小岛上修建自己的飞机跑道以用来运输战争物资。而那些小岛上的土著人从来没有见过飞机,当他们看到飞机的时候,觉得相当的牛,可以为那些白人带来各种各样的物品和食物。当二战结束后,那些土著人仿照着修建了飞机跑道,并用竹子修建了塔台。然后就在那期望着有飞机为他们送来物品和食物。

Cargo Cult 编程是一种非常流行的编程方法,使用这种方法的程序员会学习其它编程高手的编程方法,虽然他们并不知道为什么高手们要那样做,但是他们觉得那样做可以让程序工作起来。举个例子,当时有大量的程序员在J2EE出现的第一年中过度地使用了EJBs和Entity Beans。

刻舟求剑编程

刻舟求剑是一个很流行的寓言了。这种风格的编程在程序员的圈子里是非常常见的。比如,有一天,你发现了一个空指会的异常,于是你到了产生空指针异常的地方,简单地放上一个判断: if (p != NULL)。

是的,这样的fix可以让你的程序工作起来,但你并没有真正地解决问题。你只不过是在你的船边记下了剑掉下去的位置,这样做只不过把问题隐藏起来,最终只会让你的程序的行为变得神出鬼没。你应该找到为什么指针会为空的原因,然后再解决这个问题。

设计模式驱动型编程

正如这种编程的名字所说的,这种编程风格使用大量的设计模式,在你的程序中,四处都是设计模式,你的代码到处都是Facade,Observer ,Strategy,Adapter,等等等等。于是,你的程序要处理的业务逻辑被这些设计模式打乱得无法阅读,最后,也不知道是业务需求重来,还是设计模式重要,总之,实际业务需求的程序逻辑被各种设计模式混乱得不堪入目。

侦探型编程

在解决一个Bug的时候,侦探型程序员会调查这个Bug的原因。然后,则调查引发这个BUG的原因的原因。再然后,其会分析修正代码后是否会导致其它代码失败的因果关系。再然后然后,他会使用文本搜索查找所有使用这个改动的代码,并继续查找更上一级的调用代码。最后,这个程序员会写下30个不同的情形的测试案例,就算这些测试案例和那个Bug没有什么关系,最最后,这个程序员有了足够多的信心,并且精确地修正了一个拼写错误。

与此同时,其它一个正常的程序修正了其它5个Bug。

屠宰式编程

使用这种风格的程序员,对重构代码有着一种难以控制的极端冲动。他们几乎会重构所有经手的代码。就算是在产品在Release的前夜,当他在修正几个拼写错误的bug同时,其会修改10个类,以及重构与这10个类有联系的另20个类,并且修改了代码的build脚本,以及5个部署描述符。

文章:来源
(全文完)


关注CoolShell微信公众账号和微信小程序

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
好烂啊有点差凑合看看还不错很精彩 (46 人打了分,平均分: 4.89 )
Loading...

各种流行的编程风格》的相关评论

  1. 很好的文章,但有几处小小的笔误,我在下边列出来,希望博主改下:

    原文:如果我们把一个正规的程序员和一个撞大运的程序员放在一起做结地,
    修正:如果我们把一个正规的程序员和一个撞大运的程序员放在一起做结对,

    原文:那个正规的程序可以马上变得发疯起来,
    修正:那个正规的程序员可以马上变得发疯起来,

    原文:比如,有一天,你发现了一个空指的异常,
    修正:比如,有一天,你发现了一个空指针的异常,

    原文:最后,也不知道是业务需求重来
    修正:最后,也不知道是业务需求重要

    原文:与此同时,其它一个正常的程序修正了其它5个Bug。
    修正:与此同时,其它一个正常的程序员修正了其它5个Bug。

  2. “程序员”总是打成”程序”,少个”员”,看起来非常的不舒服,望博主发文前再三检查,否则像我这种重度强迫症的程序”员”会像吃了苍蝇般难受

  3. 揭阳无聊人 :
    我觉得个“侦探型编程”最好。。。但现实往往不容你这么做,因为当出现BUG的时候BOSS会要求快速 快速 更快速的修改好。这时候,如果你知道哪里出错了,你只能使用“刻舟求剑编程“处理好BUG,交给BOSS审核,然后再做“侦探型编程“;如果你不知道哪里出错了,你只能使用“散弹枪编程”,各种查找出 出现错误的地方,然后“刻舟求剑编程”,最后再做“侦探型编程”。

    同意

  4. 呵呵,项目上线前我还是有点屠夫的。改别人代码的话就小心翼翼,控制自己的洁癖症了。

  5. 侦探型编程,这个是我常用的,挺费精力,但我觉得很必要~也许文章的意思是,要考虑整体工作效益

  6. welpher.yu :
    貌似是随着进度的进行会把以前的架构给变了,难道是屠夫?

    屠夫当然不会觉得自己是屠夫了,但是他们总是会在不经意间就重构了代码和框架……

  7. 对于屠宰式编程我深有体会,其实这个有利有弊,多半屠夫都是对这个工程相当相当的熟悉的人,带来的问题是屠夫几刀下去,小弟们可能要花10倍的时间读懂新的东东了。 如果屠夫能把一次几个毫无关联的改动分开提交,然后在给点注释就好了。可惜大牛们都很忙,可怜了苦逼的小弟,看着东一榔头西一棒子的改动瑟瑟发抖。

  8. 未系统学过设计模式,某天有朋友在我面前鼓吹设计模式的时候,我一听差点晕了,原来这就是设计模式?这不是我早就用了多年的很普通的解决方案么?所以,我不是设计模式驱动型的。

    凡是负责任的开发者都应该是侦探型的,在我的眼里,所有现象都必须是在预期中的,所有结果都必须是可解释的。当然为了进度,在解决了BUG并测试之后需要发布,但在心中必然要记住这个曾经的BUG,在睡不着的时候,在爬山的时候……或者在公司里没有美女找你的时候,就是你要搞清楚这BUG来龙去脉的时候。把一个未决的问题长久地留在脑海里并择时思考也是一种能力,更是一种责任。

三水进行回复 取消回复

电子邮件地址不会被公开。 必填项已用*标注