自动备份恢复框架开发小结


开发这个框架的过程有比较明显的值得推荐的过程。

流水账

开始开发的时候在设计实体类重构了很多次,推翻了很多次,这里是最浪费时间的。

业务逻辑还好的编写没有什么问题,但是最大的问题出现在了需求分析部分。

由于对需求不太明确,导致了开发中不断增加额外的功能,几乎是框架崩溃了。后来昨天经过了详细的思考,确定了框架和应用的区别,把

数据库恢复的多样性放在了外部、把备份存档的多样性也放在了外部。

就是说,备份框架不考虑存档问题,仅备份,之后的问题交给了外部。

恢复的时候,也不考虑如何获取备份文件,仅提供计划,由外部满足恢复要求。

经过了需求的再造,终于问题明朗,开发也就完成了。

开发总结:

1. 需求分析非常重要,一定要明确功能模块的职责:单一!

2. 实体类设计非常重要,要反复推敲,一旦出现问题,会导致整个系统所有代码的重构,非常严重。

3. 开发过程中竟然没有使用一点的测试,一气呵成,测试留在了最后。(有好有不好) 

4. 开发测试部分书写了完善的测试文档,对功能模块单独测试、再集成测试,这样测试过程非常的顺利,有bug,但是都是小问题,很快的解决,不存在业务逻辑的bug。

精华

1. 开发过程就应该对业务逻辑有明确的分工,从底层到高层、从简单到复杂,这样编写测试文档就非常方便。 

2.  编写完善的测试文档,非常的重要! 

原文地址:https://www.cnblogs.com/zc22/p/1629995.html