很多实施GJB5000的组织，大多都会有这样的现象：由于软件开发在组织的业务中只占很小的比重，软件开发一直得不到重视，留给软件开发的时间总是很短，所以，软件开发人员在编写好代码，完成编译集成，简单验证了正常情况下的功能，就提交软件给系统。至于软件的验证工作，在实施GJB5000之前，是交给了系统联试；在实施GJB5000之后，则是交给了测试人员。
这样做的结果是软件在联试或测试过程中发现大量的Bug，软件开发人员花费大量时间修复这些Bug，软件产品交付节点推迟，以至于影响系统的研发进度。
这种现象合理吗？
软件开发人员当然也不愿意软件出现那么多的Bug，但他们会说：给我的开发时间这么短，我能够实现软件的功能就不错了，哪还有时间去做充分的验证呢？
虽然有这些客观理由，但是软件开发人员把自己根本没有把握，几乎肯定会出问题的软件提交给后续的研发环节，仍然是不负责任的。
1. 谁的产品，质量谁负责
在质量管理体系中，有这样的说法：谁的产品，质量谁负责。
不说软件，就是硬件产品的加工，前面的工序能够不管质量就交给后面的工序吗？这肯定是不被允许的。
软件也是一样道理。
软件产品是软件开发人员编写代码“生产”出来的，那么软件开发人员就要对软件产品的质量负责，软件开发人员不能将带有问题的软件产品传递到下个工序。
为此，软件开发人员就要进行单元测试和集成测试，并且代码和分支的覆盖率应该达到100%。
只有这样，软件开发人员才有提交软件的信心。
2. 研制周期短不是软件开发人员不做验证的借口
也许有很多软件开发人员会觉得撞天屈，我也想做验证，可没有时间啊？
臣妾做不到啊！
但这并不是软件开发人员不做验证的借口。
“开发周期短”，那么你在接这个软件开发任务的时候有没有估算你的开发周期，有没有向领导争取更多的时间或者更多的资源，有没有像敏捷那样先开发那些明确的需求而不是一直等待，有没有采取测试驱动的开发方法？
进一步的，你能不能把单元测试自动化？
开发周期短，不能成为软件开发人员不做软件验证，“躺平”接受提交有问题软件产品的借口。
所以，对自己的软件产品充分验证，不提交有问题的软件产品给下个工序，应当成为软件开发人员的职业素养。
这正是：
谁的产品谁负责，质量不能靠甩锅
开发如能高质量，最终交付会更好
参考书目：代码整洁之道：程序员的职业素养，作者：（美）罗伯特 C. 马丁（Robert C. Martin），出版社：人民邮电出版社
联系客服
