各种流行的编程风格

在编程这个行当里摸爬滚打这些年，各种风格的开发者都见过不少。下面梳理了几种典型的“奇葩”流派，看看你身边有没有这样的“大神”？如有遗漏的，欢迎补充。

散弹枪编程

这种风格说白了就是“乱枪打鸟”。举个例子：某个方法调用报错了，程序员的第一反应是“把参数从false改成true试试”；不行？那就干脆把整个方法注释掉，或者换一种更随意的操作，直到程序跑起来为止，至于出错的根因是什么，完全不清楚。要是一个正规的程序员和这位“选手”结对编程，估计用不了多久，正规的那位也会被带跑偏，智商直线下降。而两个“散弹枪选手”凑在一起，破坏力可是翻倍，造成的后果比单打独斗还要糟糕。

撞大运编程

这比散弹枪编程要“温和”一些，但也相当普遍。很多程序员在不理解程序底层逻辑、不清楚代码实际行为的情况下，靠“试错”让程序跑起来。一旦出问题，只有两条路：要么停下来，老老实实分析出错原因；要么直接切换到散弹枪模式，开始胡乱修改。有趣的是，测试驱动开发（TDD）反而成了这类程序员的一个“科学”挡箭牌——只要我的测试通过了，你还有什么话好说？当然，TDD本身是个好东西，它确实能在一定程度上控制撞大运式开发带来的风险。

Cargo-Cult 编程

Cargo-Cult这个说法源自二战时期太平洋小岛上的土著。当时美军在这些岛上修建机场跑道，用于运输战争物资。当地人从没见过飞机，看到这些“大鸟”能带来食物和物品，觉得特别神奇。战争结束后，他们也模仿着修跑道、建塔台，然后天天盼着有飞机飞过来给他们送东西。编程圈里的这种行为比比皆是：有些程序员看见高手写了一堆复杂的代码，自己也不管为什么，照葫芦画瓢往项目里塞。最经典的例子就是J2EE刚兴起那几年，很多人不管业务需不需要，满屏都是EJB和Entity Beans，至于有没有必要？先用了再说。

刻舟求剑编程

这个成语大家都熟悉，在代码里也是屡见不鲜。比如遇到空指针异常，很多人的第一反应就是在那一行加上一个 if (p != NULL)。程序不报错了，但问题真的解决了吗？没有。你把剑掉的位置记在了船边，可船一直在往前走。这种修法只是把问题掩盖起来，最终只会让程序的行为变得神出鬼没。真正该做的，是顺着指针往下追，找到它为什么会为空的原因，然后彻底解决。

设计模式驱动型编程

有些程序员对设计模式走火入魔。代码里到处都是Facade、Observer、Strategy、Adapter……业务逻辑被层层封装，阅读代码就像剥洋葱，剥到最后发现核心逻辑已经被模式淹没了。到头来，你分不清是为了解决业务问题而用模式，还是为了用模式而用模式。最终代码变得难以维护、无法阅读，业务逻辑被这些设计模式搅得一团糟。

侦探型编程

这类程序员修Bug，就像福尔摩斯探案：先查Bug的原因，再查引发这个Bug的原因的原因，然后分析修正代码会不会导致其他代码出错，接着用文本搜索查找所有相关调用，最后写下30个测试案例——尽管其中大部分跟这个Bug没啥关系。一套操作猛如虎，终于精准地修正了一个拼写错误。与此同时，隔壁工位的正常程序员已经顺手修好了另外5个Bug。

屠宰式编程

这类程序员对重构代码有一种难以克制的冲动。哪怕产品明天就要上线了，他在修几个拼写错误的同时，也要顺手改掉10个类，重构与之相关的另外20个类，甚至还要修改构建脚本和部署描述符。结果呢？后果往往不堪设想。

参考文献