写代码实现功能难，维护别人的代码更难。离开之前的公司，投入新公司的怀抱， 几乎所有的开发者，都遇到过要维护烂代码的尴尬情形。那么，如果新入职的一家公司，需要我去维护烂代码，我是该辞职呢？还是看在工资的面子上，硬着头皮干下去？
当接盘侠可不是一个好的体验，给自己带来最大影响的，莫过于自己的胆子越来越小了。生怕哪里代码改了，没有按照前辈的想法运行，毕竟人都已经走了，锅只能是留下的人来背。
胆子小还不算是什么大问题，要是看见要维护的代码，没有开发文档、代码还挤在一起，没有注释，血压是蹭蹭蹭的往上涨，恨不得宰了写代码的那个家伙。
几乎所有的开发者，到了新公司，都有过这样的经历，潇洒一些的，直接拍屁股走人，不信邪的，撸起袖子重构一下。但俗话说的好：重构一时爽，头发不再长。经验丰富的程序员，可不会轻易的进行重构。
那就只剩下拍屁股走人这条路了吗？当然不是，一个拥有10年工作经验的程序员，看到一堆烂代码，绝对不会轻易离职，因为他明白，无论走到哪儿，碰到的肯定都是烂代码。
留下烂代码，有很多种原因，并不代表着公司的实力。绝大不多数开发人员到新公司后，都会觉得新公司代码很烂。这种“烂”的感觉，除了代码本身的问题，还有业务逻辑层面的关系。
当你不了解业务逻辑是怎么变化的，这个烂代码是怎么写出来的，有什么特殊背景时，你只是以纯技术的角度看待问题，自然就觉得它烂出天际了。
假如你因接手代码太烂，而提出辞职，那么下一家公司，一样会面临同样的问题。
我们得肯定的是，没人会故意写一些烂代码出来，每个程序员，都有写出优雅代码的心。但可能因为水平不够，导致在别人看来，就是所谓的垃圾代码。一个很好的例子：当你回首看自己三个月前些的代码时，你一定会：
一位刚实习一个月的实习生，就碰到了一件让人哭笑不得的事，技术部老大突然拍案而起，大叫道：“这是谁写的烂代码！查一下！”
“老，老大，这是你三个月前写的。”
其次，技术更新迭代很快，市场的变化也很大，产品自然也一直演变，也许当时看起来不错的代码，随着时间的推移、代码的堆砌，慢慢就变成了大家眼中的烂代码了。
再者，先实现产品功能，再优化，是当今快速发展的互联网市场，最基本的原则。在产品初期，往往不会过多考虑架构设计、性能优化之类的，几乎都会把精力放在功能实现上，而功能的实现是永远不会结束的，留给技术人员优化、重构的时间实在太少。于是乎，破窗效应产生，越大型的产品，留下的问题、烂代码也就越多。
看见所谓的烂代码，很容易有挫败感，还会引发其他负面情绪。但我们不应该看见了代码就发愁，看见代码脏乱差就埋怨，看见代码逻辑复杂就头疼，搞不清调用关系就放弃。那样，永远成为不了代码的主人，只能一次又一次的被代码蹂躏。
你只需要记住一句话：所有不能将你毁灭的，都将成为你的垫脚石！
