公司新员工认为公司的代码很烂，是鼓励他重构还是让他先熟悉业务逻辑？

入职新公司，从重构代码到放弃

这里恰好有个帖子在讨论这个话题 , t/322970

你是看到那个帖子，故意发的吧，哈哈

@XhstormR 是的，我确定和上一个帖子的不在同一家公司，不过我也经常遇到这样的问题。如果鼓励新人重构，我得面对很大的风险，如果坚持要他在熟悉了整个的业务逻辑后再重构（或者说改进），可能会让新人受不了，很难平衡。

首先还是熟悉业务逻辑再重构吧。
之前公司的架构师技术很牛逼，有代码洁癖，经常看见别人代码顺手就重构了。

也发生过数次改完代码之后某些地方跑不起来的事情。
不是黑架构师；他重构的代码多了去了，出错率还是很低的。

我是想说我们的架构师算得上是对业务有一定的理解，并且代码水平很高的人了，他都会重构出问题，新员工又有多大把握？

如果只有这两个选项的话，还是建议先熟悉业务逻辑。至少，先弄明白代码是怎么变烂的。但是对重构的「鼓励」还是要有的，只是别上手就干就行

先写单元测试啊……不写测试怎么重构？你们的重构不会是从头写一个吧

答案是无须理会这种想法，每个新人去一家新公司都会觉得公司代码很烂，那是因为他没被产品虐过。

@feiyuanqiu
@66450146
不理解业务，光凭已有代码写单元测试么。

我觉得我的代码也很烂。

但既然能跑，当然懒得改了。

新需求会使得代码越来越烂，直到受不了开始重构或小范围重构。

必须让他先熟悉业务逻辑！
必须让他先熟悉业务逻辑！
必须让他先熟悉业务逻辑！

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

我觉得可以鼓励，但是要有方案，要能说服团队其他人。不仅仅是说服 leader 。
然后掉坑里了自己爬出来，别指望别人能救你。
其实只要不是大重构，小模块，随便改，改出问题改就是了，又不是不过测试改完直接上线。双赢局面，没必要这么谨慎，搞的大家都不爽。

如果是觉得整个代码都是一坨屎，要全部重构。那可以无视这样的想法，太年轻了而已。

说实话，能觉得模块码烂，还能撸起袖子去改的程序员，真是很难得的一个精神。我身边 90%都是只是嘴上说，绝对不动手干的。下一次下一次下一次，无数的下一次造就了烂代码。
所以原则上应该鼓励，精神难得。不符合现实的情况我想也能说服的。

额 以我这个菜鸟角度来看 必须熟悉业务逻辑 代码烂不烂暂且不谈 至少跑起来了 重构还是等熟悉业务之后再说吧

问他哪个开源项目代码写得好，好在哪里，然后就没有然后了，很多人其实不是觉得代码烂，而是根本搞不懂，也不想看

我也认为应该鼓励重构，作为老员工应该协助把好关，事前提供尽量多的项目背景资料和注意事项，事中对新代码进行检查验证。不过新员工最好还是要好好熟悉业务先，把握好业务才能做好重构这件事情，况且很多业务流程还是不断变化的，谁也不想写一堆烂代码。

你司新员工进公司没有新任务吗？可以悠哉悠哉的重构代码？

架构师是为重构代码而生的吗？仿佛感觉到了深深的恶意？

不熟悉业务，也能重构？

@elgoog1970

我觉得我司代码也很危险，但我不会想重构，太乱了……

刚入职一周，老大授权从小模块开始。。

不熟悉业务的情况下如何重构？

读邹欣老师的《构建之法(现代软件工程)》的时候就看到过老司机是怎么回复的：
这些代码就是我们刚来的时候认为之前的代码太烂然后重构的...

第一次代码不都要走读么

先熟悉业务。
等他熟悉业务逻辑后，他就会发现，如果由他来写，代码会更烂。

看他级别咯，牛逼的可以，毕业没两年的千万别。浪费战斗力。
如果做重构必须要有一个完整的保障系统， UT 、功能测试等，保证重构出来的是对的。

另外 lz 的问题也有点奇怪，不懂公司业务怎么重构？我无法理解

或许等他熟悉了业务代码后，就会发觉自己见识少，这代码写的简直在该场景下香喷喷的呢？ （手动滑稽）

我们公司是家小公司，每年大概也就招两个人，算上离职的，人员虽然不是负增长，也基本接近零增长，所以我们对来的新人都当宝贝一样，尽量避免新人离职。

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

什么是重构，什么不是重构
http://www.vaikan.com/what-refactoring-is-and-what-it-isnt/

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

你要知道新写的代码一年后也会变成 legacy ，也会有人认为很烂。不存在一次重写就没有烂代码了这种事。只有每次碰一段代码都把它改的比以前更好这种缓慢、渐进的方式才是实际可行的。

