定位报错、异常数据、接口失败、权限问题、页面逻辑错误与线上偶发问题。
SECONDARY DEVELOPMENT / MAINTENANCE
已有系统继续做，
不必从零重来。
接手已有软件项目，处理BUG修复、功能新增、接口调整、性能优化、系统升级与长期维护。先判断现有代码还能不能安全继续，再决定最合适的改造方式。
源码评估问题定位功能新增安全上线持续维护
01 / WHAT WE TAKE OVER
不是只有“大改版”才叫二次开发。
从一个线上BUG，到一个新业务模块，再到旧系统逐步升级，都可以按实际范围评估。
在已有系统中增加业务模块、字段、流程、报表、权限、审批或后台能力。
对接或替换支付、短信、微信生态、第三方平台、ERP、CRM及内部API。
处理慢查询、高并发瓶颈、接口响应慢、缓存策略和资源占用问题。
逐步升级框架、依赖、数据库、中间件和部署方式，降低长期维护风险。
持续处理线上问题、日常迭代、服务器部署、版本发布与运行保障。
接手旧项目，先评估，再动代码。
了解源码、技术栈、数据库、服务器、账号、第三方接口和当前问题。
尽可能建立开发或测试环境，确认项目可以编译、启动、连接数据库并复现问题。
确认耦合、依赖版本、历史BUG和数据变更风险，再拆分开发范围。
把需求拆成可测试、可验收的小版本，减少一次性改动过大带来的风险。
准备备份、发布和回滚方案，上线后持续观察并处理真实使用反馈。
02 / PROJECT TYPES
这些已有项目都可以先评估。
项目是不是我们原来开发的并不重要，关键是现有资产是否完整、风险是否可控。
常见项目类型
Java / Spring Boot 管理系统企业内部业务平台CRM / 订单 / 审批系统微信小程序与管理后台Web应用与API服务服务器与部署环境维护
常见技术环境
JavaSpring BootMySQLVue / ReactREST APIRedisDockerLinux
03 / BEFORE WE START
能提供这些资料，评估会更快。
资料不完整也可以聊，但越接近真实运行环境，越容易判断工作量和潜在风险。
项目源码、分支情况、构建说明，以及是否拥有合法使用和修改权限。
数据库类型、表结构、数据量级、备份方式，以及是否存在历史数据问题。
服务器系统、运行方式、域名、证书、反向代理、容器和发布流程。
哪些BUG必须先修、哪些功能要新增、哪些问题只是“偶尔出现”。
支付、短信、微信、OSS、地图、邮件及其他接口平台的账号与密钥管理情况。
明确什么必须先做、什么可以后做，以及每个阶段怎样算验收完成。
04 / DECISION
继续改、局部重构，还是重新做？
不是看到老代码就建议重做。更合理的是先判断业务价值和维护风险。
系统运行稳定、技术栈还能维护、只是增加功能时，优先在现有基础上继续开发。
系统能用但局部难维护时，保留正常业务，逐步替换高风险模块。
某些模块结构失控、性能严重不足或依赖不可维护时，只重做问题最集中的部分。
源码缺失、核心依赖无法运行或系统与当前业务完全不匹配时，再认真评估重新开发。
05 / FAQ
软件二次开发常见问题。
如果你的系统情况比较复杂，可以直接把技术栈、现状和希望修改的内容发过来。
不是中羽科技开发的系统也能接手吗？
可以。通常会先评估源码、数据库、服务器、第三方接口和部署环境，再确定适合继续迭代、局部重构还是重新实现部分模块。
可以只修一个BUG或增加一个小功能吗？
可以。BUG修复、功能新增、接口调整和页面优化都可以单独评估，不要求必须重做整套系统。
Java老项目还能继续二次开发吗？
多数情况下可以，但需要确认JDK、Spring或Spring Boot、数据库、中间件、依赖版本和部署环境是否仍可维护。
没有测试环境怎么办？
会优先评估是否能建立独立开发或测试环境。直接在线上修改风险较高，重要改动应尽量先在可回滚的环境中验证。
二次开发为什么通常要先评估源码？
同一个功能在不同代码结构里的工作量可能差异很大。历史BUG、耦合程度、数据库结构和第三方接口都会影响实际成本和风险。
06 / RELATED
继续了解已有系统接手。
如果你正在准备把项目交给新的开发团队，这两部分内容最有用。
手里有一套旧系统？
先判断它还能不能继续改。
把技术栈、当前问题和想增加的功能发过来，不需要先整理成完整需求文档。