从问题闭环到测试驱动开发

前日，找领导签字，确定一事项。

主要为某规范的替换更改流程；

周五打电话给领导，说明因为 对归档日期有要求， 需要将归档日期提前，

所以系统正规流程因为时间和序列号绑定，无法操作，因此需要特事特办，出一个内部流程；

然后与之说明情况后，答曰他不在公司，委托找副总；

然后下班了。

于是，第二天，他又出差回来了。

派人带过去材料，他说不能正常归档原因那块言不达意，他看不懂。

然后又派回来。此人来电问我该规范如何修改。

然后又与领导联系，逐字确认原因，修改为 需要提前归档日期。

然后修改文件，然后签字完成。

1.这个事情除了事先料想不周之外，另外一个重要原因是闭环没有完全落实下来。

2.即使有闭环的思路，但重点位置没有逐字逐句和领导实现沟通，达成共识。

3.第三个是异地找人代理操作，这一点更需要注意，领导疑问对方可能并不知如何解释，所以实现沟通好免除此人后顾之忧是非常之有必要的。

4.领导的想法和我们有差别，比较小心谨慎，保证每一个点他都明确，方可签字任责，理解万岁。

从此来看ATDD即测试驱动开发，是一种闭环的思路，以明确的输入和预期输出来判断程序的完整性。

能够以测试驱动开发执行完一个工程的话，恐怕代码质量和设计水平是会有本质飞跃的。

可见设计思路，开发流程的规范性、完整性还是能从结构化的、工程化的角度上来保证软件产品质量的。