什么项目？说重构就重构？？

挑一个业务逻辑巨复杂，多表联合查询，多条件判断，继承关系复杂的，居于数据库多级联动菜单什么的，限定让他玩一个星期，然后到期让他交任务，交完之后 review 的时候可以随便开火，保准治好～

@shijingshijing 很可能会吓跑了，公司对新员工要给予多一些理解与支持才好吧？

领导拍板重构一部分功能，但是又时间不足，只能改改然后尽量能用先的我现在心情复杂的看着这贴。。

改了代码就一定要进主干么？完全可以放他先去改呀，改完再评估（要不要采用），正好加深下对系统的了解，多好。

肯定要先熟悉业务啊, 业务都不熟悉怎么重构, 那不是瞎搞吗?
业务逻辑没熟悉之前, 改个 bug 都要几个人 review, 小心翼翼的.

还有一点: 我见过很多的所谓重构, 其实并没有比原来的代码好, 比如很多的重构号称会提高性能, 但是在重构之前却连个性能度量的指标都拿不出来, 就是对着书自己拍脑袋觉得性能提高了, 实际上瓶颈根本不在那个地方.
还有的, 号称要让代码更加优雅, 结果写出来的东西行数是减少了, 可是太过晦涩, 后面的新员工上手更加痛苦, 间接增加了 bug 率, 比如很多人诟病的 if..elif...elif...else 之类, 咋看起来是很傻, 但是代码逻辑简单有的时候就是优点啊啊, 新人一看就知道在干什么, 多的那几行代码根本不叫事.

接楼上, 我并不是反对重构, 而是反对没有证据支持的拍脑袋重构, 这些基本是在做无用功, 重构完毕后 bug 收敛又要很长时间. 现在的有些工程师太浮躁, 动不动就要重构, 就跟很多的团队动不动就要搞一个框架一样. 这大概就是所谓的"面向简历编程"?

说明老员工被倒挂了

大多数新来的都喜欢秀一秀，搞得好还好，搞不好就害死人了然后自己跑路，留下烂摊子害别人

曾经挖了一个哥们过来，一来公司就嚷嚷要把现有的 mvc 项目全部用 webform 重写，没两天就给他制服了

@fenngBig 老员工不会被倒挂，只是小庙留不住大神，老员工离职通常是追寻更好的发展，公司是支持的。

@Midnight 居然有人要把 mvc 换成 webform 的。

让他写单元测试先

https://www.zhihu.com/question/32039226 你读一下这篇吧 我之前读的有些感触，专门为你重新搜出来的，有个员工抱怨和上级的回复，很有意义

鼓励他换工作 也许他写得更烂

鼓励他换工作 如果你是领导，重不重构都应该在你的掌控之中；如果你不是领导，对业务也很熟悉，但早有重构之念，却又怕节外生枝，所以推向别人，又不给予帮助。故，建议他换工作。哈哈哈。

@hst001 来，说出你的故事~

也许他写的更烂+1

虽然经常碰到自己认为写得很烂的代码，但很多时候想改却有心无力，不是从上到下下定决心要重构的话还是慎重点好。

我觉得吧，先熟悉业务逻辑，因为项目不等人，业务熟悉后也能合理重构项目代码

如果他是神级的，鼓励他重构，
否则，还是哈哈哈，先看业务，等他有本事把自己那部分重构过了再说。

个人建议，先熟悉业务啊，一上来就重构绝对是作死。他如果要重构也成，你让他自己先把旧的功能重写一部分，完了再看他要不要。我这种强迫症晚期，经常重构自己框架和项目的人，都没勇气直接重构再跑的项目，都是小心翼翼的自己先做完一部分，测试没问题了，一点点换的。

目测翻页？ 当然是鼓励他熟悉业务的情况下重构？ 不要非得二选一

熟悉业务逻辑 +1

一定是让他先熟悉业务逻辑，没有调查就没有发言权

新员工到岗肯定是想要有机会施展一下自己的技术，来证明自身的实力，要鼓励，有经验的人肯定知道要先熟悉业务再重构。

1.线上的话，稳定第一
2.重构的话，会对团队带来什么后果
3.有没有想过怎么避免后边的代码继续烂下去

不要让入职少于一年的同事重构代码，切记

没有单元测试的重构，无从谈起啊。
再聪明的人也做不到 - 因为代码的复杂都是持续增加的（其实就是 ifelse ），总归是可以到达人类的极限的。
必须要单元测试，并且是从局部开始。

当然要熟悉业务为先。
业务都不熟悉谈重构觉得挺扯淡的。

业务都不熟悉怎么重构?

你要让他重构估计重构出一坨然后自己离职了……

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

