平台选型
接手别人做的系统二开为什么风险高？什么时候应该重做？
二开风险大主要来自四件事：文档缺失、测试缺失、规范混乱、责任边界不清。新团队接手要先花时间"考古"原代码，但出了问题原作者不在了又找不到人，风险一边在加一边在转嫁。当原系统架构跟不上、文档严重缺失、改动量超过 60% 的时候，重做通常比二开更快、更稳。
为什么二开风险特别高
- 文档质量决定一切：原团队留下的注释、接口文档、部署文档，往往只够原团队自己看懂。新团队接手前两个月主要在"读代码读历史"
- 没有测试覆盖：改一处不知道影响哪里。每改一个功能都要从头测一遍整个系统
- 代码规范不统一：可能是几代不同的人写的，命名、目录、风格混乱
- 历史包袱：很多"看起来没用"的代码可能是早期某个客户特殊需求留下的，删了就出问题
- 第三方依赖老旧：用到的开源库、SDK 版本停在几年前，升级会牵动一片
- 数据库设计有历史债：表结构、字段含义不一定符合现在的业务，但不能随便改
- 责任难界定：新出问题，是原代码就有的 Bug 还是二开引入的？扯不清
什么情况下二开是合适的
- 系统架构相对现代（近 2–3 年的主流框架）
- 原团队留下了基础文档和清晰的代码结构
- 改动范围明确，主要是新增功能而非改造老逻辑
- 改动量在 30%–50% 以内
- 原数据库结构基本合理，不需要大改
什么情况下应该重做
- 系统超过 5 年、技术栈已经停止维护
- 文档严重缺失，关键逻辑全靠"猜"
- 业务模型已经变化，需要重构核心数据结构
- 改动量超过 60%，相当于把原代码逐行拆掉重写
- 性能架构跟不上，本地化部署单机扛不住
- 安全性问题严重，原代码有明显的注入风险、明文密码、过期协议
怎么评估
我们接手二开类项目时，前期会做一份"代码 + 业务双向尽调"：
- 跑通原系统，确认能在新环境运行
- 通读核心模块代码，估算可读性和复杂度
- 对齐客户的目标改动清单
- 评估改动是"插点逻辑"还是"动地基"
- 给出三个选项：纯二开、重做核心 + 保留外围、完整重做
通常这份尽调要 1–2 周，但能避免后期"做着做着发现没法做"的尴尬。
我们做过的 智慧赋能-工厂管理数字化 项目里，客户原有一套老 MES，本来想二开。我们尽调后发现原系统是十多年前的技术栈，表结构和现在业务对不上，建议重做。客户接受后只用了原系统一半的预算就上了新系统，跑得也比之前稳得多。
简单说，二开不是绝对不能做，但要"先看清楚再下手"，不能凭"先接手再说"的心态。