事情是这样的，前几天在朋友圈，我看到一朋友发表了一条说说：“入职新公司，从重构代码到放弃”，我就问他怎么了？他说，刚进一家新公司，接手代码太烂，领导让我先熟悉业务逻辑，然后去修复之前项目中遗留的bug，实在不行就重构。

关键是，离职的那位仁兄走之前，还跟我在QQ上说，老哥辛苦了，我写的很乱真不好意思，但我是故意的。

这几天，我都在想，要不要离职？

———

听完你的遭遇，我想先说一句，离职那位仁兄太狠了！！！

其次，我相信，这个问题很多人都遇到过。

每个新人去一家新公司都会觉得公司代码很烂，可能是因为他没被产品虐过。

其实，这种新员工很不错了，一看就是真萌新，重构这种事，老板看不到 KPI，出了事还得自己兜底，还会得罪人，费力不讨好，何必呢！

老前辈的警世良言一定要牢记：重构一时爽，头发不再长。

还有，工作了10年的码农，到了新公司，绝不会说这种话。

不过话说回来，能觉得模块代码烂，还能撸起袖子去改的程序员，真是很难得的一种精神。我身边 90%都是只是嘴上说，绝对不动手干的。下一次下一次下一次，无数的下一次造就了烂代码。

「 要不要重构 」
 

很多人口中的重构就是重写，而不是去改善现有的代码。

现在的有些工程师太浮躁, 动不动就要重构, 就跟很多的团队动不动就要搞一个框架一样。

说实话，以我个人的经验来说，绝大多数开发人员到新公司后，都会觉得代码很烂，但通常他不了解业务逻辑是怎么变化的，这种代码是在什么情况下写出来的，有什么特殊的背景（除了真的是乱搞的，绝大多数的“烂代码”一般都是有原因的：业务需求改改改，这个需求明天就要上线等等等等），有多少坑（很少有人能在极短时间内把所有的坑都找出来）。

如果贸然去重构，风险非常大。而且再说难听点，就算重构完了，也有可能是一堆新的“烂代码”替换老的“烂代码”。

所以，进了一家新公司，别动不动就重构，先了解项目的业务逻辑。

「 要不要离职 」
 

其实在我看来，如果仅仅因为接手代码太烂，就选择离职，那么你跳槽到下一个公司依然会面对同样的现状，因为几乎每个人，都会觉得自己公司的项目代码很烂。

我们先说说造成这种现象的原因是什么，首先，我们得相信，没有任何一个人故意把自己的代码写的很烂，每个人都想把自己的代码写的很优雅，扩展性很好，但是可能当初水平不够，在当时看似还不错的代码，日后在别人看来就是所谓的垃圾代码。

我们每个人都在进步，别说别人了，你现在看你三个月之前的代码，可能你都会觉得写的很垃圾，如果你没有这种感觉，只能说你在止步不前。

其次，技术更新换代太快，市场的变化也太快，产品自然也一直在演变，也许在当时看起来还不错的代码，随着时间的推移，功能的更新，代码的堆彻，慢慢就变成后来者眼中的烂代码了。

「 如何从烂代码中爬出来 」
 

假如你真的要接手别人的代码，怎样才能不被玩儿死呢？

虽然你可能会说，听了很多道理，依然交接不好代码，可作为经常被别人的代码玩得欲仙欲死的老司机，我有些话如鲠在喉，不吐不快。

当你被要求接管要离职的程序员的代码时，如果能注意以下几点，就有可能活着从他的代码里爬出来。

1. 产品需求与业务流程文档

产品需求与业务流程文档，这些是你先要找到的，你接手的代码，必然和某个产品需求相对应，必然实现了某个业务流程，先了解产品需求和业务流程，才能更好的读代码。

假如你的团队就是没文档，Ok，也可以要求离职或转移战线的这位程序员把需求描述出来，把业务流程画出来。

2. 测试环境

了解了产品需求和业务流程，最好能体验一下软件，从用户的角度来理解软件的使用。这个时候你要么需要生产环境，要么需要测试环境。哪个环境不重要，重要的是，你需要一个能Run，能体验的软件。