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

[vultr]

[chiu]

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

[Grubber]

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

[sagaxu]

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

[jerryshao]

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

[murmur]

第一次代码不都要走读么

[lhbc]

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

[loryyang]

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

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

[ThinkCat]

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

[vultr]

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

[powergx]

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

[poke707]

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

[afxcn]

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

[lightening]

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

[veelog]

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

[shijingshijing]

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

[watsy0007]

https://www.v2ex.com/t/322970#reply0

[afxcn]

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

[wjh3936]

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

[jybox]

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

[eyp82]

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

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