1.摘要
最近写了不少代码，review了不少代码，也做了不少重构，总之是对着烂代码工作了几周。为了抒发一下这几周里好几次到达崩溃边缘的情绪，我决定写一篇文章谈一谈烂代码的那些事。
2.写烂代码很容易
刚入程序员这行的时候经常听到一个观点：你要把精力放在ABCD（需求文档/功能设计/架构设计/理解原理）上，写代码只是把想法翻译成编程语言而已，是一个没什么技术含量的事情。
当时的我在听到这种观点时会有一种近似于高冷的不屑：你们就是一群傻X，根本不懂代码质量的重要性，这么下去迟早有一天会踩坑，呸。
可是几个月之后，他们似乎也没怎么踩坑。而随着编程技术一直在不断发展，带来了更多的我以前认为是傻X的人加入到程序员这个行业中来。
语言越来越高级、封装越来越完善，各种技术都在帮助程序员提高生产代码的效率，依靠层层封装，程序员真的不需要了解一丁点技术细节，只要把需求里的内容逐行翻译出来就可以了。
很多程序员不知道要怎么组织代码、怎么提升运行效率、底层是基于什么原理，他们写出来的是在我心目中烂成一坨翔一样的代码。
但是那一坨翔一样代码竟然他妈的能正常工作。
即使我认为他们写的代码是坨翔，但是从不接触代码的人的视角来看（比如说你的boss），代码编译过了，测试过了，上线运行了一个月都没出问题，你还想要奢求什么？
所以，即使不情愿，也必须承认，时至今日，写代码这件事本身没有那么难了。
3.烂代码终究是烂代码
但是偶尔有那么几次，写烂代码的人离职了之后，事情似乎又变得不一样了。
想要修改功能时却发现程序里充斥着各种无法理解的逻辑、改完之后莫名其妙的bug一个接一个，接手这个项目的人开始漫无目的的加班，并且原本一个挺乐观开朗的人渐渐的开始喜欢问候别人祖宗了。
我总结了几类经常被艹祖宗的烂代码：
3.1.意义不明
能力差的程序员容易写出意义不明的代码，他们不知道自己究竟在做什么.
就像这样：
public void save() {
for(int i=0;i<100;i++) {
//防止保存失败，重试100次
document.save();
}
}
对于这类程序员，我一般建议他们转行。
3.2.不说人话
不说人话是新手最经常出现的问题，直接的表现就是写了一段很简单的代码，其他人却看不懂。
比如下面这段：
public boolean getUrl(Long id) {
UserProfile up = us.getUser(ms.get(id).getMessage().aid);
if (up == null) {
return false;
}
if (up.type == 4 || ((up.id >> 2) & 1) == 1) {
return false;
}
if(Util.getUrl(up.description)) {
return true;
} else {
return false;
}
}
很多程序员喜欢简单的东西：简单的函数名、简单的变量名、代码里翻来覆去只用那么几个单词命名；能缩写就缩写、能省略就省略、能合并就合并。这类人写出来的代码里充斥着各种g/s/gos/of/mss之类的全世界没人懂的缩写，或者一长串不知道在做什么的连续调用。
还有很多程序员喜欢复杂，各种宏定义、位运算之类写的天花乱坠，生怕代码让别人一下子看懂了会显得自己水平不够。
简单的说，他们的代码是写给机器的，不是给人看的。
3.3.不恰当的组织
不恰当的组织是高级一些的烂代码，程序员在写过一些代码之后，有了基本的代码风格，但是对于规模大一些的工程的掌控能力不够，不知道代码应该如何解耦、分层和组织。
这种反模式的现象是经常会看到一段代码在工程里拷来拷去；某个文件里放了一大坨堆砌起来的代码；一个函数堆了几百上千行；或者一个简单的功能七拐八绕的调了几十个函数，在某个难以发现的猥琐的小角落里默默的调用了某些关键逻辑。
这类代码大多复杂度高，难以修改，经常一改就崩；而另一方面，创造了这些代码的人倾向于修改代码，畏惧创造代码，他们宁愿让原本复杂的代码一步步变得更复杂，也不愿意重新组织代码。当你面对一个几千行的类，问为什么不把某某逻辑提取出来的时候，他们会说：
“但是，那样就多了一个类了呀。”
3.4.假设和缺少抽象
相对于前面的例子，假设这种反模式出现的场景更频繁，花样更多，始作俑者也更难以自己意识到问题。比如：
public String loadString() {
File file = new File("c:/config.txt");
// read something
}
文件路径变更的时候，会把代码改成这样：
public String loadString(String name) {
File file = new File(name);
// read something
