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