重构老项目，团队里多是新人，对业务不了解，有什么好的方式？

先开一些前期的沟通培训会议，把项目做什么的，从系统层面上介绍一下，再从模块层面介绍一下各个模块的输入输出。沟通的细节就到专业的词汇讲解吧。让新人对于项目有整体上的认识是非常重要的。另外项目当中肯定也有一些坑还留着，也要挖掘出来。
code review 是重构老项目必须做的，有一种误区是感觉写代码的时间算工作时间，review 时间就是浪费了。如果没有好好 review 代码，再加上你是重构，后期出问题加上加班维护，反而得不偿失。
新项目可以把单元测试覆盖率正好上马，一开始可以从项目中的重点模块开始，覆盖率的要求也不要定的太高，一步一步慢慢来。

补充：code review 一开始可以大家一起参加几次，这样有助于形成比较固定的代码风格。后期就是模块的 developer 和 onwer 结对进行 review ，这样也兼顾了效率。

我个人觉得 code review 对增加业务逻辑的理解效率极低，建议是产品经理首先对项目全貌做一下概括介绍，然后一个个模块分批迭代，例如你们决定先重写订单模块，就先充分了解订单需求和对应数据库结构（没必要看老代码），团队设计好代码架构，单独开发订单服务，然后在老项目中把订单接口从本地运行改为转发请求到新服务，直到所有服务迭代完毕

能跑就不要动..

更何况没有单元测试,没有集成测试,重构只是自找苦吃.

最快的方法是整出一份项目使用说明书，比如电商平台的商品上架流程，新人自己作为用户操作过一遍就大概知道哪些功能模块是干什么的，针对操作过的模块进行修改

先用 1-2 周的时间熟悉业务，不搞开发。老人讲业务逻辑、数据逻辑，新人边学边讲，每个人都要讲，都要评价。

公室政治？盲猜空降了洗了一波人

@standchan 好细节，感谢。
@wangritian 开发兼顾 pm 的角色，目前还没有对业务形成自己的理解
@chenqh 有自动化测试，单元测试也有但是不强制

@cvbnt 电商比较常见，我们这个领域比较专业
@huage 你们是这样实践的吗？感觉还挺少见的，最后都变成走形式，哈哈

重写

自顶向下说说为什么要这样组织代码，每个模块核心职责是啥。 然后有针对性去对一个模块有更深入的了解。 单纯的 codereview 可以简单的看成是自底向上，在没有 context 的情况下对为什么要这么写，写得好不好很多时候很难去评判的。

全部裁了，把老人招回来。

@anerevol 是的，感觉也需要这样的一套方法或者方法论，code reivew 的话也有局限性。

codeview 是一种方法，但是对于新人来说，有点慢，也不易理解，
1. 可以先让熟悉项目的人或架构讲解下项目的整体流程，各个模块之间关系，画出关系图，先有个整体了解和印象，在解释下一些专业词汇
2. 代码细节流程的话，那就要问负责这块的老开发和产品，其实最重要是曾经遇到哪些坑，咋避坑
3. 最快其实是上手写代码，当然从简单模块开始，这个时候可以一起 codeview ，给配个导师 。看你这应该没有培训新人的项目
4. 最后就是测试，单元测试，集成测试等
暂时想到这些

解决屎山的方法只有，抛掉一块删掉做一下微服务。

老项目重构的时候 顺便补一下 设计文档啊 ，测试用例啊啥的 也是挺好的

@starlion 现在就是老的开发忙于做分派给自己的一些 story ，具体他做了啥不是特别清楚。另一方面整个架构之前讲过了，但时间太久有些忘了，需要再看一下，专业词汇没人讲，都是自己一个个查字典，知识库，自己体会。
@DeWjjj 实际我们是重写。
@akira 是的呢，good idea ，我们老的项目有很多测试用例，但是不一定适合新的项目

我最近也在思考这个问题，我的结论是有工具能够把项目，把前前后后参与的人，前因后果能够非常方便、高效、不额外浪费大量精力地记录下来。
我已经有模糊的想法，感觉可以形成一个强有力的产品，不过可能帮不上你这次的忙。有兴趣的朋友可以一起讨论。

你这次的话，我个人建议是先梳理需求。然后按照需求，大概的进行 code review ，颗粒度到文件、方法名、API 即可。

防御式编程

@chenqh #4 重构就有 OKR 了，晋升/跳槽利器

做下依赖升级，在运行个几年。除非换框架语言，新人重构感觉也不一定写的更好