老前辈的警世良言一定要牢记：重构一时爽，头发不再长。
还有，工作了10年的码农，到了新公司，绝不会说这种话。
不过话说回来，能觉得模块代码烂，还能撸起袖子去改的程序员，真是很难得的一种精神。我身边 90%都是只是嘴上说，绝对不动手干的。下一次下一次下一次，无数的下一次造就了烂代码。
到底要不要重构？
很多人口中的重构就是重写，而不是去改善现有的代码。
现在的有些工程师太浮躁, 动不动就要重构, 就跟很多的团队动不动就要搞一个框架一样。
说实话，以我个人的经验来说，绝大多数开发人员到新公司后，都会觉得代码很烂，但通常他不了解业务逻辑是怎么变化的，这种代码是在什么情况下写出来的，有什么特殊的背景，除了真的是乱搞的，绝大多数的“烂代码”一般都是有原因的：业务需求改改改，有多少坑其实很少有人能在极短时间内把所有的坑都找出来。
如果贸然去重构，风险非常大。而且再说难听点，就算重构完了，也有可能是一堆新的“烂代码”替换老的“烂代码”。
所以，进了一家新公司，别动不动就重构，先了解项目的业务逻辑。
我到底要不要离职？？？
其实在我看来，如果仅仅因为接手代码太烂，就选择离职，那么你跳槽到下一个公司依然会面对同样的现状，因为几乎每个人，都会觉得自己公司的项目代码很烂。
我们先说说造成这种现象的原因是什么，首先，我们得相信，没有任何一个人故意把自己的代码写的很烂，每个人都想把自己的代码写的很优雅，扩展性很好，但是可能当初水平不够，在当时看似还不错的代码，日后在别人看来就是所谓的垃圾代码。
我们每个人都在进步，别说别人了，你现在看你三个月之前的代码，可能你都会觉得写的很垃圾，如果你没有这种感觉，只能说你在止步不前。（欢迎加入全栈开发交流圈子，群号：864305860）。
其次，技术更新换代太快，市场的变化也太快，产品自然也一直在演变，也许在当时看起来还不错的代码，随着时间的推移，功能的更新，代码的堆彻，慢慢就变成后来者眼中的烂代码了。
从该死的烂代码中爬出来 ！
产品需求与业务流程文档，这些是你先要找到的，你接手的代码，必然和某个产品需求相对应，必然实现了某个业务流程，先了解产品需求和业务流程，才能更好的读代码。
了解了产品需求和业务流程，最好能体验一下软件，从用户的角度来理解软件的使用。这个时候你要么需要生产环境，要么需要测试环境。哪个环境不重要，重要的是，你需要一个能Run，能体验的软件。
负责交接代码给你的那位同事，要么在办离职，要么已经介入了其他产品，眼下很可能已无心恋战，但你心里要清楚，只有他才能提供代码层面的东西，比如类图、模块划分说明、数据流图、时序图、状态图等等。
所以，你需要他整理一些文档和图表出来。你可以告诉领导你需要上面的东西，让领导和他沟通，让他在离开之前准备好这些文档给你，并留一些时间以便你熟悉。
不要被浩渺如烟并且陌生怪诞的代码吓得不敢动弹，现在就开始读，立刻，马上，坚持十分钟，再坚持十分钟，你就能妙悟真谛。
最后，当你再碰到这种事儿的时候，请记住老前辈的这句警世良言：
那些不能将你击溃的代码，都将成为你成长的垫脚石。
网友评论