重构代码太烂,要不要辞职?

原创 年树先生 随笔 前端面试 4641阅读 2018-10-20 21:05:24 举报

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

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

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

到底要不要重构?

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

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

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

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

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

我到底要不要离职???

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

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

我们每个人都在进步,别说别人了,你现在看你三个月之前的代码,可能你都会觉得写的很垃圾,如果你没有这种感觉,只能说你在止步不前。(欢迎加入全栈开发交流圈子,群号:864305860)。

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

从该死的烂代码中爬出来 !

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

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

负责交接代码给你的那位同事,要么在办离职,要么已经介入了其他产品,眼下很可能已无心恋战,但你心里要清楚,只有他才能提供代码层面的东西,比如类图、模块划分说明、数据流图、时序图、状态图等等。

所以,你需要他整理一些文档和图表出来。你可以告诉领导你需要上面的东西,让领导和他沟通,让他在离开之前准备好这些文档给你,并留一些时间以便你熟悉。

不要被浩渺如烟并且陌生怪诞的代码吓得不敢动弹,现在就开始读,立刻,马上,坚持十分钟,再坚持十分钟,你就能妙悟真谛。

最后,当你再碰到这种事儿的时候,请记住老前辈的这句警世良言:

那些不能将你击溃的代码,都将成为你成长的垫脚石。

评论 ( 0 )
最新评论
暂无评论

赶紧努力消灭 0 回复