《人月神话》出版以来，IT行业的科技公司们一直苦苦追寻传说中以一当十的超级程序员，最新的研究表明确实存在这样一小撮效率奇高的“程序金刚”，但是一位普通程序猿如何能够蜕变成代码金刚呢？

你可以说：之前改一个模块要3天，重构之后1天就可以了。但是怎么应对“不就是做个数据库操作吗为什么要3天”这类问题？烂代码“烂”的因素有不确定性、开发效率也因人而异，想要证明这个东西“确实”会增加两天开发时间，往往反而会变成“我看了3天才看懂这个函数是做什么的”或者“我做这么简单的修改要花3天”这种神经病才会去证明的命题。

我惊奇地发现原作者实际上是一群拥有很高技术水平的资深工程师。是什么导致一群有能力的开发者产出并交付这样一堆垃圾呢？我能想到的原因有很多。这些是我认为连资深的团队都可能会沾染的坏习惯，这些坏习惯会严重地影响你的终端产品，甚至连源码检查或者开发方法论都无法拯救。

在维护别人的代码时一定要保持平常心， 「烂代码」无处不在，就算是再牛逼公司中再牛逼的程序也会生产出在别人眼里的「烂代码」。 有句话说的好：既然逃避不了被强奸的命运，那就学会享受吧！下面为大家奉上一些另人哭笑不得的代码博大家一笑

最近写了不少代码，review了不少代码，也做了不少重构，总之是对着烂代码工作了几周。为了抒发一下这几周里好几次到达崩溃边缘的情绪，我决定写一篇文章谈一谈烂代码的那些事。 这里是上篇，谈一谈烂代码产生的原因和现象。

经常有人问我这种看上去很简单，但是实际上非常复杂的问题。“我团队中有一个人写的代码极其纷乱复杂，根本无法维护。我该怎么办？”

大家都在抱怨同事的代码写的烂，前同事遗留下来的代码bug多…… 那问题来了，写这些烂代码的人都去哪了？ 好奇怪哎!

我最近一直在想我们作为一个行业为什么总是产出糟糕代码的原因。