软件代码审计要解决的，不是旧系统“看起来还能不能改”，而是改造启动前必须查清的使用边界。现有代码、数据库和运行资料能否支撑后续改动，改动又会把不兼容风险留在什么位置，构成审计的核心问题。
先核对代码、数据与资料
审计通常从开发语言、框架、源代码完整性和数据库结构入手。需要确认技术栈是什么、源代码是否齐全、数据库结构是否清晰。有源代码，并不等于可以直接修改。缺少数据库说明、部署资料和接口文档时，开发人员仍要重新摸清系统，评估时间会明显增加。文档齐全时，这项工作可能只需几天；没有源代码，或代码与数据库都比较混乱时，周期会明显拉长。
同一轮核对还要看重复代码是否大量存在、第三方接口是否仍然可用，以及原开发团队是否保留了部署资料。重复实现意味着同一规则散落多处，后续改动一个字段，就可能影响多个页面和流程。接口已经不可用，或对方系统没有标准接口，就不能再把旧系统仍可对接当成默认前提。
扩展能力决定审计结论
代码审计的落点，是判断系统还能不能继续扩展。采用模块化设计的系统，新增功能可以落在相对独立的模块里；页面、业务规则和数据库操作混在一起的系统，局部修改很容易扩散，项目周期也更难准确估算。审计应把资料缺口、重复与耦合程度、接口可用性写成可核对的结论，用来决定改造、重构，还是分阶段重建。
审计结论若只停留在笼统的质量评价，对后续选型没有帮助。它需要明确哪些部分可以在现有边界内修改，哪些改动会因资料缺失、重复实现或接口不可用而扩散，以及系统是否还值得继续扩展。开发做到一半才发现原系统无法兼容，通常就是这些判断被跳过的结果。
