首先要考虑的是接不接老项目。有时候会有选项，老项目还是新项目。

老项目会有一些商业价值，但可能是一个烂摊子，会背锅，主要精力放在架构上，以一个旁观者的身份，平常心看待烂代码，划分业务模块，做一些封装处理。

清理没有调用的接口、代码，保持业务代码干净。清理接口会有一些风险，可以让前端全局搜索是否有调用。

看看数据库表关联关系设计是否正确，一对一、一对多、多对多，相对核心的业务，可以做一些重构。看业务模块涉及到的表结构，再看看产品界面，基本能理解业务，避免陷入过多代码细节。

清理依赖的第三方服务。比如，之前直播用的目睹，数据库表，代码很多用的都是目睹id，后面用了阿里云直播，目睹id就可以用频道表id替代。同时接口返回也用频道表id替代，范围比较大，减少前端修改。

没有再用到的表加_del后缀。可以写代码检测，找出后人工检查一遍，算是清理数据库表。

业务内部拆分。比如，用户上传的视频作业跟内部人员上传的课程章节视频在后台管理系统，会有不同的搜索过滤。再举个栗子，课程作业只需要显示最新的那一份，定义为重新提交作业，上传了新的，老的就可以标记为删除。俱乐部却不同，需要显示用户上传过的所有作业。

接口拆分，保持接口功能单一。不同业务用不同接口，如果用同一个接口，业务变化时，会有各种判断，返回给前端的字段变化，慢慢变得越来越混乱。

了解数据规模。比如，老师工作台课程列表，分为有待办任务和没有待办任务。根据业务情况，每天18点都会有服务号推送给课程老师，还有多少未点评的作业，正常情况下，在一段时间内，各位老师都会清理待办任务。那有待办任务的列表就会比较少，接口就可以一次性返回。没有待办任务的列表随着时间积累慢慢变多，因为课程变多，接口就需要分页。

修改比较别扭的部分。比如，提交作业的用户id保存在in_channel_id，in_channel_id的命名由来是之前用了目睹直播，目睹id在数据保存在channel_id，被认为是外部频道id，in_channel_id就作为内部频道id，表又是多块业务公用，偷个懒就找个字段插了，用type字段区分。每次用到都感觉很奇怪，还不如再加一列customer_id，做数据订正，对应代码也做调整。

找之前负责这块业务的人聊聊，可能能有一些有用的信息。或者对比类似业务怎么写的，借鉴。

产品提的新需求、测试提的bug，发现之前的有一些问题，顺便重构，其他的可以先不动，优化无止境。多少人，多少代码量，大体上决定了最后能改成什么样，量力而行。

新项目就是重新开始，避免之前犯的错误，表结构设计好，否则后面改动代价会比较大。接口分离，封装的函数尽量小一些，减少兼容，便于后期维护。可以找一些架构方面的书看看，实践。

不管接的是新项目，还是老项目，都需要多用，多思考。