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

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

 

流水账

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

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

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

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

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

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

 

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

 

开发总结：

1. 需求分析非常重要，一定要明确功能模块的职责：单一！

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

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

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

 

精华

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

2.  编写完善的测试文档，非常的重要！