工程与质量保障

为什么单独讲这件事

功能能不能做出来，客户在演示时看得见；但系统能不能长期稳定运行、换个人能不能接手维护， 在交付那一刻是看不出来的。这部分工作的价值要在半年、一年之后才体现—— 而它恰恰是决定软件"能不能用得住"的关键。

以下是我们在每个项目中都会执行的动作。

一、需求分析与技术设计

先把业务流程和数据模型理清楚再写代码。这一步省略了，后面所有工作都会加倍返工。

• 梳理业务流程、角色权限、数据字段与状态流转，输出需求确认文档；
• 确定数据模型与接口约定，明确字段含义、数据来源与更新频率；
• 输出可评审的技术方案，说明架构选择、技术选型理由与工作量评估；
• 识别风险点（第三方接口稳定性、数据迁移、性能瓶颈）并提前给出应对方案。

二、代码规范与代码评审

统一的代码风格与目录结构约定，关键变更走代码评审。

• 统一命名规范、分层结构与错误处理方式，避免同一种问题在项目里出现五种写法；
• 关键模块（鉴权、支付、数据计算、并发处理）的变更必须经过评审；
• 评审关注点包括：边界条件处理、异常分支、并发安全、SQL 查询效率、日志可读性；
• 评审意见记录在案，便于追溯设计决策的原因。

这一步的目的不是流程好看，而是保证换人接手时仍然读得懂代码。

三、测试与质量验证

• 接口测试——覆盖正常流程与异常分支，包括参数缺失、越权访问、重复提交、并发冲突；
• 界面功能测试——按角色与权限逐项验证，覆盖空状态、加载态、错误提示；
• 端到端回归——核心业务流程（如下单、审核、结算）在上线前跑完整链路；
• 真机验证——涉及移动端与小程序的项目，在真实设备上验证，不只看模拟器；
• 兼容性检查——主流浏览器与主流机型的基础兼容验证。

四、持续集成与标准化部署

• 标准化的构建、打包与发布流程，减少人工操作步骤；
• 环境配置项集中管理并与代码分离，避免出现「只能在本机运行」的系统；
• 静态资源与配置文件的版本管理，支持快速回滚；
• 生产环境部署前后做核对，确保线上版本与预期版本一致。

五、安全与权限设计

这类工作没做好，往往是出了事才知道。我们在设计阶段就把它作为约束条件纳入。

• 接口鉴权——所有业务接口默认需要鉴权，公开接口显式声明白名单并说明理由；
• 数据权限隔离——不只是「能不能进这个页面」，而是「能不能看到这条数据」，按组织、角色与归属关系逐层过滤；
• 敏感信息保护——密码加盐哈希存储、敏感字段加密、日志中不打印完整凭证；
• 操作留痕——关键操作（增删改、导出、权限变更）记录操作人、时间与内容；
• 最小权限原则——默认不授权，按需分配，及时回收。

六、性能与稳定性治理

• 慢查询治理——识别并优化全表扫描、缺失索引、N+1 查询；
• 缓存策略——明确缓存范围、过期时间与失效时机，避免缓存与主库数据不一致；
• 连接池配置——按实际并发量合理设置，避免连接耗尽导致服务整体不可用；
• 并发压测——对核心接口做压力测试，关注的是高峰期能不能扛住，而不只是平时跑得快；
• 异常监控——关键接口的错误率与响应时间异常时能及时发现，而不是等用户投诉。

七、文档与知识转移

交付时一并提供，而不是事后补：

• 部署文档——环境要求、部署步骤、配置项说明、常见问题处理；
• 接口说明——接口清单、参数、返回值、错误码与鉴权方式；
• 数据字典——表结构、字段含义与关联关系；
• 运维手册——日常巡检项、日志位置、备份策略、故障排查路径；
• 代码说明——关键模块的设计思路说明。

目标是让客户团队具备自主维护和后续扩展的能力，而不是形成"必须找原厂"的依赖。

八、上线后运维与迭代

上线是项目的中点，不是终点。

• 持续跟踪运行状态与用户反馈，处理故障与优化需求；
• 按实际使用数据调整功能，而不是按最初的假设一路做下去；
• 积累运行数据形成下一轮迭代计划，让系统随业务一起演进。

相关页面

• 交付流程——这些工程实践落在流程的哪个阶段
• 技术能力——支撑这些保障措施的技术基础
• 软件研发服务——软件交付的范围与周期