程序员都是这样，看不起别人的代码，觉得谁写的都不如自己的。也不想想，谁愿意写垃圾代码？时间紧，任务重，人手不够，给种原因造成的。
重构？我也遇到过类似的新同事，写了一半跑路了。

三年以下工作经验的最喜欢一来公司说代码烂，结果过去一段时间发现他自己也是个烂货

先熟悉业务。。。然后他就放弃重构了。。。

先让他去熟悉业务 然后发配去写测试 覆盖了超过 90%了再谈重构
你猜他会在哪个阶段放弃？

觉得代码烂？我的好多程序员朋友接手别人代码的时候都有这样的感觉（错觉？）。重构什么的 等先熟悉业务逻辑以后再谈重构吧。

有些东西在重构的时候，一堆 bug

至今有些愧疚，在第一家公司重做一个由 dede 写的产品，做了差不多半年还没做出个样子，然后自己辞职了。

只允许小规模重构，比如修改命名，添加注释，提取变量之类的，而不允许更改业务逻辑。如果要更改业务逻辑，必须先写单元测试。

这个事还是挺有感触的。

校招拿了公司 offer ，提前进来实习。由于在拿到 offer 之前已经有了较为正式的实习经历（一家很有潜力股的创业公司，写代码的人几乎都是从 BAT 出来的），代码质量非常好，跟着老大学了很多。如果不是地域原因，我都考虑留那里了。回到正文，来到公司以后，也是对项目写的代码不尽如人意，所以感到不满，对 Mentor 提出重构某个大模块。在大部分团队成员不太赞成的情况下，我还是自己拉分支干了起来，一边熟悉业务流程，一边重构代码。重构完成后，由 Mentor 和该模块以前的负责人一起 review 代码，尽管在测试最后阶段发现了一个由于之前的烂代码而没有留意到的坑，后来填补以后跟着日常版本上线了。

回想起这段经历，我觉得可能是每个新人刚来到公司都想做的事情，冲动可以理解，关键还是看是否能把逻辑理清，把旧代码熟悉以后再去考虑重构。

我看电影或者拳击赛认为他们都是花架子，一点也不凶悍。然后我去健身房，举不起 20 公斤的哑铃。

先熟悉业务和旧代码,否则就是一点职业精神都没有
公司请你来不是搞出问题来的,是搞定问题

我都想改现有项目的架构了，但是一个是没时间，一个是担心别人不服…… 虽然我就是架构

@tension2012 说的在理，特别是有业务发展掺杂进来历史演变，烂其实是有“原因”的。

开个分支让他试试呗，能有什么风险？

@zhouzm 浪费人力啊，公司花钱又不是让他学习的，重构上面折腾花费的时间用来替老员工复制粘贴，打杂可以帮老员工省不少事呢，这样能加快现有项目进度啊。。。

@cc7756789 23333 那岂不是还做不成花架子

如果现在的代码运行很好，不需要在此基础上加功能，建议不重构。
如果需要加功能，而且拓展性不好，拆东墙补西墙的赶紧重构吧，不过新人的话，还是先熟悉代码吧～～

建议先熟悉业务逻辑 /代码习惯，其他的晚点再说吧。

你的代码写的很烂
http://www.vaikan.com/your-code-sucks/

@shijingshijing 可是楼主更担心的是怕打击新员工积极性，导致留不住人啊。

刚到一家新公司到处喊 low 的一看就是新兵蛋子，
最近公司刚来了个新兵蛋子，刚到公司第一天就到处喊 low ，结果观察了几天更 low ，
一家公司的技术 low 是有原因的，比如一个人顶几个人的工作量等等，能够实现跑稳已经很好了。

让他感受一下业务逻辑，再跟他撕逼一下（测试下他水平

(他的水平==low)?'新兵蛋子装逼正常- -':'让他重构代码';

别重构 , 还没重构完就跑了 ..

我老板一直是鼓励我重构的，不过是想重构哪，先把测试补全了再重构。

只想问问，稍微有点历史的项目，哪家没有“烂代码”？

而稍微成功点的项目，哪个是没有点“历史”的？

很多“烂代码”，是由于历史造成的。换句话说，这个代码，当年就是好代码，当年整个社区就是这种 style 。

也是因为这种 style ，造成了问题，社区积极改进，有了今天的新的规范。

而一般来讲，没有太多经验的新人，拿着今天改进过的规范，吐槽前人的“烂”。。。

其实。。再过 2 年，今天的“好代码”，又会被吐槽烂，历史一直回重复。

觉得解决这个问题，主要还是看 leader 。不过稳定运行的模块，千万要慎重，烂比挂好。。。

先好好熟悉业务再说，很多代码“烂”确实是各种稀奇古怪的需求造成的。
好比我之前公司，有的代码活了 10 几年了，但没人敢真正的说去重构它。
风险远大于收益。