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

[vultr]

[lbp0200]

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

[Ouyangan]

这里恰好有个帖子在讨论这个话题 , https://www.v2ex.com/t/322970

[XhstormR]

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

[vultr]

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

[just4test]

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

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

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

[SilentDepth]

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

[feiyuanqiu]

@just4test 理论上重构的第一步是写单元测试，保证重构后和重构前程序运行结果一致
如果一上来直接就开始改代码，那当然容易出问题

[66450146]

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

[hst001]

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

[just4test]

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

[jarlyyn]

我觉得我的代码也很烂。

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

[gamexg]

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

[angelface]

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

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

[sampeng]

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

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

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

[yoke123]

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

[tension2012]

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

[afxcn]

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

[wyntergreg]

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

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

[qwer1234asdf]

不熟悉业务，也能重构？

[michaelzhou]

@elgoog1970