开发阶段真正被管起来的东西

一句话总结

在SI开发阶段实际管理的是标准、形状、进度这三个，而不是代码质量，原因是创建这个系统的人2年后就不在了。

为什么标准先呢？

如果开发者有20个人，就会出现20种风格。每个风格都有自己的合理性，但3年后维护的人必须阅读全部20种风格。SI系统的寿命一般为7~10年，制造者通常在2年内就不在了，所以阅读者的时间比使用者的喜好要贵得多。

所以标准不是为了制作好的代码，而是为了制作可预测的代码。无论打开哪个文件，如果同一位置有相同的东西，即使是第一次看到的模块，30分钟就能修复。

开发标准先来

SI项目的开发第一周不是开始编程，而是开始阅读开发标准定义书。 软件包结构、类命名规则、日志级别使用标准、异常处理方式、共同代码使用法、 查询编写规则（允许动态查询的范围、是否使用提示）写在那里。

理由很简单。如果开发者有20个人，就会出现20种风格，3年后进行维护。 人必须读完这20个。SI系统的寿命一般为7~10年， 制作的人一般在2年内都不见了。

如果是公共事业的话，这里会叠加电子政府标准框架。基于Spring， 提供共同组件（登录、上传文件、公告板、代码管理）。 因为版本和JDK组合在营业公告中明确规定，所以“最新版本最好”是不通的。

形状管理——比起分支，更像“标签和发布笔记”

最近SI也使用Git。但是如果照样使用开源项目式分支策略的话 不太合适。原因是分配单位不是“功能”，而是**“阶数”**。

• 1次开放：会员/订单
• 第二次开放：结算/统计
• 稳定化补丁：每周四晚上

所以实际上重要的是三个。

1. 部署的内容和源代码是否一致—如果不带标签部署，3个月后无法找到要回溯的目标。
2. 谁什么时候为什么改变了什么——这是在提交信息中输入要求ID或缺陷ID的原因。 fix bug这样的提交信息不会给维护负责人任何信息。
3. 运营反映履历—除了源代码履历外，还需要“什么时候发布了什么版本”的大队长。

如果是封闭网络项目的话，外部GitHub不行，所以内部GitLab，甚至更严重的话 文件服务器+zip是形态管理。即使在那种环境下，标签=发布成果快照这样的 只要遵守原则，就能避免最坏的情况。

单位测试 — SI 中这个单词的实际含义

必须准确了解术语。在学校学到的单元测试（JUnit）和作为SI结果的 “单元测试”虽然重叠，但并不相同。

区分	对象	结果	谁
单元测试（UT）	程序/画面1个	单元测试场景·结果书	开发者本人
综合测试（IT）	业务流程、系统间联动	综合测试场景·缺陷管理队长	QA/PL，双方系统
接管测试(UAT)	客户业务场景	接管测试结果书、检查确认书	客户实际工作

SI的单元测试结果表一般是这样的表格。

TC-207 | 주문 조회 - 정상 | 조건: 고객ID=C001, 기간=2026-01~2026-06
       | 기대: 12건 조회, 응답 3초 이내
       | 결과: 12건, 1.8초 | 판정: Pass | 시험일: 2026-08-11 | 시험자: 김영주

重要的是'有多少个例外案例'。只有正常案例的单元测试结果表是 在审查中反对是正确的。至少这个是必须有的。

• 缺少必填值
• 长度超出/类型不一致
• 无权限的用户
• 查询结果0件
• 同时修改（乐观锁冲突）

代码评论和静态分析

大型项目一般在合同中包含质量项目。用静态分析工具（SonarQube等） 设定目标为0个致命缺陷和0个安全漏洞。

新手经常在这里遇到的事情：在截止前不久第一次运行静态分析，结果出现了2000个。 从一开始就要每天轮流。规则是项目开始时团队商量后锁定， 之后，只阻止新出现的违规方式（以新代码为基准）是现实的。

进展率的诚实

用于每周报告的进度率一般是“完成项目数/全部项目数”。 所以，节目目录要准确，进度率才有意义。

还有一个规则：如果没有单元测试结果书，就不是完成。 如果编程都完成了，只剩下测试的话，最后两周所有人员都会 将追溯性地填写测试结果书。那个文件有什么价值呢？ 虽然谁都知道，但没有人说。

在现场相遇的样子

在该阶段，进度报告最容易被扭曲。“80%完成”的报告连续几周停留在80%是典型的迹象。

原因通常是因为没有单元格。如果有项目列表，进度可以算作“全部118个中92个单元格测试通过”这样的可数数字，但如果没有列表，就会平均到各自的体感。而且体感总是停留在90%附近。

形态管理也因为同样的原因而错位。无论如何精心制定分支策略，在部署单位是“次序”的项目中，什么什么时候发布更重要。如果没有标签和发布备注，在发生故障时，没有人能肯定“现在上线的代码是什么时候的”。