团队代码评审时「团队类型规范」该重点看什么？：老项目迁移中的问题清单与建议
团队在进行老项目迁移时，面对存量代码量大、历史包袱重的情况，通常应该优先关注哪些高风险点，才能避免迁移后出现更多隐患？
迁移前应优先识别高风险代码与结构问题
迁移老项目时，重点应放在高耦合模块、重复代码、隐式依赖、过深的调用链、难以测试的逻辑以及历史遗留的临时处理上。这些部分最容易在迁移过程中放大问题。代码评审中可以重点确认模块边界是否清晰、命名是否统一、异常处理是否一致、配置是否外置、重复实现是否有合并空间。对于长期无人维护的代码，建议结合日志、埋点和线上告警信息，判断是否存在潜在故障风险，再决定是否立即重构或分阶段改造。
如果项目只是把代码格式统一一下，似乎就能减少很多问题，那为什么在老项目迁移中还要特别强调团队类型规范，甚至把它放在代码评审重点里？
团队类型规范决定了协作方式和长期可维护性
代码风格只影响表面一致性，团队类型规范关注的是更深层的协作规则，比如模块职责划分、接口边界、数据结构约定、异常处理方式、命名标准、目录组织方式和测试要求。老项目迁移时，如果这些规范不统一，不同开发者会沿用各自习惯，导致同类问题不断重复，后续修改也更容易引发连锁影响。评审时应确认代码是否符合团队约定，是否能被其他成员快速理解和接手，是否方便扩展和回滚。这样做的目标不是追求形式统一，而是降低沟通成本和维护成本。
迁移老项目时，很多历史代码看起来都不够理想，但资源有限，不可能全部改造。评审时应该依据什么标准来判断哪些部分值得立即重构，哪些可以暂时沿用？
以业务风险、变更频率和维护成本作为判断标准
是否重构应结合业务影响、变更频率、故障概率和维护成本综合判断。对于核心链路、经常修改、经常出问题或难以测试的代码，建议优先重构，因为这些区域的收益更高。对于稳定运行、短期内不再改动、风险可控的代码，可以先保留，只做必要的规范化处理。代码评审时还可以检查该模块是否存在可替代实现、是否能通过适配层隔离旧逻辑、是否适合拆分为更小的组件。迁移不是一次性清空历史，而是按风险分层处理，让改造节奏与业务目标保持一致。